Received: by 10.213.65.68 with SMTP id h4csp142689imn; Tue, 3 Apr 2018 17:25:33 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+/O0GDW35nuVkeOlNDh4607LXozP2i1BB7m9N4MxzpPsllRd1YqOpRK5jDnubSIxlnEvFu X-Received: by 10.98.178.76 with SMTP id x73mr10369079pfe.193.1522801533455; Tue, 03 Apr 2018 17:25:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522801533; cv=none; d=google.com; s=arc-20160816; b=ZbQgb/aP6yTdIITgcNrxjrX0xOcJdNvdhHq8WVPxHS/ugkSNOBIntWnJ5Ek0QNSL0b 68QXieQp7Oq6mcrPN4RhyZ0UF9ZsYjwp+QD0WWIjfE5YOj94JB5M9S9B7fl845Etlki8 LUUDLojePaCEfSA2sSwx9ypF0X/SNHhdWjzOqTjvc9HANXZD8fsyHDZueJw7JgNMlFhs IbXfseks0k35tBqo4FuACxE1mb2FRLJ08aPUrcM1Yi1HH4zmjvYolA4EmrRlZGnWi1Yz EnXl049NDd2W+JoJWbA764+6rCoc8ngtBuCGON8QjHuT1i3UofZlG3hMYlGMhJqv6PH7 WJrg== 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 :references:in-reply-to:mime-version:dmarc-filter :arc-authentication-results; bh=yrLP1jdeRKwfeRUZMfAm/VrSAEhDutqRjpjEISTCHa4=; b=BCCUNvu+ofSRiCtARV5DAvSJ6tQLfLJ2/Gjv3AwPCiCnhTowljNaAtNSsdjRSgErgT aG/UHGYWXH8LLrDjf+suCh7AAUs0iMPSM8q0b/KbCBNg2NHfpYgZ7kDzu/wWHkQOc0CL k4M67OScrNQyZeq8taShFvs75Zn9IshpbA0Vz9Bf8vOsuWZ7k/KQ7DSXZbsgCOklBTug m08lDbTAApnCP95ddY0W1AMHGb4iE1ujCWPFVLXHkztXuswMjG+tBRf9p5PzGrnK/ROc 0gtDHKvOnz17O7nBK4TBKqBievMgVZKQGOdgYFG0MLEx/Cba4MVRrpbLu3lSvTexfVLI z1qg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w19-v6si1727887plq.156.2018.04.03.17.25.18; Tue, 03 Apr 2018 17:25:33 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756729AbeDDAYE (ORCPT + 99 others); Tue, 3 Apr 2018 20:24:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:58802 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756624AbeDDAYA (ORCPT ); Tue, 3 Apr 2018 20:24:00 -0400 Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9D1992183B for ; Wed, 4 Apr 2018 00:23:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9D1992183B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org Received: by mail-io0-f169.google.com with SMTP id e79so24188779ioi.7 for ; Tue, 03 Apr 2018 17:23:59 -0700 (PDT) X-Gm-Message-State: AElRT7GLBw2p+8vvX4/s+Pk/yIC+L0jf7kDvvgl+OGbNnaC/kI5+Nkkk 4mFLn1Ogh1pI5RrStfEWi6cbA3zhn30AJa+Bo3fdYw== X-Received: by 10.107.57.84 with SMTP id g81mr14215579ioa.6.1522801438911; Tue, 03 Apr 2018 17:23:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.137.70 with HTTP; Tue, 3 Apr 2018 17:23:38 -0700 (PDT) In-Reply-To: References: <4136.1522452584@warthog.procyon.org.uk> <186aeb7e-1225-4bb8-3ff5-863a1cde86de@kernel.org> <30459.1522739219@warthog.procyon.org.uk> <9758.1522775763@warthog.procyon.org.uk> <13189.1522784944@warthog.procyon.org.uk> <9349.1522794769@warthog.procyon.org.uk> From: Andy Lutomirski Date: Tue, 3 Apr 2018 17:23:38 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [GIT PULL] Kernel lockdown for secure boot To: Jann Horn Cc: Linus Torvalds , Matthew Garrett , Andrew Lutomirski , David Howells , Ard Biesheuvel , James Morris , Alan Cox , Greg Kroah-Hartman , Linux Kernel Mailing List , Justin Forbes , linux-man , joeyli , LSM List , Linux API , Kees Cook , linux-efi 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 Tue, Apr 3, 2018 at 5:17 PM, Jann Horn wrote: > On Wed, Apr 4, 2018 at 2:06 AM, Linus Torvalds > wrote: >> On Tue, Apr 3, 2018 at 4:59 PM, Matthew Garrett wrote: >>> >>> Ok. So we can build distribution kernels that *always* have this on, and to >>> turn it off you have to disable Secure Boot and install a different kernel. >> >> Bingo. >> >> Exactly like EVERY OTHER KERNEL CONFIG OPTION. >> >> Just like all the ones that I've mentioned several times. >> >> Or, like a lot of other kernel options, maybe have a way to just >> disable it on the kernel command line, and let the user know about it. >> >> That would still be better than disabling secure boot entirely in your >> world view, so it's (a) more convenient and (b) better. >> >> Again, in no case does it make sense to tie it into "how did we boot". >> Because that's just inconvenient for everybody. > > Without taking a stance regarding whether I think that kernel lockdown > makes sense, I think Matthew's point is this: > If you don't have lockdown, secure boot doesn't provide a benefit, > since an attacker could just modify the init binary instead of messing > with your kernel. > If you have secure boot, you want lockdown to prevent chainloading > into a backdoored version of the real OS. I don't think that's the argument here. Secure boot can be used to protect initramfs, since initramfs comes from the secure boot-verified bootloader. That verified initramfs can protect the init binary. As far as I can tell, what's really going on here is that there's a significant contingent here that wants to prevent Linux from chainloading something that isn't Linux. (There doesn't seem to be a real benefit to preventing Linux from chainloading Linux, since the chainloaded Linux is unlikely to let the attacker do much that the original rooted Linux kernel wouldn't have allowed.) In particular, Microsoft, which de facto controls most of the secure boot key ecosystem, doesn't want Windows to be chainloaded without having its signature verified. I admit I'm not quite sure why Microsoft considers this important. They already require a TPM for all new systems, and any important secrets can be sealed by the TPM such that a maliciously chainloaded Windows kernel couldn't access those secrets. But secure boot predates the WHQL TPM requirement if I remember correctly, and I suspect that we're seeing leftover requirements from secure-boot-but-no-TPM era.