lkml.org 
[lkml]   [2006]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC][PATCH 0/11] security: AppArmor - Overview
From
Date
On Fri, 2006-04-21 at 16:35 -0400, Stephen Smalley wrote:
> 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).

Oh, and in the case, of links to programs (as opposed to data files),
the AppArmor folks have been known to encourage people to create
multiple hard links to a single program with different profiles as a way
of supporting multiple security domains for a single program, e.g.
creating multiple links to bash and using them as user shells to
establish different security domains for users.

--
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/

\
 
 \ /
  Last update: 2006-04-21 22:42    [W:0.902 / U:0.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site