Linux capabilities: the practical guide

Capabilities in 60 seconds#

Traditionally, a binary either ran as root (all powers) or as you (few powers). Capabilities break root's powers into ~40 fine-grained units — CAP_NET_RAW, CAP_SYS_ADMIN, and so on — that can be attached to specific files. A binary with CAP_SETUID can change UIDs; one with CAP_DAC_READ_SEARCH can read any file. Useful for least privilege — dangerous when attached to the wrong binary.

What LinPEAS reports#

LinPEAS has a dedicated capabilities section: it runs the equivalent of a recursive getcap sweep and highlights binaries carrying capabilities, colouring the interesting ones. Treat it like the SUID section — a shortlist to verify by hand, not a verdict. Our SUID guide covers the sibling technique; the triage discipline is identical.

The dangerous ones#

Anything on a binary you do not recognise deserves investigation; the table above is the "drop everything and look" shortlist.

Verifying manually#

getcap -r / 2>/dev/null          # list every file with capabilities
capsh --decode=00000000a80425fb   # decode a capability mask into names
getcap /usr/bin/python3           # inspect one binary

Compare LinPEAS's list against your own getcap sweep — they should agree. Then ask of each binary: does this program legitimately need this power? A text editor with CAP_DAC_OVERRIDE is a finding; a container runtime with CAP_SYS_ADMIN may be by design.

From finding to root (lab only)#

The exploitation pattern mirrors SUID abuse: a binary with a powerful capability can be coaxed into doing a privileged thing on your behalf — reading a protected file, writing somewhere root-owned, or spawning a shell with elevated privilege. Public technique references such as GTFOBins document per-binary abuse paths; work them in your lab, and confirm each step before moving on.

Fixing capability findings#

• Drop unneeded capabilities: setcap -r /path/to/binary removes them all.
• Prefer narrow sudo rules or dedicated service accounts over broad capabilities.
• Re-run getcap -r / after changes and diff against the baseline.
• Treat CAP_SYS_ADMIN on any non-infrastructure binary as a misconfiguration until proven otherwise.

Where capabilities hide in modern stacks#

Capabilities matter most in two places. First, containers: container runtimes grant sets of capabilities to containers, and an over-privileged container (or a --privileged one) hands you host-level power — which is why LinPEAS's container section and its capabilities section should be read together. Second, custom binaries: in-house tools compiled with capabilities attached are a classic finding because nobody remembers they are there.

Decoding what you see#

LinPEAS and getcap show capabilities in two forms: names (cap_sys_admin+ep) and sometimes raw hex masks. The +ep suffix means the capability is effective and permitted — i.e. actually usable right now. Decode unfamiliar masks explicitly rather than guessing:

capsh --decode=00000000a80425fb

If a mask decodes to something on the dangerous list and the binary does not obviously need it, you have a finding worth a ticket — on your own hosts — or a vector — in your lab.