[GIT PULL] Kernel lockdown for secure boot

Thu Apr 5 01:28:53 UTC 2018

On Thu, Apr 5, 2018 at 2:26 AM, Matthew Garrett <mjg59 at google.com> wrote:
> On Tue, Apr 3, 2018 at 11:56 PM Peter Dolding <oiaohm at gmail.com> wrote:
>> On Wed, Apr 4, 2018 at 11:13 AM, Matthew Garrett <mjg59 at 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.
>
> They can be modified to set the appropriate bit in the bootparams - the
> reason we can't do that in the UEFI case is that Linux can be built as a
> UEFI binary that the firmware execute directly, and so the firmware has no
> way to set that flag.
>
With some of your embedded hardware boot loaders you have exactly the
same problem.   Where you cannot set bootparams instead have to hard
set everything in the kernel image.  This is why there is a option to
embedded initramfs image inside kernel image because some of them will
only load 1 file.

So not using UEFI  you run into the exact same problem.   So lockdown
on or off need to be a kernel build option setting default.   This
could be 3 options Always on, Always off and "Automatic based on boot
verification system status".

https://linux.die.net/man/8/efibootmgr

Also I have a problem here in non broken UEFI implementations -@ |
--append-binary-args that is very simple set the command line passed
into UEFI binary loaded by the firmware with the Linux kernel this
comes bootparams.   Yes using --append-binary-args can be a pain it is
used to tell the Linux kernel where to find the / drive.   So turning
lockdown off by bootparams is down right possible with working UEFI.
There is a lot of EFI out there that does not work properly.

>> 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.
>
> Which is why Shim allows you to disable validation if you prove physical
> user presence.

Good idea until you have a motherboard where the PS2 ports have failed
and does not support usb keyboard so you have no keyboard until after
the kernel has booted so no way to prove physical presence.   Or are
working on something embedded that has no physical user presence
interface in the boot stages these embedded devices can also be UEFI
with secureboot.  Not everything running UEFI has keyboard,
screen....anything that you can prove physical user presence with
sometimes you have to pure depend on the signing key.

If I am a person who has made my own PK and has my own KEK in UEFI
system I should have the right to sign kernel with lockdown off by
default.   I may need this for diagnostics on hardware without user
interface and I may need this because the hardware is broken and I
have set PK and KEK set by direct firmware  flash access possibly by
jtag or possibly before critical port on motherboard died.

Of course I am not saying that Microsoft and others cannot have rules
that say if using their KEK that you cannot do this.   But if the
machine is my hardware and I have set my own PK and KEK set I do know
what I am doing and I should be allowed to compromise security if I
wish its my hardware.   I should not have to custom hack to do it.
Of course I am not saying that the setting in Linux kernel
configuration system cannot have a big warning that you should not do
this unless you have no other valid option and I am not saying that
the kernel should not log/report if it see what appears to be a
questionable configuration like dmesg "SECURITY ISSUE:  UEFI
secureboot detected enabled kernel built with lockdown disabled system
at risk of comprise".  Something audit tools could check logs for. .

So a kernel booting secureboot with lockdown disabled in kernel
configuration is perfectly fine to log a message that this is the
case.   Always forcing lockdown on because you see UEFI secureboot
will cause issues.

Broken hardware to get around a failed motherboard with UEFI
secureboot locked on you may wish to chain load though a kernel that
you have the means to sign to boot a different OS that is going to be
complex for you to sign due to on going updates.

In my eyes lockdown have a kernel configuration option with 5 options
setting the mode.
1) Automatic: On if a verified boot system is known to the kernel this
may be UEFI secure boot this could be other systems the Linux kernel
can detect in future and off if verified boot is not detected/disabled
or if user approves turning it off by user presence test.,
2) Always on:  That no matter what the Linux kernel turns lockdown on.
No user action or shim action is going to turn it off.
3) On but user/boot bootparams controllable.   So user can give
command line to EFI or other boot-loader to turn it off so no user
presence test and this is need in some cases..
4) Always off:  that is always off no matter what and put error in
dmesg if the Automatic on condition is found.
5) Completely build linux kernel without lockdown code bar with a
single dmesg reporting this.

3-5 all provide security risks all have valid usage reasons.
3 you may want command line controllable you are developing on a
system with user presence cannot be confirmed and you need to be able
to switch between lockdown on and off and you only want to send 1
kernel cross to device in development stages.
4 is simple you have a case where you need lockdown always off line
chain loading on a system where things have gone wrong.
5 can quite simply be diagnostics we have a issue we want to
absolutely confirm that the lockdown code is not the cause.

I can understand if 3-5 are forbin when using Microsoft KEK or other
parties KEKs but those building their own kernels using their own keys
should not have those restrictions it their hardware it thier
configuration if they decide to make it insecure it their choice..

Peter Dolding
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html