Changes/DIGLIM

DIGLIM

Summary

Digest Lists Integrity Module (DIGLIM) provides a repository of file digests from authenticated sources, such as RPM headers, to be used by kernel services for remote attestation and/or secure boot at application level.

Owner

• Name: Roberto Sassu
• Email: roberto.sassu@huawei.com

Current status

• Targeted release: Fedora Linux 37
• devel thread
• Last updated: 2022-02-14
• FESCo issue: #2721
• Tracker bug: <will be assigned by the Wrangler>
• Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

Integrity Measurement Architecture (IMA), a kernel service for remote attestation and secure boot at application level, has been integrated in the kernel since a long time. However, two main barriers limited its wide adoption. First, it extends a Platform Control Register (PCR) of the Trusted Platform Module (TPM) in an unpredictable way (due to parallel execution of software), making it impossible to use that PCR for sealing policies of TPM keys. Second, it requires that a file signature is added to the package header for each file to be appraised.

Digest Lists Integrity Module (DIGLIM) takes a different approach. It allows IMA to extend a PCR in a predictable way or to verify the authenticity of files by querying an in-kernel repository of authenticated reference values, built from information already available in existing packages (FILEDIGESTS section of the RPM header, with signature in the RSAHEADER section). Data source authentication does not require additional key management. With support for PGP keys in the kernel, the official Fedora PGP keys can be imported to the builtin keyring of the kernel and used to verify the PGP signature of the RPM headers.

DIGLIM is not specifically tied to IMA. Since it is based on the hash table implementation of the kernel, it can store data of different types or be used by other kernel subsystems. It might for example store fsverity digests, to achieve the goal of another proposed change with less overhead (by adding to the RPM header digests instead of signatures). It might also be used by other kernel services, such as Integrity Policy Enforcement (IPE), a new LSM being proposed for inclusion in the upstream kernel.

A preliminary performance evaluation showed that DIGLIM does not introduce a significant overhead. A repository of executables and shared libraries digests, of a Fedora 33 minimal installation, occupies less than 800k of memory.

The new feature behaves as follows. A modified kernel with the DIGLIM patches will expose to user space an interface to add/remove file digests from the kernel hash table. A user space parser, executed by the kernel during early boot, parses RPM headers found in /etc/diglim in the initial ram disk (included with a custom dracut script) and uploads them to the kernel. When a file is accessed, IMA calculates the file digest and queries it with DIGLIM. If the digest is found, no new entries are added to the measurement list and appraisal is successful. If the digest is not found, a new entry with the file digest is added to the measurement list and appraisal fails. When packages are installed or removed, the kernel hash table is kept synchronized with a new rpm plugin.

Feedback

DIGLIM has been proposed some time ago, and was previously known as IMA Digest Lists.

The original implementation was found to be too invasive, as both the management of the repository of reference values and the new measurement and appraisal mechanisms based on the query of the repository needed to coexist with the existing code. DIGLIM is now implemented as a standalone module, which includes the repository management part, and exposes a simple API so that IMA and other kernel services can use it to implement the query part (much simpler).

At the time IMA Digest Lists was published, the proposal of adding file signatures to the package header was deemed to be more mature and suitable for adoption. From previous and current discussions, it seems that Linux distribution vendors are a bit reluctant to make such change, especially due to the increased size of the packages. DIGLIM just requires a modification of the kernel, rpm and dracut, and could work on old distribution versions once the modified packages are installed.

Another remote attestation-specific issue is that the approach of measuring only unknown software reduces the amount of information available to remote verifiers for the integrity evaluation of the system being attested. In particular, a measurement list made with the DIGLIM approach does not show which file have been actually accessed and when. This tradeoff was chosen to make the PCR value extended with software measurements predictable and to allow the usage of sealing policies based on that PCR.

Benefit to Fedora

The main benefits of DIGLIM have been elaborated here.

Briefly summarizing: DIGLIM brings the benefits of kernel services for integrity detection (measurement) and protection (appraisal) to Linux distributions, and relieves the distributions from the burden of managing the integrity functionality.

More specifically, it will make a system running Fedora attestable without the need of using dedicated remote attestation protocols. In fact, the assertion that a system is running a specific set of software will be implicitly implied by the ability of that system to correctly respond to the other peer in the TLS handshake protocol. This could be achieved with widely available software such as the Apache web server, the tpm2 openssl engine and a browser. Also Keylime, a Red Hat-based solution for remote attestation, could make use of the proposed scheme.

It will also make Fedora able to detect tampering of its components at a more privileged level, the kernel, without the interference of user space programs. Once tampering has been detected, the actions of the altered component are prevented before that component gets the chance to perform any action. Fedora could be configured to also allow the usage of components provided by the user, if the user wishes to do so (DIGLIM has a tool to build custom digest lists).

Scope

• Proposal owners:
  • Maintain the following patch sets for the Linux kernel, and possibly have them accepted in the upstream kernel:
    • IMA execution policies
    • DIGLIM basic features
    • DIGLIM advanced features
    • DIGLIM integration with IMA
    • PGP keys and signatures
    • Support for PGP appended signatures
  • Port the digest_list rpm plugin from openEuler to Fedora:
  • Create dracut configuration file/module for copying RPM headers to the initial ram disk (optimization: copy only RPM headers related to files in the initial ram disk)
  • Introduce scriptto enable IMA measurement/appraisal execution policies in the boot loader configuration:

• Other developers:
  • Review the changes proposed above

• Release engineering: https://pagure.io/releng/issue/10473
  • Discuss with Release engineering team about the possibility of enabling IMA measurement and/or appraisal policies since first boot (a checkbox in Anaconda would cause the boot loader configuration to be updated to enable such policies)
  • The feature might be enabled later by the user without any change required for the image generation

• Policies and guidelines: N/A

• Trademark approval: N/A

• Alignment with Objectives: Yes

Upgrade/compatibility impact

The user should ensure that software (not updated) from the old distribution is packaged and the package header is signed, or the user should create and sign a custom digest list for the software which is to be allowed to run after the upgrade.

How To Test

DIGLIM is already available for testing. A Fedora 34 kernel package with DIGLIM is available in this copr project.

The installation instructions have been published to the linux-integrity kernel mailing list here.

User Experience

Both integrity detection and protection will be transparent for the user. For protection, the user will notice a change only if his actions (or of a malicious software on his behalf) are not in accordance with the integrity policy being enforced (e.g. the user executes an unknown binary).

Dependencies

• kernel
• rpm
• dracut

The feature owner will be responsible to submit all the changes necessary and will not depend on other developers' work.

Contingency Plan

• Contingency mechanism: remove provided patches from the packages
• Contingency deadline: rebuilding the packages without the new patches can be done at any time
• Blocks release? No

Documentation

A comprehensive documentation can be found here.

Release Notes

Release notes will be derived from the documentation.