Establishing Trust in Linux Keyrings - Is Trust Built-in, Imputed, or Transitive?

### Overview Presented by George Wilson (IBM Linux Technology Center Security Team Lead and Security Architect) and Elaine Palmer (IBM Research Security Department), this presentation analyzes how trust is established within Linux kernel keyrings. Specifically focusing on internal `.keyrings` consumed by the kernel, the speakers explore three primary paradigms of trust: built-in, imputed, and transitive. They evaluate the kernel keyring architecture leading up to Linux 5.17 and critique the introduction of the `.machine` keyring in Linux 5.18, proposing structural restrictions to ensure proper key hygiene and separation of duties.

### Key Topics - **Trust Models**: Trust operates as a continuum or stepwise function rather than a simple binary choice. In disconnected boot environments where online revocation checks (such as OCSP) are unavailable, the kernel must rely on what it is told to trust. - **Three Sources of Trust**: 1. *Built-in Trust*: Keys compiled directly into the kernel image (or inserted into pre-allocated space prior to signing) at build time. 2. *Imputed Trust*: Trust attributed to an entity based on its origin, source, or reputation (e.g., machine owner or administrator injecting keys via firmware/MOK). 3. *Transitive Trust*: Trust extended automatically to a target because an already trusted entity vouches for or cryptographically signs it (e.g., certificate authorities). - **Linux Keyring Architecture (up to 5.17)**: Examination of the built-in trusted keyring, secondary trusted keyring, `.ima` keyring (Integrity Measurement Architecture for verifying files, kernel modules, and kexec images), the platform keyring (used strictly for kexec kernel images from UEFI/firmware/MOK), and the blacklist keyring (used to block files and certificates by digest or TBS field). - **Linux 5.18 `.machine` Keyring & Criticisms**: The addition of the `.machine` keyring upstreamed functionality long carried as out-of-tree distro patches. However, its broad scope permits loaded machine keys to verify kernels, kernel modules, and kexec images indiscriminately, prompting IMA maintainers to disable the `.ima` keyring when the machine keyring is configured to prevent unintended trust inheritance.

### Technical Details & Proposals Prior to kernel 5.18, upstream mechanisms lacked a standard method for end users or machine owners to load custom keys and sign kernel modules without vendor-specific distro patches. Linux 5.18 introduced the `.machine` keyring—linked directly to the secondary trusted keyring—to dynamically ingest Machine Owner Keys (MOK) or platform variables via imputed trust.

However, because the `.machine` keyring inherits the broad authority of the secondary keyring, any loaded key can verify modules, kexec payloads, and indirectly influence IMA file verification. Because keys imported via MOK may represent an uncurated set, this broad scope breaks security boundaries.

To resolve this, Wilson and Palmer propose restricting keys accepted into the `.machine` keyring strictly to Certificate Authority (CA) certificates (`CA=TRUE` and key usage restricted to certificate signing, both marked critical). Under this model: - **Separation of Duties & Key Hygiene**: Machine owners and administrators install parent CA certificates, while child code-signing certificates are issued separately and can be rotated frequently without touching the firmware or parent keyring. - **Re-enabling IMA**: Restricting `.machine` keys prevents code-signing keys from directly bypassing IMA verification policies, enabling the `.ima` keyring to remain safely active. - **Discussion & Audience Insights**: Audience feedback highlighted that common practice often relies on self-signed code-signing certificates with CA bits enabled, which complicates migration to a two-tier hierarchy. Additionally, audience discussion suggested evaluating CA path length constraints (such as excluding path length 0) and adopting more granular, expressive administrative policy frameworks for keyrings beyond raw cryptographic signature verification.

### Takeaways While Linux 5.18 successfully brings machine owner key capabilities upstream, broad keyring trust assignments introduce security regressions for subsystems like IMA. Enforcing structural separation between CA certificates and code/data signing certificates—potentially supplemented by expressive keyring policies—is necessary to maintain key hygiene and robust access controls in modern Linux deployments.