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:	Fri, 15 Jun 2007 13:43:31 -0700 (PDT)
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Stephen Smalley <sds@...ho.nsa.gov>, casey@...aufler-ca.com
Cc:	Greg KH <greg@...ah.com>, 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


--- Stephen Smalley <sds@...ho.nsa.gov> wrote:

> On Fri, 2007-06-15 at 11:01 -0700, Casey Schaufler wrote:
> > --- Greg KH <greg@...ah.com> wrote:
> > 
> > 
> > > A daemon using inotify can "instantly"[1] detect this and label the file
> > > properly if it shows up.
> > 
> > In our 1995 B1 evaluation of Trusted Irix we were told in no
> > uncertain terms that such a solution was not acceptable under
> > the TCSEC requirements. Detection and relabel on an unlocked
> > object creates an obvious window for exploitation. We were told
> > that such a scheme would be considered a design flaw.
> > 
> > I understand that some of the Common Criteria labs are less
> > aggressive regarding chasing down these issues than the NCSC
> > teams were. It might not prevent an evaluation from completing
> > today. It is still hard to explain why it's ok to have a file
> > that's labeled incorrectly _even briefly_. It is the systems
> > job to ensure that that does not happen.
> 
> Um, Casey, he is talking about how to emulate AppArmor behavior on a
> label-based system like SELinux,

Yes. What I'm saying (or trying to) is that such an implementation
would be flawed by design.

> not meeting B1 or LSPP or anything like that
> (which AppArmor can't do regardless).

We're not talking about an implementation based on AppArmor. As
you point out, we're talking about implementing name based access
control as an extension of SELinux.

> As far as general issue
> goes, if your policy is configured such that the new file gets the most
> restrictive label possible at creation time and then the daemon relabels
> it to a less restrictive label if appropriate, then there is no actual
> window of exposure.

Is it general practice to configure policy such that "the new file gets
the most restrictive label possible at creation time"? I confess that
my understanding of the current practice in policy generation is based
primarily on a shouted conversation in a crowded Irish pub.

> Also, there is such a daemon, restorecond, in SELinux (policycoreutils)
> although we avoid relying on it for anything security-critical
> naturally.

Yes, I am aware of restorecond. I find the need for restorecond troubling.

> And one could introduce the named type transition concept
> that has been discussed in this thread without much difficulty to
> selinux.

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.


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/