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

gregat_private

On Tue, Apr 17, 2001 at 01:28:22AM +0200, Flavien Lebarbe wrote:
> Some questions/thoughts :
> 
> *) What about hook arguments ? Does the kernel give the
> module relevant information about which process and what 
> the process wants to do ? Is this info always available ?

Part of defining all of this, is figuring out what everyone needs for
each hook.  Chris's initial post has most of the functions taking
(void).  This needs to change based on feedback from everyone.  So far I
haven't seen any discussion about this, so I guess everyone likes the
current proposal? :)

> *) Why would we need some inheritance if a function
> is not defined ? If a module wants the same function to be
> called far a whole subset, it just has to register that same
> function for each of the sub-functions, and that's it 
> (arguments really are an issue).
> Adding inheritance looks difficult to me (arguments problem,
> how many levels of inheritance, how to define the hierarchy...)

One requirement is that you _have_ to define every hook in your
interface, otherwise the kernel does a call to NULL and it dies.  If you
don't need every function just do a instant return.  This is much faster
than forcing the kernel to check to see if the function pointer is NULL
for every call.

> *) Interfaces with the security modules :
> LSM can decide how they want to interact with the
> system themselves Just to list a few methods that I 
> have in mind :
>   *) No interaction, config is compiled into the module
>      before loading it.
>   *) Module reads /proc/whateveritwants at init time
>      and registers itself only after reading its
>      config. Nothing can be changed afterwards.
>   *) Module implements a new ioctl/device/syscall
> 
> Anyhow : that's not our business, but the module 
> writers business.

Agreed.

> *) About loading several modules : What about
> this : We have a list of loaded modules (told to not
> register by insmod argument), and a super-module can 
> load itself, register itself in the hooktable, 
> and ask other modules for checking, adding its own 
> logic (like "all modules must accept", or, "one is 
> enough", or "ask only module A for network stuff",
> whatever.).

First cut I don't want to mess with this.  I think that the capabilities
module will export all of its functions, so if other modules want to
hook into them, they can.  Otherwise things get very messy, very
quickly.

> *) What about unloading a LSM ? Argh... Kinda
> hard : kernel is SMP, so we can imagine one processor
> is inside a hook call, and another one wants to change
> the LSM_hook_table and release the memory that contains
> the currently-executed hook... Looks to me that we need 
> a semaphore that is incremented each time we enter a 
> hook function and decremented each time we return... 
> That's a pain !

Not hard, consider the following code:
	lock_kernel();
	security_ops = &dummy_security_ops;
	unlock_kernel();

where dummy_security_ops is a table that the kernel has of functions
containing:
	{ return 0; }
for every security call (i.e. no security model at all.)

I have a sample implementation of Chris's header here, but have held off
posting it to get feedback from other people.  If there isn't any other
discussion, I'll post it in a few days (after I look at the LTT more to
"borrow" all of the good ideas in there :)

thanks,

greg k-h

-- 
greg@(kroah|wirex).com
http://immunix.org/~greg

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