Robertosassu (talk | contribs) No edit summary |
Robertosassu (talk | contribs) No edit summary |
||
| Line 3: | Line 3: | ||
== Summary == | == 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 | 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 == | == Owner == | ||
* Name: [[User:robertosassu| Roberto Sassu]] | * Name: [[User:robertosassu| Roberto Sassu]] | ||
* Email: | * Email: roberto.sassu@huawei.com | ||
== Current status == | == Current status == | ||
| Line 17: | Line 17: | ||
[[Category:SystemWideChange]] | [[Category:SystemWideChange]] | ||
* Targeted release: [[Releases/ | * Targeted release: [[Releases/36 | Fedora Linux 36 ]] | ||
* Last updated: {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} | * Last updated: {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} | ||
* FESCo issue: <will be assigned by the Wrangler> | * FESCo issue: <will be assigned by the Wrangler> | ||
| Line 24: | Line 24: | ||
== Detailed Description == | == 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 | 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 | 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 [//fedoraproject.org/wiki/Changes/FsVerityRPM 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. | 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 [//fedoraproject.org/wiki/Changes/FsVerityRPM 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 [//lore.kernel.org/linux-security-module/1634151995-16266-1-git-send-email-deven.desai@linux.microsoft.com/ Integrity Policy Enforcement (IPE)], a new LSM being proposed for inclusion in the upstream kernel. | ||
A preliminary performance evaluation showed that DIGLIM | 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, measurement is skipped and appraisal is successful. If the digest is not found, a measurement of the file is performed and appraisal fails. When packages are installed or removed, the kernel hash table is kept synchronized with a new rpm plugin. | |||
== Feedback == | == Feedback == | ||
| Line 42: | Line 44: | ||
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --> | <!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --> | ||
== Benefit to Fedora == | == Benefit to Fedora == | ||
The main benefits of DIGLIM have been elaborated [//lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sassu@huawei.com/ here]. | The main benefits of DIGLIM have been elaborated [//lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sassu@huawei.com/ here]. | ||
Briefly summarizing: DIGLIM brings the benefits of kernel services for integrity detection (measurement) and protection (appraisal) to Linux distributions, and relieves the distributions | 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.dev/ Keylime], a Red Hat-based solution for remote attestation, could make use of the proposed scheme. | 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.dev/ 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). | 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 to do so (DIGLIM has a tool to build custom digest lists). | ||
== Scope == | == Scope == | ||
| Line 59: | Line 60: | ||
*** [//lore.kernel.org/linux-integrity/20210915163145.1046505-1-roberto.sassu@huawei.com/ DIGLIM advanced features] | *** [//lore.kernel.org/linux-integrity/20210915163145.1046505-1-roberto.sassu@huawei.com/ DIGLIM advanced features] | ||
*** [//lore.kernel.org/linux-integrity/20210930115533.878169-1-roberto.sassu@huawei.com/ DIGLIM integration with IMA] | *** [//lore.kernel.org/linux-integrity/20210930115533.878169-1-roberto.sassu@huawei.com/ DIGLIM integration with IMA] | ||
** Port the | ** Port the [//gitee.com/src-openeuler/rpm/blob/master/Add-digest-list-plugin.patch 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) | ** 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 | ** Introduce [//gitee.com/openeuler/digest-list-tools/blob/master/scripts/setup_grub2 script]to enable IMA measurement/appraisal execution policies in the boot loader configuration: | ||
* Other developers: | * Other developers: | ||
| Line 79: | Line 78: | ||
== Upgrade/compatibility impact == | == 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 ensure that software from the old distribution is packaged and the package header is signed, or he should create and sign a custom digest list for the software he wishes to use after the upgrade. | ||
== How To Test == | == How To Test == | ||
| Line 87: | Line 86: | ||
== User Experience == | == 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 | 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 == | == Dependencies == | ||
| Line 95: | Line 94: | ||
* dracut | * dracut | ||
The feature | The feature owner will be responsible to submit all the changes necessary and will not depend on other developers' work. | ||
== Contingency Plan == | == Contingency Plan == | ||
Revision as of 14:26, 16 December 2021
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 secure boot at application level.
Owner
- Name: Roberto Sassu
- Email: roberto.sassu@huawei.com
Current status
- Targeted release: 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 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, measurement is skipped and appraisal is successful. If the digest is not found, a measurement of the file is performed 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 he 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:
- 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: #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 he 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 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
The most comprehensive documentation can be found here.
Release Notes
Release notes will be derived from the documentation.