Re: posix capabilities inheritance

["Theodore Ts'o" <tytso@mit.edu>]

On Tue, Oct 21, 2003 at 06:26:45AM -0500, Michael Glasgow wrote:
> I wrote a simple setuid-root wrapper which sets some capabilities, 
> gives up all other privs, and and then execs a shell.  I was hoping
> to use this wrapper as a login shell so that I could have a user  
> log in interactively with a small subset of elevated privileges.
> 
> Unfortunately after looking over the capabilities code in the 2.4
> kernel, it would appear that this is not currently possible, and
> my wrapper cannot work without filesystem support for capabilities.
> And even then, I'd have to set each file's inheritable flag for the
> capabilities I want on every executable that I am likely to run,
> including the shell.  Am I mising something, or is this an accurate
> description?

No, you're not missing anything.

What happened here is that originally there was a security
vulnerability caused by an a badly desgined attempt to take advantage
of capabilities without filesystem support.  In order to fix it, the
patch took a very conservative path, which completely disabled the use
of selective capability inheritance.  (Capabilities are still useful,
but only in setuid root programs that selectively drop unneeded
capabilities --- still in my opinion the best way to use capabilities,
BTW).

> As an interim workaround, how about assuming all capabilities are
> inheritable in fs/exec.c:prepare_binprm, i.e. instead of
> cap_clear(bprm->cap_inheritable), call cap_set_full() ???  I don't
> think this would break anything, and it would make capabilities a
> lot more useful until we get fs support merged in.

I agree this is safe, and allows the use of your setuid wrapper
script.  The one reason why I think it's better to modify programs is
that it's too easy for individual system administrators to screw up
the configuration used by your wrapper script, and accidentally
introduce a security vulnerability into their system.  It's dangerous
to give a program some capability (or reduce the capability given to a
program designed to be setuid) without examining the source code and
being clueful.  So by making the program setuid and editing the source
code to add an explicit capability drop in the program is much, much
safer compared to having a random system administrator to edit a
config file and trust that he or she does so correctly.

						- Ted