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 for Android: free password hash cracker in your pocket

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

Message-ID: <20070623001149.GI3457@sequoia.sous-sol.org>
Date:	Fri, 22 Jun 2007 17:11:49 -0700
From:	Chris Wright <chrisw@...s-sol.org>
To:	Chris Mason <chris.mason@...cle.com>
Cc:	James Morris <jmorris@...ei.org>,
	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

* Chris Mason (chris.mason@...cle.com) wrote:
> I'm sure people there will have a different versions of events.  The
> one part that was discussed was if pathname based security was
> useful, and a number of the people in the room (outside of 
> novell) said it was.  Now, it could be that nobody wanted to argue
> anymore, since most opinions had come out on one list or another by
> then.  

Indeed.  The trouble is that's too high level compared with the actual
implementation details.  AA is stalled because it has failed to get
VFS support for it's model.  I don't see a nice way out unless it
changes it's notion of policy language (globbing is the tough one)
or gets traction to pass dentry/vfsmount all the way down.  Paths are
completely relevant for security, esp. when considering the parent dir
and the leaf (as in forward lookup case).  Retroactively creating the
full path is at the minimum ugly, and in the worst case can be insecure
(yes AA has taken many measures to mitigate that insecurity).

> But as someone who doesn't use either SElinux or AA, I really hope
> we can get past the part of the debate where:
> 
> while(1)
>     AA) we think we're making users happy with pathname security
>     SELINUX) pathname security sucks

Yes.  Please.  Both parties are miserably failing the sanity test.
Doing the same thing over and over and expecting different results.

AA folks: deal with the VFS issues that your patchset have in a palatable
way (which does not include passing NULL when it's inconvenient to
do otherwise).  You've already missed an opportunity with Christoph's
suggestions for changes in NFS.  I know you've considered many alternative
approaches and consistently hit dead ends.  But please note, if you
have coded yourself into a corner because of your policy language,
that's your issue to solve, not ours.

SELinux folks: do something useful rather than quibbling over the TCSEC
definition of MAC and AA's poor taste in marketing literature.  Here's
some suggestions:

1) Make SELinux usable (it's *still* the number one complaint).  While
this is a bit of a cheap shot, it really is one of the core reasons AA
advocates exist.
2) Work on a variant of Kyle's suggestion to squash the relevancy of AA.
3) Write an effective exploit against AA that demonstrates the fundamental
weakness of the model (better make sure it's not also an issue for
targetted policy).

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