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

[erik quanstrom <quanstro@quanstro.net>]

> If one buys this argument, then namespaces are not valid security constructs

they are not security constructs at all.  though ftpd and a few friends
use rfork(2) to create a pgrp that doesn't allow attaches.  very simple
and effictive, but probablly not strong security.

> either, and Plan 9 security boundaries are defined solely by user id.

on the cpu server and authentication server , this is true.  on the file
server, group also matters.

> 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.

use RFNOMNT.

> (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.

factotum protects against this by making itself undebuggable and
unpagable.  /sys/src/cmd/auth/factotum/fs.c:/^private

also, binding '#p' into the namespace isn't required for everything.
combined with rfork(RFNOMNT), nor is providing network services.

> You have to ensure that I can't dial it and authenticate with
> factotum.  It's a mess!)

how would that attack work?

supposing that you have a fully jailed process.  if it has a connection
to the fileserver, which does do security by user id, the jailed process
can still mess with you.  say by deleting all your files.

i think the real question here is why don't you trust your
processes?  is it because someone else is running them

> 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.

i don't understand this.

this doesn't seem like a compelling reason to turn namespaces into
containers.  for the reasons you cite, containers are also unattactive
solutions to security problems.

- erik