Re: [9fans] sendfd() on native Plan 9?

[Nathaniel W Filardo <nwf@cs.jhu.edu>]

[-- Attachment #1: Type: text/plain, Size: 2519 bytes --]

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;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]