> > Bingo!
> 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.
> - as much compatibility as possible while still being a capabilities-based
> system
I don't think so. A true capability-based system is _not_ Unix-compatible
under any reasonable meaning of the term, so the point is moot anyway.
Sure, you _can_ run a capability-based system in a Unix-like fashion (give
root a all-powerful shell, make all SUID root executables all-powerful and
you are almost home free: You'd need a few other things, like a
capability-aware tar(1) et al). But that is completely orthogonal to the
implementation of capabilities.
OTOH, you want the capability implementation be absolutely bulletproof. So,
it has to be simple (no gratuituous hair in the kernel!), tamper/smuggling
resistant (no posibilities to create capable binaries elsewhere with hex
editors or other tools and import them somehow), old kernels or tools which
aren't aware of capabilities have to break in the safe (i.e., non-granting)
direction.
That's why I think your idea is interesting, but doesn't quite cut it.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- 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/