linux-kernel - Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

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:   Thu, 8 Mar 2018 19:10:54 -0800
From:   Andy Lutomirski <luto@...capital.net>
To:     David Miller <davem@...emloft.net>
Cc:     luto@...nel.org, alexei.starovoitov@...il.com,
        keescook@...omium.org, ast@...nel.org, tixxdz@...il.com,
        viro@...iv.linux.org.uk, daniel@...earbox.net,
        torvalds@...ux-foundation.org, gregkh@...uxfoundation.org,
        mcgrof@...nel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel-team@...com,
        linux-api@...r.kernel.org
Subject: Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

> On Mar 8, 2018, at 6:31 PM, David Miller <davem@...emloft.net> wrote:
> 
> From: Andy Lutomirski <luto@...nel.org>
> Date: Fri, 9 Mar 2018 02:12:24 +0000
> 
>> First, compile your user code and emit a staitc binary.  Use objdump
>> fiddling or a trivial .S file to make that static binary into a
>> variable.  Then write a tiny shim module like this:
>> 
>> extern unsigned char __begin_user_code[], __end_user_code[];
>> 
>> int __init init_shim_module(void)
>> {
>>  return call_umh_blob(__begin_user_code, __end_user_code - __begin_user_code);
>> }
>> 
>> By itself, this is clearly a worse solution than yours, but it has two
>> benefits, one small and two big.  The small benefit is that it is
>> completely invisible to userspace: the .ko file is a bona fide module.
> 
> Anything you try to do which makes these binaries "special" is a huge
> negative.

I don’t know what you mean.  Alexei’s approach introduces a whole new kind of special module.  Mine doesn’t. 

> 
>> The big benefits are:
> 
> I don't see those things as benefits at all, and Alexei's scheme can
> easily be made to work in your benefit #1 case too.
> 

How?  I think you’ll find that a non-modular implementation of a bundled ELF binary looks a *lot* like my call_umh_blob().

> It's a user binary.  It's shipped with the kernel and it's signed.
> 
> If we can't trust that, we can't trust much else.

I’m not making any arguments about security at all. I’m talking about functionality. 

If we apply Alexei’s patch as is, then I think we’ll have a situation where ET_EXEC modules are only useful if they can do their jobs without any filesystem access at all.  This is fine for networking, where netlink sockets are used, but I think it’s not so great for other use cases. If we ever try to stick a usb driver into userspace, we’re going to want to instantiate the user task once per device, passed as stdin or similar, and Alexei’s code will make that very awkward.