Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp1575748imc; Mon, 11 Mar 2019 17:43:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqwXRH83EyRvvKzQ8td2cEC+sbw6Rzji5DuPngd8qOv72iI4tGArmuLUXXGkQkOG9Gy6QkoV X-Received: by 2002:a65:6085:: with SMTP id t5mr24257957pgu.257.1552351416129; Mon, 11 Mar 2019 17:43:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552351416; cv=none; d=google.com; s=arc-20160816; b=syWnt9ful31aMi2wnlN/2mhbNKWM+Iy2c1l/SlnTQ6X4XDYRNcF8obnLtT4ZqSFTWo k0WBYIBkkVQoTl4PZ/XVXkuPXSbFvpXBG/MF1EIR//C4ay8tW7/9l16d2hv2eTnClMs9 DlBVMY+nT98zSs/+SGvN81uyj0u8+HY0tJaxnwoUJV56E33dBT2uNqtv9Y8EkaJXdMTf T/Mtj9LFvD1D8jP1ldza7ATm58ORez4CNtQcrx0p6es/JU8fQfkbcg87fS7B1ru0prqF U0i441lgAyCPF2aDEg7F5KETiavDe7rZHTgFVxVu3FC7ZcjYsscFe0AiR+78TLuBbitz fCxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=cvqMwPmDKPaOeSABeD2s16ykBRIp+PzgwWPBhWyxVEQ=; b=rlwDXkjvkFnldcdAIjjFw7vAM3aPSDx3Ofbe4OWf41gUWpTuAkP2D+AR2AdaPNE/Pq xspTAmfSPnzaz0DOlsRfjzvJGcdQTFbyG/TQUTCxcUuw43IyWQPl7KcZrTJwAdsDwcfy W7lxCSowhS4WYVh4XbVW+QHfVfHEQ1xfiCUwTFc007CFdKE8MLYASKsMKJKfj9SyfHCH ljsdKjyBEY6LDetVgiP81bcQsVzl7UTq+0vao4XZ3oyFIFHz7bGSd5J3BHVJ3l6MieX/ 617YcjgIX0NrZhe5hb0VLjpbaiORuADgD0NPsuughSUUGZT10T+UBxTnr02Azk60MOu+ bgiA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=dX1i2jSK; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r5si5874356pgk.401.2019.03.11.17.43.19; Mon, 11 Mar 2019 17:43:36 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=dX1i2jSK; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726513AbfCLAmv (ORCPT + 99 others); Mon, 11 Mar 2019 20:42:51 -0400 Received: from mail-io1-f68.google.com ([209.85.166.68]:39262 "EHLO mail-io1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726411AbfCLAmu (ORCPT ); Mon, 11 Mar 2019 20:42:50 -0400 Received: by mail-io1-f68.google.com with SMTP id x3so554385ior.6 for ; Mon, 11 Mar 2019 17:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cvqMwPmDKPaOeSABeD2s16ykBRIp+PzgwWPBhWyxVEQ=; b=dX1i2jSKZA4k2wZVaRbGVlOezSHggBIsV5kLw8RrBaLOPLmspsgVoGcvMJqguCUerK ZXjOxBHo+QUaUq4URYfyldyG5Zzv4kty3PoFduEHaz82xy9+mwA7lL+SswBTN+qVf32A 7M/5ic/YrrJdBRgbpDsy0GXoINrmb2d5RicvwHT2FtsrrVZb5TItDhbpVkZLczf0ElO9 bQ3I7ITpjH8owFH7XEzYfZqnsBDDsjeei2t05ThBeLUKWUiqt0OtEqEhQ3df9Iub7Mv9 430dYIwg2VG4LNI/gqwxbfjgyXBz6BSUFfTnUOcoiYHDlu+ym45B5n6bGbcw2PcAPQGf ETPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cvqMwPmDKPaOeSABeD2s16ykBRIp+PzgwWPBhWyxVEQ=; b=r/GMVtWcfRxDq2kJIGjy6MQbfibluplV0yYhVAGaiyM7xlQ7GDlL+V4hl9WfFwmHSb LxnDKz1ABEqlIMJ0FtZF1qua9zrqIl3javgpDmeCmOgeVCaa3ca79HEiOS1q1J/vFejH Xz0XQLO+rdIG9NPL7Y4rgO5y/zGvFHQtqKPdNe2HtvGxb6MSQukR3JY77dBm14XHcy/1 CMhavmgOEiWNdw5IdYMxQVuttRiOcdrutsZbuRLGgRU9hpddxiMwPxxA7TwyiIjEIE9u SjRRCArGHEE1HT1PD6VAx7DfnD579h2+u24FZDjZGFKEDI3HyDS1WeCM/VlMnCPRv5BA WsWQ== X-Gm-Message-State: APjAAAXYkafO/bRgF4Ld2J2fdI8ZVbQrxCu5uFSIatcUAwGAFjDVp/6e sJGD8AwqcjZG74i4RBjq0t8o6ZmbnQ7Z5/lc9oai+g== X-Received: by 2002:a5e:c901:: with SMTP id z1mr3331209iol.304.1552351369117; Mon, 11 Mar 2019 17:42:49 -0700 (PDT) MIME-Version: 1.0 References: <20190306235913.6631-1-matthewgarrett@google.com> <1551930990.31706.279.camel@linux.ibm.com> In-Reply-To: From: Matthew Garrett Date: Mon, 11 Mar 2019 17:42:38 -0700 Message-ID: Subject: Re: [PULL REQUEST] Kernel lockdown patches for 5.2 To: Mimi Zohar Cc: James Morris , LSM List , Linux Kernel Mailing List , David Howells Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 6, 2019 at 8:24 PM Matthew Garrett wrote: > > On Wed, Mar 6, 2019 at 7:56 PM Mimi Zohar wrote: > > The kexec and kernel modules patches in this patch set continues to > > ignore IMA. This patch set should up front either provide an > > alternative solution to coordinate the different signature > > verification methods or rely on the architecture specific policy for > > that coordination. > > Hi Mimi, > > I'm working on a patch for this at the moment which can then be added > to either patchset. Is there a tree that contains the proposed Power > architecture policy? I want to make sure I don't accidentally end up > depending on anything x86. I've been digging into this some more, and want to ensure that I get the appropriate semantics. Are we happy with the x86 solution for module signing (ie, if the arch policy is enabled and the kernel supports module signatures, use module signatures rather than IMA signatures)? If so, that just leaves kexec. For platforms that support PE signing for kernels (x86 and arm), are we ok punting to that? If so then to maintain the semantics we have for lockdown in general (ie, no way for a user to modify ring 0 code) then I think that would mean allowing kexec_file() only when the following criteria are met: 1) IMA is appraising kexec with digital signatures, either ima digital signatures or ima hashes with associated EVM digital signatures 2) CONFIG_INTEGRITY_TRUSTED_KEYRING is set in order to prevent an attacker being able to add a key to the keyring Does this sound reasonable? Are there any further criteria that are required for this?