On 4/21/06, Stephen Smalley <[email protected]> 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 [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]
