RE: New stacker performance results

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

> -----Original Message-----
> From: linux-security-module-bounces@private [mailto:linux-security-module-
> bounces@private] On Behalf Of Serge E. Hallyn
> Sent: Wednesday, May 25, 2005 10:39 PM
> To: Colin Walters
> Cc: Valdis.Kletnieks@private; linux-security-module@private; Stephen Smalley
> Subject: Re: New stacker performance results
> Quoting Colin Walters (walters@private):
> > 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.
> A few years ago, while I was still working on DTE, I was contacted by
> someone who ran a large web-cgi farm.  He wanted to know whether DTE
> could be used to satisfy his security goals.  In particular, he had 100k
> users who could use a few global cgi scripts, but once they ran cgi
> scripts under their own directory, those scripts should only be able to
> access files under their own home directory, with a few predefined
> exceptions.  In addition it shouldn't be "hard" to add or remove users.
> To express this in TE would require a very large policy, with policy
> reloads for user add/remove.  In contrast, a very simple LSM (dirjail)
> was able to express the policy efficiently.

This could be done with a single constraint as Colin mentioned elsewhere in this
thread. Is the policy reload really a problem?

> To take away this kind of flexibility from people actually trying to
> install real systems should not be done lightly.

I understand the argument as:

a) TE / current SELinux policy language can be used to express many security
goals and is a good choice as a general purpose language.
b) If TE is not appropriate other policy models can be implemented as new
security servers.

So no one is, I think, really arguing for limiting flexibility - this is more
about implementation strategy.


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

This archive was generated by hypermail 2.1.3 : Wed May 25 2005 - 19:50:48 PDT