Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759642AbXFUVSb (ORCPT ); Thu, 21 Jun 2007 17:18:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755916AbXFUVSV (ORCPT ); Thu, 21 Jun 2007 17:18:21 -0400 Received: from gate.in-addr.de ([212.8.193.158]:48731 "EHLO mx.in-addr.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755082AbXFUVSU (ORCPT ); Thu, 21 Jun 2007 17:18:20 -0400 Date: Thu, 21 Jun 2007 23:17:43 +0200 From: Lars Marowsky-Bree To: Stephen Smalley Cc: James Morris , Pavel Machek , Crispin Cowan , Greg KH , Andreas Gruenbacher , jjohansen@suse.de, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching Message-ID: <20070621211743.GN20105@marowsky-bree.de> References: <20070615200623.GA2616@elf.ucw.cz> <20070615211157.GB7337@kroah.com> <46732124.80509@novell.com> <20070616000251.GG2616@elf.ucw.cz> <20070621160840.GA20105@marowsky-bree.de> <20070621183311.GC18990@elf.ucw.cz> <20070621192407.GF20105@marowsky-bree.de> <20070621195400.GK20105@marowsky-bree.de> <1182459594.20464.16.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1182459594.20464.16.camel@moss-spartans.epoch.ncsc.mil> X-Ctuhulu: HASTUR User-Agent: Mutt/1.5.9i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1491 Lines: 41 On 2007-06-21T16:59:54, Stephen Smalley wrote: > Or can access the data under a different path to which their profile > does give them access, whether in its final destination or in some > temporary file processed along the way. Well, yes. That is intentional. Your point is? > The emphasis on never modifying applications for security in AA likewise > has an adverse impact here, as you will ultimately have to deal with > application mediation of access to their own objects and operations not > directly visible to the kernel (as we have already done in SELinux for > D-BUS and others and are doing for X). Otherwise, your "protection" of > desktop applications is easily subverted. That is an interesting argument, but not what we're discussing here. We're arguing filesystem access mediation. > Um, no. It might not be able to directly open files via that path, but > showing that it can never read or write your mail is a rather different > matter. Yes. Your use case is different than mine. Regards, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/