Hi, On Sun, Apr 15, 2001 at 09:57:24PM -0400, Karim Yaghmour wrote: > > Keep in mind that, in most cases, the impact is lower than 0.25%. Someone else already suggested using some sort of bitmap to decide which hooks are actually plugged in by any security module. Maybe with this there will be even much less overhead (especially if implementing the bitmap lookup as a preprocessor macro). I will do some testings with the bitmap approach when I have put up a test machine (I'm getting my hands on some hardware for this, but it will take some time :-( ). We should also think a little bit about hook organization. As pointed out, we will probably have to deal with several hundred hooks to manage. I think a hierarchical hook layout will be somewhat helpful (for example we have the hooks /filesystem/open, /filesystem/delete, /socket/create and so on). This can also be used for some sort of hook inheritance (if hook /filesystem/delete is not used, use /filesystem hook, so that for example a security policy that wants to completely disable filesystem access only has to plug into /filesystem and leave the hooks below /filesystem unused). Andreas -- How much net work could a network work, if a network could net work? _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Sun Apr 15 2001 - 19:31:51 PDT