On Tue, Nov 6, 2012 at 12:24 PM, Lucas De Marchi <lucas.demarchi@xxxxxxxxxxxxxx> wrote: > Hi Milan, > > On Tue, Nov 6, 2012 at 1:20 PM, Milan Broz <mbroz@xxxxxxxxxx> wrote: >> 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). > > Besides the ugly fact of trying to vendor-lock-in the user, what is a > whitelist in kmod really helping? User could just remove the whitelist > from the config. > > Really, if this patch is all about vendor-lock-in (regardless if it's > an open source friendly company), you already got my nack. I won't comment on the mechanism itself, but I don't see how this is implementing vendor-lock-in at all. It's a generic mechanism to whitelist which modules can be loaded on a system regardless of which kernel vendor those modules come from. >From what I understand, the patch has nothing to do with vendor-lock-in. It seems to be about giving admins more control over which modules can be loaded, particularly in the presence of hotplug mechanisms that can auto-load drivers for various devices when they're plugged in. (For full disclosure, I'm posting from a gmail address but I am a Red Hat employee. I do not speak for Red Hat and my views are my own.) 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
