< Changes
(Owner information is presently incorrect. Need to co-ordinate with maintainer(s)) |
(More modules necessary, corrected certain commands) |
||
| Line 1: | Line 1: | ||
<!--Todo: | |||
* More modules necessary as dependencies (gcry_rijndael, gcry_sha256, procfs, archelp, mpi, gcry_rsa, gcry_sha1). Additionally, should other algorithms be supported? | |||
* Therefore, for now, gpg key can only be rsa and twofish, serpent and whirlpool cannot be used for boot partition. | |||
* Need to check whether grub inherits shim's MOK keys | |||
* Pull request - should sort out matter of change owner--> | |||
<!-- 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 18: | Line 23: | ||
--> | --> | ||
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | <!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | ||
<!-- The actual name of your proposed change page should look something like: Changes/Include_security_modules_in_efi_Grub2. | <!-- The actual name of your proposed change page should look something like: Changes/Include_security_modules_in_efi_Grub2. This keeps all change proposals in the same namespace --> | ||
= Include several modules in the EFI build of Grub2 for security use-cases <!-- The name of your change proposal --> = | = Include several modules in the EFI build of Grub2 for security use-cases <!-- The name of your change proposal --> = | ||
| Line 24: | Line 29: | ||
<!-- 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" | Include Grub's "verify," "cryptodisk," "luks" and <others here> modules in grubx64.efi of the 'grub2-efi-x64' package. | ||
== Owner == | == Owner == | ||
| Line 137: | Line 142: | ||
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>" ( | 2. Add "trust (hd0,gpt1)/efi/fedora/<gpg key>" (change this based on your environment, 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 | ||
| Line 152: | Line 157: | ||
1. Backup boot partition | 1. Backup boot partition | ||
2. Run cryptsetup luksFormat | 2. Run cryptsetup luksFormat /dev/sda2 --type luks1 (change this based on your environment to boot's block device) | ||
3. Open luks container and restore backup | 3. Open luks container and restore backup | ||
| Line 164: | Line 169: | ||
7. Reboot. Grub should ask for the password created in step 2. If system then starts, change is successful | 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 | (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 186: | Line 191: | ||
== 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 | * Contingency mechanism: (What to do? Who will do it?) Revert the shipped configuration <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | <!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | ||
* Contingency deadline: Beta freeze | * Contingency deadline: Beta freeze <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | <!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | ||
* Blocks release? N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Blocks release? N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Revision as of 19:14, 28 March 2019
Include several modules in the EFI build of Grub2 for security use-cases
Summary
Include Grub's "verify," "cryptodisk," "luks" and <others here> modules in grubx64.efi of the 'grub2-efi-x64' package.
Owner
- Name: Name here
- Email: Email address here
- Release notes owner:
Current status
- Targeted release: Fedora 31
- Last updated: 2019-03-28
- 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)
- 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
For "verify":
1. Generate a signing key with "gpg --gen-key" and copy it to the EFI partition
2. Add "trust (hd0,gpt1)/efi/fedora/<gpg key>" (change this based on your environment, 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, 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)
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
Release Notes
Fedora now supports Grub's detached verify and cryptodisk functionality natively, even on secure boot systems.