[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171129162945.u2zjcoe4gsanhmkc@thunk.org>
Date: Wed, 29 Nov 2017 11:29:45 -0500
From: Theodore Ts'o <tytso@....edu>
To: David Miller <davem@...emloft.net>
Cc: gnomes@...rguk.ukuu.org.uk, keescook@...omium.org,
mcgrof@...nel.org, tixxdz@...il.com, luto@...nel.org,
akpm@...ux-foundation.org, james.l.morris@...cle.com,
ben.hutchings@...ethink.co.uk, solar@...nwall.com,
serge@...lyn.com, jeyu@...nel.org, rusty@...tcorp.com.au,
linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
kernel-hardening@...ts.openwall.com, corbet@....net,
mingo@...nel.org, netdev@...r.kernel.org, peterz@...radead.org,
torvalds@...ux-foundation.org
Subject: Re: [PATCH v5 next 1/5] modules:capabilities: add
request_module_cap()
On Wed, Nov 29, 2017 at 10:58:16AM -0500, David Miller wrote:
> That's not what we're talking about.
>
> 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.
Right, and the best solution to this problem is to include in the
signature the name of the module. (One way of doing this is adding
the module name into the cryptographic checksum which is then
digitally signed by the kernel module key; we would have to bump the
version number of the signature format, obviously.) This binds the
name of the module into the digital signature so that it can't be
renamed.
- Ted
Powered by blists - more mailing lists