Re: disable-cap-mlock

[Andrew Morton <akpm@osdl.org>]

Andrew Morton <akpm@osdl.org> wrote:
>
> Rumour has it that the more exhasperated among us are brewing up a patch to
> login.c which will allow capabilities to be retained after the setuid.

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.

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().

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())

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.

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.

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 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.