Re: disable-cap-mlock

[Chris Wright <chrisw@osdl.org>]

* Andrew Morton (akpm@osdl.org) wrote:
> So I spent a few hours getting pam_cap to work, and indeed it is now doing the
> right thing.  But the kernel is not.

Do you have a patch?  Seems it could be useful to get this and libcap back
up-to-date .

> It turns out that the whole "drop capabilities and then run something"
> thing does not work in either 2.4 or 2.6.  And hasn't done since forever. 
> What we have in there is no more useful than suser().

Indeed.  This is often how I refer to it.  There's one exception.
Without the use of execve(), a resident daemon can drop it's privs as
needed.

> You can do prctl(PR_SET_KEEPCAPS, 1) so that permitted caps are retained
> across setuid().  And after the setuid() you can raise effective caps
> again.  So that's workable, although pretty sad - it requires that su and
> login be patched to run the prctl and to re-raise effective caps.
> 
> But the two showstoppers are:
> 
> 1) capabilities are unconditionally nuked across execve() unless you're
>    root (cap_bprm_set_security())

Or exec'ing a setuid root program.  And in either of those cases they
get raised to full sets, which may not be nice.

> 2) the kernel unconditionally removes CAP_SETPCAP in dummy_capget() so
>    it is not possible for even a root-owned, otherwise-fully-capable task
>    to raise capabilities on another task.  Period.

This is how the kernel was before the security stuff went in.  

> I must say that I'm fairly disappointed that we developed and merged all
> that fancy security stuff but nobody ever bothered to fix up the existing
> simple capability code.

Our goal was actually to keep is compatible.  All of it's limitations
predate the security stuff.

> Particularly as, apparently, the new security stuff STILL cannot solve the
> extremely simple Oracle-wants-CAP_IPC_LOCK requirement.
> 
> Chris has proposed a little patch which will enable the retention of caps
> across execve.  I'd be interested in knowing why we _ever_ dropped caps
> across execve?  I thing we should run with Chris's patch - but the new
> functionality should of course only be enabled by some admin-settable knob.

I'm not sure, but it likely has to do with anticipating having the fs
bits of capabilities to do proper setting at execve().  I think basically
nobody really uses capabilites except in either simple root drops a
few privs ways (no exec), or within larger security models running as
kernel modules.

> I'm looking at securebits.h and wondering why that exists - there's no code
> in-kernel to set the thing, although it is exported to modules.  Perhaps
> securebits should be exposed in /proc and used to enable
> retain-caps-across-execve.

IIRC, changing those (existing) securebits settings creates an unusable
machine.  Again, I think there was some anticipation of the fs bits
going in later.  Perhaps those securebits pieces could just be removed?

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net