Messages in this thread | | | Subject | Re: caps in elf, next itteration (the hack get's bigger) | Date | Thu, 15 Apr 1999 12:10:40 -0400 | From | Horst von Brand <> |
| |
"David L. Parsley (lkml account)" <kparse@salem.k12.va.us> said:
[...]
> named(8) just happens to be my favorite example, but others apply as well; > at this point, I think the question is: do we implement capabilities as > they were designed to be implemented (stickybit/immutable solution), or do > we break the semantics of capabilities to work around problems in the > solution based on setuid-root?
Capabilities were _not_ designed to be implemented in any particular way, even less by overloading existing permission bits.
OK, let's check again: Where are we going? Possibilities include:
a) A vaguely unixy system with all-powerful root + capability-protected daemons and whatnot
b) A fully capability based system, that by its very nature doesn't look like Unix at all, at least to the sysadmins in charge
Note that the above might very well run on the same kernel, AFAIKS. The difference is in policies, in capabilities and permissions of the various binaries.
Then consider the relevant standards (POSIX, perhaps some of the Rainbow series?) or their draft versions.
Then look around for Unixy systems that use capabilities, and (more important, perhaps) at other systems that have them.
(a) has still serious security implications (if I hijack a root process, I'm home free), but it might make this much harder to do to an attacker. So this might be useful in a limited way.
(b) means throwing away much of the Unix tradition, massive rewrite of tools, etc. Could be an interesting idea for somebody who wants to build a bulletproof distribution, of for similar uses. But for this to be taken seriously it would also need massive amounts of work elsewhere (get B certification or thereabouts, I'd guess)
Whatever is done, I strongly suggest that (b) is not simply made impossible to ease (a). Also, even for (a) the whole workings of the userland (and the systems programs) has to be carefully scrutinized, several tools either patched or supplemented with capability-aware, specialized tools. And then the whole capability setup for _all_ programs has to be done, either patching the relevant Makefiles or by some extra tool that keeps a database of capabilities and sets them when a new version is installed (RPM could be extended to at least keep this info, or the Debian package manager...).
Note that all this work _has_ to be done, whatever the way capabilities are implemented in the end. That's why I lobby for putting them into the filesystem: It's the _only_ guaranteed secure place to keep them, and nobody paranoid enough to go to (b) will let anything non-local even get near their system. For (a), if NFS/CODA/iso9660/VFAT/NTFS/whatever don't know about capabilities, anything you get that way has _no_ capabilities, and can't be a security risk.
For transition, the path will consist in a new filesystem (or a variant of an existing one), and a lot of userspace changes. Nobody in its sane mind will run old and new kernels alternatively on a security-sensitive machine anyway, so the dual boot scenarios are moot anyway. Except perhaps for testing or setting up the whole system, and there security will have to be relaxed. Linux already knows of several differeent security levels in the kernel, use that: A "Install" level with a "root", a "Normal" level without. Or even different kernels, where the first gets obliterated after the system is running. -- 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/
| |