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

madaidan via Whonix Forum:

Boot modes by madaidan · Pull Request #12 · Kicksecure/apparmor-profile-everything · GitHub

Merged.

We can add the grub menus once we figure that out.

grub boot menu entries are probably already sorted out. See:

But untested. What is not done yet is “warn against superroot”. Did not
get to that yet. But that can be done any time later. See it this way.
First, there wasn’t any root/superroot separation / boot modes. Now
there is. To educate against superroot is just a further detail enhancement.

1 Like
1 Like
1 Like

I tried removing access to logs but it didn’t work. Removing read access to /var/log/** caused XFCE to fail to start which I cannot debug due to no logs.

I couldn’t restrict just dmesg either. It doesn’t seem to read stuff from a file but use some kernel magic to get the logs.

I did manage to restrict journalctl though which might be useful although its usefulness would be very limited due to the tons of other info in /var/log/.

1 Like

Should /etc/apparmor/ (not the same as apparmor.d) and /var/cache/apparmor/ be protected by dangerous-files?

Dunno if they pose much of a risk. Or, we can just add:

deny /**/apparmor/ rw,
deny /**/apparmor/** rw,

We might also want to change our apt/dpkg protections to:

deny /**/apt/ rw,
deny /**/apt/** rw,
deny /**/dpkg/ rw,
deny /**/dpkg/** rw,

Instead of selecting just a few folders.

1 Like

Superroot is allowed to change them.

1 Like

The following is non-ideal.

mount -t securityfs nosuid,nodev,noexec /sys/kernel/security

echo "profile systemd-sysctl /lib/systemd/systemd-sysctl {}" | /sbin/apparmor_parser -a

if grep "noape" /proc/cmdline; then
  echo "apparmor-profile-everything has been disabled via the boot parameter."
  exit
elif grep "superroot" /proc/cmdline; then
  echo "profile init-systemd-superroot /lib/systemd/systemd flags=(complain) {}" | /sbin/apparmor_parser -a
elif grep "aadebug" /proc/cmdline; then
  echo "profile init-systemd-debug /lib/systemd/systemd flags=(complain) {}" | /sbin/apparmor_parser -a
else
  echo "profile init-systemd /lib/systemd/systemd flags=(complain) {}" | /sbin/apparmor_parser -a
fi

This is because it does things (mount securityfs, systemd-sysctl) even if noape kernel parameter is set.


1 Like

Fixed above.

Untested.

But

echo "profile systemd-sysctl /lib/systemd/systemd-sysctl {}" | /sbin/apparmor_parser -a

will be done even in case of superroot. Is this limiting superroot / OK / intended?

1 Like

madaidan via Whonix Forum:

Should /etc/apparmor/ (not the same as apparmor.d) and /var/cache/apparmor/ be protected by dangerous-files?

Dunno if they pose much of a risk. Or, we can just add:

deny /**/apparmor/ rw,
deny /**/apparmor/** rw,

We might also want to change our apt/dpkg protections to:

deny /**/apt/ rw,
deny /**/apt/** rw,
deny /**/dpkg/ rw,
deny /**/dpkg/** rw,

Instead of selecting just a few folders.

Makes very much sense. Please add.

1 Like

Mounting securityfs and the systemd-sysctl profile is not the same as the full system policy.

Securityfs is going to be mounted with systemd anyway and systemd-sysctl is a non-configurable, basic program that just writes into /proc/sys/ based on /etc/sysctl.d/ so it isn’t limiting anyone.

1 Like

There might be other lesser known directories like this. Maybe something like /**/aptitude/. We should check around the entire system for things like these.

1 Like

https://github.com/Whonix/apparmor-profile-everything/pull/19

I will now work on module restrictions.

1 Like

https://github.com/Whonix/apparmor-profile-everything/pull/20

The only module-related attack surface now is when attackers load unnecessary modules to add attack surface.

e.g.

An unprivileged user does something that auto-loads a module then exploits a vulnerability in that module.

Or

Root runs:

find /lib/modules/$(uname -r)/kernel/ -type f -name "*.ko" | awk -F"/" '{print $NF}' | awk '{print substr($0, 1, length($0)-3)}' > /etc/modules-load.d/modules.conf

to load every single module at the next boot.

The only way to reduce the risk of this is to add blacklists to modprobe.d and protect them with dangerous-files or just compile the kernel without unnecessary modules (which hardened-vm-kernel does) and patch the kernel to restrict module auto-loading to CAP_SYS_MODULE.

1 Like

The only problem now with removing CAP_NET_ADMIN is that it breaks network connectivity as networking.service doesn’t have permissions to raise network interfaces.

Once that’s fixed, only a kernel compromise (which will be made far harder with hardened-vm-kernel and security-misc) will be able to leak the IP on the gateway as the attacker won’t be able to disable the firewall which is a massive gain in IP leak prevention.

Also, we should document how to remove the apt-get profile as that’s currently the largest attack surface. Users can probably update by chrooting if they want to.

1 Like

To fix networking, instead of giving /sbin/ifup and /sbin/ifdown the CAP_NET_ADMIN capabilities (in case it might give some dangerous functionality), it might be better to create a wrapper script that does exactly what networking.service needs then use str_replace to make it execute our wrapper instead although that might be too hacky.

1 Like
1 Like

Did that and it works fine.

The wrapper: Debian paste error

The apparmor profile: Debian paste error

Just run

str_replace "ExecStart=/sbin/ifup -a --read-environment" "ExecStart=/sbin/networking up" /lib/systemd/system/networking.service
str_replace "ExecStop=/sbin/ifdown -a --read-environment --exclude=lo" "ExecStart=/sbin/networking down" /lib/systemd/system/networking.service

whonix-firewall and networking works fine and I can’t modify the firewall.

We’d also need to prevent disabling whonix-firewall.service which can be done with

deny /etc/systemd/system/sysinit.target.wants/whonix-firewall.service w,

madaidan via Whonix Forum:

We’d also need to prevent disabling whonix-firewall.service which can be done with

deny /etc/systemd/system/sysinit.target.wants/whonix-firewall.service w,

Good idea but insufficient probably. There are probably also other
systemd units. If you break these, you can break whonix-firewall.service
as a follow-up issue.

1 Like

Ah, I didn’t think of that. Maybe deny all systemd unit changes with:

deny /etc/systemd/system/** w,

/lib/systemd/system/ is already protected as /lib/ is read-only.

Or, we can just deny changes to the symlinks:

deny /etc/systemd/system/*.wants/** w,

Or, go even further and deny all systemd changes with:

deny /etc/systemd/** w,

Or even:

deny /**/systemd/** w,
1 Like