Re: disable-cap-mlock

[Andrew Morton]

Chris Wright <chrisw@xxxxxxxx> wrote:
>
> * Andrew Morton (akpm@xxxxxxxx) 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 .

http://www.zip.com.au/~akpm/linux/patches/stuff/pam_cap-akpm.tar.gz

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

That's my point, Chris.  "the feature is bollixed, so let's write a ton of
new parallel stuff but not fix the original code".  This is how cruft
accumulates.

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

Either the fine-grained capabilities are fixable, or they should be deleted
and we go back to suser().  One of those things should have happened before
adding more code, surely?

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

Yup, we've talked about how you can drop caps in this way for *years* but I
don't think many people realised that this emperor is unclad.

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

OK.  Do you have time to do the honours?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/