* tvrtko.ursulin@private (tvrtko.ursulin@private) wrote: > Hi to all, > > I will try to summarise in this post but first... > > >No, hooks are not allowed to sleep :) Some might be, but you'd have to > >determine exactly which, and I decided it wasn't worth splitting up the > >hooks that way. At least not yet. > > Is that really so? That really limits the functionality one can implement > by using LSM hooks! No, it's not so simple. It 100% depends on the calling context, there's no such hard and fast rule. For a stacker, it's different, but for a normal security module it's only dependent on calling context (and most are safe to sleep in). > So far I was not bitten by it and my hook sleep a *lot*. Even the > sleep-while-spinlocked kernel debug code is silent. It would be great if > some major LSM authority could comment on this. Guys, I don't mean to > disrespect you (too much mafia films ;) as a non-authorities, it is just > that I don't know who is the LSM designer and/or main maintainer. (but > this is the right list!) Yes, this is the right list. I'm the maintainer for the LSM code in the 2.6 kernel (as listed in the MAINTAINERS file), but discussions are best done (like this) on the list. > That would really be a show-stopper "feature". So is there a point of me > continuing? I am not sure but will nevertheless. > > 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. That's not the case. If the critical OS part is modular, and it can be put into a state where it's not being used, then it's possible to unload the module, and insert an update (assuming it's been compiled against the correct base, etc). So, we'll do nothing special to support live updates other than what module's bring already. Also, consider there could be ugly/negative security side-effects of unloading and reloading a security module while the system is running (depends on how the module is coded). SELinux, for example, chose the simpler approach of not allowing it to be built modular. > My first approach with rw semaphors showed to be deadlock prone on module > unload. > > My second approach with RCU was invalidated by the fact that there is no > sleeping allowed between rcu_read_lock() and rcu_read_unlock(). > > Therefore it seems I will have to take David ideas for lockless operation > and disabling the module prior to unload. I guess I will try to return > -EBUSY from mod_unreg_security() until module is dereferenced by > everybody. To be completely transparent, module_exit of the module in > question should disable itself and return -EBUSY on the first invocation. > It should also return the same on all the subsequent invocations until the > module is dereferenced. Do you think that could work? > > 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... thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
This archive was generated by hypermail 2.1.3 : Tue Jan 04 2005 - 17:25:58 PST