Messages in this thread | | | Date | Sat, 17 Apr 1999 21:42:26 -0500 (CDT) | From | Daniel Taylor <> | Subject | Re: caps in elf, next itteration (the hack get's bigger) |
| |
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/
| |