From Fedora Project Wiki
m (Clarified several responses)
m (Grammar and formatting)
Line 1: Line 1:
 
<!--Todo:
 
<!--Todo:
Merge and arrange 'long-term' suggestions in a coherent manner-->
+
* Merge and arrange 'long-term' suggestions in a coherent manner-->
  
 
<!-- Self Contained or System Wide Change Proposal?
 
<!-- Self Contained or System Wide Change Proposal?
Line 64: Line 64:
  
 
== 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.
 
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.
  
 
== Benefit to Fedora ==
 
== Benefit to Fedora ==
 
 
<!-- What is the benefit to the distribution?  Will the software we generate be improved? How will the process of creating Fedora releases be improved?
 
<!-- What is the benefit to the distribution?  Will the software we generate be improved? How will the process of creating Fedora releases be improved?
 
    
 
    
Line 115: Line 113:
 
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
 
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
 
This feature will not require a rebuild of any other packages nor of the installer image. If desired, change can be delivered after install as an update.
 
This feature will not require a rebuild of any other packages nor of the installer image. If desired, change can be delivered after install as an update.
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+
* [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->
 
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->
  
Line 128: Line 126:
 
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
Change only adds modules, so existing users should have no problems.
 
Change only adds modules, so existing users should have no problems.
 
  
 
== How To Test ==
 
== How To Test ==
Line 173: Line 170:
  
 
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 192: Line 188:
 
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
Grub-efi-*-modules and grub-tools-* depend on this package, but require no change.
 
Grub-efi-*-modules and grub-tools-* depend on this package, but require no change.
 
  
 
== Contingency Plan ==
 
== Contingency Plan ==
 
 
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If your feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
 
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If your feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
 
* Contingency mechanism: (What to do?  Who will do it?) Revert the shipped configuration  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
* Contingency mechanism: (What to do?  Who will do it?) Revert the shipped configuration  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 210: Line 204:
  
 
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_(GRUB)
 
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_(GRUB)
 
  
 
== Release Notes ==
 
== Release Notes ==

Revision as of 02:39, 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 the EFI build of Grub2.

Owner

Current status

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

Detailed Description

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.

Benefit to Fedora

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

  • 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)

This feature will not require a rebuild of any other packages nor of the installer image. If desired, change can be delivered after install as an update.

  • 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 "initrd*" -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 early-launch code either through verification of signatures or encryption of the boot partition.

Dependencies

Grub-efi-*-modules and grub-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.