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

chrisat_private

* Flavien Lebarbe (flavienat_private) wrote:
> 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 ?

This is a tricky part.  Yes, the kernel passes the arguments to the
module through the interface.  Depending on how the interface is
designed, some arguements may be NULL some of the times.  LTT has some
nice abstraction with a single function like TRACE_SOCKET() or
TRACE_FILE_SYSTEM().  These functions take an event identifier (so you
know if you are dealing with an open or a close, etc) and some opaque data,
which is populated (or not) depending on where it is being called in the
kernel.  The approach you proposed above makes a less abstract interface with
unique arguments possbile for each (file_system->open(), file_system->close(),
etc).  (BTW, this is same essence as the approach I proposed earlier ;-) 
Regardless of the approach...if information is necessary in the module and
the interface supports passing it, but it isn't available in the kernel,
then that is a possible argument for the hook being in the wrong spot
(too soon, or too late in a code path).

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

I agree that it is easy to register the same function for multiple parts
of the interface to achieve inheritance in the interface.  Arguments
aren't much of an issue.  Just make sure your function is prepared to
deal with all the arguments it may get ;-)  And if you want you can
register functions with matching prototypes that just shed their arguments
and internally call your module wide policy.

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

If the register_your_modules_security_functions() is implemented in a way
that it preserves the dummy functions for cases where you've passed in a
NULL function pointer, than it is possible to overlay security modules
that target different areas.  I think we should stick with one module at
a time for starters.

-chris

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