RE: New stacker performance results

From: Karl MacMillan (kmacmillan@private)
Date: Wed May 25 2005 - 19:21:37 PDT

> -----Original Message-----
> From: linux-security-module-bounces@private [mailto:linux-security-module-
> bounces@private] On Behalf Of Colin Walters
> Sent: Wednesday, May 25, 2005 8:27 PM
> To: Crispin Cowan
> Cc: Valdis.Kletnieks@private; Stephen Smalley; linux-security-module@private
> Subject: Re: New stacker performance results
> On Wed, 2005-05-25 at 15:57 -0700, Crispin Cowan wrote:
> > So there are SEVERE disadvantages to removing LSM and forcing everyone
> > to just use SELinux. What are the advantages? I mean, other than
> > excluding all those annoying counter-revolutionary upstarts? :)
> I think there's two strongly related but still separate issues here:
> 1) Whether SELinux can express other access control LSM modules
> 2) Should LSM be removed in favor SELinux API calls, and out-of-tree
>    modules can patch the kernel (as many do).
> My interest in this discussion is 1), which came up because of 2).  So
> far I have not yet seen an actual access control LSM which isn't better
> expressed in SELinux policy.
> > The big deal from my perspective is that some of us believe that
> > label-based access control in itself is a defect, and there are other
> > ways to do it that are more effective. The SELinux procedure to build a
> > policy to contain an application is 17 steps long (literally) and the
> > corresponding Immunix process is 3 steps long, and the steps are easier.
> I have written a number of SELinux policies from scratch and I certainly
> don't recall ticking off 17 checkboxes as I wrote them.

I always use all 17 steps mandated by the NSA . . .

>  The time taken
> wildly varied, in fact; for some applications like jabberd, writing the
> policy took all of maybe 10 minutes including testing.  For others like
> Spamassassin, I wrestled for hours with the issues such as the various
> configurations (spamd versus spamc, etc) and other programs involved
> (the MTA, procmail, etc).

And I would argue that the additional time and complexity reflected not inherent
complexity in the SELinux policy language, but the real complexity of the
software you were trying to secure. More often than not SELinux is simply
exposing the real challenges in securing complex software on a complex operating


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

> So I'm extremely skeptical of this comparison, at least if you are
> making any claim about the security equivalence of the policies.
> > But "easier" is a subjective opinion, and I don't particularly want to
> > engage in SELinux bashing. It has its strengths. The claim is just that
> > there are alternatives that have their strengths too.
> I understand the claim.  It's difficult to discuss though when there
> appears to be little in the way of online technical documentation for
> Immunix (as opposed to marketing material), and source code does not
> appear to be available.

This archive was generated by hypermail 2.1.3 : Wed May 25 2005 - 19:22:18 PDT