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 http://www.linuxjournal.com/node/5737/print fails as show here # execcap 'cap_net_raw=ep' sucap nobody nobody xping www.yahoo.com Caps: =ep Caps: = [debug] uid:99, real uid:99 Caps: =ep 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 http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/libcap-1.10.tar.gz 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): 2.6.9-34.0.EL 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 bug report: http://www.gossamer-threads.com/lists/engine?do=post_view_printable;post=562021;list=linux
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