From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F121DFBC for ; Wed, 5 Sep 2018 21:01:15 +0000 (UTC) Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ADC158B for ; Wed, 5 Sep 2018 21:01:14 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id s14-v6so108115wrw.6 for ; Wed, 05 Sep 2018 14:01:14 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <17533.1536166384@warthog.procyon.org.uk> <32341.1536178494@warthog.procyon.org.uk> From: Justin Forbes Date: Wed, 5 Sep 2018 16:01:12 -0500 Message-ID: To: Andy Lutomirski Content-Type: text/plain; charset="UTF-8" Cc: James Bottomley , Peter Jones , joeyli.kernel@gmail.com, ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, Sep 5, 2018 at 3:53 PM, Andy Lutomirski wrote: > On Wed, Sep 5, 2018 at 1:34 PM, Justin Forbes wrote: >> On Wed, Sep 5, 2018 at 3:14 PM, David Howells wrote: >>> Justin Forbes wrote: >>> >>>> Lockdown is a config option on it's own, just also add a separate >>>> config option option to enable lockdown on UEFI secure boot. >>> >>> The patchset has that already (CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT). >>> >>> One of the issues appears to be that we're making it boot-time conditional at >>> all. If I understand him correctly, Linus seems to want us to make everything >>> locked down at compile time or not at all. >>> >> >> The last push attempt dropped that patch and did have the compile time >> (CONFIG_LOCK_DOWN_MANDATORY) as well as an option for command line >> enabling with lockdown=1 (CONFIG_LOCK_DOWN_KERNEL). It just didn't >> have an option for triggering off of UEFI Secure Boot. As a distro, >> running CONFIG_LOCK_DOWN_MANDATORY isn't much of an option. We ran >> the 4.17 development series in rawhide with CONFIG_LOCK_DOWN_KERNEL, >> and no one noticed that their secure boot was off. This is why it is >> somewhat frightening to change the behavior, users assume it is all >> working because things boot, and never notice they are missing some >> protection that they assumed was there. Before we rebased stable >> distros I reworked the CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT to work >> with the current patch set and that is what we are carrying now. >> While I would love to see everything pushed as a whole, I would still >> be much happier than I am now if everything else pushed and we only >> had to carry the patch to trigger off of UEFI status. It is a minor >> detail that shouldn't be blocking the entire patch set at this point. >> If Linus agrees that it can be pushed with CONFIG_LOCK_DOWN_MANDATORY >> as the only option, that is fine. Still much less out of tree for us >> to worry about. > > I'm not really convinced this needs a whole tech topic. I send an > email awhile back, but didn't hear back, so here goes roughly again: > > As far as I can tell, there are two issues blocking lockdown, both of > which should be relatively easily resolvable: > > 1. When exactly is lockdown enabled? > > 2. What exactly does lockdown do? > > #1 is clearly resolvable. Worst case, a bare minimum version can get > merged where, for example, lockdown is either mandatory or is enabled > by boot option. Distros can carry a patch for alternative policies > for a little while until the dust settles. > > #2 is a bigger deal. At least one version that shipped in a Fedora > kernel actually broke systemd, and that's not cool. And I really > think we need to make lockdown non-binary to get this right. I've > proposed LOCKDOWN_PROTECT_INTEGRITY (i.e. try to prevent root from > modifying the running kernel) and LOCKDOWN_PROTECT_SECRECY (try to > prevent root from reading kernel memory), and no one seems to have > actually objected. > The Fedora issue was the bpf hammer. I am looking to find a better solution for that one, but dropped the patch in the meantime. It was removed shortly after it was found. This is one of the many reasons I don't like all or nothing at compile time, but again, we can carry the patch to toggle separately until a better solution is worked out. > So I would propose the following. Someone (me? David?) prepares a > very stripped down lockdown patchset. It adds the basic config > options for CONFIG_LOCK_DOWN_KERNEL and whatever compile-time > mandatory variants we want, and it adds the helpers so various > subsystems can ask whether lockdown is on. And it adds one single > lockdown user in the kernel. And we merge that. Then we add > additional lockdown users one at a time. > I would be fine with this, I just want some sort of path forward. > This will resolve what I see as the major issue that has blocked > lockdown: the patchset is too big and spans too many subsystems. > Every time it's submitted it gets bogged down in important but > distracting discussions like "what, exactly, should the following bpf > feature do in lockdown mode?". These matter, but there is no > legitimate reason for them to block the overall feature -- it's > entirely fine if the initial version of lockdown doesn't protect bpf > at all. > > --Andy > > [There's only a ~30% change I can make LPC this year...] If you can make it, I will certainly be there and would be happy to discuss moving this forward.