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: <539355.82720.qm@web36612.mail.mud.yahoo.com>
Date:	Fri, 15 Jun 2007 15:37:48 -0700 (PDT)
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Greg KH <greg@...ah.com>
Cc:	Stephen Smalley <sds@...ho.nsa.gov>,
	Crispin Cowan <crispin@...ell.com>,
	Andreas Gruenbacher <agruen@...e.de>,
	Pavel Machek <pavel@....cz>, 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

--- Greg KH <greg@...ah.com> wrote:

> On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
> > 
> > Yup, I see that once you accept the notion that it is OK for a
> > file to be misslabeled for a bit and that having a fixxerupperd
> > is sufficient it all falls out.
> > 
> > My point is that there is a segment of the security community
> > that had not found this acceptable, even under the conditions
> > outlined. If it meets your needs, I say run with it.
> 
> If that segment feels that way, then I imagine AA would not meet their
> requirements today due to file handles and other ways of passing around
> open files, right?

That segment is itself divided (think the "Judean Peoples Front"
and the "Peoples Front of Judea") on many issues, but as it has
always put correctness over ease of use I would expect AppArmor to
have a tough roe to hoe. There are other segments for which AppArmor
may well be appealing, and those segments have always been much
larger than Judea.

> So, would SELinux today (without this AA-like daemon) fit the
> requirements of this segment?

The JPF is head over heels in love with SELinux, restorecond and all.
The PFJ has some issues, but will most likely go along with the JPF
in part because the JPF is bringing the beer and besides, what are
their alternatives today? The PJF ("that's him, over there") is still
stunned by some of what SELinux accepts as normal (restorecond, 400,000
line "policy" definitions with embedded wildcards) and spends a lot
of time chanting the TCB Principle in hopes that it will help, but
no lightning strikes from above to date.

But you knew that. I'm an advocate of making a variety of alternates
available which is why I had originally proposed the authoritative
hooks version of the LSM and why I don't believe in rolling every
possible security facility into SELinux. I also believe in warning
people of pitfalls before they've impaled themselves on the spikes,
but some people gotta have the experience. Just trying to help.

Casey Schaufler
casey@...aufler-ca.com
-
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/