Red Hat SummitEste conteúdo não está disponível no idioma selecionado.
Chapter 5. Configuring RHEL on GCP with Secure Boot
The Secure Boot mechanism in the Unified Extensible Firmware Interface (UEFI) specification controls execution of programs at the boot time. Secure Boot ensures the execution of only trusted and authorized programs, while preventing unauthorized programs by verifying digital signatures of the boot loader and other components at the boot time.
5.1. Introduction to Secure Boot
The Secure Boot mechanism is a security protocol that provides authentication access for specific device paths by using defined interfaces. Successive authentication configuration overwrites the former configuration, by making it non-retrievable. It ensures that a trusted vendor has signed the boot loader and the kernel. Red Hat Enterprise Linux firmware checks the digital signature of the boot loader and related components against trusted keys stored on the hardware. If any component is tampered with or signed by an untrusted entity, the booting process aborts, which prevents potentially malicious software from taking control of the system. Additionally, the RHEL kernel offers the lockdown mode that ensures only a trusted vendor signed kernel modules are loaded.
5.2. Components of Secure Boot
Secure Boot consists of firmware, signature databases, cryptographic keys, boot loader, and hardware modules. The components of the UEFI trust sequence are listed below:
-
Key Exchange Key database (KEK): Exchange of public keys to establish trust between the RHEL instance and the platform firmware such as Hardware Virtual Machine (HVM). You can also update Allowed Signature database (
db) and Forbidden Signature database (dbx) by using these keys. - Platform Key database (PK): A self-signed single key database to establish trust between the RHEL instance and the cloud service provider. It also updates KEK database.
-
Allowed Signature database (
db): A database that maintains a list of certificates or binary hashes to check whether the binary file is allowed to boot on the system or not. Additionally, you can import all certificates fromdbin the kernel.platformkeyring. This feature allows you to add and load signed third-party kernel modules in thelockdownmode. -
Forbidden Signature database (
dbx): A database that maintains a list of forbidden certificates or binary hashes to boot on the system.
Binary files check against the dbx database as well as the Secure Boot Advanced Targeting (SBAT) mechanism. SBAT allows you to revoke older versions of specific binaries by keeping the certificate that has signed the binaries as valid.
Additional resources
5.3. Stages of booting a RHEL instance on a cloud platform
When a RHEL instance boots in the Unified Kernel Image (UKI) mode and with Secure Boot enabled, the RHEL instance interacts with cloud service infrastructure in the following sequence:
-
Integrity verification : Initially, when a cloud hosted firmware boots, it checks and verifies the RHEL instance integrity with Secure Boot. When the RHEL Kernel boots in the Secure Boot mode, it enters in a
lockdownmode and also extends the kernel.platformkeyring with an ephemeral key and other keys to sign third party modules. - Variable store initialization : Next, this firmware initializes UEFI variables from a variable store, which is a dedicated storage area for information that are necessary for the boot process and runtime operations. If the RHEL instance boots for the first time, the firmware initializes the variable store from default values of the VM image.
Bootloader : After that the firmware loads the
shimboot loader for the RHEL instance in a x86 UEFI environment.-
The
shimbinary extends the list of trusted certificates with Red Hat Secure Boot CA, and optionally, with Machine Owner Key (MOK) that is neededfor bare metal platforms to update Secure Boot variables compatible with OEM vendors.
-
The
-
UKI : The
shimbinary loads the RHEL Unified Kernel Image (UKI), which is thekernel-uki-virtpackage. To use the UKIcmdlineextensions, the RHEL kernel checks their signatures against Allowed Signature database (db) andMOKto ensure that they are signed by both Red Hat Enterprise Linux and the end user.
Additional resources
5.4. Configuring a RHEL instance with the Secure Boot mechanism from a publicly available RHEL image on Google Cloud Platform
Publicly available Red Hat Enterprise Linux images on Google Cloud Platform can be booted in Secure Boot enabled state. By default, it contains the Allowed Signature database (db) with Microsoft certificates.
Prerequisites
-
You have installed the
keyutilspackage.
Procedure
Launch a publicly available Red Hat Enterprise Linux instance from Google Cloud console with
Turn on Secure Bootoption enabled.
Verification
Verify if
Secure Bootis enabled:$ mokutil --sb-state SecureBoot enabledUse the
keyctlutility to verify the kernel keyring for the custom certificate:$ sudo keyctl list %:.platform 4 keys in keyring: 12702216: ---lswrv 0 0 asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4 50338534: ---lswrv 0 0 asymmetric: Red Hat Secure Boot CA 5: cc6fa5e72868ba494e939bbd680b9144769a9f8f 681047026: ---lswrv 0 0 asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53
5.5. Configuring a RHEL instance with the secure boot mechanism from a custom RHEL image on Google Cloud Platform
The following procedure configures a RHEL instance by including a custom certificate into the SecureBoot DB, which allows you to sign custom artifacts, such as third party kernel modules and UKI extensions.
Prerequisites
-
You have installed the
python3,efivar,keyutils,openssl, andpython3-virt-firmwarepackages. -
You have installed the
google-cloud-cliutility. See installing gcloud CLI on RHEL.
Procedure
Create a new random Universally Unique Identifier (UUID) and store it in a system generated random text file:
$ uuidgen --random > GUID.txtGenerate a new RSA private key
PK.keyand a self-signed X.509 certificatePK.cerfor the Platform Key database:$ openssl req -quiet -newkey rsa:4096 -nodes -keyout PK.key -new -x509 -sha256 -days 3650 -subj "/CN=Platform key/" -outform DER -out PK.cerThe
opensslutility generates a common namePlatform keyfor the certificate by setting output format to Distinguished Encoding Rules (DNR). DNR is a standardized binary format for data encoding.Generate a new RSA private key
KEK.keyand a self-signed X.509 certificateKEK.cerfor the Key Exchange Key database:$ openssl req -quiet -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj "/CN=Key Exchange Key/" -outform DER -out KEK.cerGenerate a custom certificate
custom_db.cer:$ openssl req -quiet -newkey rsa:4096 -nodes -keyout custom_db.key -new -x509 -sha256 -days 3650 -subj "/CN=Signature Database key/" --outform DER -out custom_db.cerDownload the Microsoft certificate:
$ wget https://go.microsoft.com/fwlink/p/?linkid=321194 --user-agent="Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36" -O MicCorUEFCA2011_2011-06-27.crtDownload the updated forbidden signatures (dbx) UEFI Revocation List File for 64 bit system:
$ wget https://uefi.org/sites/default/files/resources/x64_DBXUpdate.binUse the
google-cloud-cliutility to create and register the image from a disk snapshot with the desired Secure Boot variables:$ gcloud compute images create <example-rhel-9-efi-image> --source-image projects/<example_project_id>/global/images/<example_image_name> --platform-key-file=PK.cer --key-exchange-key-file=KEK.cer --signature-database-file=custom_db.cer,MicCorUEFCA2011_2011-06-27.crt --forbidden-database-file x64_DBXUpdate.bin --guest-os-features="UEFI_COMPATIBLE"Launch the instance of an
example-rhel-9-efi-imageimage with theTurn on Security Bootfeature from Google Cloud console.
Verification
Check if the newly created RHEL instance has Secure Boot enabled:
$ mokutil --sb-state SecureBoot enabledUse the
keyctlutility to verify the kernel keyring for the custom certificate:$ sudo keyctl list %:.platform ... 757453569: ---lswrv 0 0 asymmetric: Signature Database key: f064979641c24e1b935e402bdbc3d5c4672a1acc ...
