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:	Thu, 21 Jun 2007 22:17:37 -0600
From:	Crispin Cowan <crispin@...ell.com>
To:	James Morris <jmorris@...ei.org>
CC:	Chris Mason <chris.mason@...cle.com>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	Lars Marowsky-Bree <lmb@...e.de>, Pavel Machek <pavel@....cz>,
	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

James Morris wrote:
> On Thu, 21 Jun 2007, Chris Mason wrote:  
>>> The incomplete mediation flows from the design, since the pathname-based
>>> mediation doesn't generalize to cover all objects unlike label- or
>>> attribute-based mediation.  And the "use the natural abstraction for
>>> each object type" approach likewise doesn't yield any general model or
>>> anything that you can analyze systematically for data flow.
>>>       
>> This feels quite a lot like a repeat of the discussion at the kernel
>> summit.  There are valid uses for path based security, and if they don't
>> fit your needs, please don't use them.  But, path based semantics alone
>> are not a valid reason to shut out AA.
>>     
> 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.
>   
The above two paragraphs appear to contradict each other.

> Recall that the question asked by Lars was whether there were any 
> outstanding technical issues relating to AppArmor.
>
> AppArmor does not and can not provide the level of confinement claimed by 
> the documentation, and its policy does not reflect its actual confinement 
> properties.  That's kind of a technical issue, right?
>   
So if the document said "confinement with respect to direct file access
and POSIX.1e capabilities" and that list got extended as AA got new
confinement features, would that address your issue?

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
	AppArmor Chat: irc.oftc.net/#apparmor


-
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/