group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1401532@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package grub2 - 2.02-2ubuntu1

---------------
grub2 (2.02-2ubuntu1) bionic; urgency=medium

  * Merge with Debian; remaining changes:
    - debian/patches/support_initrd-less_boot.patch: Added knobs to allow
      non-initrd boot config. (LP: #1640878)
    - Disable os-prober for ppc64el on the PowerNV platform, to reduce the
      number of entries/clutter from other OSes in Petitboot (LP: #1447500)
    - debian/build-efi-images: provide a new grub EFI image which enforces that
      loaded kernels are signed for Secure Boot: build gsb$arch.efi; which is
      the same as grub$arch.efi minus the 'linux' module. Without fallback to
      'linux' for unsigned loading, this makes it effectively enforce having a
      signed kernel. (LP: #1401532)
    - debian/patches/install_signed.patch, grub-install-extra-removable.patch:
      - Make sure if we install shim; it should also be exported as the default
        bootloader to install later to a removable path, if we do.
      - Rework grub-install-extra-removable.patch to reverse its logic: in the
        default case, install the bootloader to /EFI/BOOT, unless we're trying
        to install on a removable device, or explicitly telling grub *not* to
        do it.
      - Move installing fb$arch.efi to --no-extra-removable; as we don't want
        fallback to be installed unless we're also installing to /EFI/BOOT.
        (LP: #1684341)
      - Make sure postinst and templates know about the replacement of
        --force-extra-removable with --no-extra-removable.
  * Sync Secure Boot support patches with the upstream patch set from
    rhboot/grub2:master-sb. Renamed some patches and updated descriptions for
    the whole thing to make more sense, too:
    - dropped debian/patches/linuxefi_require_shim.patch
    - renamed: debian/patches/no_insmod_on_sb.patch ->
      debian/patches/linuxefi_no_insmod_on_sb.patch
    - debian/patches/linuxefi.patch
    - debian/patches/linuxefi_debug.patch
    - debian/patches/linuxefi_non_sb_fallback.patch
    - debian/patches/linuxefi_add_sb_to_efi_chainload.patch
    - debian/patches/linuxefi_cleanup_errors_in_loader.patch
    - debian/patches/linuxefi_fix_efi_validation_race.patch
    - debian/patches/linuxefi_handle_multiarch_boot.patch
    - debian/patches/linuxefi_honor_sb_mode.patch
    - debian/patches/linuxefi_move_fdt_helper.patch
    - debian/patches/linuxefi_load_arm_with_sb.patch
    - debian/patches/linuxefi_minor_cleanups.patch
    - debian/patches/linuxefi_re-enable_linux_cmd.patch
    - debian/patches/linuxefi_rework_linux16_cmd.patch
    - debian/patches/linuxefi_rework_linux_cmd.patch
    - debian/patches/linuxefi_rework_non-sb_efi_chainload.patch
    - debian/patches/linuxefi_rework_pe_loading.patch
    - debian/patches/linuxefi_use_dev_chainloader_target.patch
  * debian/patches/dont-fail-efi-warnings.patch: handle linuxefi patches and
    the casting they do on some architectures: we don't want to fail build
    because of some of the warnings that can show up since we otherwise build
    with -Werror.

grub2 (2.02-3) UNRELEASED; urgency=medium

  * Use current location for upstream signing key
    (debian/upstream/signing-key.asc).
  * Update upstream signing key to a non-expired version.

  [ Debconf translations ]
  * [sq] Albanian (Silva Arapi; closes: #874497).

grub2 (2.02-2) unstable; urgency=medium

  * Comment out debian/watch lines for betas and pre-releases for now.
  * Cherry-pick upstream patch to allow mounting ext2/3/4 file systems that
    have the 'encrypt' feature enabled (closes: #840204).

grub2 (2.02-1) unstable; urgency=medium

  * New upstream release.
    - xen: Fix wrong register in relocator (closes: #799480).
  * Resolve symlinks for supported init paths as well as for /sbin/init
    (thanks, Felipe Sateler; closes: #842315).

  [ Debconf translations ]
  * [sr] Serbian (Karolina Kalic; closes: #691288).
  * [sr@latin] Serbian Latin (Karolina Kalic; closes: #691289).
  * [pt] Portuguese (Rui Branco - DebianPT; closes: #864171).

grub2 (2.02~beta3-5) unstable; urgency=medium

  [ Steve McIntyre ]
  * Make grub-install check for errors from efibootmgr (closes: #853234).
    There are probably still underlying issues in other similar reported
    bugs, but they're more effectively tracked elsewhere (e.g. efibootmgr)
    at this point (closes: #756253, #852513).

  [ Debconf translations ]
  * [ug] Uyghur (Abduqadir Abliz).
  * [es] Spanish (Manuel "Venturi" Porras Peralta; closes: #852977).

 -- Mathieu Trudel-Lapierre <cyphermox@xxxxxxxxxx>  Mon, 06 Nov 2017
15:37:12 -0500

** Changed in: grub2 (Ubuntu)
       Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1401532

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

Status in grub2 package in Ubuntu:
  Fix Released
Status in grub2-signed package in Ubuntu:
  Triaged
Status in grub2 source package in Trusty:
  Confirmed
Status in grub2-signed source package in Trusty:
  Confirmed
Status in grub2 source package in Xenial:
  Confirmed
Status in grub2-signed source package in Xenial:
  Confirmed
Status in grub2 source package in Yakkety:
  Confirmed
Status in grub2-signed source package in Yakkety:
  Confirmed
Status in grub2 source package in Zesty:
  Triaged
Status in grub2-signed source package in Zesty:
  Triaged

Bug description:
  [Rationale]
  GRUB should help us enforce that in UEFI mode, only signed kernels are loaded. It should not silently fall back to loading unsigned kernels.

  [Impact]
  All our users booting in UEFI; on all supported releases.

  [Test cases]

  = grub2 =

  Booting unsigned kernels:
  1) Try to boot a custom kernel
  2) Verify that the kernel will not be loaded by grub (you should see an error message about the signature)

  Booting signed kernels:
  1) Try to boot an official signed kernel (from -release or -updates)
  2) Verify that the system boots normally and no warnings are shown about signature.

  
  [Regression Potential]
  Any failure to boot presenting as a failure to load the kernel from within grub, with an "invalid signature" type error message or not, should be investigated as a potential regression of this stable update.

  ---

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