lkml.org 
[lkml]   [2004]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: disable-cap-mlock
* 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [from the cache]
©2003-2011 Jasper Spaans