On Sat, Dec 27, 2008 at 12:21:49PM -0800, Roman Shaposhnik wrote: > True. But why that should be a problem in practice? If the process > belongs to a user X that means user X has control over it. Thus the > behavior of accidental consumption of an fd that was meant to be consumed > by some other process can only be attributed to bugs in the code, not > malicious intent.
If one buys this argument, then namespaces are not valid security constructs either, and Plan 9 security boundaries are defined solely by user id. That is, the claim that "a process spawned without access to your home directory cannot get it" is flawed if that process runs as your user. (Even if I can't mount it, I can attach a debugger to a process that can and make it make system calls for me. You now have to intermediate my #p (/proc) service. You have to ensure that I can't dial it and authenticate with factotum. It's a mess!) I may be tainted by the capability microkernel koolaid, but I don't like the idea that users are the sole security domain objects, and I really dislike that I can build stronger security constructs when using multiple kernels rather than just one. Especially in a system like Plan 9, where namespaces are cheap and capabilties exist in the form of file descriptors. That is, I want to be able to build processes that cannot access resources that they were not explicitly granted when their namespace was constructed. Currently, #p and #s are rather large, open-ended, potent capabilities to grant, and refusing grant of #p and #s requires some rather careful coding and prevents a number of conveniences, as you might imagine. That is, I want, essentially, to run multiple Plan 9 systems on one Plan 9 kernel without needing to get my whole domain to know about multiple instances of my user (e.g. nwf/browser, nwf/grid, nwf, ...). Or rather, the ability to do that is a sufficient, but not necessary, condition. I can build exactly these resource-restricted namespaces if I devote an entire kernel -- and thereby an entire machine or emulation -- to it. I simply avoid granting that machine my P9 secret and (tada!) even though the uid may be "nwf", that doesn't mean anything. If #s can be virtualized -- ala srv^2 or devcapsrv or something else -- then the system is one step closer to supporting the above. There is some machinery for sealing off #p that I do not recall in full detail but may well be sufficient, at least for my desires. --nwf;
pgpnSBhknyqFX.pgp
Description: PGP signature
