Re: A new kind of security needed


On 2008-Jul-17, at 00:54 , Robert Watson wrote:

FWIW, I have some work in progress on the capability front, but it's a highly complex issue that will take years to work through properly. Unfortunately, the real issue isn't so much the OS primitives as building up a non-trivial application base that uses them. Providing primitives to subdivie applications isn't easy, but once you've done that you still have to rewrite lots of applications to take advantage of it, and in a way that shows a lot more application programmer discipline. It's not clear to me that the pressure is there to make feature-driven application development for major desktop applications adopt techniques of this sort.

Realistically, this will never happen. It would require *every*one agreeing on a single consistent API, and that just won't happen with any sort of policy-based mechanism.

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.

--lyndon
_______________________________________________
freebsd-security@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • 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: looking for a DB library for block devices
    ... I don't want to be going through the indirection of a filesystem ... well be that filesystem performance will be significant for your ... some applications, it's no longer true for most applications in ... where there's no reason to cache any data at all. ...
    (comp.unix.programmer)
  • Re: [PATCH][RFC] Simple tamper-proof device filesystem.
    ... that "Don't require modification of userland applications". ... This filesystem is intended to provide support for legacy applications. ... Can hide unwanted device nodes. ... so that all requests are checked by the tiny daemon. ...
    (Linux-Kernel)
  • Re: Adding thread support for C...
    ... This leads to the deliberate omission of low level primitives and the inclusion of only the high level api's favored by the thread api designers. ... primitives dependent on particular machine-level shared memory models, are not doing so simply because we have plucked an agenda out of thin air. ... You can't keep hardware architects from breaking things they don't understand. ... If they are used directly by applications, these costs have to be paid per-appication. ...
    (comp.programming.threads)
  • Re: Trying to design low level hard disk manipulation program
    ... BT> users and applications have become used to this)? ... pathnames are in the same directory, and have filenames which (let us ... is (precisely the current Unix semantics): ... Note also that given a case-sensitive filesystem of this type, ...
    (comp.arch)