On Tue, 29 Jun 2004 11:49:36 EDT, James Morris said: > The optimization for a single LSM is good, but won't the common case be > two LSMs (e.g. capabilities + something else) ? If so, I'd suggest having > two statically allocated entries as primary & secondary, then any further > LSMs can be stacked dynamically. Even then, unless a distro was planning > on shipping three or more stacked LSMs by default, I'd wonder if it was > really going to be useful in a wider sense. I could *easily* see "3 or more" LSMs being shipped... Consider: 1) SELinux (I'll even grant you not counting this as a "stacked").. 2) A harden-/tmp LSM like what I *started* working on.. 3) a harden-chroot LSM like Jail.. 4) a Capabilities LSM... Over 65% of the LSM that I did isn't even stuff I *wanted* to do, it was stuff that got dragged in because I ended up needing to do all of 2,3 and 4.... And sites that have some need to implement a "Users/Processes of Type X can't do Operation Y" to satisfy some local requirement (possibly not easily expressed in SELinux terms - consider a rule like "Processes run by Graduate Students may not access the Foo Shared Resource between 9AM and 5PM M-F"...) may be looking at a *fifth* LSM to implement one or two rules....
This archive was generated by hypermail 2b30 : Tue Jun 29 2004 - 09:31:33 PDT