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

flavienat_private

Hello,

I think we all agree that we need hooks to be called at some
critical points in the kernel. How many of them is not really 
clear now, but it does not really matter at this point.

At the end, we might end up with a big structure with function
pointers in it, and an exported kernel call to set it, so that
a module can do :
---
init_module()
{
  struct check_struct mymodule_checks = {
	check_fs_open: 		& mymodule_fs_read,
	check_fs_read: 		& mymodule_fs_open,
	check_fs_write:		& mymodule_fs_write,
	check_socket_open:	& mymodule_socket,
	check_socket_read:	& mymodule_socket,
	check_socket_write:	& check_socket_write_refuse,
	...
	check_kernel_checkpolicy_set: & mymodule_kernel_checkpolicy_set,
	/* How we accept other security modules...*/
  };

  kernel_set_check_policy (&mymodule_checks);
}
---

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 ?

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

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

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

*) 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 !

Flavien Lebarbé

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