Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932098AbbESSMl (ORCPT ); Tue, 19 May 2015 14:12:41 -0400 Received: from mail-la0-f42.google.com ([209.85.215.42]:35135 "EHLO mail-la0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751947AbbESSMj convert rfc822-to-8bit (ORCPT ); Tue, 19 May 2015 14:12:39 -0400 MIME-Version: 1.0 In-Reply-To: <1432058889.3277.73.camel@infradead.org> References: <31154.1431965087@warthog.procyon.org.uk> <555A88FB.7000809@kernel.org> <1432058889.3277.73.camel@infradead.org> From: Andy Lutomirski Date: Tue, 19 May 2015 11:12:17 -0700 Message-ID: Subject: Re: Should we automatically generate a module signing key at all? To: David Woodhouse Cc: Linus Torvalds , Andy Lutomirski , David Howells , Michal Marek , Abelardo Ricart III , Linux Kernel Mailing List , Sedat Dilek , keyrings@linux-nfs.org, Rusty Russell , LSM List , Borislav Petkov , Jiri Kosina Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1949 Lines: 42 On Tue, May 19, 2015 at 11:08 AM, David Woodhouse 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/