On Tue, Nov 6, 2012 at 3:44 PM, Josh Boyer <jwboyer@xxxxxxxxx> wrote: > 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. I was answering his comment about what I understood be an argument saying this was about a vendor-lock-in mechanism. I replied saying that even if this was the case, it would still fail, because the whitelist does not prevent the user . > > From what I understand, the patch has nothing to do with vendor-lock-in. I hope so, but his comment triggered my reaction ;-) > 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. then how is this any better than a whitelist in which modules get installed? 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
