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

Dan Taylor (dante@herd.plethora.net)
Sat, 17 Apr 1999 22:30:32 -0500 (CDT)

Just ignore that last message, I got further down the discussion
and discovered that this has been largely worked out by people with more
time than myself to follow the discussion.

</delurk>
Daniel Taylor

On Sat, 17 Apr 1999, Daniel Taylor wrote:

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

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