Shim 15.4 for EuroLinux

[jaromaz]

Make sure you have provided the following information:

• link to your code branch cloned from rhboot/shim-review in the form user/repo@tag
  EuroLinux/shim-review@EuroLinux-shim-x86_64-20220214
• completed README.md file with the necessary information
• shim.efi to be signed
• public portion of your certificate(s) embedded in shim (the file passed to VENDOR_CERT_FILE)
• binaries, for which hashes are added to vendor_db ( if you use vendor_db and have hashes allow-listed )
• any extra patches to shim via your own git tree or as files
• any extra patches to grub via your own git tree or as files
• build logs
• a Dockerfile to reproduce the build of the provided shim EFI binaries

What organization or people are asking to have this signed:

EuroLinux Sp. z o.o.
https://en.euro-linux.com

What product or service is this for:

EuroLinux 8

Please create your shim binaries starting with the 15.4 shim release tar file:

https://github.com/rhboot/shim/releases/download/15.4/shim-15.4.tar.bz2

This matches https://github.com/rhboot/shim/releases/tag/15.4 and contains

the appropriate gnu-efi source.

Please confirm this as the origin your shim.

Yes, we are using the source from: https://github.com/rhboot/shim/releases/download/15.4/shim-15.4.tar.bz2

What's the justification that this really does need to be signed for the whole world to be able to boot it:

EuroLinux is an enterprise-class Linux operating system based on Red Hat Enterprise Linux source code. It has been actively maintained since 2015. EuroLinux is present in the top 100 on DistroWatch. EuroLinux Sp. z o.o. is a company founded by people, who originally formed the Open Source market in Central Europe.

How do you manage and protect the keys used in your SHIM?

The keys are stored on a FIPS 140-2 certified module (YubiHSM 2 FIPS). Access to machine used to sign binaries is restricted physically. Only 2 trusted individuals have access to it.

Do you use EV certificates as embedded certificates in the SHIM?

No.

If you use new vendor_db functionality, are any hashes allow-listed, and if yes: for what binaries ?

We don't use vendor_db functionality in this build.

Is kernel upstream commit 75b0cea7bf307f362057cc778efe89af4c615354 present in your kernel, if you boot chain includes a Linux kernel ?

Yes, this commit is applied in our kernel.

if SHIM is loading GRUB2 bootloader, are CVEs CVE-2020-14372,

CVE-2020-25632, CVE-2020-25647, CVE-2020-27749, CVE-2020-27779,

CVE-2021-20225, CVE-2021-20233, CVE-2020-10713, CVE-2020-14308,

CVE-2020-14309, CVE-2020-14310, CVE-2020-14311, CVE-2020-15705,

( July 2020 grub2 CVE list + March 2021 grub2 CVE list )

and if you are shipping the shim_lock module CVE-2021-3418

fixed ?

All of those CVEs are fixed in GRUB 2.03 - we're using this version. EuroLinux doesn't ship the shim_lock mechanism - according to RHEL.

"Please specifically confirm that you add a vendor specific SBAT entry for SBAT header in each binary that supports SBAT metadata

( grub2, fwupd, fwupdate, shim + all child shim binaries )" to shim review doc ?

Please provide exact SBAT entries for all SBAT binaries you are booting or planning to boot directly through shim

Where your code is only slightly modified from an upstream vendor's, please also preserve their SBAT entries to simplify revocation

shim

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
shim,1,UEFI shim,shim,1,https://github.com/rhboot/shim
shim.eurolinux,1,EuroLinux,shim,15.4-5,security@euro-linux.com

grub2

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,1,Free Software Foundation,grub,2.02,https://www.gnu.org/software/grub/
grub.rhel8,1,Red Hat Enterprise Linux 8,grub2,1:2.02-107.el8,mail:secalert@redhat.com
grub.eurolinux8,1,EuroLinux 8,grub2,1:2.02-107.el8,mail:security@euro-linux.com

fwupd

sbat,1,UEFI shim,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
fwupd,1,Firmware update daemon,fwupd,1.5.9,https://github.com/fwupd/fwupd
fwupd.eurolinux,1,EuroLinux,fwupd,1.5.9,mail:security@euro-linux.com

Were your old SHIM hashes provided to Microsoft ?

This is our first shim submission.

Did you change your certificate strategy, so that affected by CVE-2020-14372, CVE-2020-25632, CVE-2020-25647, CVE-2020-27749,

