linux-kernel - Re: RFC: sign the modules at install time

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, 18 Oct 2012 09:29:16 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Josh Boyer <jwboyer@...hat.com>
Cc:	Rusty Russell <rusty@...tcorp.com.au>,
	David Howells <dhowells@...hat.com>,
	David Miller <davem@...emloft.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	pjones@...hat.com
Subject: Re: RFC: sign the modules at install time

On Thu, Oct 18, 2012 at 5:11 AM, Josh Boyer <jwboyer@...hat.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)

               Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/