From Fedora Project Wiki
(Fix scope)
(Ready for wrangler)
Line 1: Line 1:
<!--Todo:
 
* Merge and arrange 'long-term' suggestions in a coherent manner
 
* Specify package(s) to be changed-->
 
 
<!-- Self Contained or System Wide Change Proposal?
 
<!-- Self Contained or System Wide Change Proposal?
 
Use this guide to determine to which category your proposed change belongs to.
 
Use this guide to determine to which category your proposed change belongs to.
Line 27: Line 24:
 
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release.  
 
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release.  
 
Note that motivation for the change should be in the Motivation section below, and this part should answer the question "What?" rather than "Why?". -->
 
Note that motivation for the change should be in the Motivation section below, and this part should answer the question "What?" rather than "Why?". -->
Include Grub's "verify," "cryptodisk" and "luks" modules (and if necessary, relevant gcry modules) in the EFI build of Grub2.
+
Include Grub's "verify," "cryptodisk" and "luks" modules (and if necessary, relevant "gcry" modules) in grubx64.efi of the 'grub2-efi-x64' package.
  
 
== Owner ==
 
== Owner ==
Line 35: Line 32:
 
-->
 
-->
 
* Name: [[User:pjones| Peter Jones]]
 
* Name: [[User:pjones| Peter Jones]]
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
+
<!-- Include your email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
 
* Email: pjones@redhat.com
 
* Email: pjones@redhat.com
 
* Name: [[User:javierm| Javier Martinez Canillas]]
 
* Name: [[User:javierm| Javier Martinez Canillas]]
Line 63: Line 60:
 
== Detailed Description ==
 
== Detailed Description ==
 
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
 
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
Long-term, it may be advisable to sign the .mod files in the 'grub-efi-*-modules' package, modify grub2-mkconfig (or -install) to copy the necessary modules into the EFI partition and then allowing inserting of signed modules in secure boot instances.
+
Users utilising secure boot functionality on the UEFI platform cannot insert modules that aren't in grubx64.efi. Paradoxically, this means that security-conscious users cannot use grub's verify module, or employ (near) full disk encryption using cryptodisk and luks.
 +
 
 +
The security benefits of signature verification would reach more users if Fedora automated it by incorporating the process into grub2-mkconfig.
 +
 
 +
For the long-term, to grant flexibility with grub2 modules on secure boot instances, it may be advisable to sign the .mod files in the 'grub2-efi-x64-modules' package, modify grub2-mkconfig (or -install) to copy the necessary modules into the EFI partition when required by the user's configuration and then allow inserting of signed modules in secure boot instances.
  
 
== Benefit to Fedora ==
 
== Benefit to Fedora ==
Line 93: Line 94:
 
     https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
 
     https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
 
-->
 
-->
Users utilising secure boot functionality on the UEFI platform cannot insert modules that aren't in grub*.efi. Paradoxically, this means that security-conscious users cannot use grub's verify module, or employ (near) full disk encryption using cryptodisk and luks.
+
This change will allow users to gain trust in the integrity of early-launch code either through verification of signatures (particularly useful for initramfs, which is particularly vulnerable to possible offline modification) or encryption of the boot partition.
 
 
This change will allow users to gain trust in the integrity of early-launch code either through verification of signatures (particularly useful for initramfs, which is particularly vulnerable to possibly offline modification) or encryption of the boot partition.
 
 
 
Perhaps long-term, Fedora can use the verify module to automatically provide detached signature-based verification of the boot files.
 
  
 
== Scope ==
 
== Scope ==
Line 142: Line 139:
 
1. Generate a signing key with "gpg --gen-key" and copy it to the EFI partition
 
1. Generate a signing key with "gpg --gen-key" and copy it to the EFI partition
  
