lkml.org 
[lkml]   [2018]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [GIT PULL] Kernel lockdown for secure boot
    .

    On Wed, Apr 4, 2018 at 11:13 AM, Matthew Garrett <mjg59@google.com> wrote:

    > There are four cases:
    >
    > Verified Boot off, lockdown off: Status quo in distro and mainline kernels
    > Verified Boot off, lockdown on: Perception of security improvement that's
    > trivially circumvented (and so bad)
    > Verified Boot on, lockdown off: Perception of security improvement that's
    > trivially circumvented (and so bad), status quo in mainline kernels
    > Verified Boot on, lockdown on: Security improvement, status quo in distro
    > kernels
    >
    > Of these four options, only two make sense. The most common implementation
    > of Verified Boot on x86 platforms is UEFI Secure Boot,

    Stop right there. Verified boot does not have to be UEFI secureboot.
    You could be using a uboot verified boot or
    https://www.coreboot.org/git-docs/Intel/vboot.html google vboot.
    Neither of these provide flags to kernel to say they have been
    performed.

    So Verified boot looking off to kernel yet lockdown needing to be on
    is one very valid combination and must be supported because the Linux
    kernel does not always know when it verified boot environment. When
    the Linux kernel thinks verified boot is off it may not be trivial to
    circumvent.

    Now Verified Boot on, lockdown off. Insanely this can be required in
    diagnostic on some embedded platform because EFI secureboot does not
    have a off switch. These are platforms where they don't boot if
    they don't have a PK and KEK set installed. Yes some of these is jtag
    the PK and KEK set in.

    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.

    In fact the issue that you can not install a KEK per operating system
    installed shows a problem as well.

    So all OS use the same KEK for their installers and then you have all
    non Microsoft in a lot of cases the same KEK for booting OS. Any of
    these bootloaders/kernels with defect will end up with the security
    being exactly like Verified Boot on, lockdown off. Remember attackers
    will send around copies of what ever they need to so they can breach a
    system so they find a defective solution some where they will ship it
    everywhere. Attackers that secureboot is attempted to prevent are
    criminal anyhow what is a little bit of copyright violation to them..
    So when the current UEFI design is security theatre there should not
    be any special effort to support it.

    If UEFI was not security theatre there would be a clean way for people
    install and setup up their systems to list what operating system KEK
    should be accepted so allowing attack surface area to be minimised and
    the damaged form any flawed implementation to also be limited. This
    way end users could opt in or out of operating systems based on
    security. If user has opted out of all operating systems doing
    Verified Boot on, lockdown off: those are not a threat. Also any OS
    with defective kernel or bootloader that the system has not allowed
    the KEK of would also not be a threat.

    Really I see no reason to be bending over in the Linux kernel for UEFI
    secureboot. You list all 4 types need to exist for different usage
    case of the Linux kernel. The fact UEFI secureboot currently is
    implemented on x86 does not handle the fact all 4 use cases need to
    exist is really a issue with UEFI Secureboot that needs to be fixed by
    those designing UEFI for the future.

    Allowing the kernel to be configured the 4 different ways does not
    mean a party like Microsoft has to sign off on everything the Linux
    kernel can do. Its not like android/IOT vendors have to bow to
    Microsoft.

    The Linux kernel should not show favouritism. This does mean that
    all 4 modes should be in the kernel configuration options.

    Matthew Garrett your mistake is that only 2 are valid when all 4 are
    valid in different usage cases. Circumventing security is sometimes
    required accepting that case is hard for some people. Of course
    when a party need perform circumventing security the fact that it
    currently gives out the keys to world of UEFI systems is a very big
    security design flaw in UEFI.

    Why should the Linux kernel contain code to work around defective
    design of UEFI and limit what users not using UEFI and using UEFI can
    do?

    Peter Dolding

    \
     
     \ /
      Last update: 2018-04-04 08:57    [W:2.267 / U:0.144 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site