Traditional root model - why capabilities exist · Linux

The traditional Unix model has two privilege levels: root (UID 0) and non-root. Root can do anything; non-root cannot do privileged operations. This all-or-nothing model is the root of many security problems.

The problem with all-or-nothing root

When a service runs as root and is compromised:

The attacker has every privilege.
They can read any file, bind any port, kill any process, mount filesystems, load kernel modules.
The blast radius is the entire system.

A web server does not need to mount filesystems or load kernel modules. A database does not need to bind privileged ports. But under the all-or-nothing model, every root process has every privilege.

Capabilities

Linux capabilities split root into discrete pieces. Each capability is a single privileged operation:

CAP_NET_BIND_SERVICE: bind to ports < 1024.
CAP_SYS_ADMIN: mount filesystems, swapon, etc.
CAP_DAC_OVERRIDE: bypass file permission checks.
CAP_KILL: send signals to processes not owned by the user.
CAP_NET_RAW: use raw sockets (ping, tcpdump).
CAP_SYS_PTRACE: trace other processes.

There are around 40 capabilities. Each is a single, specific privilege.

Why capabilities matter

A web server that needs only CAP_NET_BIND_SERVICE to bind to port 80 (and the file capabilities to read its content) can run as a non-root user with just those capabilities. The blast radius of a compromise is limited to what the service actually needs.

# A web server running as non-root user 'www-data' with
# CAP_NET_BIND_SERVICE - can bind to port 80 but not much else

Capability sets

A process has several capability sets:

Permitted: the maximum capabilities the process may acquire.
Effective: the capabilities currently in effect.
Inheritable: capabilities inherited across exec.
Bounding: the maximum capabilities the process may ever acquire (kernel-wide limit).

A non-root process has empty sets by default. With file capabilities, a process can be granted specific capabilities.

Common capabilities

Capability	Allows
`CAP_NET_BIND_SERVICE`	Bind ports < 1024
`CAP_NET_RAW`	Raw sockets (ping, tcpdump, traceroute)
`CAP_SYS_ADMIN`	Mount, swapon, many admin operations
`CAP_DAC_OVERRIDE`	Bypass read/write/execute permission checks
`CAP_DAC_READ_SEARCH`	Bypass read permission checks
`CAP_KILL`	Send signals to other users’ processes
`CAP_SETUID`	Change UID (for setuid programs)
`CAP_SETGID`	Change GID
`CAP_SYS_PTRACE`	Trace processes (gdb, strace)
`CAP_SYS_RESOURCE`	Override resource limits
`CAP_SYS_TIME`	Set system clock
`CAP_NET_ADMIN`	Network configuration (interfaces, routes, firewall)
`CAP_SYS_RAWIO`	Raw I/O (port access, direct disk)
`CAP_MKNOD`	Create device files
`CAP_AUDIT_WRITE`	Write to the audit log

Inspect capabilities

# Process capabilities
grep Cap /proc/$$/status
# CapInh: 0000000000000000
# CapPrm: 0000000000000000
# CapEff: 0000000000000000
# CapBnd: 0000003fffffffff

# Decode
capsh --decode=0000003fffffffff

Set capabilities

# On a single-purpose service binary
sudo setcap cap_net_bind_service=+ep /usr/local/bin/myservice

The +ep means “effective and permitted”.

When to use capabilities

Use capabilities when:

A service needs one specific privilege (bind to port 80).
The service runs as a non-root user.
The capability can be granted as a file capability.

Use full root (or sudo) when:

The service needs many privileges.
The privilege is hard to enumerate.
The service runs interactively.