From owner-freebsd-security@FreeBSD.ORG Thu Jul 24 08:09:27 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F234106566B for ; Thu, 24 Jul 2008 08:09:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 011338FC16 for ; Thu, 24 Jul 2008 08:09:26 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id BAF3346C70; Thu, 24 Jul 2008 04:09:26 -0400 (EDT) Date: Thu, 24 Jul 2008 09:09:26 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Lyndon Nerenberg In-Reply-To: <05661513-E0DA-4B33-BD4E-FCF73943F332@orthanc.ca> Message-ID: <20080724090549.G63347@fledge.watson.org> References: <884CB541-7977-4EF1-9B72-7226BDF30188@patpro.net> <20080717085136.B87887@fledge.watson.org> <05661513-E0DA-4B33-BD4E-FCF73943F332@orthanc.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Liste FreeBSD-security Subject: Re: A new kind of security needed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 08:09:27 -0000 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. :-) Robert N M Watson Computer Laboratory University of Cambridge