Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755595AbdDGInF (ORCPT ); Fri, 7 Apr 2017 04:43:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39894 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755064AbdDGImy (ORCPT ); Fri, 7 Apr 2017 04:42:54 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 629FB19D24E Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=dyoung@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 629FB19D24E Date: Fri, 7 Apr 2017 16:42:42 +0800 From: Dave Young To: Mimi Zohar Cc: David Howells , linux-kernel@vger.kernel.org, Matthew Garrett , linux-efi@vger.kernel.org, gnomes@lxorguk.ukuu.org.uk, Chun-Yi Lee , gregkh@linuxfoundation.org, kexec@lists.infradead.org, linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, matthew.garrett@nebula.com Subject: Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set Message-ID: <20170407084242.GB11402@dhcp-128-65.nay.redhat.com> References: <20170407061935.GB10100@dhcp-128-65.nay.redhat.com> <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk> <149142335441.5101.2294976563846442575.stgit@warthog.procyon.org.uk> <20170407030545.GA4296@dhcp-128-65.nay.redhat.com> <1491536950.4184.10.camel@linux.vnet.ibm.com> <21418.1491548875@warthog.procyon.org.uk> <20170407074159.GB10737@dhcp-128-65.nay.redhat.com> <1491553688.4184.73.camel@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1491553688.4184.73.camel@linux.vnet.ibm.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Fri, 07 Apr 2017 08:42:51 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2121 Lines: 51 On 04/07/17 at 04:28am, Mimi Zohar wrote: > On Fri, 2017-04-07 at 15:41 +0800, Dave Young wrote: > > On 04/07/17 at 08:07am, David Howells wrote: > > > Dave Young wrote: > > > > > > > > > > + /* Don't permit images to be loaded into trusted kernels if we're not > > > > > > > + * going to verify the signature on them > > > > > > > + */ > > > > > > > + if (!IS_ENABLED(CONFIG_KEXEC_VERIFY_SIG) && kernel_is_locked_down()) > > > > > > > + return -EPERM; > > > > > > > + > > > > > > > > > > > > > > > > > IMA can be used to verify file signatures too, based on the LSM hooks > > > > > in ?kernel_read_file_from_fd(). ?CONFIG_KEXEC_VERIFY_SIG should not be > > > > > required. > > > > > > > > Mimi, I remember we talked somthing before about the two signature > > > > verification. One can change IMA policy in initramfs userspace, > > > > also there are kernel cmdline param to disable IMA, so it can break the > > > > lockdown? Suppose kexec boot with ima disabled cmdline param and then > > > > kexec reboot again.. > > > > > > I guess I should lock down the parameter to disable IMA too. > > > > That is one thing, user can change IMA policy in initramfs userspace, > > I'm not sure if IMA enforce the signed policy now, if no it will be also > > a problem. > > I'm not sure how this relates to the question of whether IMA verifies > the kexec kernel image signature, as the test would not be based on a > Kconfig option, but on a runtime variable. I assumed one can change the policy to avoid kexec and initramfs check And we use a global IMA status in the -EPERM check for the lockdown checking. But if there is some fine grained checking to ensure kernel signature verification it should be fine. > > To answer your question, the rule for requiring the policy to be > signed is: ?appraise func=POLICY_CHECK appraise_type=imasig > > When the ability to append rules is Kconfig enabled, the builtin > policy requires the new policy or additional rules to be signed. > ?Unfortunately, always requiring the policy to be signed, would have > broken userspace. > > Mimi > Thanks Dave