[kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions
From: Kees Cook <hidden>
Date: 2017-05-23 18:36:42
Also in:
linux-api, lkml, netdev
From: Kees Cook <hidden>
Date: 2017-05-23 18:36:42
Also in:
linux-api, lkml, netdev
On Tue, May 23, 2017 at 12:48 AM, Solar Designer [off-list ref] wrote:
For modules_autoload_mode=2, we already seem to have the equivalent of modprobe=/bin/true (or does it differ subtly, maybe in return values?), which I already use at startup on a GPU box like this (preloading modules so that the OpenCL backends wouldn't need the autoloading): nvidia-smi nvidia-modprobe -u -c=0 #modprobe nvidia_uvm #modprobe fglrx sysctl -w kernel.modprobe=/bin/true sysctl -w kernel.hotplug=/bin/true but it's good to also have this supported more explicitly and more consistently through modules_autoload_mode=2 while we're at it. So I support having this mode as well. I just question the need to have it non-resettable.
I agree it's useful to have the explicit =2 state just to avoid confusion when more systems start implementing CONFIG_STATIC_USERMODEHELPER and kernel.modprobe becomes read-only (though the userspace implementation may allow for some way to disable it, etc). I just like avoiding the upcall to modprobe at all. -Kees -- Kees Cook Pixel Security -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html