From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752993AbdK0XEi (ORCPT <rfc822;w@1wt.eu>);
        Mon, 27 Nov 2017 18:04:38 -0500
Received: from mail-vk0-f66.google.com ([209.85.213.66]:46351 "EHLO
        mail-vk0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751680AbdK0XEe (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 27 Nov 2017 18:04:34 -0500
X-Google-Smtp-Source: AGs4zMac+Nyae2MdU/h+vrKACs7pNIovwlrNxVNK4Fil428/3wMgBom04OD3buwTlJl7LzEv5Lidr1HZCG6DSROQ/FY=
MIME-Version: 1.0
In-Reply-To: <alpine.LFD.2.20.1711280924350.11830@localhost>
References: <1511803118-2552-1-git-send-email-tixxdz@gmail.com>
 <CA+55aFwFEzEU9ci=mFZprjzrhG0P0XgXgqhBSWSv7vFWEAw6rQ@mail.gmail.com>
 <20171128.041426.801732093971324601.davem@davemloft.net> <alpine.LFD.2.20.1711280924350.11830@localhost>
From: Kees Cook <keescook@chromium.org>
Date: Mon, 27 Nov 2017 15:04:32 -0800
X-Google-Sender-Auth: wSmvCnN5NuC8C2iVNJWPLJ5A1z4
Message-ID: <CAGXu5j+YPMZk=TuioD216F5kiqfWTNZcNzpjwOiZRnAfbimhpg@mail.gmail.com>
Subject: Re: [PATCH v5 next 0/5] Improve Module autoloading infrastructure
To: James Morris <james.l.morris@oracle.com>,
        Linus Torvalds <torvalds@linux-foundation.org>
Cc: David Miller <davem@davemloft.net>, Djalal Harouni <tixxdz@gmail.com>,
        Andy Lutomirski <luto@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Luis R. Rodriguez" <mcgrof@kernel.org>,
        Ben Hutchings <ben.hutchings@codethink.co.uk>,
        Solar Designer <solar@openwall.com>,
        "Serge E. Hallyn" <serge@hallyn.com>, Jessica Yu <jeyu@kernel.org>,
        Rusty Russell <rusty@rustcorp.com.au>,
        LKML <linux-kernel@vger.kernel.org>,
        linux-security-module <linux-security-module@vger.kernel.org>,
        kernel-hardening@lists.openwall.com, Jonathan Corbet <corbet@lwn.net>,
        Ingo Molnar <mingo@kernel.org>,
        Network Development <netdev@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Nov 27, 2017 at 2:31 PM, James Morris <james.l.morris@oracle.com> wrote:
> On Tue, 28 Nov 2017, David Miller wrote:
>
>> From: Linus Torvalds <torvalds@linux-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