Thread (49 messages) flat view 49 messages, 11 authors, 2017-11-30

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 -0800
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help