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

Currently, Whonix only has AppArmor profiles for a few high-risk applications. This isn’t the best. It would be much better to have everything confined by default, including init which would greatly increase security.

This can also help a lot with the “untrusted root” idea as we can just develop a system-wide policy to restrict root.

AppArmor can do this by loading a profile for systemd in the initramfs.

Even when a user installs some sketchy malware, it will be restricted by default.

This isn’t something that can be done easily though. It will require a ton of work and testing.

Android also does this but with SELinux.

I’m not aware of any Linux distribution that does this (except Android).

Edit by Patrick:

Link to source code:


Android apps are much simpler and more contained by design which makes something like systemwide SELinux possible.

Full system MAC is a PITA in my experience and I’ve tried Grsec’s RBAC back in the day which arguably has the most advanced auto profiling of any framework. I tried using it it a lot. There was a lot of unexplainable breakage despite running every program and exercising all of my needed functionality. Nonetheless if you can somehow make this work without running into serious showstopperes I don’t see why not.

Note that TOMOYO is an Apparmoresque designed MAC that supports sys wide profiling. Not sure you can stack it with Apparmor yet though.


True but to get something like that on the desktop would be great,

It will be but I think the benefits are too great to not do it.

I don’t have any experience with TOMOYO so designing system wide policies probably isn’t the best idea.

You can’t stack LSMs in the kernel. Some exceptions are made for small LSMs though like YAMA.

1 Like

I’m working on a full system policy. Currently, I’ve gotten it to boot but not much else.


Here is the policy I’m working on Debian paste error

There is still a lot left to do but it works and doesn’t (yet) break everything.


Fits any existing package?

Whonix · GitHub

In theory it fits GitHub - Kicksecure/apparmor-profile-dist: AppArmor profile for Anonymity Linux Distributions - - for better security (hardening). but… [1]
Or new package?

[1] Suggest to enable by default at some point? Not sure yet. Current policy for AppArmor was:

  • A) enable by default for packages shipped by Whonix - since then developers can test (and know) the AppArmor profile and unlikely to break things (sdwdate, …)
  • B) opt-in (install by user) for software upgraded through Debian or third parties (Tor Browser) since that is more likely to break.

I guess this is the category B)?

Please add licensing header if you’re creating a pull request for this.

Experimental full system AppArmor policy for Whonix.

It’s really awesome idea I wouldn’t have thought of.

One nitpick: it’s not “full system”. It’s all systemd unit files, which is huge. But “full system” would mean “all of /” (/usr/bin etc etc).

Could still be in package apparmor-profile-anondist but maybe not /etc/apparmor.d folder [1]?

1 Like

No, it should get its own opt-in package.

No, it is “full system”. All processes are spawned off the init process so every single process (except kernel processes) are automatically confined. That includes “all of /”.

It’s easily tested by running ps auxZ and you’ll see every process is confined or you can try using ls on a non-permitted directory such as /boot.

That’s why this is such a useful feature. Sandbox escapes will basically be nonexistent.

No binaries have the ux or Ux rule which would execute them unconfined. They all have the pix rule which executes them under their own AppArmor profile and if it doesn’t exist, it falls back to the original init-systemd profile.

1 Like

package name? Is this Debian specific or Kicksecure or Whonix?

Might have to review our existing profiles and other installed profiles for such holes?

How could apt upgrade files in /boot?

I stand corrected. Happy to be wrong. :slight_smile:

Excellent innovation!


Something generic like “Full System AppArmor Policy”.

It should be able to be used on any. I’m only testing on Whonix though.

It would be a good idea although I doubt any would be using those permissions. They’re usually regarded as dangerous even without a full system policy.

An issue I am currently facing though is the base abstraction using ix for a few files in the home directory apparmor-profile-dist/base.anondist at master · Kicksecure/apparmor-profile-dist · GitHub. This is problematic as I need to give access to the entire home directory with the pix rule so existing AppArmor profiles will still be in use. Using pix for the entire home directory and also pulling in the base abstraction (which has the ix rules) causes a conflict and the profile won’t enforce. This can be fixed by just adding a p before the ix in those rules.

I didn’t actually think of that. It can’t without disabling AppArmor. I’m hesitant to give access to /boot as that would allow a malicious program to mess with the kernel and initrd images. Although, I can probably restrict /boot access to apt only.


That’s alright. Full stop. Since you’re creating the package you should have most freedom to coin things.

I am not contributing much but seems like I am providing a Free platform with services:

  • review packages
  • build packages
  • installable from third party APT repository (similar to a PPA but more restricted, much less scalable)
  • sometimes install by default in Whonix, Kicksecure, which are distributions which potentially might become available as host operating systems, are already available for various virtualizers.

Other possible package names: apparmor-profile-full, apparmor-profile-everything.

Since there is security-misc already, perhaps a companion package security-extra (opt-in package) which comes with all the more experimental, (potential) breaking security enhancements? Or security-paranoid (depending on paranoid being viewed as compliment or insult) (after all the revelations on the state of computer security, nothing really is “paranoid”). Just brain storming.

Makes sense. Since this is becoming an opt-in package, there is nearly unlimited freedom of usability issues and inconveniences.

Could be different boot modes? Relates to multiple boot modes for better security: persistent user | live user | persistent secureadmin | persistent superadmin | persistent recovery mode.

Would be OK. However, coming at a disadvantage. That would effectively make apt a tool which can be used (by root) to modify any file on the system. It would be possible to add local or remote APT repositories to /etc/apt/sources.list.d/ folder or to define the (local!) repository URI as APT command line parameter. By using a local APT repository it might even be possible to write a wrapper script that would abuse that mechanism to write to any file on the system.


Something like security-extra sounds like it’d be good for other hardening like kernel hardening but not AppArmor changes. “paranoid” being an insult would depend on the context. I doubt security-paranoid would be viewed as an insult.

Editing the policy at boot in the initramfs based on a boot parameter sounds really hacky and doesn’t seem like a good idea.

There is already a boot parameter to disable apparmor (apparmor=0) that can be used if needed.

True. Certain configuration options are also likely able to be abused. For example

apt-get update -o APT::Update::Pre-Invoke::=/bin/mv /malicious_kernel /boot/vmlinuz

The policy can block write access to the main apt configuration files and only allow /boot access to the apt-get-update-plus wrapper so the -o and -c options have no effect. Although this comes with a customizability decrease.


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/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?


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.


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/?


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/?


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.


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


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.


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


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.


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.