Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp653628imm; Fri, 3 Aug 2018 09:18:03 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcTFwQ18OSP28f+Ksn0MVh2QkOZeHhX5H7G/jBx1vcx0Ky2y5KCsOI0Xi/1XsjpfBVDengZ X-Received: by 2002:a17:902:a9:: with SMTP id a38-v6mr4299677pla.102.1533313083724; Fri, 03 Aug 2018 09:18:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533313083; cv=none; d=google.com; s=arc-20160816; b=jdrU5HgzLBKOIeXlO20zR+u0UWfhIdewoQ0/jk6FjwWZhMHvWcIoVq3S3K2e3GhFDC kZbTLC6U5HK6HM+FVz6rPpqglozj3DJN/tllyL6T68g+NIxcvd5KSoaGi0VMlXhTUi2I u50VafaoqbPwtL4M1srph7RlrcAAzy3WVN8Sh78qON4rFXvLyOhFfYa7bqrh+ZkWT/Fw 1dpj85woOyu/hvQEYC0MIBIKeM5ncsnjh+qaDpmKiiBwjZLs37KULiWHcYiDD1mDQ0zz fKSEHgDw1fqgfS/HLXTfpnDyBbudz6DA4foM6Cnfr/wJyofpch3RtYUS8qjcKbbnhHdz 7dnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=Nmj5h/wK48XhaTLw2A7fWijogQ3AC6+cnE18hnadvD4=; b=D7Bpo7NMK6UH4uVe/kUTG+X+kgcrnk/2UrdTmSvry2Iam3xqA4ofyTFHtTY7XD1Rph IfxbNIjcZVZg02sjqwGLhFRXdMfdqIF1SdaI9z+3ZhfAg565XIwiCAAHaQC3BPY+EG36 IGBWp4Nk1GyAadq5AL2rDhDAInz0f7iGNSyAbNw0RGvNCF09ZfvINmZCXsvQatPoSDLb KMz7U+obeGzJbn8JKrfxVssTUXuvoR/4ripKEFxXf5eNE5SlqTYj0LS0MY1rNZSI0DgK VmUV0b7BttRAwlJ/58NA6XTgCIdfbtKyPX6TPt/FPS2vgfV4lrBYD1Fi5PXH61QqJu0a /t3Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r81-v6si5626826pfg.305.2018.08.03.09.17.48; Fri, 03 Aug 2018 09:18:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728025AbeHCSNl (ORCPT + 99 others); Fri, 3 Aug 2018 14:13:41 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:58965 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727356AbeHCSNl (ORCPT ); Fri, 3 Aug 2018 14:13:41 -0400 Received: from mail-io0-f198.google.com ([209.85.223.198]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1flcks-0006Ms-5x for linux-kernel@vger.kernel.org; Fri, 03 Aug 2018 16:16:42 +0000 Received: by mail-io0-f198.google.com with SMTP id e8-v6so4407952ioq.11 for ; Fri, 03 Aug 2018 09:16:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=Nmj5h/wK48XhaTLw2A7fWijogQ3AC6+cnE18hnadvD4=; b=SfVQMSS1D+UMNEH2wzFLGqIeamX3MKBQ4R5ajr3t2tA2EI7gm1UnuSYwtyQBN/n8vB bB8Krzboi58OU/2W2g4ANnQXTZ3K5UWNtXGZHlQHYpBiUdPGMx4iQNlhZn3TLboLyeQl N2138Vu24Pmzr2i7ombsENZXTWW3k8IigKaUlakoo/qSEPVe36W+CSdviIKoigOkBS+r NQulXwFN4VKj8MBXqg5MBrLkCg8W/Gl36fseQaHeyyzVLUgBqPoDXgIG0qSmRxKAgfe4 Gc/x5Jf47j92pAO532S0Bh+c/kGpZlzYQMDA3JcOKIs8DCkwUStZZw7i2UjxLkQ9I5np K6zQ== X-Gm-Message-State: AOUpUlGpQV7gWGCjJE4DXXqVHBS6fB4LAG3tw+0JgJvMfXVTUDJkrb57 Z0oGXCJi+TaT3jx688egFmd3Qqw9NjvtikAdnfC+lAXmaPS5At3O6SAdJ5Y6oedRpt5+ZnTBIUy pT49ob6YVwfLhK9xNOr7na/EAYsjvccsUQFpnO1GN5A== X-Received: by 2002:a6b:84d6:: with SMTP id o83-v6mr6869665ioi.93.1533313001079; Fri, 03 Aug 2018 09:16:41 -0700 (PDT) X-Received: by 2002:a6b:84d6:: with SMTP id o83-v6mr6869655ioi.93.1533313000793; Fri, 03 Aug 2018 09:16:40 -0700 (PDT) Received: from localhost ([2605:a601:ac7:2a20:5df8:7f89:d6e6:9952]) by smtp.gmail.com with ESMTPSA id g26-v6sm910000iti.0.2018.08.03.09.16.39 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 03 Aug 2018 09:16:39 -0700 (PDT) Date: Fri, 3 Aug 2018 11:16:36 -0500 From: Seth Forshee To: Mimi Zohar Cc: Eric Richter , linux-integrity , linux-security-module , linux-efi , linux-kernel , David Howells , Justin Forbes Subject: Re: [PATCH 3/4] ima: add support for KEXEC_ORIG_KERNEL_CHECK Message-ID: <20180803161636.GX3001@ubuntu-xps13> References: <20180725233200.761-1-erichte@linux.vnet.ibm.com> <20180725233200.761-4-erichte@linux.vnet.ibm.com> <20180803131129.GS3001@ubuntu-xps13> <1533308099.4337.424.camel@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1533308099.4337.424.camel@linux.ibm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 03, 2018 at 10:54:59AM -0400, Mimi Zohar wrote: > On Fri, 2018-08-03 at 08:11 -0500, Seth Forshee wrote: > > On Wed, Jul 25, 2018 at 06:31:59PM -0500, Eric Richter wrote: > > > IMA can verify the signature of kernel images loaded with kexec_file_load, > > > but can not verify images loaded with the regular kexec_load syscall. > > > Therefore, the appraisal will automatically fail during kexec_load when an > > > appraise policy rule is set for func=KEXEC_KERNEL_CHECK. This can be used > > > to effectively disable the kexec_load syscall, while still allowing the > > > kexec_file_load to operate so long as the target kernel image is signed. > > > > > > However, this conflicts with CONFIG_KEXEC_VERIFY_SIG. If that option is > > > enabled and there is an appraise rule set, then the target kernel would > > > have to be verifiable by both IMA and the architecture specific kernel > > > verification procedure. > > > > > > This patch adds a new func= for IMA appraisal specifically for the original > > > kexec_load syscall. Therefore, the kexec_load syscall can be effectively > > > disabled via IMA policy, leaving the kexec_file_load syscall able to do its > > > own signature verification, and not require it to be signed via IMA. To > > > retain compatibility, the existing func=KEXEC_KERNEL_CHECK flag is > > > unchanged, and thus enables appraisal for both kexec syscalls. > > > > This seems like a roundabout way to disallow the kexec_load syscall. > > Wouldn't it make more sense to simply disallow kexec_load any time > > CONFIG_KEXEC_VERIFY_SIG is enabled, since it effectively renders that > > option impotent? Or has that idea already been rejected? > > Agreed!  We can modify the "case LOADING_KEXEC_IMAGE" in > ima_load_data() to prevent the kexec_load based on > CONFIG_KEXEC_VERIFY_SIG. > > The architecture specific policy would only include the IMA appraise > rule if CONFIG_KEXEC_VERIFY_SIG was not defined. After looking at this some more I'm having second thoughts about my suggestion. As a distro we produce a kernel that needs to be flexible enough for a variety of scenarios, and if we completely close off the ability to load an unsigned kernel for kexec that's almost certainly going to end up breaking some use cases. So I think it is necessary to make this a run-time decision rather than a compile-time decision. The patch as provided does this based on whether or not the kernel was booted under secure boot. That might be reasonable, though I still find this mechanism kind of awkward. It seems like ideally there would instead be some logic that would accept the image if the KEXEC_VERIFY_SIG verification had passed, and otherwise require IMA signature verification. Thanks, Seth