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

["Dave Neuer" <mr.fred.smoothie@pobox.com>]

On 4/21/06, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>
> 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).
>
> > 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?)
>
> Indeed.  I think Thomas Bleher made a good assessment of it in:
> https://lists.ubuntu.com/archives/ubuntu-hardened/2006-March/000143.html

But what about Dr. Cowan's response at:
https://lists.ubuntu.com/archives/ubuntu-hardened/2006-March/000144.html

In particular, if you don't trust your users, why do you give them the
ability to create links?

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