Changes/DIGLIM

Change Proposal Name

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 appraisal.

Owner

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

Current status

• Targeted release: [[Releases/<36> | Fedora Linux <36> ]]
• Last updated: 2021-12-16
• FESCo issue: <will be assigned by the Wrangler>
• 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 for each file to be appraised in the package header.

Digest Lists Integrity Module (DIGLIM) takes a different approach. It makes it possible for 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, signed by the RSAHEADER section).

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 did 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.

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 for the burden of 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 he wishes 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
  • Port the digest_list rpm plugin from openEuler to Fedora:
    • digest_list rpm plugin
  • 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 script to enable IMA measurement/appraisal execution policies in the boot loader configuration:
    • script

• Other developers:
  • Review the changes proposed above

• Release engineering: #Releng issue number
  • 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 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 he wishes to use after the upgrade.

How To Test

A Fedora 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 unsigned binary).

Dependencies

• kernel
• rpm
• dracut

The feature owners 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

The most comprehensive documentation can be found here.

Release Notes

Release notes will be derived from the documentation.