2. Add "trust <gpg key>" (but grub may inherit this from shim's MOK) and "set check_signatures=enforce" to /etc/default/40_custom.
+
2. Add "trust <gpg key>" (but grub may inherit this from shim's MOK) and "set check_signatures=enforce" to /etc/default/40_custom
  
 
3. Run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
 
3. Run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
  
4. Create a file, /tmp/pass, with the key's passphrase, then execute: for x in $(find /boot -name "*.cfg" -or -name "*.mod" -or -name "vmlinuz*" -or -name "initramfs*" -or -name "grubenv"); do gpg --batch --detach-sign --passphrase-fd 0 $x < /tmp/pass; done. Then, shred /tmp/pass.
+
4. Create a file, /tmp/pass, with the key's passphrase, then execute: for x in $(find /boot -name "*.cfg" -or -name "*.mod" -or -name "vmlinuz*" -or -name "initramfs*" -or -name "grubenv"); do gpg --batch --detach-sign --passphrase-fd 0 $x < /tmp/pass; done. Then, shred /tmp/pass
  
5. Reboot. If system starts, change is successful.
+
5. Reboot. If system starts, change is successful
  
  
Line 165: Line 162:
 
6. Run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
 
6. Run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
  
7. Reboot. Grub should ask for the password created in step 2. If system then starts, change is successful. (If filesystem root is also encrypted, user may be asked for a password twice. This can be mitigated with a keyfile for filesystem root, or use of the clevis package, and likely, a tpm)
+
7. Reboot. Grub should ask for the password created in step 2. If system then starts, change is successful
 +
 
 +
(If filesystem root is also encrypted, user may be asked for a password twice. This can be mitigated with a keyfile for filesystem root, or use of the clevis package, and likely, a tpm.)
  
 
== User Experience ==
 
== User Experience ==
Line 178: Line 177:
 
  - Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora users being the most relaxed users of any operating system.
 
  - Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora users being the most relaxed users of any operating system.
 
-->
 
-->
Users may optionally elect to verify the integrity of early-launch code either through verification of signatures or encryption of the boot partition.
+
Users may optionally elect to verify the integrity of boot code either through verification of digital signatures or encryption of the boot partition.
  
 
== Dependencies ==
 
== Dependencies ==
 
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->
 
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->
 
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Grub-efi-*-modules and grub-tools-* depend on this package, but require no change.
+
Grub2-efi-x64-modules and grub2-tools-* depend on this package, but require no change.
  
 
== Contingency Plan ==
 
== Contingency Plan ==
Line 209: Line 208:
 
Fedora now supports Grub's detached verify and cryptodisk functionality natively, even on secure boot systems.
 
Fedora now supports Grub's detached verify and cryptodisk functionality natively, even on secure boot systems.
  
[[Category:ChangePageIncomplete]]
+
[[Category:ChangeReadyForWrangler]]
 
<!-- When your change proposal page is completed and ready for review and announcement -->
 
<!-- When your change proposal page is completed and ready for review and announcement -->
 
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
 
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->

Revision as of 05:53, 25 March 2019

Include several modules in the EFI build of Grub2 for security use-cases

Summary

Include Grub's "verify," "cryptodisk" and "luks" modules (and if necessary, relevant "gcry" modules) in grubx64.efi of the 'grub2-efi-x64' package.

Owner

Current status

  • Targeted release: Fedora 31
  • Last updated: 2019-03-25
  • Tracker bug: <will be assigned by the Wrangler>

Detailed Description

Users utilising secure boot functionality on the UEFI platform cannot insert modules that aren't in grubx64.efi. Paradoxically, this means that security-conscious users cannot use grub's verify module, or employ (near) full disk encryption using cryptodisk and luks.

The security benefits of signature verification would reach more users if Fedora automated it by incorporating the process into grub2-mkconfig.

For the long-term, to grant flexibility with grub2 modules on secure boot instances, it may be advisable to sign the .mod files in the 'grub2-efi-x64-modules' package, modify grub2-mkconfig (or -install) to copy the necessary modules into the EFI partition when required by the user's configuration and then allow inserting of signed modules in secure boot instances.

Benefit to Fedora

This change will allow users to gain trust in the integrity of early-launch code either through verification of signatures (particularly useful for initramfs, which is particularly vulnerable to possible offline modification) or encryption of the boot partition.

Scope

  • Proposal owners: Modify grub.macros file to include the above-mentioned modules in the GRUB_MODULES variable.
  • Other developers: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

Change only adds modules, so existing users should have no problems.

How To Test

For "verify":

1. Generate a signing key with "gpg --gen-key" and copy it to the EFI partition

2. Add "trust <gpg key>" (but grub may inherit this from shim's MOK) and "set check_signatures=enforce" to /etc/default/40_custom

3. Run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

4. Create a file, /tmp/pass, with the key's passphrase, then execute: for x in $(find /boot -name "*.cfg" -or -name "*.mod" -or -name "vmlinuz*" -or -name "initramfs*" -or -name "grubenv"); do gpg --batch --detach-sign --passphrase-fd 0 $x < /tmp/pass; done. Then, shred /tmp/pass

5. Reboot. If system starts, change is successful


For cryptography modules:

1. Backup boot partition

2. Run cryptsetup luksFormat <boot partition's block device, for example, /dev/sda2> --type luks1

3. Open luks container and restore backup

4. Add GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub

5. Confirm that /etc/fstab has the correct UUID for /boot

6. Run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

7. Reboot. Grub should ask for the password created in step 2. If system then starts, change is successful

(If filesystem root is also encrypted, user may be asked for a password twice. This can be mitigated with a keyfile for filesystem root, or use of the clevis package, and likely, a tpm.)

User Experience

Users may optionally elect to verify the integrity of boot code either through verification of digital signatures or encryption of the boot partition.

Dependencies

Grub2-efi-x64-modules and grub2-tools-* depend on this package, but require no change.

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) Revert the shipped configuration
  • Contingency deadline: Beta freeze
  • Blocks release? N/A (not a System Wide Change)
  • Blocks product? No

Documentation

https://www.gnu.org/software/grub/manual/grub/html_node/Using-digital-signatures.html

https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_(GRUB)

Release Notes

Fedora now supports Grub's detached verify and cryptodisk functionality natively, even on secure boot systems.