Lower Process Capabilities
Steve Grubb
sgrubb at redhat.com
Sun Jul 26 23:32:36 UTC 2009
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
More information about the devel
mailing list