From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:34582 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750859AbeEBBBD (ORCPT ); Tue, 1 May 2018 21:01:03 -0400 Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w420sMYi166247 for ; Tue, 1 May 2018 21:01:03 -0400 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0b-001b2d01.pphosted.com with ESMTP id 2hpx19syuq-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 01 May 2018 21:01:01 -0400 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2018 02:00:58 +0100 Subject: Re: linux-next: UEFI Secure boot lockdown patchset From: Mimi Zohar To: Matthew Garrett Cc: David Howells , linux-integrity , Ben Hutchings , nayna@linux.vnet.ibm.com Date: Tue, 01 May 2018 21:00:54 -0400 In-Reply-To: References: <26787.1519902415@warthog.procyon.org.uk> <8106.1525201247@warthog.procyon.org.uk> <1525205707.5669.91.camel@linux.vnet.ibm.com> <1525211403.5669.141.camel@linux.vnet.ibm.com> <1525213285.5669.152.camel@linux.vnet.ibm.com> <1525218220.5669.164.camel@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Message-Id: <1525222854.5669.169.camel@linux.vnet.ibm.com> Sender: linux-integrity-owner@vger.kernel.org List-ID: On Tue, 2018-05-01 at 23:46 +0000, Matthew Garrett wrote: > On Tue, May 1, 2018 at 4:43 PM Mimi Zohar wrote: > > > On Tue, 2018-05-01 at 22:32 +0000, Matthew Garrett wrote: > > > INTEGRITY_KEYRING_MODULE is defined, but doesn't appear to be used > > > anywhere. Odd. Anyway, distributions are unlikely to ship with > > > CONFIG_INTEGRITY_TRUSTED_KEYRING since it makes it impossible for users > to > > > determine which set of IMA or EVM signatures they want to trust. So if > > > validation is against the IMA keyring rather than builtin_trusted_keys, > > > it's going to be possible for users to extend the set of trusted keys. > If > > > CONFIG_KEXEC_BZIMAGE_VERIFY_SIG is set then the kernel seems to do the > > > right thing here, but it's not clear to me how that's supposed to > interact > > > with IMA? > > > From your description, whatever keys the distros are loading onto the > > builtin_trusted_keys keyring for verifying the kexec kernel image, > > could just as easily be added to the IMA trusted keyring > > (CONFIG_INTEGRITY_TRUSTED_KEYRING). I don't see the difference. > > If CONFIG_INTEGRITY_TRUSTED_KEYRING isn't set then you can load new (and > unsigned) IMA keys from userspace. So if IMA is the lockdown control > mechanism for kexec, distros must either set > CONFIG_INTEGRITY_TRUSTED_KEYRING (which I don't think is practical) or IMA > should test kexec against the builtin_trusted_keys keyring rather than the > IMA keyring. Or have I misunderstood how this works? Another option is enabling both CONFIG_INTEGRITY_TRUSTED_KEYRING and CONFIG_SYSTEM_EXTRA_CERTIFICATE. Mimi