CVE-2020-27779, CVE-2021-20225, CVE-2021-20233, CVE-2020-10713,

CVE-2020-14308, CVE-2020-14309, CVE-2020-14310, CVE-2020-14311, CVE-2020-15705 ( July 2020 grub2 CVE list + March 2021 grub2 CVE list )

grub2 bootloaders can not be verified ?

This is our first shim submission.

What exact implementation of Secureboot in grub2 ( if this is your bootloader ) you have ?

* Upstream grub2 shim_lock verifier or * Downstream RHEL/Fedora/Debian/Canonical like implementation ?

RHEL like implementation.

Which modules are built into your signed grub image?

all_video boot blscfg btrfs cat configfile cryptodisk echo ext2 fat font
gcry_rijndael gcry_rsa gcry_serpent gcry_sha256 gcry_twofish gcry_whirlpool
gfxmenu gfxterm gzio halt hfsplus http increment iso9660 jpeg loadenv
loopback linux lvm luks mdraid09 mdraid1x minicmd net normal part_apple
part_msdos part_gpt password_pbkdf2 png reboot regexp search search_fs_uuid
search_fs_file search_label serial sleep syslinuxcfg test tftp video xfs

What is the origin and full version number of your bootloader (GRUB or other)?

Same version as RHEL - with RHEL patches, our certs and SBAT data: grub2-2.02-107.

If your SHIM launches any other components, please provide further details on what is launched

It also launches fwupd.

If your GRUB2 launches any other binaries that are not Linux kernel in SecureBoot mode,

please provide further details on what is launched and how it enforces Secureboot lockdown

GRUB2 is only used to load Linux kernel.

If you are re-using a previously used (CA) certificate, you

will need to add the hashes of the previous GRUB2 binaries

exposed to the CVEs to vendor_dbx in shim in order to prevent

GRUB2 from being able to chainload those older GRUB2 binaries. If

you are changing to a new (CA) certificate, this does not

apply. Please describe your strategy.

This is our first shim submission.

How do the launched components prevent execution of unauthenticated code?

Everything validates signatures using shim's protocol.

Does your SHIM load any loaders that support loading unsigned kernels (e.g. GRUB)?

No.

What kernel are you using? Which patches does it includes to enforce Secure Boot?

RHEL version of Linux kernel 4.18.0-348 RHEL patches only.

What changes were made since your SHIM was last signed?

This is our first shim submission.

What is the SHA256 hash of your final SHIM binary?

fd1be8773a77adc3cf809d232d8984b5668b90d3f568a616f919581af9468766

[jaromaz]

We have not received emails verifying contacts and keys.
Is there anything else we can help with to speed up the process?

[mnajmajer]

@frozencemetery, When are you planning to process Shim for Eurolinux? We're using Eurolinux and want to use secure boot asap.

[kprzemek]

Hi,
I'm using EuroLinux too, and I want to try secure boot on my lab environment.
Can you give an approximate time when it will be possible?

[asquelt]

Our client is using this distribution and currently we need to turn secure boot off to install. It would be benefical for client's security compliance to get it fixed. TIA

[frozencemetery]

shim reviews are intended to be collaboratively done amongst distro vendors. The idea is that we provide a check on each other to ensure quality. This is not a service that "you" pay "us" for: there is no separation between the two. Most of us are overworked, and badgering those who can find time to do reviews at all only punishes us for trying - without offering any assistance of your own. If you want your submission done sooner, the best thing to do is make sure it is of good quality, and to
review those of others.

[ecos-platypus]

Disclaimer: I am not an authorized reviewer but review other shims to reduce the workload of the authorized reviewers and speed up the process for everyone.

