We’d also need to remove CAP_CHOWN so they can’t just do chown root -R /home
and access the home directories.
Quite a lot new profiles to review and test. Thanks!
Due to the high the risk of regressions, I’ll set to apparmor complain mode for a few days or weeks (firewall, sdwdate)? That would simplify testing a lot. Then things could move to testers repository a lot faster which has been blocked from updating due to a lot recent hardening (mount options…).
Once all missing permissions are added these can be set to default (enforce mode).
This might generally be a good apparmor strategy. Confine new things in complain mode, mass deploy (stable repository) and then gather user reports.
If /dev/pts action is needed, also these other consoles /dev/tty and the Qubes specific one are required? Existing or new abstraction perhaps?
That sounds like a good idea. I’ve tested all the new profiles and they work fine for me so there probably won’t be too many missing permissions.
I don’t think so. pts is the only one I got errors about.
A consoles abstraction already exists.
Surely.
Users could install other init systems too and thereby break things? Is our approach of blacklisting things in /etc efficient? I think there are more malicious config options than we can image / research.
Not aae but VirusForget. Did you know $HOME/.pam_environment
? Not popular but can be abused depending on threat model. Just an example.
What “legitimate” changes in /etc root should be able to do? Perhaps better restrict /etc/** or /** and then whitelist opt-in?
Other init systems aren’t supported anyway. The profile only confines /lib/systemd/systemd.
A whitelist in /etc would be preferred but that would break all legitimate configuration which might cause too much breakage.
I don’t know what that is.
Code paths are some times different for gateway vs workstation and also Non-Qubes-Whonix vs Qubes-Whonix. Hard to foresee all cases. Quite a few issues for sdwdate profile. See sdwdate apparmor profile:
sdwdate and sdwdate-gui development thread - #363 by Patrick
Also networking Qubes works different.
Oh. I only tested in in the Gateway on KVM. I forgot to test on other things.
Could you make that a drop-in instead please?
/lib/systemd/system/networking.service.d/30_apparmor_profile_everything.conf
and then change only what’s required to change:
[Service]
ExecStart=/sbin/networking up
ExecStop=/sbin/networking down
That saves a config-package-dev displace.
/sbin/networking
maybe too unspecific? Perhaps better to use /sbin/networking-apparmor-everything
or /sbin/networking-aae
to make it more specific and clear for reviewers?
and license header.
Qubes-Whonix /lib/systemd/system/qubes-whonix-network.service
uses Alias=networking.service
thereby does not benefit from this. And Remove CAP_NET_ADMIN capability would break Qubes-Whonix networking /usr/lib/qubes-whonix/init/network-proxy-setup
.
Are you sure that would work? networking.service already has ExecStart
and ExecStop
options.
I can’t fix that since I don’t have Qubes. I doubt the script would work enough for me to create a profile for it.
Did everything you asked.
https://github.com/madaidan/apparmor-profile-everything/blob/net_admin/sbin/networking-aae
Yes. systemd drop-in support is amazing. Hard to ask for better features. It explicitly supports that use case. It supports to totally replace/overwrite existing keywords or expand these too.
Just noticed. I made a mistake. The actual syntax for a drop-in is this:
[Service]
ExecStart=
ExecStart=/sbin/networking up
ExecStop=
ExecStop=/sbin/networking down
The first ExecStart=
tells systemd to clear all previous ExecStart
keywords. Otherwise it would keep the existing one and only expand, i.e multiple ExecStart=
.
Fixed
The ordering of dangerous-files got messed up a bit when the pull requests were merged. apparmor-profile-everything/dangerous-files at master · Kicksecure/apparmor-profile-everything · GitHub should be just below the systemd lines, not the kernel.d lines.
It might be better to just fix this directly in the kernel with a patch adding a kernel.dmesg_restrict=2
sysctl rather than trying to hack our way around it.
To debug, view logs… Could you use a “backdoor”? A way to make yourself superroot with /path/to/unconfined/sudo/script so you can view logs? Or serial console login as root?
madaidan via Whonix Forum:
I don’t know what that is.
madaidan via Whonix Forum:
Maybe displace would be better for this than
str_replace
.
That one I don’t understand.
madaidan via Whonix Forum:
correct variable assignment order by nyxnor · Pull Request #2 · Whonix/whonix-firewall · GitHub
It is not enforcing the actual firewall scripts. The actual firewall
scripts are in /usr/bin, see
https://github.com/Whonix/whonix-firewall/blob/master/usr/lib/whonix-firewall/enable-firewall
is only a helper script for systemd.
That was just to make networking.service execute our wrapper but now that we have the drop-in, it doesn’t matter.
It is. /usr/lib/whonix-firewall/enable-firewall executes /usr/bin/whonix_firewall which executes /usr/bin/whonix-workstation-firewall or /usr/bin/whonix-gateway-firewall.
sudo whonix_firewall
sudo /usr/bin/whonix_firewall
is a common use case. Used in Whonix documentation. Users run that manually. Therefore needs to be contained or the way users interact with that needs to be changed in the wiki and /usr/bin files would have to be moved elsewhere to discourage that.