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

if ! grep "apparmordebug" /proc/cmdline; then
  echo "profile init-systemd /lib/systemd/systemd flags=(complain) {}" | /sbin/apparmor_parser -a
elif grep "apparmordebug" /proc/cmdline; then
  echo "profile init-systemd-debug /lib/systemd/systemd flags=(complain) {}" | /sbin/apparmor_parser -a

Add something like this to https://github.com/Whonix/apparmor-profile-everything/blob/master/etc/initramfs-tools/scripts/init-bottom/apparmor-profile-everything and create an init-systemd-debug profile with debug permissions.

By “debug” I don’t mean completely unconfined, but having access to debug info like dmesg.

1 Like

Does this include superroot? Some sort of superroot is required. Otherwise not even developers could experiment with changes to essential files such as init-systemd.

1 Like

I don’t like the idea of including a “superroot” at all.

If developers need to experiment with changes, they can boot with apparmor=0, make the changes and reboot. Or, they can just give themselves write access to those files in the policies.

apparmor-profile-everything does not yet remove write access to the policies so we can easily edit them https://github.com/Whonix/apparmor-profile-everything/blob/master/etc/apparmor.d/abstractions/dangerous-files#L47 (it is commented out)

This will be changed once it’s finished though.

1 Like

Booting without any apparmor at all isn’t great. That could be just the moment that malware is waiting for. I mean malware that would be contained thanks to an apparmor profile from breaking out but then breaking out for real due to a zero apparmor boot.

Choice “either apparmor-profile-everything or no-apparmor-at-all”, “perfect or nothing” isn’t a great choice.

I need to test changes without reboot because I get the syntax wrong too often to keep rebooting.

It’s also a software freedom feature. Refusing root access (or “real/full” root) access or “then break your system by disabling apparmor” is a software freedom restriction. [1]

Could be like this:

if grep "superroot" /proc/cmdline; then
  echo "profile init-systemd-superroot /lib/systemd/systemd flags=(complain) {}" | /sbin/apparmor_parser -a
elif grep "apparmordebug" /proc/cmdline; then
  echo "profile init-systemd-debug /lib/systemd/systemd flags=(complain) {}" | /sbin/apparmor_parser -a
  echo "profile init-systemd /lib/systemd/systemd flags=(complain) {}" | /sbin/apparmor_parser -a

[1] FSF was asked earlier about their position on root access refusal. That was interesting related to Android.

If the software is truly a piece of free software which respects your essential freedoms, then you would be able to modify it so that you can gain root access (or any other type of access) and re-install it on the device. If it does not allow that, then it isn’t free software.

However, Android has many freedom issues, and lack of root access is only one of them.

The Replicant project attempts to build a fully free Android distribution which runs on several devices. Please see:

1 Like

You aren’t really going to be at constant attack from malware during development.

End users likely won’t need to edit the policies.

You can run aa-enforce /etc/apparmor.d/init-systemd which will pick up any syntax errors but won’t be able to load it.

If that’s the case, then you’re just adding another “software freedom restriction” with superroot - “then break your system by enabling superroot”.

I don’t want to poke holes in the policy for things that most people won’t need.

1 Like

There was an attack in the wild which exploited everyone non-discriminatory.

Quote https://www.whonix.org/wiki/Security_in_Real_World#Tor_Browser_Bundle

  • An old attack [archive] [13] was observed in the wild that exploited a JavaScript vulnerability in Firefox. [14] The observed version of the attack collected the hostname and MAC address of the victims’ computers, and sent that information to a remote web server. This threat is partially mitigated nowadays by the development of a security slider in the Tor Browser Bundle, which prevents the execution of JavaScript code completely with the correct settings. Nevertheless, Whonix ™ would have protected against a MAC address leak [15] and at worst leaked a hostname which is common to all Whonix ™ users.

Not a targeted attack at all. Fortunately the attacker only collected IP address and MAC address. Didn’t attempt to proceed to further infect the system with rootkits. But if it has been attempted, then apparmor might have prevented breakout of the confinement. This was an attack by a “somewhat good actor” which got caught and well analyzed. Not necessarily always that way.

Much less of a breakage than zero apparmor. I am pretty sure this will keep Free Software enthusiasts happy. I’ll even be writing documentation how to opt that boot mode in as a default boot mode. (Just modify /etc/default/grub.d.)

No need. The two or three files…

  • init-systemd-superroot [1]
  • init-systemd-debug [2]
  • init-systemd [3]

could be based on the same abstraction? And then [3] would just use the abstraction. [2] would have the abstraction and some relaxation on top. [1] would have further relexations on top.

I don’t see how would lower security for anyone who’s not using it. But once [2], [3] are implemented and all of this matured, we can look into [1] and see how would influence the security.

1 Like

It was targeted. The FBI were going after pedophiles.

It only affected Windows users anyway.

We can just use one file, init-systemd and create patches for it that are applied during installation.

e.g. during installation this would be run

cp /etc/apparmor.d/init-systemd /etc/apparmor.d/init-systemd-debug
cat debug.patch | patch -d /etc/apparmor.d -p 1
cp /etc/apparmor.d/init-systemd /etc/apparmor.d/init-systemd-superroot
cat superroot.patch | patch -d /etc/apparmor.d -p 1

Then we just need to maintain one actual profile and two small patches.

1 Like

That time yes. But nothing in principle made Linux immune. Just “luck” it was the good guys attacking all Windows users and not someone else using it for bad. Well, one could make the argument once you’re using Linux, all security hardening is overkill. Yet, I suppose, it’s our enjoyment.

installation? No installation for VM images.

