Message-Id: <1177005419.27654.157.camel@moss-spartans.epoch.ncsc.mil>
Date:	Thu, 19 Apr 2007 13:56:59 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Crispin Cowan <crispin@...ell.com>
Cc:	David Safford <safford@...son.ibm.com>,
	James Morris <jmorris@...ei.org>,
	John Johansen <jjohansen@...e.de>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: AppArmor FAQ

On Tue, 2007-04-17 at 16:09 -0700, Crispin Cowan wrote:
> David Safford wrote:
> > On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
> >   
> >> On Mon, 16 Apr 2007, John Johansen wrote:
> >>     
> >>> Label-based security (exemplified by SELinux, and its predecessors in
> >>> MLS systems) attaches security policy to the data. As the data flows
> >>> through the system, the label sticks to the data, and so security
> >>> policy with respect to this data stays intact. This is a good approach
> >>> for ensuring secrecy, the kind of problem that intelligence agencies have.
> >>>       
> >> Labels are also a good approach for ensuring integrity, which is one of 
> >> the most fundamental aspects of the security model implemented by SELinux.  
> >>
> >> Some may infer otherwise from your document.
> >>     
> > In fact, I am not sure how you can provide integrity support without
> > labels. AppArmor confines a process, but does not effectively confine 
> > its output files, precisely because the output files are not labeled. 
> > Other processes are free to access the unlabeled, potentially malicious 
> > output files without restriction. 
> >   
> That depends on what you mean by "integrity." It is true that AppArmor
> does not directly manage information flow. AppArmor assumes that if you
> granted write permission to /etc/resolv.conf, that you meant to do that.
> Whether any other process is permitted to access /etc/resolv.conf is
> determined by those other process's respective profiles.

Integrity protection requires information flow control; you can't
protect a high integrity process from being corrupted by a low integrity
process if you don't control the flow of information.  Plenty of attacks
take the form of a untrusted process injecting data that will ultimately
be used by a more trusted process with a surprising side effect.

And you can't do information flow control if you can't provide global
and persistent protection of the data, which requires labeling it and
preserving that label for its lifetime.

> What AppArmor provides is a way for administrators to confine software
> that they have to run but do not trust. The use of pathnames means that
> the administrator can understand the exact meaning of the security
> policy, without having to do a complete labeling of the file system. The
> flip side of not managing information flow is that each profile is
> independent of every other profile.

They aren't truly independent; the composition may lead to surprising
results where each individual program is "confined" exactly as you
specified, but in combination, one is able to corrupt the higher
integrity subject by actions taken by the lower integrity subject.
Particularly in the fun area of publically writable directories, where
pathnames are largely useless as an indicator.

-- 
Stephen Smalley
National Security Agency

-
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