From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756507AbbEUWGr (ORCPT ); Thu, 21 May 2015 18:06:47 -0400 Received: from mail-lb0-f175.google.com ([209.85.217.175]:36377 "EHLO mail-lb0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756064AbbEUWGn (ORCPT ); Thu, 21 May 2015 18:06:43 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150515123513.16723.96340.stgit@warthog.procyon.org.uk> <555BD715.40202@kernel.org> <31772.1432128969@warthog.procyon.org.uk> <20150520162059.GC10473@localhost> <20150521213829.GH23057@wotan.suse.de> From: Andy Lutomirski Date: Thu, 21 May 2015 15:06:21 -0700 Message-ID: Subject: Re: [PATCH 0/8] MODSIGN: Use PKCS#7 for module signatures [ver #4] To: "Luis R. Rodriguez" Cc: David Howells , Andy Lutomirski , Rusty Russell , Michal Marek , Matthew Garrett , keyrings@linux-nfs.org, Dmitry Kasatkin , "linux-kernel@vger.kernel.org" , Seth Forshee , LSM List , David Woodhouse Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 21, 2015 at 2:59 PM, Luis R. Rodriguez wrote: > On Thu, May 21, 2015 at 2:44 PM, Andy Lutomirski wrote: >> >> One option would be to add another type of verifiable thing. We can >> verify modules, and we should add firmware to the types of things that >> can be signed. We could add signing keys, too. IOW, you could ask >> the kernel to load a signing key with certain rights, and, if they key >> is validly signed by some other key that has the same rights and has a >> bit set saying that it can delegate those rights, then the kernel will >> add that signing key to the keyring. >> >> If the general infrastructure were there, this would be very little >> additional code. > > I really like this idea, but I've heard of many great ideas before > followed by nothing but vaporware. So is it a direct requirement to > implicate blocking a change for current module signature checking > strategy to a new one given the concerns you raise, or can we enable > those who wish to want additional better solutions as the one you > propose to opt-in to develop those solutions? I like the idea of the > later given that it seems those using the current module signing > infrastructure would prefer the change and enabling what you say does > not seem to be a not possible based on allowing that to be advanced. > >>From my POV (and keep in mind that I'm not really involved in this stuff and my POV shouldn't be treated as gospel), a firmware signature verification should have verification that the signature was intended to apply to a firmware file with the name being requested as a requirement. Everything else is nice-to-have. Given that, I would say that merely shoving firmware files through the module verifier as-is would not be okay. There's plenty of flexibility in how you fix it, though. Doing it with PKCS#7 authenticated attributes *gag* would work, but my off-the-cuff guess is that making that work is actually harder, even on top of David's patches, than doing it from scratch. PKCS#7 is not easy to work with. FWIW, openssl rsautl can generate raw PKCS#1 v1.5 signatures (use -pkcs, not -raw). openssl pkeyutl can do PKCS#1 v2.0 (i.e. PSS) signatures, but you'd have to write the verifier yourself. The kernel already has a v1.5 verifier that even follows the best practices that I remember. (For v2.0, there's a security proof, so an implementation of the spec is actually secure and there are no "best practices" to worry about. v1.5 is known insecure if you implement it naively.) --Andy