> "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. Really, it can be done 99% in userspace, with kernel mods
that:
- interpret stickybit + immutable as 'capability enabled' and read the
capabilities from the elf headers. Pavel's patch could be so modified
very easily, IMO.
- insure that any process attempting to set the sticky bit or create a
file with the sticky bit set have CAP_SETFCAP; on success both sticky bit
and immutable are set. This way, tar (for example) can be easily and
painlessly capability modified (with permitted==0, inheritable having at
least CAP_SETFCAP)
I _think_ everything else can be done in userspace, so this looks to put
very little 'hair' in the kernel.
> > - 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.
Well, people have pointed out correctly that this solution will differ
markedly from traditional UNIX. No doubt about it, capabilities is a
different way of doing things, but a hurdle I'm more than happy to leap.
> 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.
And not at all what I'm proposing.
> OTOH, you want the capability implementation be absolutely bulletproof. So,
> it has to be simple (no gratuituous hair in the kernel!),
Very little hair, very simple IMHO.
> tamper/smuggling
> resistant (no posibilities to create capable binaries elsewhere with hex
> editors or other tools and import them somehow),
Fixed.
> old kernels or tools which
> aren't aware of capabilities have to break in the safe (i.e., non-granting)
> direction.
Also done.
> That's why I think your idea is interesting, but doesn't quite cut it.
Certainly not true caps in the fs, but I think this takes us very far (90%
at least) and very quickly. An excellent candidate, I believe, for a
kernel option to be marked [experimental]. The 'upgrade' path would be
simple as well; in the presence of a suitable fs, a very simple utility
could convert from this system to true fs caps.
> --
> 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
- --
David L. Parsley
Network Specialist
City of Salem Schools
-
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/