Re: 2.6.6-mm1

From: Andy Lutomirski
Date: Tue May 11 2004 - 01:41:40 EST

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at