A binary has file capabilities instead of the setuid bit — does that make it harmless?
Short answer
No. File capabilities (set with setcap) split root's power into units, so a compromised program with one capability can do less damage than a setuid-root program, which gains all capabilities. But less is not none: CAP_SYS_ADMIN is overloaded and the man page says to avoid it, so review which capability was granted and why.
Engineers often treat "setcap instead of setuid" as a fix that ends the conversation. A good answer credits the improvement and still reviews the specific capability.
What capabilities change
The Linux man-pages explain that capabilities divide the privileges traditionally tied to superuser into distinct units that can be independently enabled and disabled. The stated goal is that if a program holding one or more capabilities is compromised, the damage it can do is less than the same program running as full root. Since Linux 2.6.24, capabilities can be attached to executables via extended attributes (setcap), an alternative to the setuid bit. A process running such a file gains just the granted capabilities, not all of them as a setuid-root program without file capabilities would.
Why it is not harmless
Capabilities vary in strength. CAP_NET_BIND_SERVICE lets an unprivileged program bind ports below 1024, a narrow, sensible grant. CAP_SYS_ADMIN is different: the man page warns not to choose it if you can avoid it, because a vast proportion of capability checks map to it. A binary holding it, or with a flaw in a capability-holding program, can still be a privilege-escalation path, so pentesters enumerate them (getcap -r /).
What interviewers want
"Smaller blast radius, not zero" — least privilege applied per capability.
Likely follow-ups
- How would you audit a Linux host for binaries that carry file capabilities?
- Why is CAP_SYS_ADMIN considered close to root, and what should you use instead?
- When would you choose CAP_NET_BIND_SERVICE over running a service as root?