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 11:12:17 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andy Lutomirski <luto@...nel.org>,
	David Howells <dhowells@...hat.com>,
	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?

On Tue, May 19, 2015 at 11:08 AM, David Woodhouse <dwmw2@...radead.org> wrote:
> On Tue, 2015-05-19 at 10:58 -0700, Andy Lutomirski wrote:
>>
>> Throwing away the key is outright impossible in some contexts.
>>
>> https://wiki.debian.org/ReproducibleBuilds
>
> Are any of the benefits described at
> https://wiki.debian.org/ReproducibleBuilds/About *not* just as
> achievable with the method I suggested — where you throw away the key
> and just validate that your builds are identical *except* for the
> signatures... which you can reuse, since your builds were identical.

Yes, blatantly.  Quoting that link:

Should reproducible uploads become mandatory, then the incentive of an
attacker to compromise the system of a developer with upload rights is
lowered because it is not anymore possible for the developer to upload
a binary that does not match the uploaded sources.

In the context of a kernel, this means that I shouldn't have to trust
the machine that actually generated the binary.  In principle, I
shouldn't even need to trust the person who generated the package,
since the package should be easily comparable to kernel.org sources.

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.

The actual runtime code needed to implement a hash tree solution is
maybe twenty lines.  The bzImage will be smaller, and the modules will
be smaller (although the latter is only true because the current
scheme is bloated).  The only tricky part is getting the build process
to work.

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