Messages in this thread | | | Date | Fri, 21 Apr 2006 17:38:37 -0400 | From | "Dave Neuer" <> | Subject | Re: [RFC][PATCH 0/11] security: AppArmor - Overview |
| |
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/
| |