F31 Self-Contained Change proposal: Include several modules in the EFI build of Grub2 for security use-cases

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Include_security_modules_in_efi_Grub2

== Summary ==
Include Grub's "verify," "cryptodisk" and "luks" modules
(and if
necessary, relevant "gcry" modules) in grubx64.efi of the
'grub2-efi-x64' package.

== Owner ==
* Name: [[User:pjones| Peter Jones]]
* Email: pjones(a)redhat.com
* Name: [[User:javierm| Javier Martinez Canillas]]
* Email: fmartine(a)redhat.com

== 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)
* 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>For "verify":</b>

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


<b>For cryptography modules:</b>

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

https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system...

== Release Notes ==
Fedora now supports Grub's detached verify and cryptodisk
functionality natively, even on secure boot systems.

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him

[Ben Cotton]

On Mon, Mar 25, 2019 at 4:12 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  https://fedoraproject.org/wiki/Changes/Include_security_modules_in_efi_Grub2
>  
This Change proposal is on hold.

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him

[Dominik 'Rathann' Mierzejewski]

On Thursday, 28 March 2019 at 17:30, Ben Cotton wrote:
>  On Mon, Mar 25, 2019 at 4:12 PM Ben Cotton <bcotton(a)redhat.com&gt;
> wrote:
>  >
>  > https://fedoraproject.org/wiki/Changes/Include_security_modules_in_efi_Grub2
>  >
>  This Change proposal is on hold. 
Too bad. As a long-time SecureBoot user, I was looking forward to being
able to have encrypted /boot on Fedora.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Chris Murphy]

On Wed, Apr 3, 2019 at 2:58 AM Dominik 'Rathann' Mierzejewski
<dominik(a)greysector.net&gt; wrote:
>  On Thursday, 28 March 2019 at 17:30, Ben Cotton wrote:
>  > On Mon, Mar 25, 2019 at 4:12 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  > >
>  > > https://fedoraproject.org/wiki/Changes/Include_security_modules_in_efi_Grub2
>  > >
>  > This Change proposal is on hold.
>
>  Too bad. As a long-time SecureBoot user, I was looking forward to being
>  able to have encrypted /boot on Fedora. 
I'm not sure if this has anything to do with why it's on hold, but
GRUB does not support LUKS2. And there are no TPM bindings supported
in LUKS1, but are in LUKS2. In order to get to full disk encryption
out of the box by default with automatic unlock (measured boot to
obtain the cryptographic key from the TPM), needs LUKS2. So in effect
that means we either need GRUB to support LUKS2, or settle on an
unencrypted /boot.


--
Chris Murphy

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 03 April 2019 at 21:30, Chris Murphy wrote:
>  On Wed, Apr 3, 2019 at 2:58 AM Dominik 'Rathann'
> Mierzejewski
>  <dominik(a)greysector.net&gt; wrote:
>  >
>  > On Thursday, 28 March 2019 at 17:30, Ben Cotton wrote:
>  > > On Mon, Mar 25, 2019 at 4:12 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  > > >
>  > > >
> https://fedoraproject.org/wiki/Changes/Include_security_modules_in_efi_Grub2
>  > > >
>  > > This Change proposal is on hold.
>  >
>  > Too bad. As a long-time SecureBoot user, I was looking forward to being
>  > able to have encrypted /boot on Fedora.
>  
>  I'm not sure if this has anything to do with why it's on hold, but
>  GRUB does not support LUKS2. And there are no TPM bindings supported
>  in LUKS1, but are in LUKS2. In order to get to full disk encryption
>  out of the box by default with automatic unlock (measured boot to
>  obtain the cryptographic key from the TPM), needs LUKS2. So in effect
>  that means we either need GRUB to support LUKS2, or settle on an
>  unencrypted /boot. 
Well, why can't we have LUKS1-encrypted /boot and enter the encryption
password by hand? That's still better than unencrypted /boot.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Petr Pisar]

On 2019-04-03, Dominik 'Rathann' Mierzejewski <dominik(a)greysector.net&gt;
wrote:
>  On Wednesday, 03 April 2019 at 21:30, Chris Murphy wrote:
> > On Wed, Apr 3, 2019 at 2:58 AM Dominik 'Rathann' Mierzejewski
> > <dominik(a)greysector.net&gt; wrote:
> > >
> > > On Thursday, 28 March 2019 at 17:30, Ben Cotton wrote:
> > > > On Mon, Mar 25, 2019 at 4:12 PM Ben Cotton <bcotton(a)redhat.com&gt;
> wrote:
> > > > >
> > > > >
> https://fedoraproject.org/wiki/Changes/Include_security_modules_in_efi_Grub2
> > > > >
> > > > This Change proposal is on hold.
> > >
> > > Too bad. As a long-time SecureBoot user, I was looking forward to being
> > > able to have encrypted /boot on Fedora.
> > 
> > I'm not sure if this has anything to do with why it's on hold, but
> > GRUB does not support LUKS2. And there are no TPM bindings supported
> > in LUKS1, but are in LUKS2. In order to get to full disk encryption
> > out of the box by default with automatic unlock (measured boot to
> > obtain the cryptographic key from the TPM), needs LUKS2. So in effect
> > that means we either need GRUB to support LUKS2, or settle on an
> > unencrypted /boot.
>
>  Well, why can't we have LUKS1-encrypted /boot and enter the encryption
>  password by hand? That's still better than unencrypted /boot.
>  
What's the point of encrypting /boot? All the executed bits from /boot
(grub, kernel, and initramdisk) are measured by TPM. Thus if somebody
tampers them, root file system decryption that uses TPM will fail.

-- Petr

[Stephen John Smoogen]

On Fri, 5 Apr 2019 at 04:01, Petr Pisar <ppisar(a)redhat.com&gt; wrote:
>  
> > Well, why can't we have LUKS1-encrypted /boot and enter the encryption
> > password by hand? That's still better than unencrypted /boot.
>
>  
> What's the point of encrypting /boot? All the executed
bits from /boot
> (grub, kernel, and initramdisk) are measured by TPM. Thus if somebody
> tampers them, root file system decryption that uses TPM will fail.
>  
I expect it is in the case where the TPM is not available or where you
have been given a mandate to maintain confidentiality for all bits
even if you have integrity covered. [Sometimes confidentiality is more
prized than availability.]


>  -- Petr
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail] 


-- 
Stephen J Smoogen.

[Dominik 'Rathann' Mierzejewski]

On Friday, 05 April 2019 at 10:00, Petr Pisar wrote:
[...]
>  What's the point of encrypting /boot? All the executed bits from
> /boot
>  (grub, kernel, and initramdisk) are measured by TPM. Thus if somebody
>  tampers them, root file system decryption that uses TPM will fail. 
Not everyone has a TPM chip in their machine...

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Benjamin Doron]

Hi all,
Change author here. I think that everything is on-track now. Sorry I hadn't seen any
of these messages before, there's a newer post over here
(https://lists.fedoraproject.org/archives/list/[e-mail].o...)
and I hadn't realised that this had been active. I've posted two scripts over
there too. I'd appreciate any feedback on them.

Chris,
The only system for automatic decryption with a TPM that I know of is clevis, which
operates in the initramfs for both LUKS1 and LUKS2. I mention it in the change proposal as
a recommendation, but it is by no means a requirement.

Petr,
While you are correct, I'd rather attempt to prevent tampering and also set-up a
system through which to detect any. Besides, this change proposal is simply meant to offer
security-minded users options that weren't available to them before.


Benjamin