Re: Low-cost hooks, multiple modules, per-task data

karymat_private

David Wheeler wrote:
>   The LTT micro-benchmarks don't look so great to me.  They look like a
>   lot of overhead, frankly, which may make any hooks hard to accept.

Please see my previous posting regarding how these issues can be addressed
(and will certainly be, for LTT at least).

>   The "hook" call (whatever it looks like) could be implemented in a way
>   that does things efficiently, as long as it appears simple
>   to the caller.  It could support an #ifdef to completely disable it
>   (mollifying those who "don't want it at all").

The current LTT hooks can be #ifdef as you suggest.

>   This isn't self-modifying code in the "nasty" sense -- it's merely
>   an optimization.

I agree with your line of thought. Take a look at the other self-modifying
code suggestion I made (using unconditionnal branches) and let me know
what you think.

>   Since self-patching is CPU-architecture-specific, there might a
>   "generic" implementation (to aid those porting Linux to a new CPU type
>   or one less used) and a "highly optimized" implementation for hooks.

Hmm... Interesting.

> * More needs to be done about auditing.
> 
>   But I agree that would be outside of this group.
>   Currently, it's not easy to do things like
>   "don't allow this operation if I can't audit it"  -- printk just
>   doesn't cut it.  It'd be nice to have something better than printk.

Sorry for suggesting this again, but LTT does this already is some part. 
That is, since you can see exactly all the operations taking place,
you can see what's normal and what's not. The state machine engine
I spoke of complements this since you can react to a already happening
sequence of events. Even though, as previous discussions have shown,
the hooks' positionning won't enable you to take part of the kernel's
decisions, you'll still be able to react to the decisions being taken.
(As I said before, Alan suggested that LTT could be used to bring C2
security to Linux ... anyone interested in making this a reality?)

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