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.
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/.
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.
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.
There might be other lesser known directories like this. Maybe something like /**/aptitude/. We should check around the entire system for things like these.
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.
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.
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.
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.