What are Linux capabilities?

Capabilities split the all-or-nothing power of root into distinct units, so a process can be granted only the specific privileges it needs. For example, a web server can get CAP_NET_BIND_SERVICE to bind port 80 without running as root. They are managed per process and can be attached to executables as file capabilities.

Why is CAP_SYS_ADMIN considered dangerous?

CAP_SYS_ADMIN is a catch-all that grants dozens of unrelated privileged operations — mounting filesystems, setting the hostname, creating namespaces, managing quotas and more. Because it covers so much, granting it is effectively close to full root, and several known privilege-escalation paths run through it. Prefer a narrower capability whenever one exists.

How do I see and set a file's capabilities?

Use getcap on a binary to list its file capabilities and setcap to assign them, for example setcap cap_net_bind_service=+ep /usr/bin/myserver. A process's effective capabilities can be inspected via /proc/PID/status. Capabilities attached to a file are granted when it is executed, avoiding the need for setuid root.

Which capabilities were split out of CAP_SYS_ADMIN?

Kernel 5.8 introduced CAP_BPF for loading BPF programs and CAP_PERFMON for performance monitoring, both previously requiring CAP_SYS_ADMIN. Kernel 5.9 added CAP_CHECKPOINT_RESTORE for checkpoint/restore operations. These splits let tools like profilers and eBPF agents run with much narrower privilege than before.

Are capabilities a complete sandbox?

No. Capabilities restrict privileged operations but do not isolate a process the way namespaces, seccomp filters and cgroups do. Real container security combines dropped capabilities with a seccomp profile, user namespaces and mandatory access control. Treat capabilities as one layer of defense in depth, not the whole sandbox.

Linux Capabilities Reference

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Linux capabilities break the monolithic privilege of root into individual, grantable units. Instead of running a whole program as root to do one privileged thing, you grant just the capability it needs. This reference lists the capability constants with the exact power each confers and a risk rating.

How it works

Each capability is a named bit (e.g. CAP_NET_BIND_SERVICE) that authorizes a specific class of privileged operations. A process carries several capability sets — permitted, effective, inheritable, bounding and ambient — that together decide which privileges are active. Executables can also carry file capabilities, granted on exec, which replace the old setuid-root pattern.

The risk rating here is practical guidance: some capabilities are narrow and safe (CAP_NET_BIND_SERVICE), while others — CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_BPF, CAP_DAC_OVERRIDE — are powerful enough to be treated as equivalent to full root.

Example

To let a service bind port 443 without root, drop all capabilities and grant only the one it needs:

setcap cap_net_bind_service=+ep /usr/local/bin/myserver
getcap /usr/local/bin/myserver
# /usr/local/bin/myserver cap_net_bind_service=ep

The binary can now bind privileged ports while running as an unprivileged user.

Notes

Inspect a running process with cat /proc/PID/status | grep Cap and decode the hex masks with capsh --decode=<hex>.
Dropping capabilities in a container (--cap-drop=ALL then --cap-add only what you need) dramatically shrinks the attack surface.
CAP_SYS_PTRACE lets a process read any other process’s memory — keep it out of multi-tenant environments.
Capabilities pair with seccomp, namespaces and cgroups; alone they are not a full sandbox.