Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5j+YPMZk=TuioD216F5kiqfWTNZcNzpjwOiZRnAfbimhpg@mail.gmail.com>
Date: Mon, 27 Nov 2017 15:04:32 -0800
From: Kees Cook <keescook@...omium.org>
To: James Morris <james.l.morris@...cle.com>, 
	Linus Torvalds <torvalds@...ux-foundation.org>
Cc: David Miller <davem@...emloft.net>, Djalal Harouni <tixxdz@...il.com>, 
	Andy Lutomirski <luto@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, 
	"Luis R. Rodriguez" <mcgrof@...nel.org>, Ben Hutchings <ben.hutchings@...ethink.co.uk>, 
	Solar Designer <solar@...nwall.com>, "Serge E. Hallyn" <serge@...lyn.com>, Jessica Yu <jeyu@...nel.org>, 
	Rusty Russell <rusty@...tcorp.com.au>, LKML <linux-kernel@...r.kernel.org>, 
	linux-security-module <linux-security-module@...r.kernel.org>, kernel-hardening@...ts.openwall.com, 
	Jonathan Corbet <corbet@....net>, Ingo Molnar <mingo@...nel.org>, 
	Network Development <netdev@...r.kernel.org>, Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v5 next 0/5] Improve Module autoloading infrastructure

On Mon, Nov 27, 2017 at 2:31 PM, James Morris <james.l.morris@...cle.com> wrote:
> On Tue, 28 Nov 2017, David Miller wrote:
>
>> From: Linus Torvalds <torvalds@...ux-foundation.org>
>> Date: Mon, 27 Nov 2017 10:41:30 -0800
>>
>> > 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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.