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