[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

AppArmor for Complete System - Including init, PID1, Systemd, Everything! - Full System MAC policy

We’d also need to remove CAP_CHOWN so they can’t just do chown root -R /home and access the home directories.

1 Like

Quite a lot new profiles to review and test. :slight_smile: 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?

1 Like

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.

1 Like

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?

1 Like

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

Also networking Qubes works different.

1 Like

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.

1 Like

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.

1 Like

Did everything you asked.

1 Like

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=.

1 Like

Fixed

1 Like

The ordering of dangerous-files got messed up a bit when the pull requests were merged. https://github.com/Whonix/apparmor-profile-everything/blob/master/etc/apparmor.d/abstractions/dangerous-files#L113 should be just below the systemd lines, not the kernel.d lines.

1 Like

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?

1 Like

madaidan via Whonix Forum:

I don’t know what that is.

1 Like

madaidan via Whonix Forum:

Maybe displace would be better for this than str_replace.

That one I don’t understand.

1 Like

madaidan via Whonix Forum:

https://github.com/Whonix/whonix-firewall/pull/2

It is not enforcing the actual firewall scripts. The actual firewall
scripts are in /usr/bin, see


is only a helper script for systemd.

1 Like

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.

1 Like
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.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]