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.

What is the Linux Capabilities Reference?

Searchable Linux capabilities reference covering CAP_NET_BIND_SERVICE, CAP_SYS_ADMIN, CAP_SYS_PTRACE, CAP_BPF and the rest, with the exact privilege each grants, a typical use case, and a low/medium/high risk rating. It runs free in your browser on Gera Tools, with nothing uploaded.

Linux Capabilities Reference

Name: Linux Capabilities Reference
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click 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.

Key capabilities at a glance

Capability	What it grants	Risk
`CAP_NET_BIND_SERVICE`	Bind ports below 1024	Low
`CAP_NET_RAW`	Use raw and packet sockets	Medium
`CAP_DAC_OVERRIDE`	Bypass file read/write/exec DAC checks	High
`CAP_SYS_PTRACE`	Trace any process, read its memory	High
`CAP_SYS_ADMIN`	~30 unrelated operations; near-root	High
`CAP_SYS_MODULE`	Load and unload kernel modules	High
`CAP_BPF`	Load BPF programs (kernel 5.8+)	Medium–High
`CAP_CHECKPOINT_RESTORE`	Checkpoint/restore operations (kernel 5.9+)	Medium

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.

Practical workflow: drop all, add only what you need

The safest approach for containers and system services is to start with no capabilities and add back only what the code actually calls. For Docker:

docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE myimage

For systemd services, use AmbientCapabilities=CAP_NET_BIND_SERVICE in the unit file with User=myservice to gain the same effect without touching the binary.

Inspecting capability state

To see what capabilities a running process holds, read its /proc entry and decode the hex bitmask:

cat /proc/$(pgrep myservice)/status | grep Cap
# CapInh: 0000000000000000
# CapPrm: 0000000000000400
# CapEff: 0000000000000400
# CapBnd: 000001ffffffffff

capsh --decode=0000000000000400
# 0x0000000000000400=cap_net_bind_service

The effective set (CapEff) is what is actually active right now; the bounding set (CapBnd) caps what the process can ever gain.

Notes

CAP_SYS_PTRACE lets a process read any other process’s memory — keep it out of multi-tenant environments and never grant it in shared containers.
Kernel 5.8 split CAP_BPF and CAP_PERFMON out of CAP_SYS_ADMIN, so modern profilers and eBPF tools can run narrowly privileged.
Capabilities pair with seccomp profiles, user namespaces, and cgroups; alone they are not a full sandbox — treat them as one layer in a defense-in-depth stack.