Re: inheritable set [was Re: caps in elf headers: use the sticky
Thu, 22 Apr 1999 18:00:18 -0700 (PDT)
On Thu, 22 Apr 1999, Stephen C. Tweedie wrote:
> On Wed, 21 Apr 1999 13:39:09 -0700 (PDT), Y2K <email@example.com> said:
> >> No, because "more" wouldn't have any capabilities in its "inheritable"
> >> set, so it would NOT inherit any capabilities which its parents had.
> > Thats not very compatible, right now if the parent has the caps they flow
> > to their children.
> Right. That's the entire point: automatic inheritence of all caps is a
> potential security problem, as it lets privileges leak into programs
> which weren't designed to cope with those privs. You _can't_ change
> that while maintaining compatibility. It's a simple one way choice:
> compatibility necessarily implies preserving an entire class of security
Then set a few bits in securebits or don't use root for your cap-enhanced
process. One thing I hope my patch to have is to have you able to config a
stricter kernel compile if you want that type of thing by setting the
Also hint most programs weren't designed to handle any caps besides(I am
god aka root) and most weren't designed with even that as a consideration.
The patch should have provision to set securebits on a per process basis
or a global basis. That way you can have a mostly compatible system that
has a developemental "soiled" cap-aware apache that marks securebits for
its process so you can track down problems on a per program basis instead
of dealing with the whole of user-space all at once.
After all of the user-space you care about has been corrected then you can
throw on the super strict. Anyway I should have a new version of the patch
out later today or tommorrow.
Then you can tell me if you like or hate my use of the securebits. OK
Warning when I mention capabilites I mean "soiled" capabilities not "pure".
Any caps I mention are *derived* from a withdrawn draft posix document.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/