xref: /aosp_15_r20/external/libcap/doc/capability.md (revision 2810ac1b38eead2603277920c78344c84ddf3aff)

# Notes concerning wider use of capabilities

## Overview

**NOTE** These notes were added to the libcap package in
libcap-1.03. They pre-date file capability support, but fully
anticipate it. They are some thoughts on how to restructure a system
to better leverage capability support. I've updated them to render as
an `.md` formatted file.

As of Linux 2.2.0, the power of the superuser has been partitioned
into a set of discrete capabilities (in other places, these
capabilities are know as privileges).

The contents of the libcap package are a library and a number of
simple programs that are intended to show how an application/daemon
can be protected (with wrappers) or rewritten to take advantage of
this fine grained approach to constraining the danger to your system
from programs running as 'root'.

## Notes on securing your system

### Adopting a role approach to system security

Changing all of the system binaries and directories to be owned by
some user that cannot log on. You might like to create a user with
the name 'system' who's account is locked with a '*' password. This
user can be made the owner of all of the system directories on your
system and critical system binaries too.

Why is this a good idea? In a simple case, the `CAP_FOWNER` capability
is required for the superuser to delete files owned by a non-root user
in a _sticky-bit_ protected non-root owned directory. Thus, the sticky
bit can help you protect the `/lib/` directory from a compromized
daemon where the directory and the files it contains are owned by the
system user. It can be protected to ensure that the daemon is not
running with the `CAP_FOWNER` capability...

### Limiting the damage

If your daemon only needs to be setuid-root in order to bind to a low
numbered port. You should restrict it to only having access to the
`CAP_NET_BIND_SERVICE` capability. Coupled with not having any files
on the system owned by root, it becomes significantly harder for such
a daemon to damage your system.

Note, you should think of this kind of trick as making things harder
for a potential attacker to exploit a hole in a daemon of this
type. Being able to bind to any privileged port is still a formidable
privilege and can lead to difficult but _interesting_
man-in-the-middle attacks -- hijack the telnet port for example and
masquerade as the login program... Collecting passwords for another
day.

### The /proc/ filesystem

This Linux-specific directory tree holds most of the state of the
system in a form that can sometimes be manipulated by file
read/writes.  Take care to ensure that the filesystem is not mounted
with uid=0, since root (with no capabilities) would still be able to
read sensitive files in the `/proc/` tree - `kcore` for example.

[Patch is available for 2.2.1 - I just wrote it!]