Re: [GIT PULL] Kernel lockdown for secure boot
From: Justin Forbes
Date: Wed Apr 04 2018 - 12:46:38 EST
On Wed, Apr 4, 2018 at 11:39 AM, Andy Lutomirski <luto@xxxxxxxxxx> wrote:
> On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett <mjg59@xxxxxxxxxx> wrote:
>> On Wed, Apr 4, 2018 at 6:52 AM Theodore Y. Ts'o <tytso@xxxxxxx> wrote:
>>> On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote:
>>> > Theodore Y. Ts'o <tytso@xxxxxxx> wrote:
>>> > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why
>>> > > isn't this a problem for people who are fearful that Linux could be
>>> > > used as part of a Windows boot virus in a Secure UEFI context?
>>> > Lockdown mode restricts kexec to booting an authorised image (where the
>>> > authorisation may be by signature or by IMA).
>>> If that's true, then Matthew's assertion that lockdown w/o secure boot
>>> is insecure goes away, no?
>> 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.
That is certainly the case, and one of the main reasons for the
secureboot patchset being split out and lockdown taking a different
name. The problem is, right now, secure boot is the only thing using
lockdown. I certainly wouldn't go through any effort to tie into it
with any other mechanism knowing that this patch set has been delayed
upstream for years. I would hope and expect that once lockdown is in
mainline, other verified boot mechanisms would leverage it as well.
>>> The fact that this Verified Boot on, lockdown off causes trouble
>>> points to a clear problem. User owns the hardware they should have
>>> the right to defeat secureboot if they wish to.
>> 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.