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]

Message-ID: <20070609234758.GD21229@elf.ucw.cz>
Date:	Sun, 10 Jun 2007 01:47:58 +0200
From:	Pavel Machek <pavel@....cz>
To:	Greg KH <greg@...ah.com>
Cc:	Stephen Smalley <sds@...ho.nsa.gov>,
	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

Hi!

> > > I assume you mean labels instead of handles.
> > > 
> > > AppArmor's design is around paths not labels, and independent of whether or 
> > > not you like AppArmor, this design leads to a useful security model distinct 
> > > from the SELinux security model (which is useful in its own ways). The 
> > > differences between those models cannot be argued away, neither is a subset 
> > > of the other, and neither is a misdesign. I would be thankful if you could 
> > > stop spreading this lie.
> > 
> > I have a hard time distinguishing AppArmor's "model" from its
> > implementation; every time we suggest that one might emulate much of
> > AppArmor's functionality on SELinux (as in SEEdit), someone points to a
> > specific characteristic of the AppArmor implementation that cannot be
> > emulated in this manner.  But is that implementation characteristic an
> > actual requirement or just how it happens to have been done to date in
> > AA?  And I get the impression that even if we extended SELinux in
> > certain ways to ease such emulation, the AA folks would never be
> > satisfied because the implementation would still differ.  Can we
> > separate the desired functionality and actual requirements from the
> > implementation specifics?
> 
> That's a really good point, is there a description of the AA "model"
> anywhere that we could see to determine if there really is a way to
> possibly use the current SELinux internals to show this model to the
> user?

Hmm, techdoc.pdf (attached) is supposed to describe this "model", but
it is more of "AA works like this" with no explanations.... and
includes (probably unwanted) quirks like various races during path
resolution.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "techdoc.pdf" of type "application/pdf" (156018 bytes)