Re: Benchmarks (was Re: Hooking into Linux using the LTT)

karymat_private

Andreas Ferber wrote:
> 
> 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 :-( ).

I haven't tried the bitmap approach but have to confess that I find
it quite interesting. Although there are 2 levels to this: compile-time
hook selection and runtime hook reaction. If this for runtime than
the bitmap test would occur after the generlized hooking function
would have been called and in that case you still have to pay the
price of the generalized hooking function being called.

> 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).

This hierarchical layout already exists in the patch provided with LTT,
although fine-grained hooks don't exist yet (i.e. you can hook onto
/filesystem, but can't hook to /filesystem/open, but this is easily
implemented).

Cheers,

Karim

===================================================
                 Karim Yaghmour
               karymat_private
      Embedded and Real-Time Linux Expert
===================================================

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module