From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 60D62955 for ; Wed, 27 Jul 2016 16:28:04 +0000 (UTC) Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [66.63.167.143]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 13F2E171 for ; Wed, 27 Jul 2016 16:28:04 +0000 (UTC) Message-ID: <1469636881.27356.70.camel@HansenPartnership.com> From: James Bottomley To: David Howells Date: Wed, 27 Jul 2016 12:28:01 -0400 In-Reply-To: <14209.1469636040@warthog.procyon.org.uk> References: <1469631987.27356.48.camel@HansenPartnership.com> <20150804152622.GY30479@wotan.suse.de> <1468612258.5335.0.camel@linux.vnet.ibm.com> <1468612671.5335.5.camel@linux.vnet.ibm.com> <20160716005213.GL30372@sirena.org.uk> <1469544138.120686.327.camel@infradead.org> <14209.1469636040@warthog.procyon.org.uk> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: Mark Brown , ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, 2016-07-27 at 17:14 +0100, David Howells wrote: > James Bottomley wrote: > > > 1. Population and update policy: How should we populate the default > > keyrings and revocation lists? Should we have a built in list of > > absolute trust that can never be added to? I think the current > > default here is OK: it's populate with the kernel built in keys and > > nothing else. If userspace wants to populate with, say, the secure > > boot keys, then it can do so from init. An issue here is the > > Microsoft signing key, which most Linux people have but which they > > wouldn't necessarily consider to be a source of absolute trust. > > However, third party driver vendors would like a way to get their > > key trusted by the kernel so they can easily supply modules (This > > isn't a binary module issue: the code is usually GPL, but the > > vendors would like to supply updates asynchronously to the distro > > release cycle). We can say their key should be added as part of the > > rpm that installs the module, but do users really want this key > > adding to the default keyring to be trusted for non-module > > operations? > > I have patches that allow the UEFI key and blacklist databases to add to the > kernel keyrings during boot. > > We don't want to permit loading a key from a file once the kernel is booted > unless that key is signed by a key already in the keyrings. This is a policy discussion we should have. If you populate the immutable .builtin_trusted_keys keyring with the secure boot keys, most people will end up with a Microsoft key in their keyring (and possibly even some random motherboard vendor ODM key) which they can't remove. I thought the idea was to use the .secondary_trusted_keys keyring which is mutable? That way we can have policy in userspace select which secure boot keys we might like to trust. James