Hi, On Tue, Apr 18, 2006 at 12:58:19PM +0100, Christoph Hellwig wrote: > It's doing access control on pathnames, which can't work in unix enviroments. > It's following the default permit behaviour which causes pain in anything > security-related (compare [1]). Pathnames are problematic, no doubt. So AppArmor does currently do some less-than-nice things to get around this. On the other side, pathnames is what the admins see and use, so it is the right abstraction for the sysadmin, if you want to make a higher level of security available to people without the need to get them a large amount of extra training. So that gap needs to be bridged somehow. Maybe there are better ways compared to what AA does currently, and constructive suggestions are very welcome! And no, just claiming that AA is useless or crap is not constructive AFAICT. And saying that is should be better done as part of SElinux is not either. The goals are quite different. SElinux is a solution that wants to implement policies that cover lots of things. It's accordingly powerful and complex. AppArmor is easy. Everyone with a little background in Un*x can understand what it does and how it needs to be configured. Eventually, most sysadmins of the world can configure it correctly and thus make their systems more secure. (The submission to LKML should happen RSN, the committment has been there since a long time!) I don't want to judge, but I think the approaches and goals are different enough to grant both (and evetually others) the right to live. Actually, I'm a bit worried about the discussion. When I chose Linux, it was about the freedom of choice. And we have a nice abstraction (LSM) that allows this freedom. At a small price. It's not pleasant to see that some people want to move away from that. Best, -- Kurt Garloff, Head Architect Linux R&D, Novell Inc.
Attachment:
pgpyeM3V8kKE6.pgp
Description: PGP signature
- Follow-Ups:
- Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
- From: Stephen Smalley <[email protected]>
- Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
- From: "Serge E. Hallyn" <[email protected]>
- Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
- From: Arjan van de Ven <[email protected]>
- Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
- From: [email protected]
- Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
- References:
- Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
- From: Christoph Hellwig <[email protected]>
- Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
- From: Gerrit Huizenga <[email protected]>
- Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
- From: Christoph Hellwig <[email protected]>
- Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
- Prev by Date: Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
- Next by Date: [PATCH]drivers/char/cs5535_gpio.c:call cdev_del during module_exit to unmap kobject references and other cleanups.
- Previous by thread: Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
- Next by thread: Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
- Index(es):