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]

Message-ID: <CA+55aFxYa9rd8mrJjkbUvKvLifn8uos40uNjj8L1ug873i5_aQ@mail.gmail.com>
Date:	Fri, 22 May 2015 13:40:40 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	George Spelvin <linux@...izon.com>
Cc:	David Howells <dhowells@...hat.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	LSM List <linux-security-module@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>, petkan@...-labs.com,
	"Theodore Ts'o" <tytso@....edu>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>
Subject: Re: Should we automatically generate a module signing key at all?

On Fri, May 22, 2015 at 7:13 AM, George Spelvin <linux@...izon.com> wrote:
>
> 1) Create a tool to canonicalize the kernel and modules,
>    stripping out the signatures before comparing them.  This has
>    precedent in the way the prelink tool can un-prelink binaries
>    so that hashes can be verified.

So I'd obviously prefer this, so that we have just one model for verification.

I forget the exact details of the signature (and am way too lazy to
look it up), but for the modules themselves, it's just appended to the
module contents. So getting rid of the signature is literally just
truncating the module to the original size.

For the kernel image, it's a bit nastier, since the public key is just
inserted into the object file as variables (system_certificate_list:
"__cert_list_start...__cert_list_end:" and the length in "unsigned
long system_certificate_list_size"). And because the size of the
certificate list is variable, you can't just zero it out or anything
like that to make things compare equal.

Of course, even just zeroing that out will probably work as long as
you use the *same* setup (ie kernels with just the one randomly
generated key will probably have the same certificate size - I say
"probably" because I didn't check how the encoding might affect it)

But we might also simply decide to pack the keys differently. I'd
personally be ok with it being in the initrd, for example, although
for all I know that might screw up the people who actually want to use
the BIOS secure booting thing (I don't know how much that verifies).

             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/