Understanding Linux Capabilities: Fine‑Grained Root Privilege Management

Linux Capabilities Overview

Linux is a secure operating system that assigns all system privileges to a single root user while giving ordinary users limited rights. Historically, privileged operations required either sudo or the SUID bit, which grants a file the full rights of its owner (usually root).

SUID vs. Capabilities

The SUID mechanism is opaque and expands the attack surface because any executable with the SUID bit runs with full root privileges. Linux introduced capabilities to split the monolithic root privilege into distinct functional groups that can be enabled or disabled per thread.

Capability Sets

Each thread has five capability sets, each represented by a 64‑bit mask:

Permitted : Upper bound of capabilities a thread may use.

Effective : Capabilities actually checked by the kernel for privileged operations.

Inheritable : Capabilities that may be passed to a new executable during execve().

Bounding : Superset of Inheritable; capabilities not present here cannot be added to Inheritable.

Ambient : Added in Linux 4.3 to retain capabilities across execve() without requiring the executable to be “capability‑aware”.

Typical capabilities include: CAP_AUDIT_CONTROL: Manage kernel audit. CAP_CHOWN: Change file ownership. CAP_DAC_OVERRIDE: Bypass file DAC restrictions. CAP_NET_BIND_SERVICE: Bind to ports < 1024. CAP_SYS_ADMIN: Perform system administration tasks.

Inheritance and Execve() Logic

When a thread executes execve(), the kernel computes the new capability sets using the following rules (simplified):

P'(ambient) = (file is privileged) ? 0 : P(ambient) P'(permitted) = (P(inheritable) & F(inheritable)) | (F(permitted) & P(bounding)) | P'(ambient) P'(effective) = F(effective) ? P'(permitted) : P'(ambient) P'(inheritable) = P(inheritable) P'(bounding) = P(bounding)

Key points:

For fork(), the child inherits the parent’s capabilities unchanged.

The file’s Inheritable set does not automatically become the thread’s Inheritable set; it must be added via capset().

When a non‑root user runs execve(), both Permitted and Effective sets are cleared unless SECBIT_KEEP_CAPS or SECBIT_NO_SETUID_FIXUP is set.

Practical Example: Using ping

If the ping binary has CAP_NET_RAW in its Permitted set, the capability is added to the thread’s Permitted set after execve(). If the binary is not capability‑aware, the Effective flag must be set to move the capability into the Effective set.

Docker & Kubernetes Use‑Case

bind() to 0.0.0.0:80 failed (13: Permission denied)

This error occurs when an nginx container runs as a non‑root user without the CAP_NET_BIND_SERVICE capability. To fix it, add the capability to the binary’s Inheritable set, enable the Effective flag, and declare the capability in the pod’s securityContext.capabilities section. If the binary is capability‑aware, adding the capability to its Inheritable set is sufficient.

Although Kubernetes does not yet support the Ambient set, it can be emulated manually.

Visual Aid

For further reading, see the Linux Capabilities man page and the listed references.