> 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