That would be an OK solution but I am not sure about the details, if patch is the best tool here. Boot modes seems more flexible/convenient since one can change easy from one to another.

1 Like

That’s not true at all. A lot of security hardening is leaps behind overkill.

I meant package installation.

No, we’d still have the boot modes. The patching is just so the profiles are easier to maintain (1 profile instead of 3). We’d create copies of init-systemd then patch those copies. The boot modes would then switch between the patched copies.

1 Like


Would [1], [2], [3] importing abstractions, i.e. have a line #include <abstractions/init-systemd> or #include <init-systemd-abstraction> (depending on file system layout) be a better options than patch?

1 Like

Dunno. What do you think?

1 Like

Btw, we can patch apparmor to force it to stay enabled even if there is an apparmor=0 boot parameter.


Obviously, this shouldn’t be applied by default so users aren’t forced to use apparmor, but it can be optional for users that don’t care much about freedom and don’t want apparmor to ever be disabled.

This patch only allows apparmor to be disabled if CONFIG_SECURITY_APPARMOR_DISABLE is set. If it is not set, apparmor=0 does nothing.

madaidan via Whonix Forum:

Dunno. What do you think?

Using source code based implementations, declarative implementations are
always easier to grasp than any auto generated, scripted, patched
implementations. Hence #include is strongly preferred.

1 Like

Attackers can read program binaries to try and find vulnerabilities. Important binaries like SUID ones are sometimes made unreadable for security.

Should all binaries (or just important ones like apt-get) be unreadable?

This wouldn’t have much of a security gain as an attacker can just read the open source code, read the libraries the program uses or ptrace the process. ptracing can be easily fixed though.

Also see https://stackoverflow.com/questions/29083388/why-is-it-common-for-binary-elf-suid-executables-to-also-allow-read-access

I don’t see any security advantage at all. Have there ever been cases where this would have helped? Therefore lets not add complication without gain.

One point makes sense though. Although for usability. Not security. If we remove suid then it should also remove read and exec for user. That way things fail closed and obvious rather than failing open. (su reporting wrong password even though password incorrect and no suid).

1 Like

I don’t know. I first heard about this from grsec https://forums.grsecurity.net/viewtopic.php?t=2939

I’m working on the boot modes here https://github.com/madaidan/apparmor-profile-everything/tree/boot-modes

I just have a single init-systemd file that contains all 3 profiles.

What should I add to debug and superroot?

I also need to add a grub menu but haven’t figured that out yet.

1 Like

These might be a bit much grub boot menu default entries. We already have 4:

  • persistent boot
  • recovery mode persistent boot
  • live boot
  • recovery mode live boot

Option recovery mode live boot is way too unimportant (given much important boot modes) to have a default entry. But I just now figured out how to get rid of it. Soon we will have three default boot menu entries:

  • persistent boot
  • recovery mode persistent boot
  • live boot

(By default entry I mean: easily accessible in grub default boot menu.)

Related: multiple boot modes for better security: persistent + root | persistent + noroot | live + root | live + noroot

This discussion cannot really be separated from multiple boot modes for better security: persistent + root | persistent + noroot | live + root | live + noroot.

I am not longer sure, should there be a root boot mode default entry or superoot default default entry or both? Will ask in above forum thread.

Could you please either replace the following or add an additional short options?

  • no-apparmor-profile-everything
  • apparmor-superroot
  • apparmor-debug

These are quite a lot to type when typing these manually. Suggestions for shorter versions:

  • no-apparmor-profile-everything -> noape
  • apparmor-superroot -> superroot
  • apparmor-debug -> aadebug

In some situations (Qubes) these options may not be (easily) accessible through Qubes boot menu but manually typing kernel boot parameters only (in Qubes VM settings, kernel parameter).

Suggested criteria for good short kernel boot parameter names:

  • short
  • easy to type
  • hard to misread / type wrong
  • not inappropriately conflicting with existing boot option
  • unlikely to be picked in future by a different project which isn’t aware of us (so we don’t have to change these later) to avoid double-use of these

apparmor-debug -> aadebug… Maybe for that one we could “hijack” (if there already is such a kernel boot parameter) debug?

I don’t think we should add 3 more default boot menu entries? noape, aadebug don’t seem important enough to be added as grub default boot menu entries?

For now we could merge your git branch immediately without adding any new grub boot menu entries. For now we could type noape, superroot, aadebug manually. Until we figured out the design (which menu entries should be default) and implementation of multiple boot modes for better security: persistent + root | persistent + noroot | live + root | live + noroot.

1 Like

Good question.


  • Allow running /usr/bin/sudo and /usr/bin/sudoedit apparmor unconfined by apparmor-profile-everything?
  • (Usual pam sudo password checking still applies. No changes required.)
  • Perhaps for user admin only (if that is possible)?
  • That would result in sudoedit /etc/apt/sources.list.d/custom.list to be writeable?
  • While sudo tcpdump wouldn’t be restricted by apparmor-profile-everything it would still be restricted by (exists really) /etc/apparmor.d/usr.sbin.tcpdump, which is good (and which the admin could disable if wanted)?
  • Or invent a new wrapper /usr/bin/supersudo which is allowed to run /usr/bin/sudo unconfined? That way a sysadmin or developer could easily within the same session compare apparmor-profile-everything restricted sudo vs unrestricted sudo. Similar for sudoedit.


  • dmesg
  • journalctl
  • /var/logs
  • Not sure. Can add more stuff on demand.
1 Like

What’s the point of full system confinement if you allow sudo unconfined?

Whatever the policy would stop an attacker from doing, the attacker can just preface with sudo.

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