On Thu, Jul 24, 2008 at 09:09:26AM +0100, Robert Watson wrote: > On Fri, 18 Jul 2008, Lyndon Nerenberg wrote: > > >It's sad people don't pay more attention to Plan 9. Namespaces go a long > >way towards solving this problem in a manner that's completely transparent > >to the application, and trivial for the end-user to configure and use. > > > >See: > > > >http://plan9.bell-labs.com/sys/doc/names.html > >http://plan9.bell-labs.com/magic/man2html/1/0intro > >http://plan9.bell-labs.com/magic/man2html/4/namespace > > > >In a nutshell, your view of the 'filesystem' is fully mutable. A simple > >'rfork n' in the shell will instantiate a brand new instance of the > >namespace, which you can then fiddle to your heart's content. E.g. > > > >rfork n bind /usr/ftp / > > > >creates a namespace where /usr/ftp (by convention the anonymous FTP > >directory) is now the "root" directory of the process' filesystem. > >Analogous system calls exist for programmatic use. And since there is no > >concept of (or need for) a 'superuser' these facilities are available to > >everyone. > > > >This makes sandboxing trivial for any number of remotely accessible > >network services as well as to the interactive system user. Both files and > >directories can be bind targets, and the source of the bind can as easily > >be a program as a file or directory; the ability to create secure > >synthetic filesystems just naturally falls out of this paradigm. > > > >And the applications are blissfully unaware that any of this even exists. > > Lots of people care a lot about plan9. The problem is that it's a lot like > UNIX. UNIX presupposes lots of special-purpose applications doing rather > specific and well-defined things, and that is a decreasingly accurate > reflection of the way people write applications. All these security > extensions get extremely messy the moment you have general-purpose > applications that you want to be able to do some things some times, and > other things other times, and where the nature of the protections you want > depends on, and changes with, the whim of the user. The complex structure > of modern UNIX applications doesn't help (lots of dependent libraries, > files, interpreters, etc), because it almost instantly pushes the package > dependency problem into the access control problem. I don't think it's > hopeless, but I think that any answer that looks simple is probably wrong > by definition. :-)
I think that the per-process namespaces are useful, and can be added to the existing Unix model with quite favourable consequences. On the other hand, I do not think that security is the most important application of the namespaces, or even have a direct relation to it. Implementing namespaces for FreeBSD looks as an doable and quite interesting project for me :).
pgpmZBtNpI9kc.pgp
Description: PGP signature
