Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757677AbbEVVJR (ORCPT ); Fri, 22 May 2015 17:09:17 -0400 Received: from mail-ig0-f182.google.com ([209.85.213.182]:33725 "EHLO mail-ig0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757204AbbEVVJN (ORCPT ); Fri, 22 May 2015 17:09:13 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150522141358.2581.qmail@ns.horizon.com> Date: Fri, 22 May 2015 14:09:12 -0700 X-Google-Sender-Auth: 9PgkVbsmO9wlEUEXPeE2lEaExnw Message-ID: Subject: Re: Should we automatically generate a module signing key at all? From: Linus Torvalds To: Andy Lutomirski Cc: George Spelvin , David Howells , David Woodhouse , Linux Kernel Mailing List , LSM List , petkan@mip-labs.com, "Theodore Ts'o" , Mimi Zohar Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2066 Lines: 43 On Fri, May 22, 2015 at 1:44 PM, Andy Lutomirski wrote: > > In the threat model where module signatures matter in the first place > [1], this prevents reproducible builds from serving their purpose. I > can build a kernel with a fresh signing key and throw away the private > key. You can build a canonically identical kernel with a private key > that you keep. A third party using mine is safe, but a third party > using yours is unsafe, even though the whole packages canonicalize to > exactly the same bytes. So the thing is, I don't see why the third party couldn't just re-sign his kernel with his own key (and throw it away). Now he *is* safe. He can verify that the kernel and module images match, and he has just guaranteed that no other modules can be loaded, since module loading depends on *his* key. So even if the silly case, I think signatures actually work fine. And if he doesn't have access to all modules, then he wasn't safe with the hash model anyway, because he'd have hashes in the kernel that he couldn't validate. So by definition, he'd have to have access to everything he needs to just re-sign things. And yes, he would need the ability to insert his own public key in the kernel image (he already has the ability to re-sign the modules, we have the script for that in the kernel build tree). I still think that kind of "strip off and re-populate" the signatures is a better model than having two completely different validation models. I also suspect it's less work (although I do agree that it likely means that we should package out certs differently). But whatever. Code talks louder than words. If you have a good model that does *not* screw up the build, and isn't too nasty, maybe we can add that alongside signature verification. Linus -- 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/