Quoting Karl MacMillan (kmacmillan@private): > > 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. I assume you're suggesting a constraint on u1!=u2. (which would still require 100k selinux users... you'd know better than I how much space that takes, I haven't looked) I don't think that could work. All the user directories were nfs-mounted and owned by the same uid/gid. > Is the policy reload really a problem? I assume it was. After I explained the lsm I had in mind, the guy decided he wanted to roll his own. (Don't we all :) So I have no idea what he ended up doing or how the situation has changed. > > 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. I don't argue this. Though many people do. (And please don't disregard that - I also consider vi a very good editor, but we can't force people to use it just because it has all the features one might need) > b) If TE is not appropriate other policy models can be implemented as new > security servers. Sure, they can. Or, they can be implemented as LSMs. We could also implement RSBAC as a security server under selinux under LSM. Then we could say that because you can implement jail under RSBAC, you should never do it under selinux or as an LSM. > So no one is, I think, really arguing for limiting flexibility - this is more > about implementation strategy. I understand. And I think there will be far less resistance to that once (a) someone implements alternate (or stackable :) security servers other than MLS (which isn't really an alternate ss) and/or (b) some of the improved policy tools finally come to be. -serge
This archive was generated by hypermail 2.1.3 : Thu May 26 2005 - 06:24:54 PDT