Removes uid-owner restriction from apt iptables rules #3978
Conversation
conorsch
force-pushed
the
3952-allow-apt-user-in-iptables-for-xenial
branch
from
2b2a3f0
to
e39249c
Compare
| # Find already configured apt allow line, targeting root uid, and | ||
| # subsitute entire line, dropping the uid targeting entirely, | ||
| # so both Trusty and Xenial continue to work well when invoking apt. | ||
| perl -npi -e \ |
Good flag, let's dig into that. What commands did you use to test? For example, |
Ah, now I can see that |
|
|
Pushed up another change here, attempting to resolve the DNS behavior post-upgrade. @kushaldas take this change for a spin and let me know how it treats you? |
|
@conorsch The latest push works. Though it helped to find a different problem, we do need a FPF tor-apt for xenial ready. |
|
Performed functional testing based on the test plan as follows: Trusty -> Xenial (i.e. Trusty clean install)I have tested the 'clean' install under Trusty, then doing an interactive upgrade to Xenial. The changes here seem to work as expected, both in Trusty and Xenial: apt traffic goes through the firewall, all tests pass. Xenial clean installThe provisioning process in xenial from a clean install works as expected, apt traffic can go through the firewall, all test pass. Trusty -> Trusty (this branch) -> XenialApt traffic goes through the firewall. |
There was a problem hiding this comment.
Given passwordless sudo, I think this a reasonable stopgap to ensure smooth migration to Xenial: having uid-owner set to root during the upgrade will break the upgrade process. Default action for OUTPUT chain appears to be DROP, not LOGNDROP as stated in commit message.
We should strongly consider revisiting these rules (e.g. set -m owner --uid-owner _apt) after we migrate to Xenial, since we also lock down iptables rules per user for tor, ntp and ssh (perhaps as part of the upgrade playbook?)
I'll let @kushaldas complete his review, to ensure this PR gets the careful review it needs, and resolve postinst conflicts, otherwise 👍 from me
Under Trusty, apt calls run as the root user. Under Xenial, however, apt calls run as the `_apt` user. We must ensure that the firewall rules permit apt updates on both systems, before and after the upgrade from Trusty to Xenial. We cannot add references to `_apt` under Trusty, since the user doesn't exist in the passwd file, causing the iptables-restore action to fail. Let's simply remove the uid-owner restriction on the apt-specific iptables rule. By this point in the iptables logic, non-whitelisted traffic from both the `debian-tor` and `www-data` users hsa been dropped (via jump to the LOGNDROP chain). As such, it's fine to loosen the specificity of the iptables rules somewhat, in order to ensure a smooth transition.
Simply removing the apt-specific user-based whitelisting was insufficient to unbreak DNS after a Trusty to Xenial upgrade. Also removing the restrictions on DNS resolution to allow e.g. `apt update` to function.
conorsch
force-pushed
the
3952-allow-apt-user-in-iptables-for-xenial
branch
from
48be673
to
b5e9756
Compare
|
Rebased on latest develop (66e3607) to resolve conflicts. @kushaldas , please review and let me know if you find any problems. |
|
Thanks for re-review, @kushaldas! |
Status
Ready for review.
Description of Changes
Fixes #3952.
Under Trusty, apt calls run as the root user. Under Xenial, however, apt
calls run as the
_aptuser. We must ensure that the firewall rulespermit apt updates on both systems, before and after the upgrade from
Trusty to Xenial. We cannot add references to
_aptunder Trusty, sincethe user doesn't exist in the passwd file, causing the iptables-restore
action to fail.
Let's simply remove the uid-owner restriction on the apt-specific
iptables rule. By this point in the iptables logic, non-whitelisted traffic
from both the
debian-torandwww-datausers hsa been dropped (viajump to the LOGNDROP chain). As such, it's fine to loosen the
specificity of the iptables rules somewhat, in order to ensure a smooth
transition.
Testing
We need to cover a few different scenarios here for full coverage:
In all cases, the following should be true:
sudo apt updateworks on both hostsNote that
sudo host apt.freedom.presscan still pass whereassudo apt updatewould be broken, so it's important to use the apt-update command during testing.I haven't tested all these scenarios yet myself, but opening PR to invite more feedback and increase the changes we find something to fix early.
Deployment
Yes, we must make sure this change lands in prod prior to the Xenial upgrade, otherwise we run the risk of breaking future automatic updates.
Checklist
If you made changes to the server application code:
make ci-lint) and tests (make -C securedrop test) pass in the development containerIf you made changes to
securedrop-admin:make -C admin test) pass in the admin development containerIf you made changes to the system configuration:
If you made non-trivial code changes:
If you made changes to documentation:
make docs-lint) passed locally