Overview and Recent Developments: Linux Integrity

## Overview

The Linux Integrity subsystem comprises two main components: IMA (Integrity Measurement Architecture) and EVM (Extended Verification Module), supported by trusted and encrypted keys, the MPI library for signature verification, and TPM integration. The subsystem's goals, defined in collaboration with Dave, are to detect accidental or malicious file alteration both remotely and locally, appraise file measurements against good values stored as extended attributes, and enforce local file integrity.

## Key Concepts

IMA operates on three functions: measurement (computing file hashes), appraisal (verifying files against signed hashes or signatures), and audit (recording file integrity data for forensics and analytics). Rather than hard-coding policy throughout the kernel, IMA uses a single policy file that defines which files are measured, appraised, or audited. EVM protects file metadata using HMAC or signatures stored in extended attributes, binding metadata to files through security attributes rather than inode-specific information.

The subsystem extends secure boot and trusted boot concepts to the OS level. In secure boot, each boot stage verifies the next stage's signature before transfer. In trusted boot, each stage measures the next stage and extends TPM before transfer. IMA brings trusted boot principles to userspace with the IMA measurement list.

## File Signatures and Distribution

Distributing file signatures alongside code remains a challenge. The speaker notes that RPM has supported embedded signatures for years, but Debian packaging efforts using modified tar formats or mtree have not yet been upstream. Different use cases exist for signature ownership—distros may sign, or users may re-sign locally to limit what runs on their systems.

## Key Management and Trust Chain

IMA and EVM keyrings must be created early in boot to verify policy signatures. Keys can be loaded via trusted keyrings created by the kernel itself, or through userspace keyrings locked in RamFS. The speaker discusses two methods for embedding CA keys into built-in keyrings: building keys into the kernel or reserving memory for post-install key insertion. A third method using the secondary keyring is mentioned as less optimal when extending trust from pre-boot to post-boot contexts.

## Namespacing and Container Support

The subsystem is being extended to support containers and namespaces, though challenges remain in providing container-specific visibility without leaking host information or diverging implementation approaches. Namespacing support will be staged: first IMA audit (with container identifier support), then measurement (requiring virtualized security filesystem and policy), finally appraisal (requiring keyrings and day mention namespacing).

## Recent Developments

Recent work includes portable and immutable EVM signatures by Matthew, removing filesystem-specific identifiers from HMAC calculations. Build-time IMA policies can now persist after custom policy loading. Measurement gaps have been closed, including handling of filesystems without iversion support and FUSE filesystem trust decisions. Kernel 4.16 introduced an IMA-specific lock resolving XFS deadlock issues. TPM performance has improved significantly through HRT timer changes and additional patches, enabling more measurements without performance degradation. LTP tests have been refreshed, and a standalone IMA test is in development.

## Takeaways

The speaker encourages community participation in patch review, feature discussions from multiple perspectives, and documentation improvement. Closing remaining measurement gaps and developing container/namespace support require continued collaboration and feedback from users with different use cases and deployment scenarios.