On 05/01/2005 15:42:58 "David A. Wheeler" wrote: >> * tvrtko.ursulin@private (tvrtko.ursulin@private) wrote: >>>I agree with David's point of treating writes (add/remove from chain) as >>>extremely rare. But I do not like the "leave module loaded" idea. In the >>>production environment, there must be a mechanism which enables updating >>>critical OS parts without a reboot. LSM per se does not offer that, so the >>>"stacker" module should remedy that. > >I'm sorry, I guess my reply was unclear. Please let me explain >what I meant. 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! I also can't avoid the module unload race by leaving the module loaded since then I can't load the same module again. Therefore it is clear that we need in kernel stacker manager because it is impossible to make a 100% correct solution from a module. In that way any module can unload and be replaced. >There are other problems, of course: if you disable a >module, and reload an update of it, what happens >(1) between those times, and (2) is there state that >needs to transfer from the old to the new version? >If there's no state, there may not be a problem. >You might be able to solve (1) by having the "old" and >"new" versions loaded simultaneously, then disabling the old one >(and later unloading it). You can solve (2) trivially >if there's no state. But I don't see how a stacker >could solve that problem in general if state needs >to tranfer; I believe that has to be the job of the >modules themselves (to handle state transfers). For many of >the modules I was interested in (limiting the creation >of files to certain name patterns, detecting likely >temp file problems, etc.) these weren't problems, >because the module didn't need to store internal state. These are legitimate issues. My luck is that I don't need a persistent state. Everything I need is stored in ?_security fields. Of course (1) is a risk but if we had a stacker we could offer a choice. Whether somebody wants to do an update and take the security risk, or a reboot and have some downtime. Choices are supposed to be good. Of course, you being an original stacker author, I don't need to argue that with you. :) -- Tvrtko August Ursulin Software Engineer, Sophos Tel: 01235 559933 Web: www.sophos.com Sophos - protecting businesses against viruses and spam
This archive was generated by hypermail 2.1.3 : Wed Jan 05 2005 - 08:28:50 PST