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 :-)