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