Root is allowed to run anything untrusted

[zhackwyatt]

I believe the rule allows root to run untrusted executables. Is that the intent? Bash is trusted so therefore, bash can execute any untrusted object.

https://github.com/linux-application-whitelisting/fapolicyd/blob/0ff0424d571ee74f4a9688744b89592fcbcac6e8/rules.d/20-dracut.rules#L4

[stevegrubb]

Yes, the threat model is stated in the README.md file. Protecting against root is impossible. Root can turn off the daemon or change it's rules. The purpose is to defend against unknown code before it can escalate to root.

The rule pointed to has to allow building the initramfs or you'll be pretty unhappy with kernel upgrades. The way its built is to copy all needed tools into the initramfs folder and then execute them from their new location. I really wished they did it differently so that we don't need this workaround. But at the end of the day, if you are root, you can do anything.

[zhackwyatt]

In my case, SELinux will block access to do any of that, as I am running with a custom policy. So we will modify our rule files. I guess it was just surprising because the rule has implications way beyond just Dracut.

[stevegrubb]

If you see any way to restrict it further, let me know. The freshly copied tools are untrusted since they are now in the new initramfs. Everyone is unhappy when kernel upgrades break.

[zhackwyatt]

I came up with the following. I am no means an expert, but it blocked an untrusted binary as root, so it seems better. I was also able to upgrade the kernel. Our system is not a general-purpose workstation, so it may not be appropriate.

# Allow most kernel threads
allow perm=execute uid=0 ppid=2 : all
# Allow remaining
allow perm=execute uid=0 : dir=/usr/bin/kmod trust=1
allow perm=execute uid=0 : dir=/usr/lib64 trust=1

deny_log perm=execute uid=0 trust=0 : all
deny_log perm=execute uid=0 trust=1 : trust=0

# Carve out an exception for dracut's initramfs building
allow perm=any uid=0 : dir=/var/tmp/
allow perm=any uid=0 trust=1 : all