* tvrtko.ursulin@private (tvrtko.ursulin@private) wrote: > If we assume that the different modules handle different areas of > security, then we can eliminate the ugly/negative side-effects. It's more than that. What do you do for all the already running system which lost its security state when you unplugged the module? And how do you reinitialize everything when you re-insert it? Not an insurmountable challenge, but the module must cope with this behaviour. > But in it's current form LSM is really not suitable for live updates. It > is if only one module is loaded, but what do you do if you want to update > a module which has another one piggy-backed onto it (one you don't have > control over)? I don't see that you can do it, and that is a real > show-stopper. Yes you could try to unload the one that is stacked onto > you, but that would be just awful. Let's just say, live code updates is not one of the primary goals of LSM. In truth, it's not one of the goals of the kernel either. Now, live updates of _policy_ is well within scope, and some security modules support this already. > Having each module responsible to implement (or not) stacking has it's > advantages, but I really think that we need a proper stacking (or better > said chaining) manager. Of course it should be optional in order not to > penalise performance for everybody. But we really do need it. Yes agreed. The current stacking mechanism is stop-gap at best. > >> But the fact that LSM hooks might not be allowed to sleep is still a > >> showstopper. In it's current state, LSM hooks do not provide sufficient > >> functionality to implement some of the task required for a production > >> environment. > > > >This last statement requires a leap of faith, as I don't see what > >substantiates such a claim. Many sites use LSM in production already... > > It was written under the impression that hooks are really not allowed to > sleep. As that is not the case it is not longer a valid 'complaint'. Ah, I see, thanks for clarification. > However, it would still be nice to have that aspect documented somewhere. > Not knowing which hooks are not allowed to sleep and is that always, or in > a special case, is a little strange from an interface user point of view. > If I had the knowledge I could help write that, but I don't. At one point early on, we had each hook documented with the locks held, etc. This proved to be unmaintainable as things change and it's worse to have incorrect docs than none at all. > So Serge is working on a stacking solution already. Will his work, or > something based on it, be accepted into the mainline in the near future? Many incidental issues are popping up along the way. Those are being dealt with and pushed upstream. As for full stacking, it's likely. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
This archive was generated by hypermail 2.1.3 : Wed Jan 05 2005 - 08:55:37 PST