> -----Original Message----- > From: Crispin Cowan [mailto:crispin@private] > Sent: Wednesday, May 25, 2005 10:30 PM > To: Karl MacMillan > Cc: 'Colin Walters'; 'Stephen Smalley'; linux-security-module@private > Subject: Re: New stacker performance results > > Karl MacMillan wrote: > >>SELinux is big, slow, and complicated. Not everyone likes that. QED :) > >> > >Not to take this comment too seriously, but are you referring to the security > >server currently provided by SELinux which implements TE or general framework > >provided by SELinux (FLASK)? It doesn't seem like you are making that > >distinction in your comments. > > > I have not done the detailed measurements to distinguish between the > FLASK layer and the TE layer. Most of the available information on > SELinux does not make such a distinction. Just making certain that it was clear what we were discussing. > The "big" comment is the size > of the module and the size of the set of associated utilities. Are you saying that the SELinux module has more code than is necessary to implement its feature set? Is the "big" judgment in comparison to something else, e.g. AppArmor? If so, does that size comparison really make sense based on what the two modules implement? Regardless, I'm not certain that the module size is necessarily important, only the comprehensibility of the code, which in SELinux is quite good. I'm not familiar with the AppArmor code so I can draw no conclusions. Which utilities are you referring to? The required set of utilities is very small and most are trivial. > The > "slow" comment is from SELinux's self-claimed overhead of 6-15% (Immunix > measures at 0-2%) Are these benchmarks numbers comparable at all? Are they the same benchmarks? Additionally, it is important to know whether what is being enforced is equivalent. If SELinux is providing coverage of, say, a certain IPC mechanism that AppArmor does not control at all then a comparison of IPC latency / throughput from lmbench is not exactly useful (this is a contrived example - what I have read about AppArmor leads me to believe that it lacks many of the controls that SELinux provides but I do not know for sure). If you want to make these assertions and have them be convincing, I suggest that you provide enough detail to make them meaningful. Raw percentages with no other context is hardly a meaningful comparison. > as well as other anecdotal stories about poor > performance. This is even less useful than the raw percentages. > The "complicated" remark comes from both the wide-spread > reputation that SELinux is very hard to use as well as direct > comparisons that we have done of trying to perform equivalent security > tasks with SELinux and Immunix. > Well, this has been hashed to death many times in many places. The short answer I have is that a) SELinux policy exposes the true complexities of the security issues and b) is well suited to be generated from higher level abstractions that hide some granularity where it is not needed. SELinux provides the necessary controls required to implement a wide set of security policies - I think that you would be hard pressed to create a language with the expressive power that was more concise. When that flexibility is not needed I think it is preferable to create abstractions above the current language rather than starting from scratch. This last approach is just now starting to be explored and I think that it will yield good results. > Caveat: this "equivalent task" is to create a per-application policy, > what Red Hat calls the "targeted policy". Immunix was designed from the > outset to enforce a security model very similar to the targeted policy, > while SELinux is being pressed into service to do that. Conversely, > Immunix AppArmor was not designed to enforce anything like the SELinux > "strict policy", and making it do that would produce usability problems, > at the least. > > All of which supports my point that there is more than one security > model that different users may want. LSM lets users choose the > appropriate model for them. > This only supports your point if I accept that SELinux is "being pressed into service to do that". There is nothing about the targeted policy that goes against the core concepts of SELinux. In fact, I think the existence of the targeted policy is a point in favor of the flexibility and generality of SELinux policy. BTW - I am not trying to argue for the removal of LSM, I'm simply trying to accurately portray SELinux. Karl --- Karl MacMillan Tresys Technology http://www.tresys.com (410) 290-1411 ext 134 > Crispin > -- > Crispin Cowan, Ph.D. http://immunix.com/~crispin/ > Director of Software Engineering, Novell http://novell.com
This archive was generated by hypermail 2.1.3 : Wed May 25 2005 - 20:26:48 PDT