Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751720AbbESUFg (ORCPT ); Tue, 19 May 2015 16:05:36 -0400 Received: from mail-la0-f54.google.com ([209.85.215.54]:35965 "EHLO mail-la0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750782AbbESUFd (ORCPT ); Tue, 19 May 2015 16:05:33 -0400 MIME-Version: 1.0 In-Reply-To: <1432065634.3277.81.camel@infradead.org> References: <31154.1431965087@warthog.procyon.org.uk> <555A88FB.7000809@kernel.org> <1432058889.3277.73.camel@infradead.org> <1432060732.3277.77.camel@infradead.org> <1432065634.3277.81.camel@infradead.org> From: Andy Lutomirski Date: Tue, 19 May 2015 13:05:11 -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 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1528 Lines: 32 On Tue, May 19, 2015 at 1:00 PM, David Woodhouse wrote: > On Tue, 2015-05-19 at 11:49 -0700, Andy Lutomirski wrote: >> >> If we use hashes instead of signatures on in-tree modules (at least in >> the case where no long-term key is provided), then generation of the >> temporary signing key stops being an issue because there is no longer >> a temporary signing key. > > With signatures I can make a one-line change to a module and rebuild it, > and still load it without having to rebuild my vmlinux to 'permit' it. > > My signing key is valid for as long as I *choose* it to be valid. > > I appreciate why that's a problem in your scenario, but it's a valid and > useful feature of signatures, and I don't think we can just abandon it. True, but I'd consider that use case (running a kernel built on a development machine) to be more in line with unsigned use or long-term (maybe medium-term) signing keys. IOW, for this use case, running scripts/generate_module_signing_key or whatever and configuring accordingly seems entirely reasonable to me. Or you could just turn off forced module signature verification since keeping the signing key in plaintext on your machine mostly negates any benefit of verifying signatures on that machine at runtime. --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/