[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <555A88FB.7000809@kernel.org>
Date: Mon, 18 May 2015 17:51:07 -0700
From: Andy Lutomirski <luto@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
David Howells <dhowells@...hat.com>
CC: Michal Marek <mmarek@...e.cz>,
David Woodhouse <dwmw2@...radead.org>,
Abelardo Ricart III <aricart@...nix.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Sedat Dilek <sedat.dilek@...il.com>, keyrings@...ux-nfs.org,
Rusty Russell <rusty@...tcorp.com.au>,
LSM List <linux-security-module@...r.kernel.org>,
Borislav Petkov <bp@...en8.de>, Jiri Kosina <jkosina@...e.cz>
Subject: Re: Should we automatically generate a module signing key at all?
On 05/18/2015 09:20 AM, Linus Torvalds wrote:
> On Mon, May 18, 2015 at 9:04 AM, David Howells <dhowells@...hat.com> wrote:
>>
>> Should we instead provide a script:
>>
>> ./scripts/generate-key
>>
>> That generates a key if run and make it so that the build fails if you turn on
>> module signing and there's no key.
>
> That would just be stupid.
>
> I'm not ever applying a patch like that. That would absolutely destroy
> the sane "git clean + rebuild" model.
>
> Why the hell would you want to make the sane case that people actually
> *use* be harder to use.
>
> Nobody sane bothers with long-term keys. They are inconvenient and less secure.
>
> Put the onus on making it inconvenient on those people who actually
> have special keys, not on normal people.
>
I think we should get rid of the idea of automatically generated signing
keys entirely. Instead I think we should generate, at build time, a
list of all the module hashes and link that into vmlinux.
If we want to make it better, we could instead have a concept of
dynamically loadable module verifiers. A module is acceptable if any of
the verifiers approve. We autogenerate module_hashes.ko, which
registers a verifier that accepts the modules that were built by the
kernel build in question. The main vmlinux image includes another
verifier that accepts *only* module_hashes.ko as built by the build in
question.
Then, if anyone actually wants to use a public key to verify modules,
they can build the public key into a module as opposed to dragging all
of the public key crud into the main kernel image.
Also, this scheme is compatible with deterministic builds, whereas the
current scheme is fundamentally broken if you try to deterministically
build a kernel without trusting some key issuer.
--Andy
--
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/
Powered by blists - more mailing lists