Giving an application full root access just so it can do one privileged thing — bind to port 80, capture network packets, change file ownership — is a classic case of over-permissioning. Linux capabilities exist to fix exactly that problem. Instead of an all-or-nothing root grant, capabilities let you hand a process or executable a single, specific slice of root’s power. This guide explains how capabilities work, how to assign and audit them safely, and how a misconfigured one can quietly become a privilege-escalation path.

Table of Contents

1. What Linux Capabilities Actually Are
2. Assigning and Checking Capabilities
3. Understanding the Flags: Effective, Inheritable, Permitted
4. Practical Examples
5. Important Capabilities to Know
6. The Security Risk: How Capabilities Get Abused
7. Best Practices for Managing Capabilities
8. Conclusion

---

What Linux Capabilities Actually Are

Traditionally, Linux processes are split into two categories: normal, unprivileged processes, and privileged processes running as UID 0 (root), which bypass nearly every permission check in the kernel. That binary split is convenient but dangerous — a service that only needs to open port 443 has no business also being able to load kernel modules or read every file on disk, yet running it as root grants exactly that.

Capabilities break root’s power into distinct units, each governing one category of privileged operation: manipulating network interfaces, binding to reserved ports, overriding filesystem permissions, and dozens more. A capability can be attached either to a running process or directly to an executable file, so the program gains only the narrow privilege it actually needs — never the rest of what root could do.

Assigning and Checking Capabilities

Two commands handle the day-to-day work:

• setcap — assigns capabilities to an executable file.
• getcap — displays the capabilities currently assigned to a file.

The basic syntax for assigning a capability is:

sudo setcap cap_name+flag executable_file

• cap_name is the specific capability being granted (see the list further down).
• flag controls how the capability is applied — effective, inheritable, or permitted (explained in the next section).

To check what’s assigned to a specific binary:

getcap /path/to/file

And to audit an entire system for every file carrying a capability — genuinely useful during a security review or a CTF enumeration pass:

getcap -r / 2>/dev/null

This recursively scans the filesystem and silences permission-denied noise, giving you a clean list of every capability-bearing executable on the machine.

Understanding the Flags

Each capability grant is qualified by one or more flags that determine exactly how it behaves:

• +e (Effective): The capability is active immediately when the program runs.
• +i (Inheritable): The capability can be passed down to child processes spawned by this executable.
• +p (Permitted): The capability is allowed for the executable, forming the ceiling of what it’s authorized to activate.

In practice, most real-world examples combine e and p (+ep), which grants the capability and makes it immediately active. That combination is worth recognizing on sight, because it’s also the combination attackers look for when hunting for exploitable binaries.

Practical Examples

Letting a web server bind to a privileged port without running as root. Ports below 1024 are reserved for root by default. Rather than running an entire web server as UID 0 just to open port 80, grant it the one capability it actually needs:

sudo setcap cap_net_bind_service=+ep /usr/bin/nginx

Allowing a script to reboot the system. A maintenance script that needs to trigger a restart doesn’t need full root — just this:

sudo setcap cap_sys_boot=+ep /usr/bin/my_script

Granting network administration rights. A tool that configures IP addresses or routing tables can be scoped to exactly that:

sudo setcap cap_net_admin=+ep /usr/bin/network_tool

Capturing raw network packets. Diagnostic tools like tcpdump traditionally required root to sniff traffic; a capability removes that requirement:

sudo setcap cap_net_raw=+ep /usr/sbin/tcpdump

Changing file ownership. A program that legitimately needs to chown files on behalf of users can be granted just that:

sudo setcap cap_chown=+ep /usr/bin/chown_tool

Important Capabilities to Know

Capability	What It Allows
cap_chown	Change the owner of any file
cap_dac_override	Bypass file read/write permission checks entirely
cap_dac_read_search	Bypass file read and directory search checks specifically
cap_fowner	Bypass ownership checks for most file operations
cap_kill	Send signals to processes owned by other users
cap_setuid	Change a process’s user ID
cap_setgid	Change a process’s group ID
cap_sys_admin	A very broad grant covering many system administration operations
cap_sys_ptrace	Attach a debugger to, and inspect, other users’ processes

