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: <20070615214441.GB18039@kroah.com>
Date:	Fri, 15 Jun 2007 14:44:41 -0700
From:	Greg KH <greg@...ah.com>
To:	Karl MacMillan <kmacmill@...hat.com>
Cc:	Casey Schaufler <casey@...aufler-ca.com>,
	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

On Fri, Jun 15, 2007 at 05:28:35PM -0400, Karl MacMillan wrote:
> On Fri, 2007-06-15 at 14:14 -0700, Greg KH 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?
> > 
> > So, would SELinux today (without this AA-like daemon) fit the
> > requirements of this segment?
> > 
> 
> Yes - RHEL 5 is going through CC evaluations for LSPP, CAPP, and RBAC
> using the features of SELinux where appropriate.

Great, but is there the requirement in the CC stuff such that this type
of "delayed re-label" that an AA-like daemon would need to do cause that
model to not be able to be certified like your SELinux implementation
is?

As I'm guessing the default "label" for things like this already work
properly for SELinux, I figure we should be safe, but I don't know those
requirements at all.

thanks,

greg k-h
-
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/