A new kind of security needed

[Kostik Belousov]

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 :).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20080724/e0ef874e/attachment.pgp