Features/LowerProcessCapabilities

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: Fedora 12
• Last updated: 2009-10-08
• Percentage of completion: 100%

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 harder 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: 555 /bin, 555 /lib, 000 /etc/shadow and so on. The current scope is to cover the directories in $PATH variable, library dirs, /boot, and /root. 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 with libcap-ng-utils installed.

1. System directories should have permissions of 0555. These are: /bin, /sbin, /usr/bin, /usr/sbin, /lib, /lib64, /usr/lib, /usr/lib64 and /root.
2. /etc/shadow & gshadow should have permissions of 0000
3. netcap should not show any common apps with full privs, DAC_OVERRIDE, or SETUID capabilities.
4. pscap should not show any common apps with full privs, or SETUID.
5. Exceptions to the rule would be login and cron type applications - sshd, login, gdm, kdm, and crond for example. Also the following apps are not confinable: console-kit-daemon, cups, postfix, rsyslog, auditd, audispd. The following have not been looked at: udev, hal-*, NetworkManager, wpa-supplicant.
6. Verify that normal functionality of each patched daemon still works (dhclient, gpm, smartd, bluetoothd, dbus, audisp-plugins, setroubleshootd, openswan, irqbalance).
7. Verify that a sysadmin logged in via e.g. ssh is still able to perform his/her "normal" activities
8. Verify that sudo still works as before

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.

Documentation

• http://people.redhat.com/sgrubb/libcap-ng

Filed Bugs

• filesystem/done https://bugzilla.redhat.com/show_bug.cgi?id=517575
• setup/done https://bugzilla.redhat.com/show_bug.cgi?id=517577
• dhclient/done https://bugzilla.redhat.com/show_bug.cgi?id=517649
• gpm/done https://bugzilla.redhat.com/show_bug.cgi?id=517659
• smartd/done https://bugzilla.redhat.com/show_bug.cgi?id=517728
• bluetoothd/done https://bugzilla.redhat.com/show_bug.cgi?id=517660
• dbus/done https://bugzilla.redhat.com/show_bug.cgi?id=518541

Packages Modified without tracker bz

• audit-2.0-1
• setroubleshoot-2.2.21-2
• openswan-2.6.22-1
• irqbalance-0.55-24

Release Notes

• Daemons running as root have been reviewed and patched to run with lower process capabilities. This reduces the desirability of using these daemons for privilege escalation. Additionally, the shadow file permissions have been changed to 000 and several directories in $PATH have been set to 555 in order to prevent daemons without DAC_OVERRIDE from being able to access the shadow file or write to the $PATH directories.

Comments and Discussion

• See Talk:Features/LowerProcessCapabilities