From owner-freebsd-security@FreeBSD.ORG Tue Jul 29 02:36:30 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 7C1C8106566B for ; Tue, 29 Jul 2008 02:36:30 +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 8D9428FC2C for ; Tue, 29 Jul 2008 02:36:29 +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 887EA1C081D for ; Tue, 29 Jul 2008 12:36:27 +1000 (EST) Received: from 192.168.1.10 (SquirrelMail authenticated user tim) by 192.168.1.100 with HTTP; Tue, 29 Jul 2008 12:36:27 +1000 (EST) Message-ID: <51075.192.168.1.10.1217298987.squirrel@192.168.1.100> In-Reply-To: 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> <20080725045654.GA1572@baranyfelhocske.buza.adamsfamily.xx> Date: Tue, 29 Jul 2008 12:36:27 +1000 (EST) From: "Tim Clewlow" To: freebsd-security@freebsd.org 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 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: Tue, 29 Jul 2008 02:36:30 -0000 On Thu, Jul 24, 2008 at 9:56 PM, Szilveszter Adam wrote: > 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. I'd like to offer a possible solution that I believe can be both secure and usable. This will use the AID concept outlined above. (Note, when I refer to a rwx flag in the following paragraphs, I am talking about a flag in a 4th group, ie in addition to the normal user/group/other set of flags, lets call it the app set - in addition, there is an associated AID for any of the 3 of those flags that have been set, ie there can be up to 3 different application ID's set for a single user file) When a user file is created, the kernel sets the read flag, and sets the AID for that flag to 0 (0 being a special value), the intention being that this means any application can read the file. Next the kernel sets the the write flag, and set the AID for the write flag to be the same as the application that is creating the file. (If at some later time the user wants to limit reading to a single application, then they can with the equivalent of a chmod for AID) Using this method, an errant application will only be able to damage data files that it owns. It also means if an application wants to create a new file, then it can. This solves the problems presented above. (If the file about to be created already exists, then as long as the application owns the file, it should be allowed to overwrite it as it should already have write access) For systems with this enabled, ie desktop systems, this would, for the majority of data files, work quietly in the background without the user even being aware of what is going on. One place where some work would be required is during the installation or upgrade of an application, ie as part of the installation, there would need to be some provision for acquiring the AID that the application will eventually be given by the kernel, and then setting the write AID value accordingly for any data / config files that may be created during installation. This is part of what I was referring to when I said the implementation of AID would create a system that has some important differences from a vanilla FreeBSD system. Anyway, I just wanted to offer this as being a potential way of overcoming some of the pitfalls pointed out above. Yes I know I am being persistant, and probably a bit annoying too. I dont mean it to be, I just would like to explore the possibilities of enhanced security that may be available. Feel free to shoot holes in any/all of this, I may have painted a big target here :-) Cheers, Tim.