> -----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 --- Karl MacMillan Tresys Technology http://www.tresys.com (410) 290-1411 ext 134 > -serge
This archive was generated by hypermail 2.1.3 : Wed May 25 2005 - 19:50:48 PDT