Capabilities model

For many operations on Linux, the object permission model doesn't quite fit. For instance, changing UID and GID requires some magical USER known as root. Suppose you have a long running service that needs to utilize some of these capabilities. Perhaps this service listens to kernel events and creates the device nodes for you? Such a service exists, and it's called ueventd or user event daemon. This daemon traditionally runs as root, which means if it is compromised, it could potentially read your private keys from your home directory and send them back to the attacker. This might be an extraordinary example, but it's meant to showcase that running processes as root can be dangerous. Suppose you could start a service as the root user and have the process change its UID and GID to something not privileged, but retain some smaller set of privileged capabilities to do its job? This is exactly what the capabilities model in Linux is.

The capabilities model in Linux is an attempt to break down the set of permissions that root has into smaller subsets. This way, processes can be confined to the set of minimum privileges they need to perform their intended function. This is known as least privilege, a key ideology when securing systems that minimizes the amount of damage a successful attack can do. In some instances, it can even prevent a successful attack from occurring by blocking an otherwise open attack vector.

There are many capabilities. The man page for capabilities is the de facto documentation. Let's take a look at the CAP_SYS_BOOT capability:

$ man capabilities
...
CAP_SYS_BOOT
 Use reboot(2) and kexec_load(2).

This means a process running with this capability can reboot the system. However, that process can't arbitrarily change USERS and GROUP as it could if it was running as root or with CAP_DAC_READ_SEARCH. This limits what an attacker can do:

<FROM MAN PAGE>
CAP_DAC_READ_SEARCH
 Bypass file read permission checks and directory read and execute permission checks.

Now suppose the case where our restart process runs with CAP_CHOWN. Let's say it uses this capability to ensure that when a restart request is received, it backs up a file from each user's home directory to a server before restarting. Let's say this file is ~/backup, the permissions are 0600, and USER and GROUP are the respective user of that home directory. In this case, we have minimized the permissions as best we can, but the process could still access the users SSH keys and upload those either by error or attack. Another approach to this would be to set the group to backup and run the process with GROUP backup. However, this has limitations. Suppose you want to share this file with another user. That user would require a supplementary group of backup, but now the user can read all of the backup files, not just the ones intended. An astute reader might think about the bind mounts, however the process doing the bind mounts and file permissions also runs with some capability, and thus suffers from this granularity problem as well.

The major issue, and the case for another access control system can be summarized by one word, granularity. The DAC model doesn't have the granularity required to safely handle complex access control models or to minimize the amount of damage a process can do. This is particularly important on Android, where the entire isolation system is dependent on this control, and a rogue root process can compromise the whole system.