On Fri, Mar 22, 2013 at 3:01 PM, Lucas De Marchi <lucas.demarchi@xxxxxxxxxxxxxx> wrote: > On Fri, Mar 22, 2013 at 3:46 PM, Daniel Dadap <ddadap@xxxxxxxxxx> wrote: >> On 03/22/2013 11:49 AM, Lucas De Marchi wrote: >>> >>> On Fri, Mar 22, 2013 at 1:18 PM, Tom Gundersen<teg@xxxxxxx> wrote: >>>> >>>> On Fri, Mar 22, 2013 at 3:33 PM, Lucas De Marchi >>>> <lucas.demarchi@xxxxxxxxxxxxxx> wrote: >>>>> >>>>> I'm no huge fan of this feature. Indeed I think it's a pretty broken >>>>> feature (just not as broken as the install rules we need to carry for >>>>> compatibility reasons). I also think that for people that needs this a >>>>> custom kernel with things compiled-in would be way better. >>>> >>>> Just to add my two cents to the 'this is a bad idea'-choir: This >>>> feature seems to be at the wrong level of the stack. There is nothing >>>> forcing you to use libkmod to load modules, so there would be no >>>> guarantee that only the modules on the white-list can be loaded (i.e., >>>> adding this feature would not have the same guarantee as rebuilding >>>> the kernel with only the whitelisted modules enabled, contrary to what >>>> I guess one would expect?). >>>> >>>> Could you do something similar to what was done with finit_module() >>>> and the kernel_module_from_file hook? With the right security module >>>> it seems like you should be able to catch all modules and verify that >>>> they conform to whatever criterion you have. >>>> >>>> Of course, if Lucas wants to maintain this feature that is his call :-) >>> >>> >>> So, after actually reviewing the code and not only the idea behind I >>> came to conclusion this is actually worse than I expected. >>> >>> But I don't think having this in kernel and maintaining a list of >>> whitelisted module is good - otherwise it would be easier to just have >>> modules compiled statically. And if the kernel is going to call >>> userspace to allow/deny module loading, how this is supposed to be? >>> Another helper? >>> >>> Josh/Milan, could you come up with an alternative solution to what you >>> are trying to accomplish? It seems to be a very limited use-case >>> (hardened systems) that may hurt others that don't want this, >>> rendering their machines unbootable. >> >> >> If the goal is to harden a system by allowing only certain modules to load, >> then how about using CONFIG_MODULE_SIG_FORCE, and only signing modules on >> the whitelist, and keeping kmod out of it completely? That seems like >> exactly the kind of use case that CONFIG_MODULE_SIG_FORCE would be good for. > > Sure it's a better solution and I think the real solution is in this > direction. Dave even proposed this back last year. However Josh and > Milan raised the question that in a distro kernel, it's the distro > that's going to sign the modules. And all modules will had already be > signed upon package installation. > > Removing the modules from /lib/modules will make the package manager yells. > > But... the admin could just remove the signature from modules he > doesn't want (we can provide the tooling). And then apply the > CONFIG_MODULE_SIG_FORCE as you and Dave propose. Josh/Milan, what do > you think? Great minds think alike. I just replied with the same thing. It does seem feasible, but it depends on signed modules whereas the current whitelist proposal works regardless of kernel options. It is something to think about anyway. josh -- To unsubscribe from this list: send the line "unsubscribe linux-modules" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
