|| ||Linus Torvalds <torvalds-AT-linux-foundation.org> |
|| ||Josh Boyer <jwboyer-AT-redhat.com> |
|| ||Re: RFC: sign the modules at install time |
|| ||Thu, 18 Oct 2012 09:29:16 -0700|
|| ||Rusty Russell <rusty-AT-rustcorp.com.au>,
David Howells <dhowells-AT-redhat.com>,
David Miller <davem-AT-davemloft.net>,
Linux Kernel Mailing List <linux-kernel-AT-vger.kernel.org>,
|| ||Article, Thread
On Thu, Oct 18, 2012 at 5:11 AM, Josh Boyer <email@example.com> wrote:
> It also excludes out-of-tree drivers. I wouldn't personally shed a tear
> for them, but it eliminates a use-case that people could have if we just
> stuck to the signed module approach.
> I'd prefer if we just cleaned up what we already have.
Exactly. I think the advantage of module signing is that it allows for
many different use-cases. People who care deeply about security can do
the "sign modules at kernel compile time with a one-time random key
that gets removed", and simply always reject anything else. And maybe
corporate users want something similar for corporate laptops.
And then vendors can do the "sign stuff with vendor key, and print big
warning and/or taint the kernel if loading unsigned modules" so that
people can at least validate the "standard" modules or something.
So signing is the nice flexible option, and technically the right
thing to do. I just want to make sure that what we make the *easy*
thing to do with that flexible option is the nice sane
GoodSecurity(tm) thing. If somebody wants to do something else with
it, fine, but it's not what the primary objective of the makefile
rules should be about.
I like how the default makefiles do that "create and use random key"
thing by default. THAT is what I want to see.
(Side note: I hope people realize that the random key is generated
with a 100-year lifespan. So if you build a kernel today, you do
potentially have a "year-2112 problem". I'm not horribly worried, but
I *am* a bit worried about 32-bit time_t overflow and I hope 32-bit
openssl doesn't do anything odd)
to post comments)