1# Notes concerning wider use of capabilities 2 3## Overview 4 5**NOTE** These notes were added to the libcap package in 6libcap-1.03. They pre-date file capability support, but fully 7anticipate it. They are some thoughts on how to restructure a system 8to better leverage capability support. I've updated them to render as 9an `.md` formatted file. 10 11As of Linux 2.2.0, the power of the superuser has been partitioned 12into a set of discrete capabilities (in other places, these 13capabilities are know as privileges). 14 15The contents of the libcap package are a library and a number of 16simple programs that are intended to show how an application/daemon 17can be protected (with wrappers) or rewritten to take advantage of 18this fine grained approach to constraining the danger to your system 19from programs running as 'root'. 20 21## Notes on securing your system 22 23### Adopting a role approach to system security 24 25Changing all of the system binaries and directories to be owned by 26some user that cannot log on. You might like to create a user with 27the name 'system' who's account is locked with a '*' password. This 28user can be made the owner of all of the system directories on your 29system and critical system binaries too. 30 31Why is this a good idea? In a simple case, the `CAP_FOWNER` capability 32is required for the superuser to delete files owned by a non-root user 33in a _sticky-bit_ protected non-root owned directory. Thus, the sticky 34bit can help you protect the `/lib/` directory from a compromized 35daemon where the directory and the files it contains are owned by the 36system user. It can be protected to ensure that the daemon is not 37running with the `CAP_FOWNER` capability... 38 39### Limiting the damage 40 41If your daemon only needs to be setuid-root in order to bind to a low 42numbered port. You should restrict it to only having access to the 43`CAP_NET_BIND_SERVICE` capability. Coupled with not having any files 44on the system owned by root, it becomes significantly harder for such 45a daemon to damage your system. 46 47Note, you should think of this kind of trick as making things harder 48for a potential attacker to exploit a hole in a daemon of this 49type. Being able to bind to any privileged port is still a formidable 50privilege and can lead to difficult but _interesting_ 51man-in-the-middle attacks -- hijack the telnet port for example and 52masquerade as the login program... Collecting passwords for another 53day. 54 55### The /proc/ filesystem 56 57This Linux-specific directory tree holds most of the state of the 58system in a form that can sometimes be manipulated by file 59read/writes. Take care to ensure that the filesystem is not mounted 60with uid=0, since root (with no capabilities) would still be able to 61read sensitive files in the `/proc/` tree - `kcore` for example. 62 63[Patch is available for 2.2.1 - I just wrote it!] 64