POSIX file capabilities, the dark side

This articles presents the dangers linked to the uprising of POSIX file capabilities.

Article published on 30 May 2010
last modification on 29 May 2016

by Emeric Nasi

Note: In order to understand this document it is strongly recommended you already know about POSIX capabilities. If not, read http://www.friedhoff.org/posixfilecaps.htm
Also the author supposes the reader have a good base about GNU Linux and security.
License : Copyright Emeric Nasi, some rights reserved
This work is licensed under a Creative Commons Attribution 4.0 International License.
Creative Commons License


Since kernel 2.6.25 Linux, capabilities processing is made easier. With the event of file capabilities combine with libcap2-bin tools (capsh, getpcaps, getcap, setcap), one can now reduce the exposure of superuser almighty power to hackers.
Some of the major Linux distributions such as Fedora are starting to use capabilities and have libcap2-bin tools enabled by default.
These tools can be use to improve security in these way :

  • Turn a setuid-root file into a file with minimum privileges
  • Run a service/daemon with uid other than 0 and minimum privileges
  • Run a service/daemon with uid=0 but with the minimum superuser privileges
  • Configure files so they can be accessed only by an admin or a process with the right privileges, and cannot be accessed by anyone else even unprivileged root.
  • Configure a file so that it does not have to be run by root to work properly.

However one must not be fooled by all this. Capabilities have some drawbacks.
I will first explain why capabilities can be dangerous.
Then I will show ways to circumvent capabilities and still hack system.
After that we will see how capabilities can be exploited by an attacker and thus generate more vulnerabilities

Note : Capabilities implies that superuser is not necessarily synonymous to root (uid=0). You can run a process as root that has no capabilities at all and vice-versa. That is why, when talking about superuser, I will rather use the term « superuser » than « root ».

This article has 12 pages, if you wish to read it download it here :