Lower Process Capabilities

[Steve Grubb]

Hello,

I wanted to send an email to give everyone a heads up about a project I'm 
working on. You can find the write-up here:

https://fedoraproject.org/wiki/Features/LowerProcessCapabilities

The basic idea goes something like this: We would like to do something to 
prevent priv escalation for processes running as root. For this example, lets 
take cupsd to be a good case in point. If the attacker can find a vuln with 
cupsd, then they can have root privs and all that goes with it. (SE Linux may 
prevent total compromise, but some people turn it off.)

What can be done is that we program the application to drop some of the 
capabilities so that its not all powerful. There's just one flaw in this plan. 
The directory for /bin is 0755 root root. So, even if we drop all 
capabilities, the root acct can still trojan a system. 

If we change the bin directory to 005, then root cannot write to that 
directory unless it has the CAP_DAC_OVERRIDE capability. The idea with this 
project is to not allow network facing or daemons have CAP_DAC_OVERRIDE, but 
to only allow it from logins or su/sudo.

This will fundamentally change the permissions you see when doing ls -l, but 
it will work as it always did for admins. If you wanted to test this out for 
yourselves, you can setup a VM and run the following commands:

echo "Hardening files..."
find / -type f -perm /00700 -a -uid 0 -exec chmod u-wrx {} \; 2>/dev/null
find / -type f -perm /00070 -a -gid 0 -exec chmod g-wrx {} \; 2>/dev/null
echo "Hardening directories..."
find / -type d -perm /00200 -a -uid 0 -exec chmod u-w {} \; 2>/dev/null
find / -type d -perm /00020 -a -gid 0 -exec chmod g-w {} \; 2>/dev/null
echo "Correcting a couple things..."
find /sbin -type f -perm /00000 -a -uid 0 -exec chmod u+x {} \; 2>/dev/null
find /usr/sbin -type f -perm /00000 -a -uid 0 -exec chmod u+x {} \; 2>/dev/null

This project also plans to set the permissions for /etc/shadow and 
/etc/gshadow to 0000 so that daemons running as root, but without DAC_OVERRIDE 
cannot read the shadow file. Login, [gkx]dm, and sshd will still have 
DAC_OVERRIDE or this wouldn't work.

Does a system running like this still work? Yes it does. But there is still 
one rough spot. That is the /etc/resolve.conf file. The problem is that if we 
follow the new theory of only allowing system updates with DAC_OVERRIDE, then 
root daemons cannot update dynamically created files. The solution to this is 
to move those into a directory owned by an account other than root and have 
the daemon running under that account to write the file.

This would mean that anything that writes to /etc/resolve.conf, would need to 
run under this new acct. And /etc/resolve.conf would need to be moved to 
something like /etc/resolve/resolve.conf. And then that is symlinked back to 
/etc/resolve.conf for the transition.

The last phase of the project is to play whack-a-mole and fix permission 
problems in packages that specify file permissions explicitly. The plan is to 
cover @core files first as I would like to make the minimal install work first 
and then branch out to other use cases.

Asbestos underwear is firmly in place. Let me know if any one has concerns. 
Also please try out the script above on a VM before posting so that you can 
assure yourself that everything still works. :)

Thanks,
-Steve