linux-kernel - Re: Should we automatically generate a module signing key at all?

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:	Tue, 19 May 2015 19:44:45 +0100
From:	David Howells <dhowells@...hat.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	dhowells@...hat.com, David Woodhouse <dwmw2@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andy Lutomirski <luto@...nel.org>,
	Michal Marek <mmarek@...e.cz>,
	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?

Andy Lutomirski <luto@...capital.net> wrote:

> The actual runtime code needed to implement a hash tree solution is
> maybe twenty lines.  The bzImage will be smaller,

But the initramfs image will be bigger because it will have to carry the
entire module hash list just in case any particular module needs to get loaded
from the initramfs.  You have to carry the entire hash set so that you can
hash it and compare against the one hash in the vmlinux file.

And that doesn't include the issue of hashing the firmware blobs you might
need.

> With your proposal, I need to trust that whoever built the actual
> running kernel image really did throw away the key.  If they didn't,
> then under whatever threat model requires that I enable module
> verification, I'm screwed -- the bad guy has the private key.

Each private key is used for one single kernel, so if they steal one, you can
blacklist it if you have the capability (eg. UEFI) and change your kernel.

David
--
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/