Messages in this thread | | | Subject | Re: [RFC][PATCH 0/11] security: AppArmor - Overview | From | Stephen Smalley <> | Date | Fri, 21 Apr 2006 16:44:17 -0400 |
| |
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/
| |