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

AppArmor
12

Didn’t have that idea. I was thinking rather complicated: create a deb package, add to local APT repository, apt update from local, apt install local package which runs the command (such as to modify /boot).

It supports extra options.

apt-get-update-plus does not have any limitations on passing any arguments anywhere.

usability-misc/usr/bin/upgrade-nonroot at master · Kicksecure/usability-misc · GitHub might be more suitable.

I don’t have a great answer yet. Hopefully apt upgrades to /boot can be done without entirely disabling all apparmor ( apparmor=0 )?
Even during an “admin boot” (if we can implement that one day) where “anything goes” shouldn’t want to entirely disable apparmor?

2 Likes
13

It didn’t work for me when I tried it. I must have done it wrong.

Wouldn’t this be a potential privilege escalation since it has a sudoers exception? E.g.

sudo apt-get-update-plus dist-upgrade -o APT::Update::Pre-Invoke::=/bin/bash

It doesn’t work for me though.

It would probably be a good idea to make it disable any arguments if /etc/apparmor.d/init-systemd exists.

I think we should allow apt access to /boot by default but make sure it cannot be easily abused although even then, vulnerabilities in apt could give malware access to /boot.

2 Likes
14

Does not allow passing arguments / variables.

By making it impossible to pass APT parameters as well as not allowing to write to /etc/apt/sources.list and /etc/apt/sources.list.d/?

2 Likes
15

Ah, that makes sense.

Yes as well as not allowing write access to /etc/apt/apt.conf.d as you can specify config options in there too. It may be a good idea to just disallow write access to all of /etc/apt/.

Is there any other way to sneak in configuration options? Maybe /usr/lib/apt/ or /etc/dpkg/?

2 Likes
16

Also, nothing stops an attacker from overwriting /usr/bin/apt or other commands apt uses with a malicious version.

I can possibly allow apt to only execute a few needed binaries in it’s own apparmor profile then disallow write access to those binaries in the systemd-init profile.

2 Likes
17

Other folders / files that might (lots of random guesses in following list, not too much substance yet) be vulnerable in this threat model:

  • /etc/init.d (these are reinterpreted as systemd unit files?)
  • /etc/systemd (can hold systemd unit files)
  • /usr/lib/systemd (can hold systemd unit files)
  • /usr/lib/sysusers.d (modifying user accounts might weird stuff)
  • /usr/lib/tmpfiles.d (weird file permissions might open for attack?)
  • /etc/passwd (do something weird to root account?)
  • /etc/initramfs-tools (add malicious hooks to infect initramfs)
  • /etc/default/grub
  • /etc/default/grub.d (grub boot parameters obviously can disable AppArmor)
  • /etc/grub.d

Yes.

Yes.
Also /var/cache/apt and /var/lib/dpkg.

An attacker could also try tricks such as deleting folders and using symlinks. Not thought through yet that would help an attack or already covered.

2 Likes
18

These are definitely dangerous. We need to fully prevent all runtime bootloader and initramfs modifications, otherwise an attacker can easily disable apparmor after a reboot.

There is also /usr/share/initramfs-tools/ and /usr/share/grub/.

2 Likes
19

It might be a good idea to just do

deny /**/initramfs-tools/ w,
deny /**/grub/ w,
deny /**/grub.d/ w,

To ensure there are no other directories for these that we missed.

2 Likes
20

It might be a good idea to use Pix instead of pix rules so AppArmor scrubs the environment but this will probably break hardened_malloc if we use LD_PRELOAD for it.

2 Likes
21
2 Likes
22 
mygrep -r Ux | grep apparmor
+ grep --exclude=README.md --exclude=GPLv2 --exclude=GPLv3 --exclude=COPYING --exclude=changelog.upstream-old1 --exclude-dir=mnt --exclude-dir=qubes-src/linux-template-builder/mnt --exclude=changelog.upstream --exclude-dir=.git -r Ux
apparmor-profile-xchat/etc/apparmor.d/abstractions/xchat-based:   /usr/lib/firefox-esr/firefox* Ux,
...
apparmor-profile-anondist/etc/apparmor.d/abstractions/base.anondist:  /usr/lib/security-misc/permission-lockdown rUx,

