From owner-freebsd-security@FreeBSD.ORG Wed Jul 30 11:41:51 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 CD5DF106567B for ; Wed, 30 Jul 2008 11:41:51 +0000 (UTC) (envelope-from mail@maxlor.com) Received: from popeye1.ggamaur.net (popeye1.ggamaur.net [213.160.40.50]) by mx1.freebsd.org (Postfix) with ESMTP id 62F508FC19 for ; Wed, 30 Jul 2008 11:41:51 +0000 (UTC) (envelope-from mail@maxlor.com) Received: from maxlor.mine.nu (c-82-192-240-247.customer.ggaweb.ch [82.192.240.247]) by popeye1.ggamaur.net (8.13.7/8.13.7/Submit) with ESMTP id m6UB11GK095576; Wed, 30 Jul 2008 13:01:03 +0200 (CEST) (envelope-from mail@maxlor.com) Received: from localhost (unknown [127.0.0.1]) by maxlor.mine.nu (Postfix) with ESMTP id 0D76B2E3BA; Wed, 30 Jul 2008 13:00:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at atlantis.intranet Received: from maxlor.mine.nu ([127.0.0.1]) by localhost (atlantis.intranet [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oz4dExvsIaGu; Wed, 30 Jul 2008 13:00:55 +0200 (CEST) Received: from [192.168.10.161] (pub212004072186.fx-hfc.datazug.ch [212.4.72.186]) by maxlor.mine.nu (Postfix) with ESMTPSA id BD5052E3B7; Wed, 30 Jul 2008 13:00:55 +0200 (CEST) From: Benjamin Lutz To: freebsd-security@freebsd.org Date: Wed, 30 Jul 2008 13:00:54 +0200 User-Agent: KMail/1.9.9 References: <60254.1216921273@critter.freebsd.dk> <51075.192.168.1.10.1217298987.squirrel@192.168.1.100> In-Reply-To: <51075.192.168.1.10.1217298987.squirrel@192.168.1.100> X-Face: $Ov27?7*N,h60fIEfNJdb!m,@#4T/d; 1hw|W0zvsHM(a$Yn6BYQ0^SEEXvi8>D`|V*F"=?iso-8859-1?q?=5F+=0A=09R2?=@Aq>+mNb4`,'[[%z9v0Fa~]AD1}xQO3|>b.z&}l#R-_(P`?@Mz"kS; XC>Eti,i3>%@=?iso-8859-1?q?g=3F=0A=094f?=,\c7|Ghwb&ky$b2PJ^\0b83NkLsFKv|smL/cI4UD%Tu8alAD MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807301300.54490.mail@maxlor.com> X-Scanned-By: MIMEDefang 2.64 on 213.160.40.60 Cc: Tim Clewlow 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: Wed, 30 Jul 2008 11:41:51 -0000 On Tuesday 29 July 2008 04:36:27 Tim Clewlow wrote: > 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) Can you elaborate a bit more on what the AID for the x permission is going to look like? Obviously, there have to be applications with very wide-ranging permissions (a filemanager, tools like cp and mv, or the tool used to set AID permissions). Being able to execute them often means being able to change the target file freely and non-interactively (with cp for example). So most applications should not be able to execute cp, right?. However, what about programs whose main job it is to launch other processes, such as /bin/sh. How are you going to prevent some evil application from running /bin/sh -c "cp /dev/zero /very/important/file"? If you're now thinking, limit who can run /bin/sh, consider that some application launching programs can be controlled in other ways; KDE apps can often be controlled with DCOP for example. Cheers Benjamin