> Is there any particular reason why LSM uses stacking? > > To me the possibiliy of having several, specialized modules called for > access checks in the order they were loaded, seems very useful. If one > denies, the operation is denied. That way, any LSMs could coexist without > the need for stacking implementation in every one. I agree with this, but that is not the prevailing opinion. If you think of stacking a set of small LSM's which follow the unix philosophy of "do one thing and do it well," then stacking is not just useful, but necessary. But if you think of stacking two generic modules like LIDS and selinux or DTE, then you could easily run into problems. And in any case, you would need to understand the modules, even the small ones, to understand the implications of stacking, which requires understanding the modules themselves. One thing which would be very helpful would be some layman's (for non LSM-authors) documentation about how LSM's work, which can be expected to work together, etc. In any case, there is a stacker LSM which has been loosely maintained over the years. I think the latest version is at http://www.cs.wm.edu/~hallyn/stacker.patch, though it's possible a newer one is sitting somewhere else. I do plan on attempting the following steps to ease stacking: 1. submit a patch to allow multiple LSM's to use the kernel object security pointers, such as inode->i_security. This won't fly before 2.7, and will likely meet a lot of resistance. (Though it might help if there are people speaking up when I'm shot down :) 2. submit a generalized version of the stacker LSM (hopefully without the blob_stacking.c part, since part 1 will achieve this) to be kept in the kernel tree as another LSM. The reason I'm splitting these up is that part 1 is needed even to support the current method of voluntary stacking. SELinux cannot stack the bsdjail module, for instance, even if it wanted to. Part two allows those who really want to stack things which weren't written to work together, to do so, potentially shooting themselves in the foot. But if I write a module which defines just security_bprm_set_security, do I really want to have to define 15 other hooks which a module I stack might want to define? Ugly. Anyway, coding on part 1 should start soon, to be ready to submit when 2.7 opens... -serge
This archive was generated by hypermail 2b30 : Tue Jun 29 2004 - 06:36:50 PDT