[Bug 1890672] Re: secure boot fails after upgrade to grub2-common 2.04-1ubuntu26.2

Fri Aug 7 14:36:06 UTC 2020

I'm the author of that secure boot package.
I think you might misunderstand... what it does is put all the grub config etc into a signed initramfs. So you cannot change the grub.cfg.
Also, to sign the binaries you need the GPG keyring and the passphrase.

The objective is to *not* use the shipped trusted microsoft key. The
only key in the UEFI keystore is our own chain of trust. So The goal is
to *not* use shim.

It is used in conjunction w/ full disk encryption. The only file
unencrypted is a single grub w/ the ininitramfs, and that is in turn
signed. The kernel, etc, are all on the encrypted disk. Thus they cannot
be tampered with by e.g. removing the disk etc.

Installing shim means adding someone else trust, which I don't accept.

I'm not sure what "don't support secure boot without shim" means, but I
don't think that can or should be true. It doesn't support booting the
Microsoft signed keys w/o shim, but, its certainly legal to remove the
Microsoft keys from the BIOS and still use secureboot.

as for the check_signatures=no, I'm ok if that is removed as a feature I guess, but it would need to be removed from the documentation. In my case its not a reduction in security (since you cannot change the grub.cfg w/o having the trust chain anyway).

so tldr:
* no, shim is not required to support secureboot
* yes, you can self sign securely
* no, merely having an option in grub.cfg or grub cmdline to disable subsequent checks need not reduce the security, as long as it is gated by being in a signed initramfs (and grub password is as strong as bios password)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1890672

Title:
  secure boot fails after upgrade to grub2-common 2.04-1ubuntu26.2

Status in grub2 package in Ubuntu:
  Invalid

Bug description:
  I've been using https://github.com/donbowman/ubuntu-secure-boot on my
  18.04 system for secure boot for just over two years. It worked quite
  well. This morning I did a dist-upgrade. Upon reboot, the system
  complained that my kernel wasn't signed (something along the lines of
  "$KERNEL has invalid signature.").

  I was fairly sure my kernel was signed, and signed properly, so I was
  somewhat confused. In the past, when I had messed this up, I was able
  to use `set check_signatures=no` to get the system to boot into the
  OS. This no longer worked; it is as though that flag is now being
  ignored. I had to disable secure boot in the bios to proceed and debug
  the problem.

  I upgraded to 20.04 in the hopes that that would fix my problem. I had
  no success there either.

  Searching around, I found this patch, which exists in a grub2 version
  published recently in both 18.04 and 20.04:

  +  [ Dimitri John Ledkov ]
  +  * SECURITY UPDATE: Grub does not enforce kernel signature validation
  +    when the shim protocol isn't present.
  +    - 0097-linuxefi-fail-kernel-validation-without-shim-protoco.patch:
  +      Fail kernel validation if the shim protocol isn't available
  +    - CVE-2020-15705

  ...

  diff -Nru grub2-2.04/debian/patches/0097-linuxefi-fail-kernel-validation-without-shim-protoco.patch grub2-2.04/debian/patches/0097-linuxefi-fail-kernel-validation-without-shim-protoco.patch
  --- grub2-2.04/debian/patches/0097-linuxefi-fail-kernel-validation-without-shim-protoco.patch	1970-01-01 00:00:00.000000000 +0000
  +++ grub2-2.04/debian/patches/0097-linuxefi-fail-kernel-validation-without-shim-protoco.patch	2020-07-20 18:19:08.000000000 +0000
  @@ -0,0 +1,90 @@
  +From 67508ab68e6a5be869e049a0e6474f4b717d3ab9 Mon Sep 17 00:00:00 2001
  +From: Dimitri John Ledkov <xnox at ubuntu.com>
  +Date: Wed, 22 Jul 2020 11:31:43 +0100
  +Subject: linuxefi: fail kernel validation without shim protocol.
  +
  +If certificates that signed grub are installed into db, grub can be
  +booted directly. It will then boot any kernel without signature
  +validation. The booted kernel will think it was booted in secureboot
  +mode and will implement lockdown, yet it could have been tampered.
  +
  +CVE-2020-15705
  +
  +Reported-by: Mathieu Trudel-Lapierre <cyphermox at ubuntu.com>
  +Signed-off-by: Dimitri John Ledkov <xnox at ubuntu.com>
  +---

  <Main contents omitted>

  See the following for the full diff http://launchpadlibrarian.net/490699204/grub2_2.04-1ubuntu26_2.04-1ubuntu26.1.diff.gz

  The same can be seen in 18.04:
  http://launchpadlibrarian.net/490699210/grub2_2.02-2ubuntu8.15_2.02-2ubuntu8.16.diff.gz

  I downgraded my grub to the version prior to this change (2.04-1ubuntu26) and I can now boot using secure boot.

  Given that the patch I pasted above logs the same error I was seeing,
  and given that the change in 2.04-1ubuntu26.2 (the most recent) only
  touches the post install, I'm fairly confident in saying that the
  patch I pasted introduced my problem.

  Now, perhaps there is a problem with how the secure boot package I am
  using working. I'd love to know what we should be doing differently if
  so. However, given the check_signatures=no isn't working any more, and
  it is in the official grub documentation
  (https://www.gnu.org/software/grub/manual/grub/html_node/check_005fsignatures.html)
  I think there's at least one bug here.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: grub2 (not installed)
  ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44
  Uname: Linux 5.4.0-42-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.6
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Aug  6 15:55:17 2020
  InstallationDate: Installed on 2018-05-10 (818 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  SourcePackage: grub2
  UpgradeStatus: Upgraded to focal on 2020-08-06 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1890672/+subscriptions