Review was conducted in accordance to the reviewer guidelines (https://github.com/rhboot/shim/wiki/reviewer-guidelines)

1. Submitter is a new vendor (contact verification needed label already added)
2. Build is reproducible via the Dockerfile
3. Shim is built from a custom rpm downloaded from a remote server. In my opinion this is problematic as not all files for building shim are part of the shim-review repository. When I built the shim, the files matched those in the repository. Note that the sbat.csv only contains the last line but this seems to be addressed somehow during the build. I cannot really retrace this as I have no experience with .spec files
4. The issue template is filled out in the issue but not in the tagged shim-review fork, the README.md is filled out accordingly
5. The embedded certificate is self-signed:

Issuer: C = PL, ST = Poland, L = Cracow, O = EuroLinux Sp. z o.o., CN = EuroLinux Secure Boot CA
Validity
    Not Before: Feb 11 13:32:30 2022 GMT
    Not After : Oct 29 13:32:30 2041 GMT
Subject: C = PL, ST = Poland, L = Cracow, O = EuroLinux Sp. z o.o., CN = EuroLinux Secure Boot CA

6. Submitter uses FIPS 140-2 certified hardware token
7. Validity period of 19 years seems quite long to me but reviewer guidelines keeps this open for an embedded CA cert (20 years?)
8. Embedded sbat data in shim matches the one mentioned in the issue template, shim.eurolinux seems like a sensible vendor tag
9. GRUB is used as bootloader
10. GRUB Patches
    10.1 It is stated that the CVEs are closed with the GRUB patchset from RHEL
    10.2 488 GRUB patches are included, I did not verify them due to the sheer number. It is mentioned that the patchset is directly taken from RHEL, can you please add a link to the RHEL patchset so that the patches can be compared?
11. Linux Kernel 4.18 with kernel lockdown patches is used
12. Not an update to a vulnerable shim
13. The answers regarding verification seem contrary to each other: It is stated that Everything validates signatures using shim's protocol. but at the same time shim_lock in GRUB is apparently not shipped: EuroLinux doesn't ship the shim_lock mechanism - according to RHEL.. Can you please clarify on this?

[ecos-platypus]

3. Shim is built from a custom rpm downloaded from a remote server. In my opinion this is problematic as not all files for building shim are part of the shim-review repository. When I built the shim, the files matched those in the repository. Note that the sbat.csv only contains the last line but this seems to be addressed somehow during the build. I cannot really retrace this as I have no experience with .spec files

I just reviewed a submission by RedHat that also downloads a custom rpm file from a remote server. Their shim sbat entry is also somehow appended to the base shim during the build. So I guess this part is fine.

[jaromaz]

Let me clarify the answers as requested.

Shim is built from a custom rpm downloaded from a remote server. In my opinion this is problematic as not all files for building shim are part of the shim-review repository.

The file from the repository and the file from the remote server are exactly the same, which you can easily check here:

wget -O 1.src.rpm https://vault.cdn.euro-linux.com/sources/eurolinux/8/baseos/x86_64/Packages/s/shim-unsigned-x64-15.4-5.el8.src.rpm && wget -O 2.src.rpm https://github.com/EuroLinux/shim-review/raw/EuroLinux-shim-x86_64-20220214/data/shim-unsigned-x64-15.4-5.el8.src.rpm && sha256sum 1.src.rpm 2.src.rpm

e31309faf6d3cedc4b99714722b7078d0c0af83cc918160d8b223c9fc82f4808  1.src.rpm
e31309faf6d3cedc4b99714722b7078d0c0af83cc918160d8b223c9fc82f4808  2.src.rpm

Regarding the question:

if SHIM is loading GRUB2 bootloader, are CVEs CVE-2020-14372,
CVE-2020-25632, CVE-2020-25647, CVE-2020-27749, CVE-2020-27779,
CVE-2021-20225, CVE-2021-20233, CVE-2020-10713, CVE-2020-14308,
CVE-2020-14309, CVE-2020-14310, CVE-2020-14311, CVE-2020-15705,
( July 2020 grub2 CVE list + March 2021 grub2 CVE list )
and if you are shipping the shim_lock module CVE-2021-3418 fixed ?

We decided to answer the question a bit thoroughly rather than simply: "yes, they are fixed". More on that in a moment.
Regarding the question:

How do the launched components prevent execution of unauthenticated code?

The whole process is described by Red Hat - summary:

• Shim verifies GRUB's signature and then a locked-down GRUB verifies the kernel's signature through shim.
• The kernel is configured to be locked down in Secure Boot mode.
• Furthermore, fwupd can load only UEFI updates and nothing else.

How does this translate into a potential contradiction?
There's no contradiction. It's just that RHEL, and therefore EuroLinux does not provide a shim_lock.mod GRUB module.
To sum it up: we believe there was a misunderstanding. We'll use simpler expressions for clarity next time.

[julian-klode]

Closing outdated request due to the recent round of CVEs in grub and shim requiring a new submission with fixes for all these CVEs.