Date: Wed, 29 Nov 2017 16:06:48 -0800 From: Kees Cook <keescook@...omium.org> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: David Miller <davem@...emloft.net>, "Theodore Ts'o" <tytso@....edu>, One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>, "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 2:45 PM, Linus Torvalds <torvalds@...ux-foundation.org> wrote: > 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. FWIW, I added this (well, KBUILD_MODNAME) to the module info just recently: 3e2e857f9c3a ("module: Add module name to modinfo") > 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.. Right, the aliases are why these kinds of renaming shenanigans don't mean anything: it's not distinguishable from whatever modprobe.conf ultimately tells modprobe to do. If you can't trust your filesystem to hold your kernel modules correctly, you have much bigger problems. (And yes, capabilities are a problem here, since there are many paths to full root from individual capabilities, but that's a known issue that is much larger than tricking modprobe.) -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.