[Bug 1401532] Re: GRUB's Secure Boot implementation loads unsigned kernel without warning

[Mathieu Trudel-Lapierre]

Indeed, at this moment GRUB is explicitly trying to verify kernels, but
will also silently fallback to ignoring failed verification so that
users can still boot their systems. Note that this is the case for a few
reasons, among which that ensuring a full trust chain is hard when one
also has to load modules that are locally built (we can't ship our
signing key on all systems, it would defeat the purpose).

Fixing this is the target of spec foundations-x-installing-unsigned-
secureboot.

Some basic considerations:
 - fixing grub to not silently ignore validation results
 - provide some way for users to disable validation in shim (MokSB) when they need to use custom drivers or kernels
 - ship mokutil by default so a tool is there to toggle validation

And as later steps:
 - replace disabling validation (MokSB) with allowing users to enroll their own keys from the installer, where we can helpfully walk them through the key generation and enrollment.

We're probably only looking at toggling validation for 16.04.

The net effect of properly relying on shim's validation of the
signatures from grub will be to automatically show a "Booting in
insecure mode" message when validation is disabled, but SecureBoot is
enabled. If SecureBoot is disabled, validation would succeed anyway in
both the signed kernels and unsigned kernels.

For more information, I'd refer you to the blueprint or to the source
code for shim (https://github.com/rhinstaller/shim), or contact me
(cyphermox) on IRC in #ubuntu-installer.

** Changed in: grub2-signed (Ubuntu)
       Status: Triaged => In Progress

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

Title:
  GRUB's Secure Boot implementation loads unsigned kernel without
  warning

Status in grub2 package in Ubuntu:
  In Progress

Bug description:
  Me and some other students have conducted some various experiments on
  Secure Boot enabled machines. The main focus of the tests was to
  circumvent Secure Boot and load unsigned kernels or kernels that have
  been signed with other keys.

  On your SecureBoot (https://wiki.ubuntu.com/SecurityTeam/SecureBoot)
  it is outlined that GRUB will boot unsigned kernels when the kernel is
  unsigned. During one of our experiments it seemed that this statement
  was true and that GRUB loads unsigned kernels as described on your
  page. We understand that for various reasons GRUB should still support
  the use-case when an unsigned kernel must be loaded, but with the
  current approach the user isn't aware if there is a whole chain of
  trust. For example, it could still be possible to load some malware
  before it boots the Operating System itself (bootkits). One of the
  many reasons that Secure Boot has been developed is to protect the
  user from these kind of attacks.

  With the current approach the purpose of Secure Boot is somewhat
  defeated, and the user doesn't know if the whole chain has been
  verified or not. It could easily be the case that an unsigned kernel
  has been loaded by Ubuntu without the user noticing. From our point of
  view, a better approach would be to inform the user that an unsigned
  kernel will be loaded and that the user can make a choice if he/she
  wants to proceed. The default action could be to accept the option,
  remember the user's option and sometimes remember the user of the fact
  that it is loading an unsigned kernel.

  This problem is of course related to GRUB itself and not to Ubuntu
  itself. The reason for filing this bug and informing the SecurityTeam
  of Ubuntu is to ask for their opinions and what your point of view is
  on the current approach and to see if other users classify this as a
  "bug".

  GRUB2 versions: grub-2.02~beta2, 1.34.1+2.02~beta2-9ubuntu1
  Ubuntu version: Trusty (will also affect newer and older versions, GRUB specific problem)

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