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

madaidan · December 13, 2019, 4:42pm

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.

Patrick · December 13, 2019, 4:46pm

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.

madaidan · December 13, 2019, 4:55pm

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.

Patrick · December 13, 2019, 5:15pm

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 user | live user | persistent secureadmin | persistent superadmin | persistent recovery mode - #32 by Patrick

“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”.

madaidan · December 13, 2019, 5:22pm

Then we can add

owner=(root) /** rwmlkpix,
capability,

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.

Patrick · December 13, 2019, 5:55pm

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 user | live user | persistent secureadmin | persistent superadmin | persistent recovery mode - #34 by Patrick)

madaidan · December 13, 2019, 5:57pm

What about aadebug?

Patrick · December 13, 2019, 6:01pm

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 - #220 by Patrick.

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.

madaidan · December 13, 2019, 6:08pm

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

Patrick · December 13, 2019, 6:14pm

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

madaidan · December 13, 2019, 6:18pm

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?

Patrick_mobile · December 13, 2019, 6:51pm

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

madaidan · December 13, 2019, 6:59pm

Outside. The bootloader decrypts everything before starting the initramfs.

What does this have to do with it?

Patrick_mobile · December 13, 2019, 7:15pm

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.

madaidan · December 13, 2019, 7:31pm

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
    else
        # use busybox's fold(1) and sed(1) at initramfs stage
        echo "cryptsetup: $*" | fold -s | sed '1! s/^/    /' >&2
    fi
    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.

Edit:

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

madaidan · December 13, 2019, 7:53pm

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.

madaidan · December 14, 2019, 9:01pm

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.

madaidan · December 14, 2019, 9:54pm

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

Patrick · December 15, 2019, 8:47am

I don’t like plymouth much. It seems only needed for fancy graphics during boot. I used to have some plymouth in past and hence used all my systems without it. It however looks entirely optional… The code you quoted:

Has fallbacks if plymouth isn’t installed. Pre boot FDE password entry is fully functional without plymouth. A warning message against superroot is probably easier than a password prompt.

Patrick · December 15, 2019, 8:50am

Quote GNU GRUB Manual 2.12

grub-mkconfig does have some limitations. While adding extra custom menu entries to the end of the list can be done by editing /etc/grub.d/40_custom or creating /boot/grub/custom.cfg, changing the order of menu entries or changing their titles may require making complex changes to shell scripts stored in /etc/grub.d/. This may be improved in the future. In the meantime, those who feel that it would be easier to write grub.cfg directly are encouraged to do so (see Booting, and Shell-like scripting), and to disable any system provided by their distribution to automatically run grub-mkconfig .

However, /boot/grub/grub.cfg menu entries are nicely marked by a top and bottom comment.

### BEGIN /etc/grub.d/filename ###

### END /etc/grub.d/filename ###

That looks very parse. Perhaps the grub submenu which shows the warning could be warped around it.