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

gregat_private

On Mon, Apr 16, 2001 at 09:00:05PM -0700, Seth Arnold wrote:
> * Andrew Morgan <morganat_private> [010416 20:32]:
> > How will you handle backward compatibility?
> 
> Could this system be made more generic?
> 
> init_module()
> {
>   int nrfuncs, i;
> 	
>   nrfuncs = get_kernel_security_hook_count();
>   for (i=0; i < nrfuncs; i++) {
>     switch (i) {
>       case CHECK_FS_OPEN: mymodule_checks[CHECK_FS_OPEN] = &mymodule_fs_open;
>       case CHECK_FS_READ: mymodule_checks[CHECK_FS_READ] = &mymodule_fs_read;
>       /* ... */
>       default: mymodule_checks[i] = &mymodule_instant_return_EACCES;
>     }
>   }
> 
>   kernel_set_check_policy (&mymodule_checks);
> }

In order to do that, mymodule_checks[] would have to consist of a bunch
of void (*foo)(void) calls, and we would have to cast the heck out of
them.  Not good, and not allowed, sorry.

> However, I think the *correct* approach is just as you suggested --
> refuse to load. Rationale: if a new hook was added, it could very well
> grant more access than the module would want to allow. Default deny on
> such instances wouldn't be ideal -- it may be required for proper
> operation of the machine. Default allow on such instances wouldn't be
> ideal -- it may allow a new form of file descriptors to be passed around
> or something similar to bypass the other checks.
> 
> By providing more functionality than the carefully designed modules have
> taken into account, the interactions should probably *not* be figured
> out by the kernel at load time. Perhaps this could be left up to the
> individual modules again:
> 
> init_module()
> {
>   if (OUR_FUNCTION_COUNT != get_kernel_security_hook_count())
>     return 1;
>   /* continue loading as below */
> }

The count of functions is no guarantee that the functions are of the
correct type, or in the correct order.

> Or would people perfer a static system of determining that module X
> won't load into kernel Y?

You can do it by having the code in the 
security_set_ops(struct security_ops *) function, by it checking the
version number, but that really isn't necessary.  Loading of modules
across kernel versions isn't supported or encouraged.  Just recompile
the thing.

Remember Linux does not have a binary driver/module interface :)

> [These are all just thoughts; don't hesitate to tear these suggestions
> apart if there is no redeeming value in them. :]

Ok, just doing my part :)

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