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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
