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? Lucas De Marchi -- 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
