From owner-freebsd-security@FreeBSD.ORG Thu Jul 24 09:33:28 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 DAB2E106566C for ; Thu, 24 Jul 2008 09:33:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 4CFD68FC13 for ; Thu, 24 Jul 2008 09:33:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m6O8xBFf075142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2008 11:59:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m6O8xBmN019683; Thu, 24 Jul 2008 11:59:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m6O8xBvW019682; Thu, 24 Jul 2008 11:59:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 24 Jul 2008 11:59:11 +0300 From: Kostik Belousov To: Robert Watson Message-ID: <20080724085910.GG97161@deviant.kiev.zoral.com.ua> References: <884CB541-7977-4EF1-9B72-7226BDF30188@patpro.net> <20080717085136.B87887@fledge.watson.org> <05661513-E0DA-4B33-BD4E-FCF73943F332@orthanc.ca> <20080724090549.G63347@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="S5HS5MvDw4DmbRmb" Content-Disposition: inline In-Reply-To: <20080724090549.G63347@fledge.watson.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Liste FreeBSD-security , Lyndon Nerenberg 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 09:33:29 -0000 --S5HS5MvDw4DmbRmb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 24, 2008 at 09:09:26AM +0100, Robert Watson wrote: > On Fri, 18 Jul 2008, Lyndon Nerenberg wrote: >=20 > >It's sad people don't pay more attention to Plan 9. Namespaces go a long= =20 > >way towards solving this problem in a manner that's completely transpare= nt=20 > >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= =20 > >'rfork n' in the shell will instantiate a brand new instance of the=20 > >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=20 > >directory) is now the "root" directory of the process' filesystem.=20 > >Analogous system calls exist for programmatic use. And since there is no= =20 > >concept of (or need for) a 'superuser' these facilities are available to= =20 > >everyone. > > > >This makes sandboxing trivial for any number of remotely accessible=20 > >network services as well as to the interactive system user. Both files a= nd=20 > >directories can be bind targets, and the source of the bind can as easil= y=20 > >be a program as a file or directory; the ability to create secure=20 > >synthetic filesystems just naturally falls out of this paradigm. > > > >And the applications are blissfully unaware that any of this even exists. >=20 > Lots of people care a lot about plan9. The problem is that it's a lot li= ke=20 > UNIX. UNIX presupposes lots of special-purpose applications doing rather= =20 > specific and well-defined things, and that is a decreasingly accurate=20 > reflection of the way people write applications. All these security=20 > extensions get extremely messy the moment you have general-purpose=20 > applications that you want to be able to do some things some times, and= =20 > other things other times, and where the nature of the protections you wan= t=20 > depends on, and changes with, the whim of the user. The complex structur= e=20 > of modern UNIX applications doesn't help (lots of dependent libraries,=20 > files, interpreters, etc), because it almost instantly pushes the package= =20 > dependency problem into the access control problem. I don't think it's= =20 > hopeless, but I think that any answer that looks simple is probably wrong= =20 > 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 :). --S5HS5MvDw4DmbRmb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiIRF4ACgkQC3+MBN1Mb4icbwCg5Q1jbBAujayT/7g2JMwfYR2u ycEAnjhK8d66orFayKogPHiWWgMIiFry =zY2Z -----END PGP SIGNATURE----- --S5HS5MvDw4DmbRmb--