Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Chris Mason <chris.mason@oracle.com>]

On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote:
> On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:
> > On 2007-06-21T15:42:28, James Morris <jmorris@namei.org> wrote:
> > 
> > > > A veto is not a technical argument. All technical arguments (except for
> > > > "path name is ugly, yuk yuk!") have been addressed, have they not?
> > > AppArmor doesn't actually provide confinement, because it only operates on 
> > > filesystem objects.
> > > 
> > > What you define in AppArmor policy does _not_ reflect the actual 
> > > confinement properties of the policy.  Applications can simply use other 
> > > mechanisms to access objects, and the policy is effectively meaningless.
> > 
> > Only if they have access to another process which provides them with
> > that data.
> 
> Or can access the data under a different path to which their profile
> does give them access, whether in its final destination or in some
> temporary file processed along the way.
> 
> > And now, yes, I know AA doesn't mediate IPC or networking (yet), but
> > that's a missing feature, not broken by design.
> 
> The incomplete mediation flows from the design, since the pathname-based
> mediation doesn't generalize to cover all objects unlike label- or
> attribute-based mediation.  And the "use the natural abstraction for
> each object type" approach likewise doesn't yield any general model or
> anything that you can analyze systematically for data flow.

This feels quite a lot like a repeat of the discussion at the kernel
summit.  There are valid uses for path based security, and if they don't
fit your needs, please don't use them.  But, path based semantics alone
are not a valid reason to shut out AA.

-chris