From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Garrett Subject: Re: [GIT PULL] Kernel lockdown for secure boot Date: Wed, 04 Apr 2018 16:42:20 +0000 Message-ID: References: <24353.1522848817@warthog.procyon.org.uk> <20180404135251.GD16242@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: luto@kernel.org Cc: tytso@mit.edu, David Howells , Linus Torvalds , Ard Biesheuvel , jmorris@namei.org, Alan Cox , Greg Kroah-Hartman , Linux Kernel Mailing List , jforbes@redhat.com, linux-man@vger.kernel.org, jlee@suse.com, LSM List , linux-api@vger.kernel.org, Kees Cook , linux-efi List-Id: linux-api@vger.kernel.org On Wed, Apr 4, 2018 at 9:39 AM Andy Lutomirski wrote: > On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett wrote: > > If you don't have secure boot then an attacker with root can modify your > > bootloader or kernel, and on next boot lockdown can be silently disabled. > This has been rebutted over and over and over. Secure boot is not the > only verified boot mechanism in the world. Other, better, much more > auditable, and much simpler mechanisms have been around for a long, > long time. Right and if you *know* that you're in that situation then you either turn it on in bootparams from the verified bootloader (which we can't do in UEFI because the *firmware* can be the bootloader thanks to the EFI boot stub) or you enable it from userland later (I can't remember if this version of the patchset provides that functionality, but a previous one did). > > Which is why Shim allows you to disable validation if you prove physical > > user presence. > And that's a giant hack. The actual feature should be that a user > proves physical presence and thus disables lockdown *without* > disabling verification. That's a completely reasonable feature request.