From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932076AbbETQlp (ORCPT ); Wed, 20 May 2015 12:41:45 -0400 Received: from mail-la0-f50.google.com ([209.85.215.50]:34976 "EHLO mail-la0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751631AbbETQln (ORCPT ); Wed, 20 May 2015 12:41:43 -0400 MIME-Version: 1.0 In-Reply-To: <20150520162059.GC10473@localhost> References: <20150515123513.16723.96340.stgit@warthog.procyon.org.uk> <555BD715.40202@kernel.org> <31772.1432128969@warthog.procyon.org.uk> <20150520162059.GC10473@localhost> From: Andy Lutomirski Date: Wed, 20 May 2015 09:41:21 -0700 Message-ID: Subject: Re: [PATCH 0/8] MODSIGN: Use PKCS#7 for module signatures [ver #4] To: Andy Lutomirski , David Howells , Andy Lutomirski , Rusty Russell , Michal Marek , Matthew Garrett , keyrings@linux-nfs.org, Dmitry Kasatkin , Luis Rodriguez , "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 Wed, May 20, 2015 at 9:21 AM, Petko Manolov wrote: > On 15-05-20 08:56:21, Andy Lutomirski wrote: >> >> Would it make more sense to permit X.509 chains to be loaded into the keyring >> instead if we actually need that feature? IOW, let userspace (or early >> initramfs stuff) extend our keyring trust to intermediate certs that validly >> chain to already-trusted things? I think that a reasonable design goal would >> be that everything overcomplicated that's involved should be optional, and >> moving toward embedding PKCS#7 signatures in the modules themselves does the >> other direction? > > This is similar to what i am doing right now - create CA hierarchy so we can > have something like: > > +-> KeyB > | > RootCA ---> CertA ---> CertB ---> CertC ---> KeyC > | > +-> CertA' ---> KeyA" > > The RootCA may be the one whose private key was used to sign the modules and all > downstream certificates are either directly signed by it or one of the others. > Not all of the infrastructure is in the mainline kernel, but this can easily be > rectified. Right. I guess that I can imagine some uses for this, but I don't see why those intermediate certs would be embedded with the signatures being verified as opposed to being loaded beforehand. > > Now, as Mimi pointed out this scheme is flawed and should be used with care if > at all. Revoking certificates is always a PITA. Being valid for one year only > adds to the fun. > Valid for only one year is worse than that. We might be verifying the signature on our clock driver :) I think that, at best, we could reject certificates that expired before the running kernel was built. > > Petko -- Andy Lutomirski AMA Capital Management, LLC