Chapter 5. Configuring RHEL on Azure with Secure Boot
Secure Boot is a mechanism in the Unified Extensible Firmware Interface (UEFI) specification to control the execution of programs at boot time. Secure Boot verifies digital signatures of the boot loader and its components at boot time, to ensure only trusted and authorized programs are executed, and also prevent unauthorized programs from loading.
Secure Boot is enabled for publicly available RHEL images on Azure platform. By default, it has the Allowed Signature database (db) with Microsoft certificates. Microsoft Azure allows adding custom certificates to UEFI Secure Boot variables when a new image version is registered in Azure Compute Gallery.
5.1. Understanding secure boot for RHEL on cloud 링크 복사링크가 클립보드에 복사되었습니다!
Secure Boot is a feature of Unified Extensible Firmware Interface (UEFI). It ensures that only trusted and digitally signed programs and components, such as the boot loader and kernel, run during boot time. Secure Boot checks digital signatures against trusted keys stored in hardware. If it detects any tampered components or components signed by untrusted entities, it aborts the boot process. This action prevents malicious software from compromising the operating system.
Secure Boot plays a critical role in configuring a Confidential Virtual Machine (CVM) by ensuring that only trusted entities participate in the boot chain. It authenticates access to specific device paths through defined interfaces, enforces the use of the latest configuration, and permanently overwrites earlier configurations. When the Red Hat Enterprise Linux (RHEL) kernel boots with Secure Boot enabled, it enters the lockdown mode, allowing only kernel modules signed by a trusted vendor to load. As a result, Secure Boot strengthens the security of the operating system boot sequence.
5.1.1. Components of secure boot 링크 복사링크가 클립보드에 복사되었습니다!
The Secure Boot mechanism consists of firmware, signature databases, cryptographic keys, boot loader, hardware modules, and the operating system. The following are the components of the UEFI trusted variables:
-
Key Exchange Key database (KEK): An exchange of public keys to establish trust between the RHEL operating system and the VM firmware. 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 VM firmware and the cloud platform. The PK also updates the KEK database.
-
Allowed Signature database (
db): A database that maintains a list of certificates or binary hashes to check whether the binary file can boot on the system. Additionally, all certificates fromdbare imported to the.platformkeyring of the RHEL kernel. With this feature, you can add and load signed third party kernel modules in thelockdownmode. -
Forbidden Signature database (
dbx): A database that maintains a list of certificates or binary hashes that are not allowed to boot on the system.
Binary files check against the dbx database and the Secure Boot Advanced Targeting (SBAT) mechanism. With SBAT, you can revoke older versions of specific binaries by keeping the certificate that has signed binaries as valid.
5.1.2. Stages of secure boot for RHEL on cloud 링크 복사링크가 클립보드에 복사되었습니다!
When a RHEL instance boots in the Unified Kernel Image (UKI) mode and with Secure Boot enabled, the RHEL instance interacts with the cloud service infrastructure in the following sequence:
- Initialization: When a RHEL instance boots, the cloud-hosted firmware initially boots and implements the Secure Boot mechanism.
- Variable store initialization: The firmware initializes UEFI variables from a variable store, a dedicated storage area for information that firmware needs to manage for the boot process and runtime operations. When the RHEL instance boots for the first time, the store initializes from default values associated with the VM image.
Boot loader: When booted, the firmware loads the first stage boot loader. For the RHEL instance in a x86 UEFI environment, the first stage boot loader is shim. The shim boot loader authenticates and loads the next stage of the boot process and acts as a bridge between UEFI and GRUB.
-
The shim x86 binary in RHEL is currently signed by the
Microsoft Corporation UEFI CA 2011Microsoft certificate so that the RHEL instance can boot in the Secure Boot enabled mode on various hardware and virtualized platforms where the Allowed Signature database (db) has the default Microsoft certificates. -
The shim binary extends the list of trusted certificates with Red Hat Secure Boot CA and optionally, with Machine Owner Key (
MOK).
-
The shim x86 binary in RHEL is currently signed by the
-
UKI: The shim binary loads the RHEL UKI (the
kernel-uki-virtpackage). The corresponding certificate,Red Hat Secure Boot Signing 504on the x86_64 architecture, signs the UKI. You can find this certificate in theredhat-sb-certspackage. Red Hat Secure Boot CA signs this certificate, so the check succeeds. -
UKI add-ons: When you use the UKI
cmdlineextensions, the RHEL kernel actively checks their signatures againstdb,MOK, and certificates shipped with shim. This process ensures that either the operating system vendor RHEL or a user has signed the extensions.
When the RHEL kernel boots in the Secure Boot mode, it enters lockdown mode. After entering lockdown, the RHEL kernel adds the db keys to the .platform keyring and the MOK keys to the .machine keyring. During the kernel build process, the build system works with an ephemeral key, which consists of private and public keys. The build system signs standard RHEL kernel modules, such as kernel-modules-core, kernel-modules, and kernel-modules-extra. After the completion of each kernel build, the private key becomes obsolete to sign third-party modules. You can use certificates from db and MOK for this purpose.
5.2. Configuring a RHEL VM on Azure with Secure Boot 링크 복사링크가 클립보드에 복사되었습니다!
To ensure that your Red Hat Enterprise Linux instance on the Azure cloud platform has a secured operating system booting process, use Secure Boot. When a custom RHEL Azure image is registered, the image consists of pre-stored Unified Extensible Firmware Interface (UEFI) variables for Secure Boot. This enables all the instances launched from the RHEL images to use the Secure Boot mechanism with the required variables on the first boot.
Microsoft Azure supports Secure Boot with Trusted Launch VMs. These VMs provide security mechanisms to protect against rootkits and bootkits, while providing additional features such as Virtual Trusted Platform Manager (vTPM). When creating an instance by using the GUI, you can find the Enable secure boot option under the Configure security features setting.
Prerequisites
You have installed the packages:
-
python3 -
openssl -
efivar -
keyutils -
python3-virt-firmware
-
-
You have installed the
azure-cliutility. For details, see Installing the Azure CLI on Linux.
Procedure
Generate a custom certificate
custom_db.cerby using theopensslutility:$ 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.cerConvert the certificate into
base64-encoded format:$ echo base64 -w0 custom_db.cer MIIFIjCCAwqgAwIBAgITNf23J4k0d8c0NR ....Create and edit an
azure-example-template.jsonAzure Resource Manager (ARM) file for registering a new Azure Compute Gallery image version:$ vi azure-example-template.json { "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "resources": [ { "type": "Microsoft.Compute/galleries/images/versions", "apiVersion": "2023-07-03", "name": "<your compute gallery/your image definition/version>", "location": "<location of the VHD>", "properties": { "storageProfile": { "osDiskImage": { "source": { "id": "<your-storage-account-id>", "uri": "<url-with-the-vhd>" }, "hostCaching": "ReadOnly" } }, "securityProfile": { "uefiSettings": { "signatureTemplateNames": [ "MicrosoftUefiCertificateAuthorityTemplate" ], "additionalSignatures": { "db": [ { "type": "x509", "value": [ "<base64 of custom_db.cer>" ] } ] } } } } } ] }Use the
azure-cliutility to register the image version:$ az deployment group create --name <example-deployment> \ --resource-group <example-resource-group> \ --template-file <example-template.json>- Reboot the instance from the Azure Portal.
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 keys in keyring: ... 586621657: ---lswrv 0 0 asymmetric: Signature Database key: f064979641c24e1b935e402bdbc3d5c4672a1acc ...