From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755244AbbJUSLW (ORCPT ); Wed, 21 Oct 2015 14:11:22 -0400 Received: from e28smtp03.in.ibm.com ([122.248.162.3]:36309 "EHLO e28smtp03.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752156AbbJUSLT (ORCPT ); Wed, 21 Oct 2015 14:11:19 -0400 X-Helo: d28dlp01.in.ibm.com X-MailFrom: zohar@linux.vnet.ibm.com X-RcptTo: linux-security-module@vger.kernel.org Message-ID: <1445451068.2459.302.camel@linux.vnet.ibm.com> Subject: Re: [PATCH 00/10] KEYS: Change how keys are determined to be trusted From: Mimi Zohar To: Josh Boyer Cc: David Howells , keyrings@vger.kernel.org, linux-security-module , linux-crypto@vger.kernel.org, "Linux-Kernel@Vger. Kernel. Org" Date: Wed, 21 Oct 2015 14:11:08 -0400 In-Reply-To: References: <20151021151314.4583.90962.stgit@warthog.procyon.org.uk> <1445446968.2459.272.camel@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 (3.12.11-1.fc21) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15102118-0009-0000-0000-0000085C1218 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2015-10-21 at 13:21 -0400, Josh Boyer wrote: > On Wed, Oct 21, 2015 at 1:02 PM, Mimi Zohar wrote: > > On Wed, 2015-10-21 at 16:13 +0100, David Howells wrote: > >> Here's a set of patches that changes how keys are determined to be trusted > >> - currently, that's a case of whether a key has KEY_FLAG_TRUSTED set upon > >> it. A keyring can then have a flag set (KEY_FLAG_TRUSTED ONLY) that > >> indicates that only keys with this flag set may be added to that keyring. > >> > >> Further, any time an X.509 certificate is instantiated without this flag > >> set, the certificate is judged against the contents of the system trusted > >> keyring to determine whether KEY_FLAG_TRUSTED should be set upon it. > >> > >> With these patches, KEY_FLAG_TRUSTED is removed. The kernel may add > >> implicitly trusted keys to a trusted-only keyring by asserting > >> KEY_ALLOC_TRUSTED when the key is created, > > > > Ok, but only the x509 certificates built into the kernel image should be > > automatically trusted and can be added to a trusted keyring, because the > > kernel itself was signed (and verified). These certificates extend the > > (UEFI) certificate chain of trust that is rooted in hardware to the OS. > > That doesn't sound accurate to me. The cert built into the kernel > image doesn't extend the UEFI certificates. In most cases, it is a > ephemeral cert that is automatically generated at kernel build time > and then discarded. It is not chained to or derived from any of the > UEFI certs stored in the db (or mok) variables. The built-in cert is > used for module loading verification. I agree that it should be > trusted, but not really for the reason you list. Perhaps you meant > the key that the PE image of the kernel is signed with? If so, the > kernel doesn't load that. Only shim (and grub2 via shim) read that > key. This is similar to the concept of the MoK DB. Keys added to the MoK aren't signed by a UEFI key, yet they extend the UEFI secure boot certificate chain of trust. Similarly, the certificates built into the kernel image don't need to be signed by a UEFI/MoK key for it to extend the certificate chain of trust. > However, that does bring up the UEFI db/mok certs and how to deal with > those. The out-of-tree patches we have add them to the system keyring > as trusted keys. We can modify the patches to use KEY_ALLOC_TRUSTED > to preserve that functionality I suppose. Certificates are use case specific. Just because a key was trusted at the UEFI layer doesn't mean it should be trusted by the kernel (eg. Microsoft key). To illustrate this point, David Howells/David Woodhouse recently posted/upstreamed patches to differentiate how keys loaded onto the system keyring may be used. (Reference needed.) Mimi