tvrtko.ursulin@private wrote: >No, you were perfectly clear. Maybe I was unclear? :) > >I know about general module unload race condition and that is not what is >worrying me. We have a privilege that LSM modules must call >mod_unreg_security and that is the place we can take care of any possible >race conditions. > >As I wrote in post, the problem is that in order to update a module I need >to unload it. I can't unload it if somebody else has stacked onto me! > This is just a single instance of the general problem of security policy composition. One of the things an LSM can do is block module loading and unloading, for very good reason. If someone has stacked on to you, they may well have completely blocked any ability to load or unload. The general case is that security policies can conflict, making effective stacking impossible. Thus it is a *deliberate* design in LSM that stacking is not a first-class property of the API, and if you want to do stacking, you have to do it yourself. I like the development of the stacker module. It makes stacking modules much easier than stacking by hand.. But it does not surprise me that the stacker module suffers the same limitations as stacking by hand, i.e. many intuitively desirable operations (such as unloading a module in the middle of a stack) are just infeasible. Furthermore, I submit that because the stacker module is trying to automate some core work that stacking by hand does by, er :) hand (such as composition of security policy using a default-AND logic) that using the stacker module will be even *more* restrictive than stacking by hand. Crispin -- Crispin Cowan, Ph.D. http://immunix.com/~crispin/ CTO, Immunix http://immunix.com
This archive was generated by hypermail 2.1.3 : Wed Jan 05 2005 - 09:16:26 PST