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    [W:0.024 / U:60.384 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site