SymbX/systemd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: add document about UEFI security posture in src/boot/efi/

Browse Source 
This is not intended as a user guide, but to describe the generic security
posture of the UEFI components. Hence we do not publish it on systemd.io
but only in the repository.
This commit is contained in:
Luca Boccassi
2023-10-02 14:29:10 +01:00
committed by Luca Boccassi
parent e428f1dd8a
commit 858a0dfce6
1 changed files with 99 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/boot/efi/SECURITY.md
+99
View File
@@ -0,0 +1,99 @@
# UEFI Components Security Posture
The systemd project provides a UEFI boot menu, `systemd-boot`, and a stub that can wrap a Linux kernel in a
PE binary, adding various features, `systemd-stub`. These components fully support UEFI SecureBoot, and
this document will describe their security posture and how they comply with industry-standard expectations
for UEFI SecureBoot workflows.
## Fundamental Security Design Goals
The fundamental security design goals for these components are separation of security policy logic from the
rest of the functionality, achieved by offloading security-critical tasks to the firmware or earlier stages
of the boot process (e.g.: `Shim`).
When SecureBoot is enabled, these components are designed to avoid executing, loading or using
unauthenticated payloads that could compromise the boot process, with special care taken for anything that
could affect the system before `ExitBootServices()` has been called. For example, when additional resources
are loaded, if running with SecureBoot enabled, they will be validated before use. The only exceptions are
the bootloader's own textual configuration files, and parsing metadata out of images for displaying purposes
only. There are no build time or runtime configuration options that can be set to weaken the security model
of these components when SecureBoot is enabled.
The role of `systemd-boot` is to discover next stage components in the ESP (and XBOOTLDR if present), via
filesystem enumeration or explicit configuration files, and present a menu to the user, to choose the next
step. This auto discovery mechanism is described in details in the [BLS (Boot Loader
Specification)](https://uapi-group.org/specifications/specs/boot_loader_specification/).
The role of `systemd-stub` is to load and measure in the TPM the post-bootloader stages, such as the kernel,
initrd and kernel command line, and implement optional features such as augmenting the initrd with
additional content such as configuration or optional services. These payloads can be augmented, and such
augmentations are measured too.
Since it is embedded in a PE signed binary, `systemd-stub` will temporarily disable SecureBoot
authentication when loading the payload kernel it wraps, in order to avoid redundant duplicate
authentication of the image, given that that the payload kernel was already authenticated and verified as
part of the whole image. SecureBoot authentication is re-enabled immediately after the kernel image has been
loaded.
Various EFI variables, under the vendor UUID `4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`, are set and read by
these components, to pass metadata and configuration between different stages of the boot process, as
defined in the [Boot Loader Interface](https://systemd.io/BOOT_LOADER_INTERFACE/).
## Dependencies
Neither of these components implements cryptographic primitives, cryptographic checks or drivers. File
access to the ESP is implemented solely via the appropriate UEFI file protocols. Verification of next stage
payloads is implementend solely via the appropriate UEFI image load protocols, which means authenticode
signature checks are again done by the firmware or `Shim`. As a consequence, no external security-critical
libraries (such as OpenSSL or gnu-efi) are used, linked or embedded.
## Additional Resources
BLS Type #1 entries allow the user to load two types of additional resources that can affect the system
before `ExitBootServices()` has been called, kernel command line arguments and Devicetree blobs, that are
not validated before use, as they do not carry signatures. For this reason, when SecureBoot is enabled,
loading these resources is automatically disabled. There is no override for this security mechanism, neither
at build time nor at runtime. Note that initrds are also not verified in BLS Type #1 configurations, for
compatibility with how SecureBoot has been traditionally handled on Linux-based OSes, as the kernel will
only load them after `ExitBootServices()` has been called.
Another mechanism is supported by `systemd-boot` and `systemd-stub` to add additional payloads to the boot
process: `addons`. Addons are PE signed binaries that can carry kernel command line arguments or Devicetree
blobs (more might be added in the future). In constrast to the user-specified additions in the Type #1 case
described above, these addons are loaded through the UEFI image loading protocol, and thus are subject to
signature validation, and will be rejected if not signed or if the signature is invalid, following the
standard SecureBoot model.
`systemd-boot` will also load file system drivers that are stored in the ESP, to allow enhancing the
firmware's capabilities. These are again PE signed binaries and will be verified using the appropriate
UEFI protocol.
A random seed will be loaded and passed to the kernel for early-boot entropy pool filling if found in the
ESP. It is mixed with various other sources of entropy available in the UEFI environment, such as the RNG
protocol, the boot counter and the clock. Moreover, the seed is updated before the kernel is invoked, as
well as after the kernel is invoked (from userspace), with a new seed derived from the Linux kernel entropy
pool.
When operating as a virtual machine payload, the loaded payloads can be customized via `SMBIOS Type 11
Strings`, if the hypervisor specifies them. This is automatically disabled if running inside a confidential
computing VM.
## Certificates Enrollment
When SecureBoot is supported but in `setup` mode, `systemd-boot` can enroll user certificates if a set of
`PK`, `KEK` and `db` certificates is found in the ESP, after which SecureBoot is enabled and a firmware
reset is performed. When running on bare metal, the certificate(s) will be shown to the user on the console,
and manual confirmation will be asked before proceeding. When running as a virtual machine payload,
enrollment is fully automated, without user interaction, unless disabled via a configuration file in the
ESP. The configuration file can also be used to disable enrollment completely.
## SBAT
`systemd-boot` and `systemd-stub` are built with an `SBAT` section by default. There are build options to
allow customizations of the metadata included in the section, that can be used by downstream distributors.
The `systemd` project will participate in the coordinated `SBAT` disclosure and metadata revision process as
deemed necessary, in coordination with the Shim Review group.
The upstream project name used to be unified (`systemd`) for both components, but since version v255 has
been split into separate `systemd-boot` and `systemd-stub` project names, so that each component can be
revisioned independently. Most of the code tend to be shared between these two components, but there is no
complete overlap, so it is possible for a vulnerability to affect only one component but not the other.
## Known Vulnerabilities
There is currently one known (and fixed) security vulnerability affecting `systemd-boot` on arm64 and
riscv64 systems. For details of the affected and fixed versions, please see the [published security
advisory.](https://github.com/systemd/systemd/security/advisories/GHSA-6m6p-rjcq-334c)