ANN: capwrap - grant capabilities to executables

I've written a small module¹ that enables the use of Linux capabilities on filesystems that do not support them. It is similar in spirit to ELF capabilities hack² but is not specific to the ELF executable format and is implemented as separate kernel module.

To grant capabilities to an executable, a small wrapper file is created that includes the path to an executable followed a capability set written in hexadecimal. When this file is executed by the kernel, the executable is granted the specified capabilities. The wrapper file must be owned by root and have the SUID bit set.

For example, to remove the SUID bit on the ping program while retaining its functionality:

    # chmod -s /bin/ping
    # mv /bin/ping /bin/ping_real
    # echo '&/bin/ping_real 2000' > /bin/ping
    # chmod +xs /bin/ping

Comments welcome.

Neil

¹ http://arctrix.com/nas/linux/capwrap.tar.gz
² http://atrey.karlin.mff.cuni.cz/~pavel/elfcap.html

Followup to:  <[email protected]>
By author:    Neil Schemenauer <[email protected]>
In newsgroup: linux.dev.kernel

Why not just do this with a small program if you're doing setuid anyway?

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<[email protected]>

Nothing is running with root privileges (unless root is executing it). The SUID bit on the wrapper is just a marker and does not change the effective uid of the process. Also, AFAIK, you can't pass capabilities
from one program to another using exec(). I don't completely
understand this stuff yet but fs/exec.c has these lines in the prepare_binprm() function:

        cap_clear(bprm->cap_inheritable);
        cap_clear(bprm->cap_permitted);
        cap_clear(bprm->cap_effective);

Capabilities are only raised if bprm->e_uid == 0. So, unless I'm misunderstand the code, you can't do the same thing with a SUID wrapper.

Thanks for you're comments.

Neil