Setting up secure boot with custom keys

Latest response

Hi,

I am trying to setup secure boot with RHEL8. It works out of the box. I plan to harden the system further and remove MSFT keys from UEFI. Has some one done something like this before? Gentoo has a guide, is there something similar for RHEL?

https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot#Saving_Current_Keystore_Values.2C_and_Creating_New_Keys

Zer0 0ne

Responses

Hi,

I am not aware of such a guide for RHEL either. You might find something for CentOS. We consider OEM vendors deploying their own keys, so they could sign kernels on their own, but I heard for the first time the request to remove the default-key from Microsoft. Even if written up for RHEL, as our secureboot testing is done with the Microsoft key, supporting RHEL secureboot without Microsoft key has it's limits. Considering to support this would require more customer requests. Support would mean to extend our QA chains to generating custom keys, removing the Microsoft one, and then adding such testing to all secureboot related things, like kernel updates - that seems quite heavy.

Chris

Thanks Chris,

The idea behind removing MSFT keys is to harden UEFI secure boot process. If the MSFT key is available as a part of UEFI db anyone with MSFT signed bootloader/image can boot off the device can launch a cold boot attack. Unless there are other ways that I am not aware of.

Thanks for the pointer on CentOS. Will look into that.

Thanks, I see the usecase more clearly now. "I want to lower the attack surface of my system, in removing the MSFT keys, and manage the keys myself."

If you open a customer center case, then that's a good start to answer/comment on this request in a kbase solution, and also create a RFE bugzilla, to get have engineering and product management see this and comment.

Hi both, I just wonder if this was continued/solved in any ways? Would be interested in and appreciate if you could share experiences.

Cheers!

Hoi, I have not run about anything regarding that in release notes of newer releases, and now a kbase search did not bring up good hits ether. Do you mind opening a case about that? We should probably do a kbase about the topic, and we could also ask our specialists (i.e. the shim maintainers) on their thoughts regarding this.

So as of today, status is probably unsupported. Also secure boot with hashes might be interesting for some customers.

So, I had a look into that indepth. Nowadays we can emulate TPM2 in KVM guests (or even try TPM passthrough), that made it easier for me to play with this.

In short: 2 technical ways are promising and might be used to remove Microsoft/OEM keys from the system and then still have it Secure Booted. At this moment, there seem to be no wide user requests on this, so there are no docs from Red Hat, we are not doing QA on the procedures (which would help prevent breakage of docs). The one thing we do around Secure Boot, as it's widely requested: customers want to load own kernel module/3rd party kernel modules. We have that in product docs.

I have made a small kbase documenting what is attempted in this thread, and our support state: link. Which technical status has this? I have not collected blessings from our engineering regarding these points, but "just" looked into all documentation pieces from us which I have found. Thus I have set "unverified".

Some further points ontop, with more background, and related to this thread here.

  • The actual signing script in the Gentoo docs you linked to is not shown in detail, but later a piece says “we have avoided the need for a shim bootloader”, so this seems like directly signing the kernel. Red Hat has RHEL and Fedora not standardized on that way, all our QA and testing is based on signing the additional shim layer, then GRUB2 and the kernel.
  • If a user would want to roll their own keys to the db database and sign the kernel directly, they need some kernel config options set, as per Greg’s document. Most of these options are already set in the kernel available from RHEL/Fedora repositories (which can be checked with /boot/config*), most importantly the ability to run the kernel directly from EFI. It seems though like kernel options need also to be set at compile time if the kernel is directly signed: the kernel options (like rootfs= etc.) are quite specific to each system, that means a user running their kernel directly also need to compile their RHEL/Fedora kernel themself. For RHEL users that is not recommended and supported, also for Fedora users not really recommended. When reporting kernel issues with such a kernel, as a first question we will wonder if the issue also appears with the stock kernel from repositories.
  • When you decide to roll out own keys (like the gentoo doc does), and decide to go to the full chain we recommend (shim/GRUB2/kernel), also then it’s not something we support for end users - but at least chances of issues then are smaller than with signing RHEL/Fedora kernel directly, because you would keep the chain also RHEL is using.
  • Why has Red Hat gone with shim/GRUB2/kernel, instead of directly signing the kernel? Because if the kernel was signed directly, and firmware would (using the db) directly check that signature, we would need Microsoft to sign every errata kernel. With our chain we prevent that.

Best regards, Christian

Hello Christian,

I've been attempting this Secure Boot with Own Keys on RHEL 8 separately, and just stumbled onto this discussion. I have implemented this on CentOS 7.6 without much issues. It involved creating our own keys, and adding them to EFI and signing our own boot chain with those. The packages I used for that were 'efi-tools' and 'sbsigntools'.

I'm in the process of compiling 'sbsigntools' on RHEL 8.4, but not having much luck. 'efi-tools' is compiling fine so far, but needs sbsigntools.

Is there a repo which does have these for RHEL 8? And if not, why?

Hi,

I'm not aware of a build for rhel8 either. I think that it was clearly considered that OEM vendors (Fujitsu, HPE etc.) would be able to deploy their own keys in db, and have systems then boot into Linux without Microsoft key. I think that would require sbsigntools, but I see no reference on the package being requested into RHEL at any point. Most often performed "customization" of customers is to sign 3rd party kernel modules, and RHEL comes with that code, we have that documented and declared supported. Running a system on own Secure Boot keys is probably a rare use case. EPEL also does not have sbsigntools. I would probably try to compile the Fedora28 sbsigntools on rhel8, miht have best chances. You could open a support case, if there is a business case then maybe an RFE to add the package gets considered. Code wise, we probably have it in our toolchains when building rhel8.

Christian

I was using the kernel.org sources, but I'll have a go with the Fedora28 version, good tip :) There might be a business case, so I'll probably go that route for the future.

I built the latest Fedora 34 packages on Oracle Linux 8.4:

They should build on RHEL 8.4, as well.