A few Ux, uX, cux found in Whonix source code.

Dev/git - Kicksecure

  • Ux should probably be replaced by at least Cux or better.
  • ux should probably be replaced by at least cux or better.

Also environment variables scrubing vs non-environment variables scrubbing needs to be reviewed.

2 Likes
23

Should libraries and binaries be read-only by default and only writable by apt?

It will be harder to install and update your own programs (without using apt) but it will also be harder for malware to compromise a specific program.

documentation:rsbac_handbook:configuration_basics:system_base [RSBAC: Extending Linux Security Beyond the Limits] gives some other good ideas.

2 Likes
24

As simply a user of Whonix, I would say make Whonix as safe as possible for the general user base. Whonix has so many programs included with it, I’ve never needed to install anything myself. But from what you’ve said the option of installing more software is still there for those that have the need and the knowledge to do it. I just think safety and “peace of mind” is what most Whonix users are looking for, and would go that route. Thanks for all the time to put this together!

2 Likes
25

That should be all of the ux or Ux rules gone now.

1 Like
26

All merged but not tested yet.

It all points to different boot modes. A restricted mode and a mode in which upgrades can be done.

1 Like
27

etc/apparmor.d/usr.lib.security-misc.pam_tally2-info and etc/apparmor.d/usr.lib.security-misc.permission-lockdown actually belong to security-misc?

Reverted. Could you please add to security-misc? Also license header required.

1 Like
28

^ This is important. Otherwise the profile won’t work.

The line #include <local/bootclockrandomization> will make the profile fail to load.

Above commits makes sure that the postinst script (/var/lib/dpkg/info/bootclockrandomization.postinst) contains the autogenerated debhelper code (bash) to create /etc/apparmor.d/local/bootclockrandomization.

1 Like
29

The binaries/libraries will be writable by apt so things like apt-get dist-upgrade and apt-get install will still work. The only thing that would be broken is if you put your own custom programs in /usr/bin without using the package manager.

I think it would be better to put them in apparmor-profile-anondist. The only reason they were created is so we don’t have the unconfined rules in the base abstraction that was made by apparmor-profile-anondist. security-misc is also more focused on hardening the OS in general rather than apparmor profiles.

I always forget that. I’ll try and remember next time.

1 Like
30

Some other ideas:

  • Disable network access by default and make it opt-in for some AppArmor profiles
  • Execute every binary in /usr/bin in a special “application” profile that is more restrictive so the profile doesn’t get bloated by system administration stuff
  • Remove the net_admin capability from the main profile and only give things that need it the capability. This can help make sure that IP leaks on the gateway are much harder to do even with root as the firewall cannot easily be disabled.
  • Disallow writing to /lib/modules to prevent external modules from being loaded.
  • Remove the sys_module capability and only give it to systemd-modules-load so root cannot load their own modules without breaking everything.
  • Disallow writing to init (/sbin/init, /lib/systemd/* etc.) to prevent rootkits.
  • Scrub the environment of everything.
  • Implement some grsec chroot hardening using AppArmor (and maybe a seccomp wrapper) which might make certain sandboxes more secure (firejail uses chroot AFAIK).
1 Like
31

security-misc provides applications or functionality. If these get contained using a MAC such as AppArmor, don’t these belong into the same package? The new bootclockrandomization apparmor also wasn’t added there.

apparmor-profile-anondist also has nothing to do with security-paranoid (or however this functionality gets coined). Therefore, if it doesn’t belong into security-misc, does it belong into security-paranoid?

I see. Not too bad. Kinda minority use case. Would still be nice to have (optional) if this was while security-paranoid is enabled if you can think off a solution.

1 Like