Red Hat Bugzilla – Bug 200027
Linux Capabilities are Broken
Last modified: 2007-11-30 17:07:26 EST
Description of problem:
Linux capabilities are broken in the update 3 kernel!
1) Using the 'sysctl()' system call it is possible to set
'kernel.cap-bound' to 0xFFFFFFFF even from a PID other
than PID 1.
2) 'execcap' no longer works. The example from
fails as show here
# execcap 'cap_net_raw=ep' sucap nobody nobody xping www.yahoo.com
[debug] uid:99, real uid:99
ping: icmp open socket: Operation not permitted
Note that 'xping' is a copy of /sbin/ping *without*
SUID 'root' set.
Tried this with recompiled utilities from
and get exact same results.
Also experimented with running 'sleep 30' with 'execcap/sucap'
and viewing the result with 'getpcaps'. Appears that capabilites
are always stripped away despite 'sucap'.
Version-Release number of selected component (if applicable):
Tried it with both 'x86_64' and 'i386'.
Ack! I see it's broken by design. I guess since capabilities
never caught on (too complex for the typical SA), they decided
to break it rather than correct the security holes that were
uncovered. Here's some info for others that trip over this
Hi, David. While I was unable to view the link in comment #1, I can
understand why some people view Linux's resetting of a task's capability
mask on exec() as an undesirable implementation.
However, it is possible to use capabilities constructively under Linux.
The basic idea is that an application must be setuid-to-root, and then
that app should downgrade its capabilities to its minimum required set.
I'll attach a code segment for demonstrating this in the next comment.
Created attachment 141124 [details]
demonstration of downgrading capabilities for setuid-to-root program