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

read doesn’t show any prompt. Still needs to use echo before. Might be able to use colors. (See colors in Whonix source code.)
Can’t we copy/paste from pre boot fde password entry prompt code?

1 Like

You can use the -p flag:

 read -r -p "text" prompt

I don’t know where that code is. I’ve tried looking but can’t find it.

1 Like

(edit: off topic, nevermind)

madaidan via Whonix Forum:

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.

Done in git master.

1 Like

No, I meant in https://github.com/Whonix/apparmor-profile-everything/blob/master/etc/initramfs-tools/scripts/init-bottom/apparmor-profile-everything#L18

securityfs is mounted with nosuid, nodev and noexec by default but apparmor-profile-everything would prevent that as we are mounting it ourselves in the initramfs.

1 Like

Should we further enforce “user account separation” with this?

Currently, apparmor-profile-everything doesn’t allow root to snoop in users’ home directories but that does nothing to stop root from switching to those users then accessing their files.

To do this, we’d need to remove the CAP_SETUID and CAP_SETGID capabilities (and create a sudo profile so sudo still works). We’d need to prevent root from trying to crack or change the user’s password so we’d need to block access to files like /etc/shadow.

But then, root can still compromise user applications so we need to remove CAP_SYS_PTRACE to prevent root from modifying other processes or we can just further restrict apparmor’s ptrace rules but then root can still see other processes, they just can’t ptrace them.

These are the obvious issues but there are more obscure ones like TIOCSTI (kernel patch CONFIG_TIOCSTI_DISABLE to further restrict root CAP_SYS_ADMIN) or writing to /dev/tty*.

We can solve the /dev/tty* problem by only allowing root to write to ttys they’re owner of.

There are probably some more ways root can compromise user applications/switch user accounts.

Also, these ways to compromise applications can also be used to compromise apt which is dangerous as apt has more permissions than the rest of the system.

1 Like
1 Like

madaidan via Whonix Forum:


Merged. And added on top:

1 Like

My first guess was “no, don’t bother, root should beat user”. But then we’re not only talking about user “user” but also user “apt”.

This is a strong argument. If root can set a break point and inject arbitrary code into processes such as APT, it is game over.

1 Like

apparmor-profile-everything is another reason to set this. During boot, a lot of apparmor messages are displayed on the console which slows down boot speed a large amount. We can probably set it in the initramfs so stuff before systemd-sysctl gets hidden too.

1 Like

Just did this. It’s crazy how fast boot speed improves. We should definitely add this. Maybe we should add an initramfs hook to security-misc to set this in early boot.


We can add the grub menus once we figure that out. I need this in order to make further modifications to init-systemd (as the main profile gets deleted and moved to an abstraction).

1 Like

Restricting mounting is far harder than it seems. Sandboxes need to use mount to create the filesystem within the sandbox. Many system services are sandboxed by default. This causes a lot of systemd services to fail and I don’t know how to fix this without disabling the sandbox.

1 Like

Let’s try fix the root cause.
https://github.com/Whonix/grub-output-verbose could be the cause. Try remove.

sudo apt purge grub-output-verbose

make sure /etc/default/grub.d/30_output_verbose.cfg is gone.

sudo update-grub

That should remove verbose boot kernel options? Speeds up boot?

1 Like

Allow systemd to use mount unrestricted but prohibit everyone else except exceptions such as for remount-secure?

1 Like

Doesn’t work. The console is still spammed with apparmor messages after removing that package.

The systemd profile is the everyone else profile. I do want to move away from that though and split up init-systemd to an init-only profile and everything else into a more restrictive profile. Maybe via something like

/usr/bin/** px -> confined_app,


1 Like
1 Like

madaidan via Whonix Forum:



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.

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