F36 Change: DIGLIM (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://fedoraproject.org/wiki/Changes/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: [[User:robertosassu| Roberto Sassu]]
* Email: roberto.sassu@xxxxxxxxxx


== 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
[//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@xxxxxxxxxxxxxxxxxxx/
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 [//pagure.io/fesco/issue/2547 previous]
and [//lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/JE2HGLJMLEKUJW3YBP6MQJWP43CSTC57/
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
[//lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sassu@xxxxxxxxxx/
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.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 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:
*** [//lore.kernel.org/linux-integrity/20210409114313.4073-1-roberto.sassu@xxxxxxxxxx/
IMA execution policies]
*** [//lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sassu@xxxxxxxxxx/
DIGLIM basic features]
*** [//lore.kernel.org/linux-integrity/20210915163145.1046505-1-roberto.sassu@xxxxxxxxxx/
DIGLIM advanced features]
*** [//lore.kernel.org/linux-integrity/20210930115533.878169-1-roberto.sassu@xxxxxxxxxx/
DIGLIM integration with IMA]
*** [//lore.kernel.org/linux-integrity/20181112102423.30415-1-roberto.sassu@xxxxxxxxxx/
PGP keys and signatures]
*** Support for PGP appended signatures
** 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)
** 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:
** 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 he
should create and sign a custom digest list for the software he wishes
to use after the upgrade.

== How To Test ==
DIGLIM is already available for testing. A Fedora 34 kernel package
with DIGLIM is available in this
[//copr.fedorainfracloud.org/coprs/robertosassu/DIGLIM/ copr project].

The installation instructions have been published to the
linux-integrity kernel mailing list
[//lore.kernel.org/linux-integrity/48cd737c504d45208377daa27d625531@xxxxxxxxxx/
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
[//lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sassu@xxxxxxxxxx/
here].

== Release Notes ==

Release notes will be derived from the documentation.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux