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

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

Indeed, well, that is the disadvantage of the superroot boot mode.

It’s only for the superroot boot mode. I wouldn’t know how else to implement superroot, i.e. allow manipulation of files such as in /etc/apt/sources.list.d folder or other files deemed dangerous for untrusted root. superroot is same as “trusted” root. Same as Whonix has prior apparmor-profile-everything or same as most Linux distributions.

1 Like

We can just not source the dangerous-files abstraction for superroot. At least then, an attacker has to do some work to bypass the restrictions.

That would not be superroot.
The idea of superroot is “anything goes”. Or “old Whonix”. Or “similar sudo like most Linux desktop distribution such as Debian”.
Something that stays out of the way of expert, developer or lazy users. A freedom feature.

(As mentioned here there will likely be the following grub boot menu default entries:

  • PERSISTENT mode USER (For daily activities.) (this includes “full” apparmor-profile-everything)
  • LIVE mode USER (For daily activities.) (this includes “full” apparmor-profile-everything)
  • PERSISTENT mode ADMIN (For software installation.) (this includes “full” apparmor-profile-everything)
  • PERSISTENT mode SUPERADMIN (Be very cautious!)

Add yet another mode? “superroot, but an attacker has to do some work to bypass the restrictions” - short name? Worth adding?

There are many different faccetes between security / freedom. I was hoping with three boot options (user-only, root but apparmor-profile-everything restricted, and superroot (fully unrestricted)) would give a sufficient balance. Something everyone could be happy with.

Btw I am making “some good progress” implementing the the grub boot menu entries. Will be “similar” to this very post: multiple boot modes for better security: persistent + root | persistent + noroot | live + root | live + noroot

“similar”: Well, some things are non-ideal by technical limitations of grub-mkconfig such as recovery mode might be the second and not last boot menu entry. I am not sure yet. Still in process.

“some progress” = boot menu entries that allow setting kernel boot parameters. Not a full implementation of “boot/login into user” vs “boot/login into admin”.

1 Like

Then we can add

owner=(root) /** rwmlkpix,

Should give root complete access to the entire filesystem and all capabilities while every other user is still restricted.

I don’t think it should be added. Too many boot menus will just confuse people.

1 Like

Sounds very good!

These grub default menu entries were implemented.

Please review.

Looked at /boot/grub/grub.cfg which looks good but entirely untested in a live boot for now. I thought this might be a good visualization for discussion.

Let me know if these grub boot menu entries need adjustments to work well with apparmor-profile-everything.

(Also posted here: multiple boot modes for better security: persistent + root | persistent + noroot | live + root | live + noroot)

1 Like

What about aadebug?

1 Like

Only manual kernel boot parameter (through grub boot menu key press e). No default grub boot menu entry. As per this post AppArmor for Complete System - Including init, PID1, Systemd, Everything! - Full System MAC policy.

If we still want to go for aadebug at all? Maybe already covered by superroot? Or another default grub boot menu entry PERSISTENT mode ADMIN with DEBUG? I hope not.

1 Like

aadebug should still be a thing so people can do basic debugging without worsening security too much.

Not having a boot menu for aadebug is a good idea so it doesn’t get too bloated.

Also, is it possible to add a warning to superadmin? e.g. user tries to boot with the superadmin boot menu, it pops up with a message saying something like “Don’t use this unless you know what you’re doing. Be very cautious etc. Consider using aadebug instead.”

1 Like

That is a good idea.

A nested grub boot menu is not possible due to the /etc/grub.d / update-grub framework limitations.

A systemd unit file that runs very early at boot could do. Systemd unit files are capable of accepting user terminal input such. There could be an option YES (continue boot) | NO (reboot) and a timeout which continues booting after XX seconds. Systemd unit files are as far as I know also capable of interrupting the boot process until some systemd unit has finished (timeout).

1 Like

That may be too late and the malware could’ve already exploited superroot.

It would be best to have it pre-boot. Maybe an ncurses menu in the initramfs? Is that even possible?

1 Like

Possibly? Pre boot FDE password entry is inside initramfs or outside?

1 Like

Outside. The bootloader decrypts everything before starting the initramfs.

What does this have to do with it?

1 Like

Pre boot password entry is very early. Either in /boot or initramfs. It’s an example of interactive console. Source code for inspiration for superroot warning.

Grub can encrypt /boot somehow but it’s not a feature that any distribution installers use that I know. Debian installer doesn’t use it. initramfs, kernel image, whole /boot is unencrypted.

1 Like

It seems like decryption actually happens in the initramfs. I initially thought it happened in grub due to the need for a cryptdevice boot parameter but looking into it more, it looks like the cryptroot initramfs hook does it.

That hook seems to use the cryptsetup_message function in /lib/cryptsetup/functions for messages and the source code of that function is:

cryptsetup_message() {
    local IFS=' '
    if [ "${0#/scripts/}" != "$0" ] && [ -x /bin/plymouth ] && plymouth --ping; then
        plymouth message --text="cryptsetup: $*"
    elif [ ${#*} -lt 70 ]; then
        echo "cryptsetup: $*" >&2
        # use busybox's fold(1) and sed(1) at initramfs stage
        echo "cryptsetup: $*" | fold -s | sed '1! s/^/    /' >&2
    return 0

Also, files such as /lib/cryptsetup/functions need to be protected by dangerous-files too. Otherwise an attacker can just edit something like cryptsetup_message() to run rm /etc/apparmor.d/init-systemd to bypass the policy.


/lib/cryptsetup/functions is actually already read-only due to apparmor-profile-everything making all libraries/binaries read-only. We should still look around for other things like this that are not protected in the policy though.

1 Like

There doesn’t seem to be anything that isn’t protected. All files sourced can be checked with

grep -or '\. /[^"]*' /{,usr/share,etc}/initramfs-tools/ | sed -e 's/.*://g' | awk '!x[$0]++'

Directories like /scripts/ are created in the initramfs from /**/initramfs-tools/ AFAIK.

1 Like

We should probably mount the securityfs with nosuid, nodev and noexec but this isn’t too important as barely any of /sys/kernel/security is allowed in the policy anyway.

1 Like

I think we will have to use plymouth for the early boot prompt but I have no idea how to use that.

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