On Wed, 2005-05-25 at 09:23 -0700, Casey Schaufler wrote: > In the Unix Era we made our share of mistakes, > especially with add on module interfaces and > extreme security implementations. STREAMS modules > and Information labels come to mind as prime > examples. I can think of no instance where the > two types of facilities were combined into the > same blunder. I'm not sure I follow your meaning above; it almost sounds like an indictment of LSM, which is a module interface for security implementations, not SELinux, which is a particular security implementation that presently leverages LSM but was originally implemented as a direct kernel patch that involved no kernel module at all. Even now, SELinux is not truly a kernel module; it has to be built-in to be used, and is tightly coupled to the core kernel since it implements the full range of LSM hooks (not necessarily every individual LSM hook, but a fairly sweeping set covering all kernel subsystems). > SELinux is a poor choice for a general framework. Flask/SELinux was designed as a flexible MAC framework. Feel free to suggest your own, but be ready to provide supporting documentation of how it has been analyzed for its ability to represent a wide spectrum of security models. Such analysis has been done and is available in publically available reports for SELinux. > While Type Enforcement may be used to implement > many interesting policies it is far from universal. SELinux isn't limited to TE, although it is certainly a useful building block security model. > SELinux is not a lightweight implementation, and > would be overkill if all you wanted was a minor > policy such as time-of-day access restrictions. Time-of-day restrictions can be implemented via the conditional policy support in SELinux. More generally, if there is a security model that is useful that cannot be presently expressed via SELinux, extending SELinux to support it should be more straightforward than having to implement an entirely new security module from scratch. > SELinux associates rights and privileges with > programs, a paradighm that has it's detractors. Aside from the fact that such detractors are wrong, SELinux doesn't force this paradigm, it just allows it. One can certainly write a TE policy that only assigns rights to users and does not distinguish programs at all. > But the most important problem that I see from > here is that nowhere is there a complete and > accurate description of how, *in general* one > would go about creating an arbitrary and > complete policy using SELinux. Sorry, a "complete" description of how "in general" one might create an "arbitrary" policy? The assumptions force the conclusion. -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Wed May 25 2005 - 09:46:30 PDT