linux-kernel - Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 22 Jun 2007 10:02:40 -0400
From:	Chris Mason <chris.mason@...cle.com>
To:	James Morris <jmorris@...ei.org>
Cc:	Stephen Smalley <sds@...ho.nsa.gov>,
	Lars Marowsky-Bree <lmb@...e.de>, Pavel Machek <pavel@....cz>,
	Crispin Cowan <crispin@...ell.com>, Greg KH <greg@...ah.com>,
	Andreas Gruenbacher <agruen@...e.de>, jjohansen@...e.de,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

On Fri, Jun 22, 2007 at 09:48:12AM -0400, James Morris wrote:
> On Fri, 22 Jun 2007, Chris Mason wrote:
> 
> > > The validity or otherwise of pathname access control is not being 
> > > discussed here.
> > > 
> > > The point is that the pathname model does not generalize, and that 
> > > AppArmor's inability to provide adequate coverage of the system is a 
> > > design issue arising from this.
> > 
> > I'm sorry, but I don't see where in the paragraphs above you aren't
> > making a general argument against the pathname model.
> 
> There are two distinct concepts here.
> 
> A. Pathname labeling - applying access control to pathnames to objects, 
> rather than labeling the objects themselves.
> 
> Think of this as, say, securing your house by putting a gate in the street 
> in front of the house, regardless of how many other possible paths there 
> are to the house via other streets, adjoining properties etc.
> 
> Pathname labeling and mediation is simply mediating a well-known path to 
> the object.  In this analogy, object labeling would instead ensure that 
> all of the accessible doors, windows and other entrances of the house were 
> locked, so that someone trying to break in from the rear alley would 
> not get in simply by bypassing the front gate and opening any door.
> 
> What you do with AppArmor, instead of addressing the problem, is just 
> redefine the environment along the lines of "set your house into a rock 
> wall so there is only one path to it".
> 
> 
> B. Pathname access control as a general abstraction for OS security.
> 
> Which is what was being discussed above, in response to a question from 
> Lars about technical issues, and that this _model_ doesn't generalize to 
> the rest of the OS, regardless of whether you think the mechanism of 
> pathname labeling itself is appropriate or not.

I'm sorry, but I don't see where in the paragraphs above you aren't
making a general argument against the pathname model.  I'm not trying to
get into that discussion (I'm smart enough to know I'm far too stupid to
hold my own there).

I do understand that AA is different from selinux, and that you
have valid points about the level and type of protection that AA offers.

But, this is a completely different discussion than if AA is
solving problems in the wild for its intended audience, or if the code
is somehow flawed and breaking other parts of the kernel.

We've been over the "AA is different" discussion in threads about a
billion times, and at the last kernel summit.  I think Lars and others
have done a pretty good job of describing the problems they are trying
to solve, can we please move on to discussing technical issues around
that?

-chris



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/