> period detection will not work correctly then. Yes, you are safe by the > fact that you check for atomic_dec_and_test at the exit point of each hook > and call stacker_free_module if so. Exactly. It's actually taken step by step from one of the recent RCU papers. > I don't like every hook being responsible for unload of the module. My Not for the unload, just for freeing the memory. Last user frees the memory... > approach isn't so much better, since hooks instead of free-ing do a > wake_up on exit. But it feels a small bit more logical that way (and > cleaner, again, not from the quantity of code perspective). It doesn't matter which process frees the data, though, so waking up another process to do what the current process could do seems heavyweight. Just as interrupts can run under any process' context. > You don't have any comments on stacker behaviour with no stacked modules > and security_fixup_ops implementation? Was I correct to implement it the > way I described in the previous email? The original stacker also used capabilities when no modules were stacked. I personally feel that the stacker should simply be a stacker, without any side effects of enforcing some other policy. But one of the things I may need to do is split the capabilities module into two - one to just track capabilities (which selinux would stack with) and one to do enforcement on things like ptrace and netlink_send. Maybe it would make sense to have stacker automatically load the capability_track module then. I don't plan to though, because I'd really like stacker to not assume anything about policy. As for using security_fixup_ops, that could give you a noticable performance impact if you stack 5 modules of the sort that David was talking about, which would define just one or two hooks. Now for every LSM hook, you have a dummy hook being called 5 times. On the other hand, the opposite of that argument was used to not allow if (security->function) function(args) in the first place - that a conditional might end up wasting more time than executing a simple function. I may have to add this to the list of things to try in performance trials. Again, these are all just my opinions, so I hope you'll keep working on your own and publish your code. -serge
This archive was generated by hypermail 2.1.3 : Fri Dec 24 2004 - 08:08:14 PST