RE: New stacker performance results

From: Karl MacMillan (kmacmillan@private)
Date: Wed May 25 2005 - 20:25:46 PDT

> -----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

BTW - I am not trying to argue for the removal of LSM, I'm simply trying to
accurately portray SELinux.


Karl MacMillan
Tresys Technology
(410) 290-1411 ext 134

> Crispin
> --
> Crispin Cowan, Ph.D.            
> Director of Software Engineering, Novell

This archive was generated by hypermail 2.1.3 : Wed May 25 2005 - 20:26:48 PDT