find linux capabilities with getcap

why "root" isn't always all or nothing

for a long time, linux permissions were pretty binary. you were either root, meaning you could do literally anything to the system, or you were a regular user with a much smaller set of powers. that's a problem when a program only needs one tiny root-level ability, like binding to a low network port, but the easiest fix used to be "just run it as root." that's like giving someone the master key to your entire building because they need to open one closet.

linux capabilities were built to fix that. instead of the all-or-nothing root switch, root's power got split into dozens of individual permissions, called capabilities, that can be handed out one at a time. a program can get exactly the privilege it needs and nothing else. great idea in theory. in practice, it also means capabilities can quietly pile up on binaries across your system, and most people never check.

the command: getcap -r / 2>/dev/null

this is the tool you use to actually see what's been granted. let's break it down piece by piece.

getcap -r / 2>/dev/null

getcap is the utility that reads capability metadata off files. capabilities aren't stored as a permission bit like read/write/execute, they're stored as extended attributes on the file itself, so you need a dedicated tool to see them.

-r means recursive. without it, getcap only checks a single file or directory you point it at. with it, it walks through every subdirectory starting from wherever you tell it to start.

/ is the starting point, in this case the entire filesystem, root directory down. so this command is saying "walk the whole disk and report every file that has capabilities attached."

2>/dev/null is just cleanup. scanning the entire filesystem means you'll hit directories you don't have permission to read, and normally that throws a wall of "permission denied" errors to your screen. redirecting file descriptor 2, which is stderr, to /dev/null just throws those errors away so you only see actual results.

what the output actually tells you

when you run it, you'll get lines like this:

/usr/bin/ping = cap_net_raw+ep
/usr/bin/mtr-packet = cap_net_raw+ep

that's a filepath, followed by which capability it has, followed by a flag showing how it's applied. cap_net_raw is a good example because it's everywhere. it lets a program create raw network sockets, which normally requires root, but ping only needs that one specific ability, not full root. that's the capabilities system working exactly as designed.

the "+ep" part matters too. e means effective, the capability is active right now when the program runs. p means permitted, the program is allowed to use it. you may occasionally see i for inheritable, meaning child processes can pick it up too. that last one is worth extra attention when you're auditing.

why defenders actually care about this list

here's the thing about capabilities: they're supposed to be more restrictive than full root, and usually they are. but some capabilities are basically root in a trenchcoat. cap_setuid lets a process change its own user id, which can mean becoming root. cap_dac_override lets a process ignore file read/write permission checks entirely. if either of those shows up on a binary you don't recognize, or on something sitting in a weird location like /tmp or a user's home directory, that's a real finding, not a false positive.

the honest reason this list grows without anyone noticing is convenience. someone installs a tool, a setup script grants a capability to make something "just work," and it never gets revisited. software gets uninstalled but the capability sometimes lingers on a leftover binary. none of this shows up in a normal permissions audit because most people are only checking suid bits and file ownership, not extended attributes.

how to actually secure this on your own machine

run the scan, then actually read the output instead of skimming it.

getcap -r / 2>/dev/null

for each result, ask two questions. do i recognize this binary and know why it needs this capability, and is this capability appropriate for a small, specific job versus something that's effectively full root access. anything you can't explain, research it before you decide whether to keep it.

if you find a capability that shouldn't be there, you can strip it with:

setcap -r /path/to/binary

that removes all capabilities from the file. do this on a system you own or manage, and ideally test in a non-production environment first in case something actually depended on it.

the takeaway

capabilities exist to make linux safer by breaking root's power into smaller pieces. that's a genuinely good design. the tradeoff is that those pieces can accumulate quietly and nobody checks them the way they check for suid binaries or open ports. run getcap on your own systems, know what's on that list and why, and strip anything you can't justify. five minutes now is a lot cheaper than finding out the hard way later.