Re: [PATCH v5 next 0/5] Improve Module autoloading infrastructure
From: Kees Cook <hidden>
Date: 2017-11-27 23:04:38
Also in:
linux-security-module, lkml
On Mon, Nov 27, 2017 at 2:31 PM, James Morris [off-list ref] wrote:
On Tue, 28 Nov 2017, David Miller wrote:quoted
From: Linus Torvalds <torvalds@linux-foundation.org> Date: Mon, 27 Nov 2017 10:41:30 -0800quoted
What are the real life use-cases for normal users having modules auto-load?User opens SCTP socket, SCTP protocol module loads. People build test cases via namespaces, and in that namespaces normal users can setup virtual tunnel devices themselves, and those configure operations can bring the tunnel module in.What about implementing a white list of modules which are able to be loaded by unprivileged users? Then, Linus' solution would look something like: va_start(args, fmt); ret = vsnprintf(module_name, MODULE_NAME_LEN, fmt, args); va_end(args); if (WARN_ON_ONCE(!capable(CAP_SYS_MODULE) || !capable(CAP_SYS_ADMIN) || !capable(CAP_NET_ADMIN) || !unprivileged_autoload(module_name))) return -EPERM;
We have some of this already with the module prefixes. Doing this per-module would need to be exported to userspace, I think. It'd be way too fragile sitting in the kernel. To control this via modprobe, we'd need to expand modprobe to include the user that is trying to load the module (so it can reason about who is doing it), and then teach modprobe about that so the policy could be exported to userspace. -Kees -- Kees Cook Pixel Security