POSIX Capabilities are a way to split full superuser privileges into smaller partitions of privileges. While the superuser is all-powerful, this wealth of privileges is typically not necessary for individual tasks.
Under Unix and related operating systems the superuser (commonly called
root) is all-powerful. Certain tasks need some of the superuser privileges. For instance,
/bin/ping needs the privilege to read and write raw IP packets. Usually only the superuser can do that. In order for ordinary users to run
/bin/ping, the program file is owned by
root and has the set-UID bit set. This will give
/bin/ping full superuser privileges. Thus, in addition to dealing with raw IP packets the process could install new system software, kill other processes etc. Another example is backup software that just needs to be able to read all files. In order to do that it is traditionally run with superuser privileges.
This all-or-nothing approach has ever attracted criticism because it violates the principle of least privilege – programs should have only the privileges they need to function. But assigning full superuser privileges to most programs is overkill. The risk is that if such a program is compromised (for example, by some buffer overflow with shell-code injection), then the whole system is compromised.
POSIX capabilities are a step toward the least-privilege principle. Capabilities can be assigned to programs much like the set-UID bit if the filesystem supports that. The tools to modify the capabilites are
getcap. For instance,
/bin/ping just needs the capability
CAP_NET_RAW. A backup program just needs the capability
CAP_DAC_READ_SEARCH. Compromised processes with limited capabilities cannot do much harm.
At least, that's the general idea. In practice the concept has some flaws, see CAP_SYS_ADMIN: the new root. In fact, it turns out that if a process has certain capabilities, it could elevate its privileges up to full superuser privileges, see False Boundaries and Arbitrary Code Execution.