Tuesday, January 19, 2010

POSIX File Capabilities

Sometimes you need a particular program to do a specific task that requires administrative (root) privileges. You can run your program with sudo or chown your program to root and use the setuid bit (that allows to run a program with its owner uid). However, the setuid bit has serious security issues: if you are able to change the flow of execution of the program (and if the program does not drop his root privileges once no longer necessary), you can get a root shell.

More specifically, I needed a program to be able to create raw sockets without requiring full root privileges. It's possible! Using POSIX File Capabilities that relies on capabilities architecture.

First, install required packages (libcap2 and libcap2-bin on Debian). Second, your kernel must be supporting them as well as your file system (it should be the case per default). Then, you can manage capabilities with setcap and getcap (being root of course).

Usage as explained in setcap(8):
setcap capability1[,capability2][=-+][value] <filename>

Values are in the format defined by cap_from_text(3):
  • an operand +, - or = (just like in chmod)
  • e for effective (it has it)
  • p for permitted (allowed to have or obtain)
  • i for inherited (when it forks)

For instance, to be able to create raw sockets:
setcap cap_net_raw=ep <filename>

Or to be able to bind ports < 1024:
setcap cap_net_bind_service=ep <filename>

Both at the same time:
setcap cap_net_bind_service,cap_net_raw=ep <filename>

You can then view a file's capabilities with:
getcap <filename>

And remove capabilities with:
setcap -r <filename>

If you get a look at the manual capabilities(7), security is divided into several capabilities. You can now replace all setuid/setgid bits of programs with specific capabilities when possible.
We can expect this feature to be used by default in Linux distributions: Fedora applied capabilities since version 12 and archLinux is working towards it.



  1. Be careful, removing setuid bits can generate more security issues (for example race conditions).
    I wrote an article about the risks linked to file capabilities (escalating privileges, backdoor, instability, etc)

  2. Hello emeric and thank you for your comment.
    I have read your article, good work and I agree with you, it implies several security concerns that one should be aware of. Your article is a must-read on the subject.
    I am looking forward your next articles :)

  3. Thanks,
    I am currently building my website and at the same time writing a few articles.
    I do not think I will write something new about file capabilities in the next weeks. I am waiting to have some replies from the linux/security community about the first article.
    I had also tried to create a full capable system with very few system files belonging to root (to avoid escalation), but I didn't get anything great so far.