On 11/06/2012 02:54 PM, Dave Reisner wrote: > On Tue, Nov 06, 2012 at 01:03:04PM +0100, Milan Broz wrote: >> The whitelist option allows setup of hardened systems, only >> modules on whitelist are allowed to load. >> >> This patch adds "whitelist" option and definition to libkmod >> allowing to work with whitelist (similar to blakclist, except >> whitelist, once defined, is unconditional). >> >> Without defined whitelist, there is no change. >> >> If at least one whitelist command is specified, module loading >> is limited to module matching loaded whitelist. >> >> For more context see bug >> https://bugzilla.redhat.com/show_bug.cgi?id=560084 > > I don't really agree with the "surprise enablement" use case presented. > There aren't really any negatives presented that explain what sort of > problems it avoids. Generally, it seems like a bit of an edge case -- > one where the user might as well just be compiling their own kernel with > a particular subsystem (v4l, 802.11, bluetooth) removed to prevent this > sort of thing. Hi, Yes, I fully agree, in ideal world I will not compile modules into kernel at all if I do not want them. But the problem comes from enterprise RHEL world - you have stock kernel with some set of modules (and you cannot or do not want to compile own, the reason can be lost of support, certification etc). And some customers want to harden system using several ways. Here, at least as I understand it, it means "do not allow loading modules which handle USB/speaker/microphone/... whatever you can imagine. It obviously does not solve problem with modules compiled-in kernel. I know that there are other ways (udev rules, selinux etc) but security is about multiple barriers and despite this is not useful for most of the people, I think it can be useful for others. > On the security concern, isn't this what signed modules, and in > particular, CONFIG_MODULE_SIG_FORCE is meant to provide? This is not about signature (all modules are signed), just about limiting existing module use. > I see downsides to this feature, because it's somewhat of a snake pit. > If you misuse it, you may render your machine unbootable. That's true, but the same applies for other security barriers as well. They need to prepare proper whitelist to use it properly. > Modules can > (and have) changed names. I think the proper way to do this would be to > whitelist by modalias, but that isn't possible with this patch. I can imagine one of the use case is masking some exact crypto modules (like a hw accelerated ones) while keeping other implementation loadable, so alias is not solution here. (Alias would mask all implementations.) >> +static bool module_is_not_whitelisted(struct kmod_module *mod) > > I strongly suggest that this be inverted and the call simply use > !module_is_whitelisted(module) hehe, it was exactly this way and I changed it because this was more clear to me :) np, I'll change it back. >> @@ -1143,7 +1167,7 @@ static int kmod_module_get_probe_list(struct kmod_module *mod, >> * output or in dry-run mode. >> * >> * Insert a module in Linux kernel resolving dependencies, soft dependencies, >> - * install commands and applying blacklist. >> + * install commands and applying blacklist and whitelist. > > Might be nice to generalize this and just say "applying filters" to make > it a bit more future proof. ok. Whatever, if the patch is acceptable, let me know, I'll resend fixed version. Thanks for comments! Milan -- 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
