On Fri, 2006-04-21 at 16:35 -0400, Stephen Smalley wrote:
> On Fri, 2006-04-21 at 16:06 -0400, [email protected] 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 ([email protected]) 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
