Date: Thu, 24 Jul 2008 11:59:11 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Robert Watson <rwatson@freebsd.org> Cc: Liste FreeBSD-security <freebsd-security@freebsd.org>, Lyndon Nerenberg <lyndon@orthanc.ca> Subject: Re: A new kind of security needed Message-ID: <20080724085910.GG97161@deviant.kiev.zoral.com.ua> In-Reply-To: <20080724090549.G63347@fledge.watson.org> References: <f383264b0807161710m285ed915m8ea9d088fbe83df9@mail.gmail.com> <alpine.BSF.1.00.0807162303490.34772@treehorn.dfmm.org> <884CB541-7977-4EF1-9B72-7226BDF30188@patpro.net> <20080717085136.B87887@fledge.watson.org> <05661513-E0DA-4B33-BD4E-FCF73943F332@orthanc.ca> <20080724090549.G63347@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080724085910.GG97161>