From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net From: erik quanstrom Date: Tue, 30 Dec 2008 10:31:19 -0500 In-Reply-To: <20081230082245.GA8355@masters10.cs.jhu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] sendfd() on native Plan 9? Topicbox-Message-UUID: 74310b4a-ead4-11e9-9d60-3106f5b1d025 > 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