Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp449892imm; Fri, 3 Aug 2018 06:12:42 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfoqGCwQJrZ1zY2U5EDw2VnXFlCDlMBBO/JjDtdaoD4NrGwLClZEyHQ8gb3r+6OPLinGSrA X-Received: by 2002:a63:bf43:: with SMTP id i3-v6mr3750841pgo.342.1533301962717; Fri, 03 Aug 2018 06:12:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533301962; cv=none; d=google.com; s=arc-20160816; b=NnZio6vw4LmyYsTFWEcQwGy6VsbCP0cnwGo4Q/pBqWZZmvlyEIs0/Jj4/T/JeFRnMq MG3+w8Pr/YFKrywgq1kT+h9fSe2opBISBQHiTyGV49KIxySJAGay4QF5r2XE3FvKzs33 bfhxlEJNYWUg9El5XXJf/kSHJSowoizFFbqp6ggW0GWTSir4ystRGK7UTSvB2C2iHoVU QcpnEYmPL3jX+DDhWVtUzTmJNKU9rC4N7hqVkdhaVIvoBqXVKhYdbs7kTOnc1uphYXPe XxxrqmfSZO9eIDwY5TfXFeRNe1IwjefADif4E0hxNZNIQPPCuiXHwslzo7rvnK+ZLjop ONZA== 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-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=2IbJzeDoYA1WZUw2b0yUey+OFe3tTgbEAknAwk5jJIw=; b=X8j66fyHtIxBKkvm3CPP4m0tP0P2puq3r7S2NTeZgIM1fAItuSlIS+uf61ByHALOWE pQpmSCPdrnrlfSaPSnqxAOlSDVi8MdhAOBTOlE+wX3j+Wvuqw9AHQN817ebDv5pCVnQe RB/KNFYLLBqe5Yqvm2BChUyzKM43P9B1ezLpQSZEa9pnigGTXn/uR2hd3PXuKduGEPDP y81EvP9fDtZJb3kFGBzMeTCSA3YxPRAQCUzRgK+KbwuxAc8uKEk1B/0jZBdZze9l6fjv P9e0XL6XGf2wY4As/GFj8o+f0gniUTF41B0KG3hnManMq2bpZ3DPhpfZhcUJuOiS79Og FUoA== 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 i3-v6si3617167plb.44.2018.08.03.06.12.27; Fri, 03 Aug 2018 06:12:42 -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 S1732017AbeHCPHx (ORCPT + 99 others); Fri, 3 Aug 2018 11:07:53 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:55598 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730129AbeHCPHx (ORCPT ); Fri, 3 Aug 2018 11:07:53 -0400 Received: from mail-it0-f71.google.com ([209.85.214.71]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1flZri-0004Ki-1i for linux-kernel@vger.kernel.org; Fri, 03 Aug 2018 13:11:34 +0000 Received: by mail-it0-f71.google.com with SMTP id r184-v6so5541380ith.0 for ; Fri, 03 Aug 2018 06:11:34 -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:in-reply-to:user-agent; bh=2IbJzeDoYA1WZUw2b0yUey+OFe3tTgbEAknAwk5jJIw=; b=NXDBUx54lbf5pejIWANNaYKN46O2kOodp+McmYsS8FZajnUEeqZWHvJRw+oEeBvDMy eeAcpfR77oqJEt1LBQ7MIzON97jNsPBEVaZ+MYOWBRv+m7twX7+83Fg82zHuUfSXKmBV y73pIPmIUtvu0h/nihayQSL/megHYupLSfJBSh54NtZdjcvI5dnw8TZnlUxc81wlX3uT B2NStXun7mHpWRbR6VNe8TNYf34AeN6QECI/EmG6rheHJIctDEL201FuUTrsdtGdEb90 aWP15WzEKA8qkqVdOYX5AslhqS9gvaa36tSd1OZzDGiWYZ8w1AtIBVp46OO4TGZWtXpW +PDg== X-Gm-Message-State: AOUpUlEypZDFYd2VqZ53nIDT1QTY6/58SIE0AHXHxgLUaEo16+Xqai7Z Bc+knQNbc0J78nibWzjAurVGBnaC/gcBuT2kbjU/aBHHo6NN4KxMBZbr6F72bCrVsbD/whh9hen J+AI0WLAEd3gC1yiQXaHYvERQFzM7EFJe+UN6eK9drw== X-Received: by 2002:a6b:2353:: with SMTP id j80-v6mr5486908ioj.99.1533301892977; Fri, 03 Aug 2018 06:11:32 -0700 (PDT) X-Received: by 2002:a6b:2353:: with SMTP id j80-v6mr5486887ioj.99.1533301892696; Fri, 03 Aug 2018 06:11:32 -0700 (PDT) Received: from localhost ([2605:a601:ac7:2a20:5df8:7f89:d6e6:9952]) by smtp.gmail.com with ESMTPSA id l13-v6sm2604210itb.43.2018.08.03.06.11.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 03 Aug 2018 06:11:32 -0700 (PDT) Date: Fri, 3 Aug 2018 08:11:29 -0500 From: Seth Forshee To: Eric Richter Cc: 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: <20180803131129.GS3001@ubuntu-xps13> References: <20180725233200.761-1-erichte@linux.vnet.ibm.com> <20180725233200.761-4-erichte@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180725233200.761-4-erichte@linux.vnet.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 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? Thanks, Seth