Chapter 5. Configuring RHEL on GCP with Secure Boot
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 from db in the kernel .platform keyring. This feature allows you to add and load signed third-party kernel modules in the lockdown mode. Forbidden Signature database ( dbx ): A database that maintains a list of forbidden certificates or binary hashes to boot on the system. Note 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 SBAT mechanism 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 lockdown mode and also extends the kernel .platform keyring with an ephemeral key and other keys to sign third party modules. Variable store initialization : , 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 shim boot loader for the RHEL instance in a x86 UEFI environment. The shim binary 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. UKI : The shim binary loads the RHEL Unified Kernel Image (UKI), which is the kernel-uki-virt package. To use the UKI cmdline extensions, the RHEL kernel checks their signatures against Allowed Signature database ( db ) and MOK to ensure that they are signed by both Red Hat Enterprise Linux and the end user. Additional resources Red Hat Enterprise Linux and Secure Boot in the cloud 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 keyutils package. Procedure Launch a publicly available Red Hat Enterprise Linux instance from Google Cloud console with Turn on Secure Boot option enabled. Verification Verify if Secure Boot is enabled: Use the keyctl utility to verify the kernel keyring for the custom certificate: 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 , and python3-virt-firmware packages. You have installed the google-cloud-cli utility. 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: Generate a new RSA private key PK.key and a self-signed X.509 certificate PK.cer for the Platform Key database: The openssl utility generates a common name Platform key for 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.key and a self-signed X.509 certificate KEK.cer for the Key Exchange Key database: Generate a custom certificate custom_db.cer : Download the Microsoft certificate: Download the updated forbidden signatures (dbx) UEFI Revocation List File for 64 bit system: Use the google-cloud-cli utility to create and register the image from a disk snapshot with the desired Secure Boot variables: Launch the instance of an example-rhel-9-efi-image image with the Turn on Security Boot feature from Google Cloud console. Verification Check if the newly created RHEL instance has Secure Boot enabled: Use the keyctl utility to verify the kernel keyring for the custom certificate:
mokutil --sb-state SecureBoot enabled 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 uuidgen --random > GUID.txt openssl req -quiet -newkey rsa:4096 -nodes -keyout PK.key -new -x509 -sha256 -days 3650 -subj "/CN=Platform key/" -outform DER -out PK.cer openssl req -quiet -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj "/CN=Key Exchange Key/" -outform DER -out KEK.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.cer 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.crt wget https://uefi.org/sites/default/files/resources/x64_DBXUpdate.bin 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" mokutil --sb-state SecureBoot enabled sudo keyctl list %:.platform 757453569: ---lswrv 0 0 asymmetric: Signature Database key: f064979641c24e1b935e402bdbc3d5c4672a1acc