Messages in this thread | | | Subject | Re: [PATCH] Capabilities, this time in elf section | Date | Fri, 16 Apr 1999 14:38:57 -0400 | From | Horst von Brand <> |
| |
Richard Gooch <rgooch@atnf.csiro.au> said:
[...]
> 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/
| |