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

Fri Aug 7 15:29:16 UTC 2020

> 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.

I think grub's name for that is not initramfs, but something different?
Anyway:

I suggest you look at my secureboot project, you'll see I understand
what you're trying to achieve - I did the same thing with systemd-boot.

Now - this is a _very special_ use case, and not what secure boot is
designed for (it was designed against systems installing rootkits, not
local users fiddling with your FDE). I think shim even allowed you to
boot unsigned stuff by pressing a key at some point, because local users
are trusted.

Optimally, what you want to do on new kernels and stuff is to take them
to a separate offline machine with the key, sign them and transfer them
back to reduce the rootkit risk.

The repository makes no mention of that special use case, potentially
causing people to install it who do not have FDE or do not need the
additional properties of signed early userspace. It only says "Ubuntu is
not checking signatures at all, this does", and that's not helpful. If
users come along and install it, thinking they make their system more
secure, and don't know the tradeoff they make, that's bad.

> I'm not sure what "don't support secure boot without shim" means

You forgot the "we". Shim is part of our secure boot process, and we do
not test or work on or support booting without it.

-- 
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:
  Confirmed

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