Notice how broad some of these are. cap_dac_override and cap_sys_admin in particular are close enough to full root that granting them casually defeats much of the point of using capabilities in the first place.

The Security Risk

Capabilities are a genuine security improvement over blanket root access — but only when applied narrowly. Misconfigured capabilities are a well-documented privilege escalation vector, and security auditors and penetration testers routinely check for them for exactly that reason.

Here’s a concrete illustration of why. Suppose a root-owned file like /var/backups/.old_pass.bak is readable only by root, and an unprivileged user has no direct way to access it. If that same user finds a binary — say tar — that has been granted cap_dac_read_search (a capability that bypasses read and directory-search permission checks), they can use it to read the protected file indirectly:

getcap -r / 2>/dev/null
# reveals: /home/user/tar = cap_dac_read_search+ep

./tar -cf pass.tar /var/backups/.old_pass.bak   # archive the protected file
./tar -xf pass.tar                              # extract it, now readable

Because tar itself is carrying the capability, it can reach into the protected file on the user’s behalf — even though the user running it has no such permission themselves. This isn’t a flaw in tar; it’s a flaw in whoever granted that capability to a general-purpose archiving tool without considering what else it could be used for. Security researchers maintain public references — most notably the GTFOBins project — cataloging exactly which common binaries become dangerous when paired with which capabilities, precisely so administrators and auditors can check their own systems against known patterns.

Best Practices for Managing Capabilities

• Grant the narrowest capability that solves the problem. If a program only needs to bind to a low port, give it cap_net_bind_service — not cap_sys_admin “just in case.”
• Avoid capabilities on general-purpose binaries. Tools like tar, vim, python, and perl are powerful and flexible by design, which is exactly what makes them dangerous to grant elevated capabilities to — they can usually be repurposed to read, write, or execute far beyond their original intent.
• Audit regularly. Run getcap -r / 2>/dev/null periodically, especially after installing new packages or restoring backups, and investigate anything unexpected.
• Prefer capabilities over SUID where possible. A SUID binary runs entirely as root; the equivalent binary with a narrow capability only gets the one privilege it needs, meaningfully shrinking the blast radius if it’s ever exploited.
• Document every grant. Keep a record of which binaries have which capabilities and why, so an unfamiliar entry during an audit stands out immediately instead of blending in.
• Treat cap_dac_override, cap_dac_read_search, cap_setuid, and cap_sys_admin as high-risk by default. These four are the ones most frequently abused for privilege escalation, so any binary carrying them deserves extra scrutiny.

Frequently Asked Questions

Do capabilities replace sudo? No. sudo controls which users can run which commands with elevated rights, typically for interactive administration. Capabilities control what a specific executable can do at the kernel level, regardless of who runs it. The two solve different problems and are often used together.

Are capabilities specific to a distribution? No — capabilities are a Linux kernel feature (libcap), not a distribution feature, so setcap and getcap behave the same way on Debian, Ubuntu, RHEL, Fedora, and Arch alike, though the package providing them may have a different name.

Do capabilities work inside containers? Yes, and this matters more than most admins expect. Container runtimes like Docker grant a default set of capabilities to every container by default. Reviewing and trimming that default set — via --cap-drop and --cap-add — is one of the highest-value, lowest-effort container hardening steps available.

What happens if I remove a capability by mistake? The program simply loses that specific privilege and will fail or fall back to unprivileged behavior wherever it needed it — it won’t affect the rest of the binary’s normal, unprivileged functionality.

Conclusion

Linux capabilities are one of the more elegant tools available for reducing how much root access your services actually need — turning an all-or-nothing decision into a precise, auditable grant. Used deliberately, they shrink your attack surface. Used carelessly — especially on flexible, general-purpose binaries — they can hand an attacker a direct path from an unprivileged shell to full system compromise. The difference between the two outcomes almost always comes down to one habit: auditing what’s actually been granted, and asking whether it still needs to be.