linux-kernel - Re: [PATCH] kmod: don't load module unless req process has CAP_SYS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 14 May 2017 12:45:37 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Mahesh Bandewar <mahesh@...dewar.net>
Cc:     Ingo Molnar <mingo@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        Kees Cook <keescook@...omium.org>,
        David Miller <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Mahesh Bandewar <maheshb@...gle.com>
Subject: Re: [PATCH] kmod: don't load module unless req process has
 CAP_SYS_MODULE

On Fri, May 12, 2017 at 04:22:59PM -0700, Mahesh Bandewar wrote:
> From: Mahesh Bandewar <maheshb@...gle.com>
> 
> A process inside random user-ns should not load a module, which is
> currently possible. As demonstrated in following scenario -
> 
>   Create namespaces; especially a user-ns and become root inside.
>   $ unshare -rfUp -- unshare -unm -- bash
> 
>   Try to load the bridge module. It should fail and this is expected!
>   #  modprobe bridge
>   WARNING: Error inserting stp (/lib/modules/4.11.0-smp-DEV/kernel/net/802/stp.ko): Operation not permitted
>   FATAL: Error inserting bridge (/lib/modules/4.11.0-smp-DEV/kernel/net/bridge/bridge.ko): Operation not permitted
> 
>   Verify bridge module is not loaded.
>   # lsmod | grep bridge
>   #
> 
>   Now try to create a bridge inside this newly created net-ns which would
>   mean bridge module need to be loaded.
>   # ip link add br0 type bridge
>   # echo $?
>   0
>   # lsmod | grep bridge
>   bridge                110592  0
>   stp                    16384  1 bridge
>   llc                    16384  2 bridge,stp
>   #
> 
>   After this patch -
>   # ip link add br0 type bridge
>   RTNETLINK answers: Operation not supported
>   # echo $?
>   2
>   # lsmod | grep bridge
>   #

Well, it only loads this because the kernel asked for it to be loaded,
right?

> 
> Signed-off-by: Mahesh Bandewar <maheshb@...gle.com>
> ---
>  kernel/kmod.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/kernel/kmod.c b/kernel/kmod.c
> index 563f97e2be36..ac30157169b7 100644
> --- a/kernel/kmod.c
> +++ b/kernel/kmod.c
> @@ -133,6 +133,9 @@ int __request_module(bool wait, const char *fmt, ...)
>  #define MAX_KMOD_CONCURRENT 50	/* Completely arbitrary value - KAO */
>  	static int kmod_loop_msg;
>  
> +	if (!capable(CAP_SYS_MODULE))
> +		return -EPERM;

At first glance this looks right, but I'm worried what this will break
that currently relies on this.  There might be lots of systems that are
used to this being the method that the needed module is requested.  What
about when userspace asks for a random char device and that module is
then loaded?  Does this patch break that functionality?

thanks,

greg k-h