Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754912AbcKUQYw (ORCPT ); Mon, 21 Nov 2016 11:24:52 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:41460 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754836AbcKUQYt (ORCPT ); Mon, 21 Nov 2016 11:24:49 -0500 Subject: Re: [PATCH 4/9] KEYS: Allow unrestricted boot-time addition of keys to secondary keyring From: Mimi Zohar To: David Howells Cc: Petko Manolov , keyrings@vger.kernel.org, matthew.garrett@nebula.com, linux-security-module@vger.kernel.org, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ima-devel Date: Mon, 21 Nov 2016 11:24:28 -0500 In-Reply-To: <18864.1479741430@warthog.procyon.org.uk> References: <1479737095.2487.34.camel@linux.vnet.ibm.com> <20161117064100.hmjmfw42ytm526yh@p310> <147931984418.16460.6639993676886095760.stgit@warthog.procyon.org.uk> <147931987366.16460.12891767069975068260.stgit@warthog.procyon.org.uk> <26349.1479376560@warthog.procyon.org.uk> <18864.1479741430@warthog.procyon.org.uk> 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: 16112116-0028-0000-0000-000003538CE3 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16112116-0029-0000-0000-0000115EDE6C Message-Id: <1479745468.2487.60.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-21_13:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611210283 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1136 Lines: 25 On Mon, 2016-11-21 at 15:17 +0000, David Howells wrote: > Mimi Zohar wrote: > > > > > > This allows keys in the UEFI database to be added in secure boot mode > > > > > for the purposes of module signing. > > > > > > > > The key import should not be automatic, it should be optional. > > > > > > You can argue this either way. There's a config option to allow you to > > > turn this on or off. Arguably, this should be split in two: one for the > > > whitelist (db, MokListRT) and one for the blacklist (dbx). > > > > By "config", you're not referring to a Kconfig option, but a UEFI db > > option, making it hidden/unknown to someone building a kernel. If you > > really want to add this support, make it clear and easily seen by > > defining a "restrict_link_by_builtin_or_uefi" function. > > No: by "config" I *am* referring to Kconfig. Good, I found the Kconfig LOAD_UEFI_KEYS option for loading the keys on the keyring. Lets say that someone does want to use those keys for kernel modules, but only for kernel modules, not for any other types of files (eg. kexec kernel image/initramfs)? Mimi