Re: [RFC][PATCH 0/11] security: AppArmor - Overview

[Stephen Smalley <sds@tycho.nsa.gov>]

On Fri, 2006-04-21 at 16:06 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 21 Apr 2006 14:07:33 EDT, Stephen Smalley said:
> > On Fri, 2006-04-21 at 10:30 -0700, Chris Wright wrote:
> > > * Stephen Smalley (sds@tycho.nsa.gov) wrote:
> > > > Difficult to evaluate, when the answer whenever a flaw is pointed out is
> > > > "that's not in our threat model."  Easy enough to have a protection
> > > > model match the threat model when the threat model is highly limited
> > > > (and never really documented anywhere, particularly in a way that might
> > > > warn its users of its limitations).
> > > 
> > > I know, there's two questions.  Whether the protection model is valid,
> > > and whether the threat model is worth considering.  So far, I've not
> > > seen anything that's compelling enough to show AppArmor fundamentally
> > > broken.  Ugly and inefficient, yes...broken, not yet.
> > 
> > Access control of any form requires unambiguous identification of
> > subjects and objects in the system.   Paths don't achieve such
> > identification.  Is that broken enough?  If not, what is?  What
> > qualifies as broken?
> 
> I'd be willing to at least *listen* to an argument of the form "paths are
> in general broken, but we have constraints X, Y, and Z on the system such
> that the broken parts never manifest" (for instance, a restriction on
> hardlinks that prevents hardlinking 2 files unless the resulting security
> domains of the two paths would be identical).

IIUC, AppArmor does impose such constraints, but only from the
perspective of an individual program's profile.  Upon link(2), they
check that the program had link permission to the old link name and that
both the old link name and new link name have consistent permissions in
the profile, and they prohibit or limit by capability the ability to
manipulate the namespace by confined programs.  But this doesn't mean
that another program running under a different profile can't create such
a link (if allowed to do so by its profile, of course), or that an
unconfined process cannot do so.  There is no real "system policy" or
system-wide security properties with AppArmor; you can only look at it
in terms of individual programs (which themselves are identified by path
too).

> However, I'll say up front that such an argument would only suffice to
> move it from "broken" to "very brittle in face of changes" (for instance,
> would such a hardlink restriction cause collateral damage that an attacker
> could exploit?  How badly does it fail in the face of a misdesigned policy?)

Indeed.  I think Thomas Bleher made a good assessment of it in:
https://lists.ubuntu.com/archives/ubuntu-hardened/2006-March/000143.html

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/