orcharhino and SecureBoot
Security is mandatory in today’s IT. Although orcharhino was primarily developed for lifecycle management of servers, more and more customers demand unattended provisioning and lifecycle management of laptop systems. This often means that you have to enable SecureBoot.
In this article, we would like to give you a short introduction to SecureBoot and explain why it is difficult to combine it with orcharhino’s unattended provisioning.
What is SecureBoot?
SecureBoot is part of the Unified Extensible Firmware Interface (UEFI) specification. That again is an enhancement of the Extensible Firmware Interface (EFI) first developed for Intel’s Itanium 64bit architecture back in 1998 [1]. UEFI is the central interface between the operating system (OS) and the platform firmware. Established as a successor of BIOS, it has become the common standard in today’s hardware platforms.
SecureBoot ensures the authenticity of software that is loaded and executed by the firmware with the help of cryptographic mechanisms. The trustworthy Linux system is only the last link in a chain of software components. A typical chain of trust is firmware, bootloader, Linux kernel, and kernel modules.
Verification takes place with the same basic concepts we know from website certificates that use pairs of public and private keys. The private key encrypts a hash of the data object: the actual signature. The signature is then appended to the data object. For verification on the target hardware, UEFI decrypts the signature with the public key, which must be present in the firmware (see later). The result is again a hash. If decrypted signature hash and self-calculated hash of the data object match, authenticity is proven. The data object was signed by the instance that provided the public key using the corresponding private key. We call the owner of the private key the authority.
By the way, you can check for yourself if your system is currently running with enabled SecureBoot by executing mokutil --sb-state.
How it Works
Typically, the firmware is part of a computer’s mainboard. On the mainboard’s built-in storage (non-volatile random access memory, NVRAM), there are several signature databases. The stored data typically consists of certificates containing public keys, signatures, or hashes of binaries. The OS has no direct writing access to this storage.
Among the signature databases, we find the platform key (PK) database, the key exchange key (KEK) database, a signature database (db), and a forbidden signature database (dbx). The PK database typically contains the OEM certificate [2]. This is required for updating objects in the KEK database. KEK in turn verifies updates in db and dbx. By default, db contains a Microsoft certificate verifying binaries signed by Microsoft. As a result, the mainboard OEMs, including their delegations, and Microsoft are the only trusted Certificate Authorities (CAs) in such a default setup.
And what about Linux? Major Linux distributions rely on a signing process in which they obtain a Microsoft-signed EFI binary, called shim [4]. shim is the very first binary that is loaded and executed by the firmware. Every distribution’s shim is equipped with a vendor database containing the distribution’s own certificate. shim loads, verifies, and executes the bootloader (e.g., GRUB2), which needs to be signed by the distributor. The bootloader eventually loads the distribution-signed Linux kernel, calls shim for verification, and executes it if verification is successful.
Using a major Linux distribution with corresponding kernel and kernel modules that are installed and updated via official package repository works quite well. By the way, shim is always executed, even if SecureBoot is disabled. It simply loads and executes the bootloader without verification.
Out of My Control?
Now, you might think, “Wait, can I still run my own software on my own hardware?” This gives rise to the question whether it is a good idea to have Microsoft as a single CA deciding if a system is allowed to boot or not. However, besides disabling SecureBoot, there are two other options:
First, most firmwares allow users to switch to a custom or setup mode, where self-created certificates can be installed in an attended way for PK, KEK, and db. This means that the bootloader, the kernel, and all kernel modules are signed whenever they are updated. Even components already signed by a distributor would have to be resigned with the corresponding custom key.
Second, there is a feature called Machine Owner Key (MOK) Manager. With this distribution-signed EFI binary, the user can interactively add or remove additional public keys in a persistent way on NVRAM during boot. With the MOK, a user could, for instance, import a self-created certificate for a custom kernel before reboot. After reboot, shim starts the MOK Manager, where the key enrollment must be confirmed by the user interactively.
As a compromise between effort and security, the second way is usually chosen by individual end users and many companies. Both ways require physical presence of the user in front of the system, and fundamental changes are not possible without interaction.
What Do We Gain in Terms of Security?
With SecureBoot enabled, you can be sure, at least to some degree, that you are running a trustworthy Linux kernel. The risk of bootkits and rootkits nesting is minimized. Typical attack vectors, such as the remote replacement of a malicious Linux kernel, can be prevented. Users can exclude components with known vulnerabilities from booting via dbx entries.
Still, the risk remains that users are tricked (social engineering) to enroll malicious keys, and existing keys can be stolen or compromised. Furthermore, the initramfs, which is executed by the Linux kernel at the very beginning of the boot process and which is responsible for mounting the root file system, is not covered by any SecureBoot measures.
However, even the NSA advises its administrators to switch to SecureBoot-enabled systems in a technical report from late 2020 [3].
orcharhino and SecureBoot
As explained in the introduction, provisioning laptops is becoming an increasingly important demand. orcharhino offers various ways of provisioning, but they differ significantly in the level of automation. Depending on the number of laptops, this can be crucial.
Let’s assume the following scenario: you have a new laptop, SecureBoot is disabled, and you want to provision a recent Ubuntu Linux. If you want to keep effort at a minimum, plug in the network cable, power on the laptop, and boot from network. Automation starts here: with the Discovery plug-in enabled in orcharhino, the laptop fetches a CentOS shim and GRUB over the network and starts booting.
GRUB gets the default Foreman Discovery Image (FDI) based on CentOS from the network, starts it, and reports the laptop’s facts to orcharhino. In the user interface, you can find the system at Hosts -> Discovered Hosts. If there are applicable discovery rules, the desired Ubuntu Linux distribution will start automatically, for example directly via kexec without reboot. The last step during installation is subscribing the system to the orcharhino server. The system then reboots, boots from disk, and Ubuntu Linux is up and running.
The same scenario on a SecureBoot-enabled system does not work without further ado. The behavior is the same, including the FDI reporting its facts to orcharhino. However, the following start of the Ubuntu installation via kexec fails. The problem lies in the restriction to a single distribution by the initially loaded shim. Remember: this was based on CentOS, so only kernels signed by the CentOS key are allowed. shim and the enabled SecureBoot puts all further bootloader and kernel into lockdown.
Booting signed binaries that are not known to db (containing only the Microsoft certificate), shim’s vendor database (containing only the distribution’s certificate), or MOK’s database (empty by default) is not possible anymore until the next reboot.
Possible Solutions
We would like to give you a short overview of possible solutions, which depend on customer-specific requirements and conditions in addition to the users’ willingness to compromise. Each solution has trade-offs in terms of automation level, possibility of reinstallation, and diversity of distribution that can be provisioned.
-
Run provisioning process with disabled SecureBoot and enable it afterwards. This is the most pragmatic way and doesn’t need any adaptions or further effort besides the fact that manual interaction is required after installation. Respective components of the target Linux distribution are distribution-signed and shim is installed anyway. Every reinstallation would require interactive toggling of the SecureBoot state.
-
Restrict yourself to one distribution and use a target-distribution-based FDI. If users opt for this approach, they will have to replace all involved components with versions provided by the desired target distribution. These are network shim and GRUB on the orcharhino server as well as the FDI. The individualized FDI allows users to execute any component as long as all of them are from the same distribution. However, building a suitable FDI is a challenging task.
-
Enhance orcharhino to allow network boot configuration per host. orcharhino’s way of providing a network boot is a bottleneck. One and the same shim and/or GRUB is delivered to each host (see previous section). From the moment a host goes into build mode, DHCP and TFTP must be configured to point to and provide corresponding distribution-signed components. This corresponds to the second approach but without the need for target-distribution-based FDIs and with the possibility to use kexec in FDI (lockdown).
-
Build a shim containing certificates of major distributions. Having a shim that successfully verifies all major distributions would eliminate the issue of distribution fixation. At least with a network-booted GRUB, any distribution Linux kernel could be booted for installation. A technical proof of concept exists and ATIX is currently evaluating this approach. Apart from bootloader chainloading issues and maintenance effort, there is a risk that this will not pass the official review process due to objections from the CA.
Conclusion
SecureBoot was developed to make systems more secure. However, there is some controversy. An incident called BootHole in 2020 (CVE-2020-10713) enabled exactly what SecureBoot was supposed to prevent: the injection of malicious code [5]. This incident has shown that SecureBoot still needs to be improved in some places (and already has been [6]).
orcharhino is capable of provisioning hosts even with SecureBoot enabled. By means of an initial evaluation of our customers’ processes, we know which solution to choose. Workflows on desktop and notebook management are, however, subject to certain restrictions.
Jan Löser
Latest posts by Jan Löser (see all)
- Custom Discovery Images for SecureBoot - 6. March 2024
- orcharhino and SecureBoot - 15. February 2023
