https://fedoraproject.org/wiki/Changes/Include_security_modules_in_efi_Grub2 == Summary == Include Grub's "verify," "cryptodisk" and "luks" modules in grubx64.efi of the 'grub2-efi-x64' package. Note: Although the build process will automatically include explicit dependencies ("mpi," "gcry_sha1," "procfs" and "archelp"), the following implicit ones must also be included: "gcry_sha256," "gcry_rsa," "gcry_rijndael," "gcry_serpent," gcry_twofish" and "gcry_whirlpool" == Owner == * Name: [[User:benjamind|Benjamin Doron]] * Email: benjamin.doron00@xxxxxxxxx * Name: [[User:pjones|Peter Jones]] * Email: pjones@xxxxxxxxxx * Name: [[User:javierm|Javier Martinez Canillas]] * Email: fmartine@xxxxxxxxxx == Detailed Description == Users utilising secure boot functionality on the UEFI platform cannot insert grub modules. Paradoxically, this means that security-conscious users cannot use grub's verify module for signature verification, 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`. Similarly, it would be easier to use cryptodisk functionality if it were configurable by anaconda. This can be considered for future releases, after allowing time to straighten out the details of the implementation and analyse the benefits/costs. For the long-term, to grant flexibility with grub2 modules on secure boot instances in general, it may be advisable to consider signing the .mod files in the 'grub2-efi-x64-modules' package, allow inserting of signed modules in secure boot instances and then modify `grub2-mkconfig` to copy the necessary modules into the EFI partition when required by the user's configuration. == 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 the 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 == <b>Disclaimer: Commands assume that tester is root. Secure Boot must be disabled for testing purposes (`insmod` is forbidden under Secure Boot, for now. The description details a tentative plan to get us to a place where that can be changed). Ensure that the package 'grub2-efi-x64-modules' is installed, and for testing purposes, copy the contents to the EFI partition with `cp -r /usr/lib/grub/x86_64-efi/ /boot/efi/EFI/fedora/`</b> <b>For "verify":</b> 1. Generate an RSA signing key with `gpg --full-generate-key` (option 4), then export it with `gpg --export > pubkey` and move it to the EFI partition with `mv pubkey /boot/efi/EFI/fedora`. You can also export the private key (`gpg --export-secret-keys > seckey`), but the signing process doesn't require it as gpg will get the key from its own directory. 2. Add "insmod verify," "insmod gcry_sha256," "insmod gcry_rsa," "trust (hd0,gpt1)/efi/fedora/pubkey" (change this based on your environment) and "set check_signatures=enforce" to /etc/grub.d/40_custom 3. Run `grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg` 4. Run `export GPG_TTY=$(tty)`. Don't ask, apparently something changed in gpg with a recent update. 4. Create a file, /dev/shm/pass, with the key's password and execute: `for x in $(find /boot -name "*.cfg" -or -name "*.lst" -or -name "*.mod" -or -name "vmlinuz*" -or -name "initramfs*" -or -name "grubenv"); do gpg --batch --pinentry-mode loopback --detach-sign --passphrase-fd 0 $x < /dev/shm/pass; done`. Then, `shred /dev/shm/pass` 5. Reboot. If the system starts, backup and remove .sig files. If the system does not start this time, change is successful (To recover from a now non-booting system, open the grub terminal and execute `set check_signatures=no`. The system should then boot, and .sig files can be replaced or regenerated.) <b>For cryptodisk functionality:</b> 1. Backup the files in your boot partition 2. Run `cryptsetup luksFormat /dev/sda2 --type luks1` (change this based on your environment to /boot's block device) Note: If filesystem root is also encrypted, it is recommended that the same password be used for boot as for root to decrease the amount of engagement required at start-up. Consider using --iter-time with low time in milliseconds (default is 2000ms) 3. Open luks container with `cryptsetup luksOpen /dev/sda2 --type luks1 crypt_boot` (change this to match your environment) and run `mkfs.ext4 /dev/mapper/crypt_boot`, then mount and restore backup 4. Add "GRUB_ENABLE_CRYPTODISK=y" to /etc/default/grub 5. Correct /etc/fstab to the correct UUID for /boot 6. Add an entry for the boot container to /etc/crypttab (i.e. "luks-<your luks UUID> UUID=<your luks UUID> none discard"), then run `dracut -vf --regenerate-all` 7. Run `grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg` 8. Reboot. Grub should ask for the password created in step 2. If the system then starts, change is successful (If filesystem root is also encrypted, the user will 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 guarantee 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 upon/are a part of this package, but require no change. == Contingency Plan == * Contingency mechanism: 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. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
