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 08:17:42 -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 Thu, Jun 21, 2007 at 09:06:40PM -0400, 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.

I'm sorry, but I don't see where in the paragraphs above you aren't
making a general argument against the pathname model.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