Feature Name
Lower Process Capabilities
Summary
This feature will lower the capabilities of all root daemons and many setuid apps. File and directory permissions may be reworked to require DAC_OVERRIDE for any system update.
Owner
- Name: Steve Grubb
- email: <sgrubb@redhat.com>
Current status
- Targeted release: [[Template:Fedora12 ]]
- Last updated: June 23
- Percentage of completion: 20%
Detailed Description
When someone attacks a system, they normally can't do much unless they can escalate privileges. What this feature will do is reduce the number of attack targets that can be used to escalate privileges. If root processes do not have all capabilities, they will be hard to use to subvert the system.
But if some does successfully attack a root process, can steps be taken to render it hard to take advantage of? The answer is yes. Processes with the root uid can still damage a system. This is because they can write to nearly any file and of course read the /etc/shadow file. But if we harden the system so that root requires the DAC_OVERRIDE capability, then only a limited number of processes can damage the system. This won't affect any admin abilities because they always get full privileges which includes DAC_OVERRIDE.
A hardened system would have permissions like: 005 /bin, 005 /etc, 000 /etc/shadow and so on. This scheme does not affect selinux in any way and complements it since capabilities are DAC controls and they have first vote on allowing an access.
Benefit to Fedora
The benefit is that Fedora is more secure.
Scope
The scope for this is system wide.
I have created a new app, netcap, that can show network facing apps that have privilges. I would like to reduce capabilities on everything that is in the minimal platform install to start with and then work outwards to daemons that are commonly used. These apps will be patched to use the libcap-ng program to lower capabilities.
Next, I would like to use the pscap program to find apps that have privileges that are not network facing. They should drop capabilities, too.
Lastly, I would like to change the default permissions of a lot of directories to require DAC_OVERRIDE to write into. Certain trusted databases in the /etc directory tree should also be set for 0000 permissions.
Of particular concern is the /etc/resolve.conf file. We do not want to give DAC_OVERRIDE to any network facing daemons as they will be attack targets. So we will need to move resolve.conf to a directory owned by a dedicated acct that any dhcp clients would run under. They will be able to write the file. There should probably be a symlink to the old location during transition so that systems still work.
How To Test
This can be tested on any and all systems.
1. netcap should not show any common apps with full privs, DAC_OVERRIDE, or SETUID capabilities. 2. pscap should not show any common apps with full privs, or SETUID. 3. Exceptions to the rule would be login and cron type applications - sshd, login, gdm, kdm, and crond for example. 4. Directory permissions for system directories should not allow writing to unless DAC_OVERRIDE is possesed. This would be directories like /etc, /var, /bin, /sbin, /usr/bin, /lib, lib64 and so on.
User Experience
They should not notice any changes or problems. It should be invisible to them. if they looked at file permissions, they will notice them being different.
Dependencies
There are many dependencies as this touches many programs.
Contingency Plan
Achieving this for the minimal install is within reach. Anything beyond that is really icing on the cake. The granularity of the project is at the package level and not finishing would just leave some apps working like they always did. We can fix them some other day.
The critical pieces is libcap-ng library, getting directory permissions changed, getting critical file permissions changed, patching network facing apps, then patching internal apps, setuid apps, and finally apps that root might use to read untrusted data.