- 1 Include several modules in the EFI build of Grub2 for security use-cases
Include several modules in the EFI build of Grub2 for security use-cases
Include Grub's "verify," "cryptodisk" and "luks" modules (and if necessary, relevant "gcry" modules) in grubx64.efi of the 'grub2-efi-x64' package.
- Name: Peter Jones
- Email: email@example.com
- Name: Javier Martinez Canillas
- Email: firstname.lastname@example.org
- Release notes owner:
- Targeted release: Fedora 31
- Last updated: 2019-03-25
- Tracker bug: <will be assigned by the Wrangler>
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.
- 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)
- Release engineering: #Releng issue number (a check of an impact with Release Engineering is needed)
- List of deliverables: 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)
Change only adds modules, so existing users should have no problems.
How To Test
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.)
Users may optionally elect to verify the integrity of boot code either through verification of digital signatures or encryption of the boot partition.
Grub2-efi-x64-modules and grub2-tools-* depend on this package, but require no change.
- 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
Fedora now supports Grub's detached verify and cryptodisk functionality natively, even on secure boot systems.