Re: A new kind of security needed



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 :).

Attachment: pgpyOAQ5t0r9Q.pgp
Description: PGP signature



Relevant Pages

  • Re: A new kind of security needed
    ... Robert Watson wrote: ... 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. ... 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. ...
    (FreeBSD-Security)
  • Re: A new kind of security needed
    ... your view of the 'filesystem' is fully mutable. ... 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. ... 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. ...
    (FreeBSD-Security)
  • Re: VMS (was: GUI v Script)
    ... DEC's lead architect on VMS to do things right with WinNT. ... respect DOS was much closer to UNIX than to VMS. ... services UNIX provides for running applications can usually be counted ... and it provided true networking support, ...
    (comp.object)
  • Re: How can I enter APL on an i386/ASCII laptop keyboard?
    ... with a number of very large applications ... running under AIX and Linux ... small Unix timesharing machines and higher-end Apollo and Sun ... a pretty good job in trying to keep the level of abstraction at least ...
    (comp.lang.apl)
  • Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)
    ... Subject: Unix runs faster, maybe (was: Re: Educating ... potential VMS users) ... CPU, and hence CPU utilization *will* be low, even if the ... not simply involve install OS, add applications, test and move to prod. ...
    (comp.os.vms)