< Changes
m (Corrects path to file) |
(Bug resolved, continuing work, etc) |
||
| Line 1: | Line 1: | ||
<!--Todo: | <!--Todo: | ||
• Top priority: | • Top priority: Does SB need to be enabled after all?? | ||
• Determine exactly which files need to be signed | |||
• Add | • Triple faults occur on VMware Workstation platform, but not on bare-metal. Cause unknown. Investigate using debug=all and try with check_signatures=no | ||
• Add instructions to ensure future signing of files (kernel postinstall and maybe rpm postinstall (if next point doesn't cover it already through a rpm postinstall hook to grub scripts)) to "Detailed Description" and "How to Test" | |||
• Review "Detailed Description" for functionality that can be presently implemented | |||
• Has change now become system-wide? | |||
• Should other modules be included to allow use of other algorithms? (Unnecessary in the proposed long-term plan) | |||
• Improve formatting of terminal commands | • Improve formatting of terminal commands | ||
• Pull request - should sort out matter of change owner--> | • Pull request - should sort out matter of change owner--> | ||
| Line 39: | Line 43: | ||
This should link to your home wiki page so we know who you are. | This should link to your home wiki page so we know who you are. | ||
--> | --> | ||
* Name: [[User: | * Name: [[User:benjamind| Benjamin]] | ||
<!-- 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. --> | <!-- 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: | * Email: benjamin.doron00@gmail.com | ||
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --> | * Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --> | ||
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo) | <!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo) | ||
| Line 68: | Line 72: | ||
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. | 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. | 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. | ||
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. | 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. | ||
| Line 103: | Line 107: | ||
== Scope == | == Scope == | ||
* Proposal owners: Modify grub.macros file to include the above-mentioned modules in the GRUB_MODULES variable. | * Proposal owners: Modify grub.macros file to include the above-mentioned modules in the GRUB_MODULES variable (and then send a pull request). | ||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
| Line 141: | Line 145: | ||
--> | --> | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<b>Disclaimer: Commands assume that tester is root. | |||
Ensure that the package 'grub2-efi-x64-modules' is installed, and for testing purposes, copy the contents to the EFI partition with</b> <code>cp -r /usr/lib/grub/x86_64-efi/ /boot/efi/EFI/fedora/</code> | |||
<b>For "verify":</b> | <b>For "verify":</b> | ||
1. Generate an RSA signing key with gpg -- | 1. Generate an RSA signing key with <code>gpg --full-generate-key</code>, then export it with <code>gpg --export > pubkey</code> and move it to the EFI partition with <code>mv pubkey /boot/efi/EFI/fedora</code>. You can also export the private key (<code>gpg --export-secret-keys > seckey</code>), but the signing process doesn't require it and gpg will get the key from its own directory. | ||
2. Add "insmod verify," "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 <code>grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg</code> | |||
4. Run <code>export GPG_TTY=$(tty)</code>. Don't ask, apparently something changed in gpg with a recent update. | |||
4. Create a file, / | 4. Create a file, /dev/shm/pass, with the key's password and execute: <code>for x in $(find /boot -name "*.cfg" -or -name "*.lst" -or -name "*.efi" -or -name "*.mod" -or -name "vmlinuz*" -or -name "initramfs*" -or -name "grubenv"); do gpg --batch --detach-sign --passphrase-fd 0 $x < /dev/shm/pass; done</code>. Then, <code>shred /dev/shm/pass</code> | ||
5. Reboot. If system starts, backup and remove .sig files. If system does not start this time, change is successful | 5. Reboot. If system starts, backup and remove .sig files. If system does not start this time, change is successful | ||
| Line 160: | Line 169: | ||
1. Backup boot partition | 1. Backup boot partition | ||
2. Run cryptsetup luksFormat /dev/sda2 --type luks1 (change this based on your environment to /boot's block device) | 2. Run <code>cryptsetup luksFormat /dev/sda2 --type luks1</code> (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 a low time (in ms), as grub seems single-threaded. Additionally, do not use twofish, serpent (for encryption) or whirlpool | 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 a low time (in ms), as grub seems single-threaded. Additionally, do not use twofish, serpent (for encryption) or whirlpool | ||
(for hashing) here, as this change does not account for them | (for hashing) here, as this change does not account for them | ||
3. Open luks container, run mkfs.ext4 /dev/mapper/luks-<your luks UUID> and restore backup | 3. Open luks container, run <code>mkfs.ext4 /dev/mapper/luks-<your luks UUID></code> and restore backup | ||
4. Add GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub | 4. Add GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub | ||
| Line 170: | Line 179: | ||
5. Confirm that /etc/fstab has the correct UUID for /boot | 5. Confirm that /etc/fstab has the correct UUID for /boot | ||
6. Add an entry for the boot container to /etc/crypttab, then run dracut -vf --regenerate-all | 6. Add an entry for the boot container to /etc/crypttab, then run <code>dracut -vf --regenerate-all</code> | ||
7. Run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg | 7. Run <code>grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg</code> | ||
8. Reboot. Grub should ask for the password created in step 2. If system then starts, change is successful | 8. Reboot. Grub should ask for the password created in step 2. If system then starts, change is successful | ||
Revision as of 04:12, 15 May 2019
Include several modules in the EFI build of Grub2 for security use-cases
Summary
Include Grub's "verify," "cryptodisk" and "luks" modules in grubx64.efi of the 'grub2-efi-x64' package.
Note: The dependencies "gcry_rijndael," "gcry_sha256," "procfs," "archelp," "mpi," "gcry_rsa" and "gcry_sha1" must also be included.
Owner
- Name: Benjamin
- Email: benjamin.doron00@gmail.com
- Release notes owner:
Current status
- Targeted release: Fedora 31
- Last updated: 2019-05-15
- 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. Similarly, it would be easier to use cryptodisk functionality if it were configurable by anaconda.
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 (and then send a pull request).
- 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)
Upgrade/compatibility impact
Change only adds modules, so existing users should have no problems.
How To Test
Disclaimer: Commands assume that tester is root.
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/
For "verify":
1. Generate an RSA signing key with gpg --full-generate-key, 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 and gpg will get the key from its own directory.
2. Add "insmod verify," "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 "*.efi" -or -name "*.mod" -or -name "vmlinuz*" -or -name "initramfs*" -or -name "grubenv"); do gpg --batch --detach-sign --passphrase-fd 0 $x < /dev/shm/pass; done. Then, shred /dev/shm/pass
5. Reboot. If system starts, backup and remove .sig files. If 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.)
For cryptography modules:
1. Backup 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 a low time (in ms), as grub seems single-threaded. Additionally, do not use twofish, serpent (for encryption) or whirlpool
(for hashing) here, as this change does not account for them
3. Open luks container, run mkfs.ext4 /dev/mapper/luks-<your luks UUID> 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. Add an entry for the boot container to /etc/crypttab, 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 system then starts, change is successful
(If filesystem root is also encrypted, 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 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
Release Notes
Fedora now supports Grub's detached verify and cryptodisk functionality natively, even on secure boot systems.