From owner-freebsd-security@FreeBSD.ORG Thu Jul 24 08:05:46 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 A9B36106566B for ; Thu, 24 Jul 2008 08:05:46 +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 3622C8FC13 for ; Thu, 24 Jul 2008 08:05:46 +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 BE5A246C53; Thu, 24 Jul 2008 04:05:45 -0400 (EDT) Date: Thu, 24 Jul 2008 09:05:45 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Tim Clewlow In-Reply-To: <50456.192.168.1.10.1216301690.squirrel@192.168.1.100> Message-ID: <20080724085912.U63347@fledge.watson.org> References: <884CB541-7977-4EF1-9B72-7226BDF30188@patpro.net> <20080717085136.B87887@fledge.watson.org> <50456.192.168.1.10.1216301690.squirrel@192.168.1.100> 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:05:46 -0000 On Thu, 17 Jul 2008, Tim Clewlow wrote: > The "One Laptop Per Child" organisation seem to be taking the sandbox/jail > concept to its extreme in an attempt to neuter viruses. In FreeBSD terms, > they appear to be insisting that each user application on the laptop be run > in its own jail. > > http://news.softpedia.com/news/The-100-Laptop-Virus-Free-37464.shtml > > This may be feasible on a system designed to be very restrictive in regards > to hacking/tinkering, but much more difficult, if not impossible, to > implement on a system like FreeBSD (how do you build a piped process group > when all the individual processes are separately jailed?) I think it's worth comparing this and other approaches to the Sandbox approach used in the version of Mac OS X in the iPhone, which fairly firmly compartmentalizes applications. The obvious upsets are a high level of isolation. The downsides are also pretty important to think about, though: common non-OS-provided infrastructure is minimized, inter-process services are limited, and especially, inter-application data sharing. Notice that the iPhone is careful not to expose a generic file system interface for sharing a single user's files between applications, and for good reason. This captures, I think, the fundamental challenges of desktop security quite well: desktop environments are highly interconnected and interdependent software packages built with a lot of mutual trust and integration. If you start slicing them up, you both completely disrupt the model they are designed around, and you also limit their ability to do some fairly widely depended on things. > Perhaps a security layer could be implemented that includes the ability to > designate some applications as being only allowed to run if they are in a > jail, and then have all other executables not available to be run on their > own. But this would be a very different system from FreeBSD. Maybe it could > be done with a sysctl switch, or maybe it would be such a major change it > should really be considered a separate operating system in its own right, ie > perhaps better implemented as part of PCBSD, or something of that ilk. > > Of course, if it can be done, without upsetting everyone, then that would be > ideal, but I agree there would be a great deal of work involved. Jails are extremely useful, but rest on the principle of pretty complete isolation of jailed environments. This is great for ISPs, but not so good if you want your web browser to sometimes, but not always, be able to upload your OpenOffice.org accounting spreadsheets to web sites. Even if you play a lot of grafting games using nullfs, etc, it's still messy. Assuming a desire to move incrementally towards a more fine-grained model, I suspect the starting point is to produce some security tools for application-based subdivision of the OS environment (and user rights), and then apply them in the most critical places first. I've had capability-related patches for FreeBSD on the back-burner for some time -- they allow processes to arbitrarily subdivide themselves into "jails" passing only very specific rights into the compartments, etc. They're not really for widespread use, since I've been trying to drive their development by adapting applications to use them for things like executing script interpreters, etc, and that process is slow, as it involves a lot of software adaption, but some of the work, at least, is probably ready to see the world. Robert N M Watson Computer Laboratory University of Cambridge 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 From owner-freebsd-security@FreeBSD.ORG Thu Jul 24 09:06:20 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 14F56106566B for ; Thu, 24 Jul 2008 09:06:20 +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 BADF38FC1A for ; Thu, 24 Jul 2008 09:06:19 +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 8ACFB46B0C; Thu, 24 Jul 2008 05:06:19 -0400 (EDT) Date: Thu, 24 Jul 2008 10:06:19 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kostik Belousov In-Reply-To: <20080724085910.GG97161@deviant.kiev.zoral.com.ua> Message-ID: <20080724100439.D63347@fledge.watson.org> 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> <20080724085910.GG97161@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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:06:20 -0000 On Thu, 24 Jul 2008, Kostik Belousov wrote: >> 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 :). Sounds good to me :-). As with all such project (variant symlinks, process-local name spaces, etc), do be very careful about security -- often as not, such projects risk tripping over problems with privilege-escalated processes, such as setuid binaries, etc, which place strong trust in the file system name space. Robert N M Watson Computer Laboratory University of Cambridge 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-- From owner-freebsd-security@FreeBSD.ORG Thu Jul 24 15:52:58 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 9B04A106566B for ; Thu, 24 Jul 2008 15:52:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outI.internet-mail-service.net (outi.internet-mail-service.net [216.240.47.232]) by mx1.freebsd.org (Postfix) with ESMTP id 814888FC0C for ; Thu, 24 Jul 2008 15:52:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 0EE322370; Thu, 24 Jul 2008 08:39:28 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 02F462D6054; Thu, 24 Jul 2008 08:39:26 -0700 (PDT) Message-ID: <4888A217.9000109@elischer.org> Date: Thu, 24 Jul 2008 08:39:03 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Robert Watson 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> <20080724085910.GG97161@deviant.kiev.zoral.com.ua> <20080724100439.D63347@fledge.watson.org> In-Reply-To: <20080724100439.D63347@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 24 Jul 2008 16:43:17 +0000 Cc: Kostik Belousov , 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 15:52:58 -0000 Robert Watson wrote: > > On Thu, 24 Jul 2008, Kostik Belousov wrote: > >>> 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 :). > > Sounds good to me :-). there is some work going on by the Verio guys and by others with some namespace separation.. > > As with all such project (variant symlinks, process-local name spaces, > etc), do be very careful about security -- often as not, such projects > risk tripping over problems with privilege-escalated processes, such as > setuid binaries, etc, which place strong trust in the file system name > space. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-security@FreeBSD.ORG Thu Jul 24 16:51:46 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 A9848106566B; Thu, 24 Jul 2008 16:51:46 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3DDB68FC27; Thu, 24 Jul 2008 16:51:46 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.14.1) with ESMTP id m6OGdaex004217; Thu, 24 Jul 2008 09:39:36 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m6OGda4b004216; Thu, 24 Jul 2008 09:39:36 -0700 (PDT) Date: Thu, 24 Jul 2008 09:39:36 -0700 (PDT) From: Matthew Dillon Message-Id: <200807241639.m6OGda4b004216@apollo.backplane.com> To: Robert Watson 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> <20080724085910.GG97161@deviant.kiev.zoral.com.ua> <20080724100439.D63347@fledge.watson.org> Cc: Kostik Belousov , 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 16:51:46 -0000 Doesn't OpenBSD have a syscall filtering mechanic where one can restrict the file paths the program is allowed to access? What I would like to see is the ability to just wrap an application with a few process-tracked control directives which restricts what portion of the filesystem and kernel namespace the program (and all its children)" can then access. So, e.g. something like: #!/bin/csh # pmac $$ << EOF restrict all allow-read ~/.firefox /usr/pkg/bin allow-read /etc allow-write ~/.firefox ~/download allow-connect <<<<<< ok that probably would be allow-connect named a gaping hole, but... exec firefox ... EOF It seems to me it would be fairly simple filter to make. The problem with using different usernames, jails, chroots... the problem with all of that is that they are not fine-grained mechanisms and it is seriously inconvenient to set up on an application-by-application basis. -Matt Matthew Dillon From owner-freebsd-security@FreeBSD.ORG Thu Jul 24 18:07:56 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 CF2481065687 for ; Thu, 24 Jul 2008 18:07:56 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9B7878FC15 for ; Thu, 24 Jul 2008 18:07:56 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.64.3]) by phk.freebsd.dk (Postfix) with ESMTP id C398B170E3; Thu, 24 Jul 2008 17:41:15 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m6OHfD6P060255; Thu, 24 Jul 2008 17:41:14 GMT (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 24 Jul 2008 09:39:36 MST." <200807241639.m6OGda4b004216@apollo.backplane.com> Date: Thu, 24 Jul 2008 17:41:13 +0000 Message-ID: <60254.1216921273@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Kostik Belousov , Liste FreeBSD-security , Robert Watson , 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 18:07:56 -0000 In message <200807241639.m6OGda4b004216@apollo.backplane.com>, Matthew Dillon w rites: > Doesn't OpenBSD have a syscall filtering mechanic where one can restrict > the file paths the program is allowed to access? Yes they do. Really smart programs modify the strings after the check and get to access the files anyway. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-security@FreeBSD.ORG Thu Jul 24 18:23:26 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 47B1E106566C for ; Thu, 24 Jul 2008 18:23:26 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outY.internet-mail-service.net (outy.internet-mail-service.net [216.240.47.248]) by mx1.freebsd.org (Postfix) with ESMTP id 3ACD88FC14 for ; Thu, 24 Jul 2008 18:23:26 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 3E44E2425; Thu, 24 Jul 2008 11:23:26 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 1BB082D604A; Thu, 24 Jul 2008 11:23:24 -0700 (PDT) Message-ID: <4888C882.30707@elischer.org> Date: Thu, 24 Jul 2008 11:22:58 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Poul-Henning Kamp References: <60254.1216921273@critter.freebsd.dk> In-Reply-To: <60254.1216921273@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 24 Jul 2008 18:27:34 +0000 Cc: Kostik Belousov , Liste FreeBSD-security , Robert Watson , 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 18:23:26 -0000 Poul-Henning Kamp wrote: > In message <200807241639.m6OGda4b004216@apollo.backplane.com>, Matthew Dillon w > rites: >> Doesn't OpenBSD have a syscall filtering mechanic where one can restrict >> the file paths the program is allowed to access? > > Yes they do. > > Really smart (multithreaded) > programs modify the strings after the check and get > to access the files anyway. though it's not always successful. It's kind of strange that they don't just copyin the name. > From owner-freebsd-security@FreeBSD.ORG Thu Jul 24 23:20:26 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 C01B91065676; Thu, 24 Jul 2008 23:20:26 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 95DBE8FC16; Thu, 24 Jul 2008 23:20:26 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.14.1) with ESMTP id m6ONKQN2007280; Thu, 24 Jul 2008 16:20:26 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m6ONKPgW007279; Thu, 24 Jul 2008 16:20:25 -0700 (PDT) Date: Thu, 24 Jul 2008 16:20:25 -0700 (PDT) From: Matthew Dillon Message-Id: <200807242320.m6ONKPgW007279@apollo.backplane.com> To: Kostik Belousov , Liste FreeBSD-security , Robert Watson , Lyndon Nerenberg References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> Cc: 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 23:20:26 -0000 Well, what we are talking about here is not just copying OpenBSD, but perhaps providing a similar feature that doesn't have the same security failings. I think the best way to approach the problem is to work out the desired userland API first... find the easiest and most convenient way to wrap an application, what kind of features are desired, etc, and then implement it. It seems to me that while there are many system calls which can indirectly provide filesystem accessibility (1), the biggest guns are the ones which have to run through namei(). That bodes very well for being able to code up namespace controls that would also properly operate across softlinks. FreeBSD's namei() does do a copyinstr()... at that point the path and its various components are in kernel space. The only gotcha that I see is how to match directory-relative components against global paths. You might need a working kernel-side CWD for that. I dunno, I haven't thought that far ahead. (note 1): For a production system I think one must separate recovery from exploitation. The idea of having namespace restrictions is not to prevent the exploitation from occuring, but instead to prevent it from causing so much damage that the sysad is forced to compare the entire set of accessible filesystems against backups to revalidate the system. -Matt Matthew Dillon From owner-freebsd-security@FreeBSD.ORG Fri Jul 25 03:18: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 82C181065687; Fri, 25 Jul 2008 03:18:28 +0000 (UTC) (envelope-from tim@clewlow.org) Received: from clewlow.org (clewlow.org [210.215.149.194]) by mx1.freebsd.org (Postfix) with ESMTP id D32138FC18; Fri, 25 Jul 2008 03:18:27 +0000 (UTC) (envelope-from tim@clewlow.org) Received: from 192.168.1.100 (localhost [127.0.0.1]) by clewlow.org (Postfix) with ESMTP id DEF1A1C0844; Fri, 25 Jul 2008 13:18:24 +1000 (EST) Received: from 192.168.1.10 (SquirrelMail authenticated user tim) by 192.168.1.100 with HTTP; Fri, 25 Jul 2008 13:18:25 +1000 (EST) Message-ID: <51095.192.168.1.10.1216955905.squirrel@192.168.1.100> In-Reply-To: <200807242320.m6ONKPgW007279@apollo.backplane.com> References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> <200807242320.m6ONKPgW007279@apollo.backplane.com> Date: Fri, 25 Jul 2008 13:18:25 +1000 (EST) From: "Tim Clewlow" To: "Matthew Dillon" User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Kostik Belousov , Liste FreeBSD-security , Robert Watson , 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: Fri, 25 Jul 2008 03:18:28 -0000 > Well, what we are talking about here is not just copying > OpenBSD, > but perhaps providing a similar feature that doesn't have the > same > security failings. > > I think the best way to approach the problem is to work out the > desired > userland API first... find the easiest and most convenient way > to wrap > an application, what kind of features are desired, etc, and then > implement it. > > It seems to me that while there are many system calls which can > indirectly provide filesystem accessibility (1), the biggest > guns are > the ones which have to run through namei(). That bodes very > well for > being able to code up namespace controls that would also > properly operate > across softlinks. FreeBSD's namei() does do a copyinstr()... at > that > point the path and its various components are in kernel space. > > The only gotcha that I see is how to match directory-relative > components against global paths. You might need a working > kernel-side > CWD for that. I dunno, I haven't thought that far ahead. > > (note 1): For a production system I think one must separate > recovery > from exploitation. The idea of having namespace restrictions is > not > to prevent the exploitation from occuring, but instead to > prevent > it from causing so much damage that the sysad is forced to > compare the > entire set of accessible filesystems against backups to > revalidate > the system. > > -Matt Some more thoughts. The existing DAC method already provides sufficient protection (we all hope) to system objects, often via root/wheel. What we really want is a mechanism to protect user data from being clobbered by an errant program. By extending the traditional DAC with an Application ID (AID) the kernel could allow or deny processes that are part of a particular application from accessing a file based on the rwx flags of the AID for a particular user file. Note 1: the AID would only be tested if/after normal DAC has granted access. Note 2: It may be desirable to limit this extention to a particular section of the file system, eg /home/ - perhaps via a configuration setting somewhere. Note 3: There would need to be a way of guaranteeing unique identification of an application, maybe the full path / binary name. Note 4: It would not need to be an extension to DAC, it could just as easily be a layer added on top. Anyway, to summarise, my thinking is that: to protect all/most of a users data from a badly behaving user process (eg firefox), there would need to be a way to allow/deny specific applications from accessing specific files - and therefor at a minimum there must be the equivalent of an Application ID to match against. Just some thoughts, Tim. PS - This may already be covered by MAC, I should really read more about that :-) From owner-freebsd-security@FreeBSD.ORG Fri Jul 25 05:38:55 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 A8CAE1065678 for ; Fri, 25 Jul 2008 05:38:55 +0000 (UTC) (envelope-from sziszi@bsd.hu) Received: from mail.rubicom.hu (mail.rubicom.hu [89.147.80.28]) by mx1.freebsd.org (Postfix) with ESMTP id BF38B8FC24 for ; Fri, 25 Jul 2008 05:38:53 +0000 (UTC) (envelope-from sziszi@bsd.hu) Received: from localhost ([127.0.0.1] helo=mail.rubicom.hu) by mail.rubicom.hu with smtp (Exim 4.63) (envelope-from ) id 1KMFMN-0003Wu-5d for freebsd-security@freebsd.org; Fri, 25 Jul 2008 06:56:55 +0200 Received: from ip5993549e.rubicom.hu ([89.147.84.158] helo=baranyfelhocske.buza.adamsfamily.xx) by mail.rubicom.hu with esmtp (Exim 4.63) (envelope-from ) id 1KMFMM-0003Wk-QK for freebsd-security@freebsd.org; Fri, 25 Jul 2008 06:56:54 +0200 Received: from baranyfelhocske.buza.adamsfamily.xx (localhost [127.0.0.1]) by baranyfelhocske.buza.adamsfamily.xx (8.14.2/8.14.2) with ESMTP id m6P4usHr001958 for ; Fri, 25 Jul 2008 06:56:54 +0200 (CEST) (envelope-from sziszi@bsd.hu) Received: (from sziszi@localhost) by baranyfelhocske.buza.adamsfamily.xx (8.14.2/8.14.2/Submit) id m6P4usaE001957 for freebsd-security@freebsd.org; Fri, 25 Jul 2008 06:56:54 +0200 (CEST) (envelope-from sziszi@bsd.hu) X-Authentication-Warning: baranyfelhocske.buza.adamsfamily.xx: sziszi set sender to sziszi@bsd.hu using -f Date: Fri, 25 Jul 2008 06:56:54 +0200 From: Szilveszter Adam To: freebsd-security@freebsd.org Message-ID: <20080725045654.GA1572@baranyfelhocske.buza.adamsfamily.xx> References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> <200807242320.m6ONKPgW007279@apollo.backplane.com> <51095.192.168.1.10.1216955905.squirrel@192.168.1.100> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51095.192.168.1.10.1216955905.squirrel@192.168.1.100> User-Agent: Mutt/1.5.18 (2008-05-17) 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: Fri, 25 Jul 2008 05:38:55 -0000 On Fri, Jul 25, 2008 at 01:18:25PM +1000, Tim Clewlow wrote: > Some more thoughts. <...> > The existing DAC method already provides sufficient protection (we > all hope) to system objects, often via root/wheel. What we really > want is a mechanism to protect user data from being clobbered by an > errant program. By extending the traditional DAC with an Application > ID (AID) the kernel could allow or deny processes that are part of a > particular application from accessing a file based on the rwx flags > of the AID for a particular user file. This idea may work quite well for a server (and already does, there are several implementations out there). But for an interactive desktop software that a user drives in real-time (like firefox, as you mention) this does not work. Think about it: You want firefox to not touch your files in your ~ directory, so you configure FF in this way. But then, somehow you come to the very unlikely idea that you want to actually download something from the web. (eg a PDF manual for the latest gadget that you bought) Or upload one of your photos to an online album (as Robert Watson has already pointed out). What now? FF is not allowed to touch your files, so will not be able to do at least the first case (because that requires write access to some location in order to save the file) but quite possibly the second may not work either, after all, why would you want FF to read your office documents, so you have already denied that as well. There is no secure and usable solution to this problem, as Robert has already pointed out. The whole notion of sandboxing rests on the idea that the behaviour of an application is very deterministic (it only does A, and never, ever, anything else, during normal operation) and not very complex. Typical desktop software is already very complex, has a lot of functions and is not deterministic almost by design: there is a human sitting in front of it, doing this on one occassion and something else on another. If you allow everything that the functions of the software might cover (or only a reasonable set) you are already almost at the status-quo: You have to allow access to many-many objects, many of which are not in use most of the time, some are not in use ever, but who knows. Anything else is bad: Requiring reconfiguration of the sandbox everytime you want to save a file and then setting it back does not work. Prompting the user "Are you sure you want FF to access your files?" is bad. ("Yes, do it already!") Using "trusted" components, services, or locations to hack around it is bad. (When push comes to shove, there is nothing that could be "trusted" on a normal PC, not even the hardware in this age of mobile computing.) So no, the idea itself is interesting but does not work in the general case. It does work in specific cases though, and there it should be considered. (For example in a public Internet terminal you have no business to save anything on the local hard drive, so there is no need to allow that. But then, the desired effect can be reached much more easily there even with the existing access control.) -- Regards: Szilveszter ADAM Budapest Hungary