Re: 2.6.6-mm1

[Andy Lutomirski]

Chris Wright wrote:
> * Chris Wedgwood (cw@xxxxxxxx) wrote:
>
> > On Mon, May 10, 2004 at 03:02:03PM -0700, Andrew Morton wrote:
> >
> >
> > > Capabilities are broken and don't work.  Nobody has a clue how to
> > > provide the required services with SELinux and nobody has any code
> > > and we need the feature *now* before vendors go shipping even more
> > > ghastly stuff.
> >
> > eh? magic groups are nasty...  and why is this needed?  can't
> > oracle/whatever just run with a wrapper to give the capabilities out
> > as required until a better solution is available
>
>
> I agree.  I have a patch that at least fixes this bit of capabilities
> (currently, what you suggest doesn't work right), which could easily be
> dusted off and resent.

I'll try and get my patch ready for testing soon.  It got sidetracked by 
the compute_creds race (erm... and my inability to fix it right the 
first time).

Before I clean it up and rediff it, here's a question:

I would like to make the inheritable mask mean "these are the only 
capabilities that this process or its children may ever hold."  That 
means tweaking setuid to disable itself if the inheritable mask is not 
full to avoid auditing every setuid program ever written..  The benefit 
is that cap_bset can be removed and securelevel can done sanely (by 
adding a sysctl that means "setuid needs this set of capabilities").  It 
also means that servers could drop inheritable caps, so, if they are 
hacked, the attacker can't try to exploit setpcap / setuid / 
(eventually) vfs caps.  The downside is added complexity.

If I don't do that, I'm not quite sure what to do with the inheritable 
mask.  It seems to be only marginally useful.

Thoughts?

--Andy
-
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/