linux-kernel - Re: [PATCH v5 next 1/5] modules:capabilities: add request_module

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]

Message-ID: <CA+55aFyobrT7SkFC+PVX0USvRicVt_UPH_nkc-G9Bi8yrCCgPw@mail.gmail.com>
Date:   Wed, 29 Nov 2017 14:45:35 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     David Miller <davem@...emloft.net>
Cc:     "Theodore Ts'o" <tytso@....edu>,
        One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
        Kees Cook <keescook@...omium.org>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Djalal Harouni <tixxdz@...il.com>,
        Andrew Lutomirski <luto@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        James Morris <james.l.morris@...cle.com>,
        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>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        LSM List <linux-security-module@...r.kernel.org>,
        "kernel-hardening@...ts.openwall.com" 
        <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 1/5] modules:capabilities: add request_module_cap()

On Wed, Nov 29, 2017 at 7:58 AM, David Miller <davem@...emloft.net> wrote:
>
> We're talking about making sure that loading "ppp.ko" really gets
> ppp.ko rather than some_other_module.ko renamed to ppp.ko via some
> other mechanism.
>
> Both modules have legitimate signatures so the kernel will happily
> load both.

Yes. We could make the module name be part of the signing process, but
one problem with that is that at module loading time we don't actually
have the filename any more.

User space opens the file and then just feeds the data to the kernel.
So if you fooled modprobe into feeding the wrong module, that's it.

And yes, we can obviously embed the module name into the ELF headers
(that is all part of the signed payload), but the module name doesn't
actually necessarily match what we originally asked for.

Why? Module aliases and module dependencies - which is why we have
that user mode side at all. When we do "request_module(XYZ)" we don't
necessarily know what the dependencies are, so we expect modprobe to
just load the right modules.

So if modprobe then loads some other module (dccp or whatever), the
kernel has no real way to know "oh, that wasn't part of the dependency
chain for the module we aked for".

Now, if modprobe is taught to check that the filename of the module
that it opens actually matches the metadata in the ELF sections, that
would solve it, but it's out of the kernels hands..

             Linus