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

[Valdis.Kletnieks@vt.edu]

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).

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?)

Attachment: pgpd6sVzO5RHN.pgp
Description: PGP signature