[...]
> I'm not necessarily advocating "capabilities light". I'm definately
> advocating a "capabilities practical" scheme, which obviously includes
> NFS and similar support.
I would love that, iff such a scheme does not (a) preclude "capabilities
full", and (b) it doesn't add potential unwanted interactions with
capabilities in metadata (its the _only_ reasonable place for them anyway)
or random careless setups.
I'm not convinced that the overloading of bits + keeping metadata in the
executable file is at all secure (b), and I worry about (a).
[...]
> Sure. But in your sticky+immutable scheme (or any variation), or in
> fact a scheme where cap masks are kept in the FS metadata, the grant
> and inherit masks require privilege to modify.
That's part of the whole design, yes.
[...]
> In addition, my scheme gives you a pretty flexible system for
> increasing security on non-caps kernels. You can easily set things up
> so that when root runs another binary, the uid and euid are set to
> nobody, if that binary has no capability header, or doesn't have any
> inheritable caps set. The only thing you can't control is statically
> linked binaries without the magic code. But if you're setting up a
> secure system, you'd relink those anyway.
That looks like a lot more work than a simple "setcaps ..." on the affected
executables. Plus you _can't_ do it with your propietary database which you
need to trust for raw access to partition /dev/foo... and all to be able to
smuggle capabilities behind the system's back via tar(1) et al? Where (with
the inmutable bit) the whole idea of being able to use the existing tools
transparently is long lost anyway?
-- 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/