On Sun, 25 Nov 2001, rhys tucker wrote: > superuser logic. The first security module overrides the dummy module by > redirecting security_operations to itself. Security modules may > implement different security polcies and may be stacked i.e. SELinux, > capabilities and DTE security modules may be in effect at the same time > (although I don't know if such a configuration is sensible). Just to clarify about stacking: you can easily stack most security modules with either the dummy (traditional superuser) module or the capabilities module because these two modules do not use the security fields added by LSM. So you can stack SELinux or DTE with capabilities. But stacking two security modules that both use the security fields requires that the two security modules use a shared convention for using the security field, e.g. a common security object header with a module identifier and a link for chaining multiple security objects on a single security field. I don't think that anyone has done this yet, so you can't just stack SELinux and DTE. Also, you can implement multiple security policies within a single security module. SELinux provides a flexible nondiscretionary access control architecture that cleanly separates policy definition from policy enforcement, so you can implement many different kinds of policies within its framework. The security policy in SELinux is encapsulated in a separate component called the security server, and an example security server is provided that implements a combination of Role-Based Access Control, Type Enforcement, and optionally Multi-Level Security. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Mon Nov 26 2001 - 09:53:26 PST