Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751230AbbEXKyQ (ORCPT ); Sun, 24 May 2015 06:54:16 -0400 Received: from lan.nucleusys.com ([92.247.61.126]:45003 "EHLO zztop.nucleusys.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751022AbbEXKyL (ORCPT ); Sun, 24 May 2015 06:54:11 -0400 Date: Sun, 24 May 2015 13:52:55 +0300 From: Petko Manolov To: Mimi Zohar Cc: David Howells , "Luis R. Rodriguez" , Andy Lutomirski , 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 Subject: Re: [PATCH 0/8] MODSIGN: Use PKCS#7 for module signatures [ver #4] Message-ID: <20150524105255.GC7238@localhost> Mail-Followup-To: Mimi Zohar , David Howells , "Luis R. Rodriguez" , Andy Lutomirski , 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 References: <20150521213829.GH23057@wotan.suse.de> <20150515123513.16723.96340.stgit@warthog.procyon.org.uk> <555BD715.40202@kernel.org> <31772.1432128969@warthog.procyon.org.uk> <20150520162059.GC10473@localhost> <32540.1432280936@warthog.procyon.org.uk> <1432297697.2450.53.camel@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1432297697.2450.53.camel@linux.vnet.ibm.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -1.0 (-) X-Spam-Report: Spam detection software, running on the system "zztop.nucleusys.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 15-05-22 08:28:17, Mimi Zohar wrote: > On Fri, 2015-05-22 at 08:48 +0100, David Howells wrote: > > Luis R. Rodriguez wrote: > > > > > > 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" > > > > > > How exactly do you go about uploading CertB to the kernel BTW? > > > > Assuming RootCA or CertA is present in the kernel, the idea would be to use > > the add_key() system call or the request_key() mechanism to add the key to > > the system keyring. The key in the cert would only be added to the keyring > > if it is trusted by a key already there. > > From Petko's description, the RootCA is on the system keyring, but CertA is on > a new IMA trusted CA keyring. So everything you said is true, but on this > new, yet to be upstreamed, IMA trusted CA keyring. [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1895 Lines: 41 On 15-05-22 08:28:17, Mimi Zohar wrote: > On Fri, 2015-05-22 at 08:48 +0100, David Howells wrote: > > Luis R. Rodriguez wrote: > > > > > > 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" > > > > > > How exactly do you go about uploading CertB to the kernel BTW? > > > > Assuming RootCA or CertA is present in the kernel, the idea would be to use > > the add_key() system call or the request_key() mechanism to add the key to > > the system keyring. The key in the cert would only be added to the keyring > > if it is trusted by a key already there. > > From Petko's description, the RootCA is on the system keyring, but CertA is on > a new IMA trusted CA keyring. So everything you said is true, but on this > new, yet to be upstreamed, IMA trusted CA keyring. I only named this intermediate keyring .ima_root_ca because this is how i use it. However, it is system-wide trusted keyring, which accepts keys that are either trusted by CAs in the .system_keyring or higher level CA is already in .ima_root_ca. For example CertC will be accepted in .ima_root_ca if CertB is already there. The name (.ima_root_ca) is misleading and should be replaced with something that better describes it's functionality. As far as i see there is no reason this keyring not to hold the CA that verifies module's signature. Petko -- 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/