From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 30 Dec 2008 03:22:45 -0500 From: Nathaniel W Filardo To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20081230082245.GA8355@masters10.cs.jhu.edu> References: <20081223180148.GO9593@masters10.cs.jhu.edu> <49516BC3.10100@kix.es> <8ccc8ba40812231553r43d7baa5mde4de7174e78ed20@mail.gmail.com> <20081224011053.GP9593@masters10.cs.jhu.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [9fans] sendfd() on native Plan 9? Topicbox-Message-UUID: 73f6e456-ead4-11e9-9d60-3106f5b1d025 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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; --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklZ2lUACgkQTeQabvr9Tc99sQCfW+2k9A5EjYsSblFyiOGNuhdx k+oAninEOZ/CVtWqAmZKkr/IhpMvQQgv =ZTCD -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ--