Messages in this thread | | | Date | Tue, 18 Apr 2006 13:35:48 -0700 | From | Crispin Cowan <> | Subject | Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks |
| |
Stephen Smalley wrote: > On Tue, 2006-04-18 at 12:31 -0700, Crispin Cowan wrote: > >> AppArmor (then called "SubDomain") showed how this worked in practice >> years before the Targeted Policy came along. The Targeted Policy >> implements an approximation to the AppArmor security model, but does it >> with domains and types instead of path names, imposing a substantial >> cost in ease-of-use on the user. >> > Just to clarify a few points: > - It is true that both AppArmor and SELinux with targeted policy only > (effectively) restrict a subset of processes, but SELinux with targeted > policy provides complete mediation of all objects and operations for > those processes, not just capabilities and files like AppArmor. > Agreed, with the caveat that mediating all those things comes with expense, and AppArmor doesn't mediate them by design, because our goal is to keep the host from being compromised by a hacked application, not to control all information flow. Different goals produce different designs.
> - Targeted policy demonstrates that a general purpose mechanism that is > capable of complete mediation of all processes, objects, and operations > (SELinux) can be applied to selective control if that is your goal. The > reverse is not true; AppArmor is limited by its design. > Also agreed, and also caveated that the general purpose system emulating the simple system is much more complex than the simple system itself, and simplicity is a critical part of secure design. In this case, the most expensive impact on simplicity is the complexity of the policy that users have to manage.
> - Ease of use should be addressed in the user interface, not by using a > broken kernel mechanism. There is ongoing work to address the > useability of SELinux in userspace; it doesn't require changing the > kernel mechanism to rely on pathnames (which is broken). > Mediating by file names rather than inodes is the fundamental place where we disagree. I am delighted with LSM, because it allows us to disagree without having to fight about it.
Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com
- 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/
| |