Re: caps in elf, next itteration (the hack get's bigger)

Daniel Taylor (dante@plethora.net)
Sat, 17 Apr 1999 21:42:26 -0500 (CDT)


On Tue, 13 Apr 1999, David L. Parsley (lkml account) wrote:

> On Tue, 13 Apr 1999, Horst von Brand wrote:
>
> > "David L. Parsley (lkml account)" <kparse@salem.k12.va.us> said:
> > > I'm curious, Dr. von Brand; have you considered stickybit + immutable? (as
> > > explained in my recent treatise to Richard ;-) It solves a lot of
> > > problems and gives us:
> > >
> > > - a MUCH truer implementation of capabilities
> >
> > Not quite true. IMO, either you do it the whole way or don't do it. The
> > (user level) pain involved in both cases is quite similar, the benefits are
> > very different. Plus the kernel hair is significantly enhanced with this
> > kind of kludge.
>
> Ok, so you _are_ advocating _true_ capability support in the fs, ext3 most
> likely. That's _definitely_ what I want eventually, but I feel the latest
> incarnation of the stickybit solution takes quite a few steps in the right
> direction.

Methinks many people here are missing a major point.

All the way or not at all. An incomplete, manged, hairy
implementation of capabilities is worse than none at all.

This is a *SECURITY MODEL*, you don't do gross hacks when
implementing it, because anything you break opens your
system up. Especially you do not implement it as a series
of hacks based on the existing security model, which it is
intended to be an alternative for, not a supplement to.

If you want to implement something that kinda looks like
capabilities as a layer on the current security model, call
it something like "privilege limitations" and go to town.

Daniel Taylor

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/