Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759824AbXFUTzm (ORCPT ); Thu, 21 Jun 2007 15:55:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759444AbXFUTyo (ORCPT ); Thu, 21 Jun 2007 15:54:44 -0400 Received: from gate.in-addr.de ([212.8.193.158]:48212 "EHLO mx.in-addr.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1759573AbXFUTyl (ORCPT ); Thu, 21 Jun 2007 15:54:41 -0400 Date: Thu, 21 Jun 2007 21:54:00 +0200 From: Lars Marowsky-Bree To: James Morris Cc: Pavel Machek , Crispin Cowan , Greg KH , Andreas Gruenbacher , Stephen Smalley , 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: <20070621195400.GK20105@marowsky-bree.de> References: <466C303E.5010304@novell.com> <20070615165054.GA11345@kroah.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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: 1890 Lines: 46 On 2007-06-21T15:42:28, James Morris wrote: > > A veto is not a technical argument. All technical arguments (except for > > "path name is ugly, yuk yuk!") have been addressed, have they not? > AppArmor doesn't actually provide confinement, because it only operates on > filesystem objects. > > What you define in AppArmor policy does _not_ reflect the actual > confinement properties of the policy. Applications can simply use other > mechanisms to access objects, and the policy is effectively meaningless. Only if they have access to another process which provides them with that data. And now, yes, I know AA doesn't mediate IPC or networking (yet), but that's a missing feature, not broken by design. > You might define this as a non-technical issue, but the fact that AppArmor > simply does not and can not work is a fairly significant consideration, I > would imagine. If I restrict my Mozilla to not access my on-disk mail folder, it can't get there. (Barring bugs in programs which Mozilla is allowed to run unconfined, sure.) If the argument is that AA provides somewhat different semantics - and for some use cases "weaker" ones - than SE Linux, that is undoubtly true. However, it appears to be the case that those are the differences which make AA's model different from SELinux as well, so it appears a trade-off best left to the admin / user to choose what fits their needs best. 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/