Documentation/admin-guide/device-mapper/dm-ima.rst

Source file repositories/reference/linux-study-clean/Documentation/admin-guide/device-mapper/dm-ima.rst

File Facts

System
Linux kernel
Corpus path
Documentation/admin-guide/device-mapper/dm-ima.rst
Extension
.rst
Size
32705 bytes
Lines
716
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

======
dm-ima
======

For a given system, various external services/infrastructure tools
(including the attestation service) interact with it - both during the
setup and during rest of the system run-time.  They share sensitive data
and/or execute critical workload on that system.  The external services
may want to verify the current run-time state of the relevant kernel
subsystems before fully trusting the system with business-critical
data/workload.

Device mapper plays a critical role on a given system by providing
various important functionalities to the block devices using various
target types like crypt, verity, integrity etc.  Each of these target
types’ functionalities can be configured with various attributes.
The attributes chosen to configure these target types can significantly
impact the security profile of the block device, and in-turn, of the
system itself.  For instance, the type of encryption algorithm and the
key size determines the strength of encryption for a given block device.

Therefore, verifying the current state of various block devices as well
as their various target attributes is crucial for external services before
fully trusting the system with business-critical data/workload.

IMA kernel subsystem provides the necessary functionality for
device mapper to measure the state and configuration of
various block devices -

- by device mapper itself, from within the kernel,
- in a tamper resistant way,
- and re-measured - triggered on state/configuration change.

Setting the IMA Policy:
=======================
For IMA to measure the data on a given system, the IMA policy on the
system needs to be updated to have following line, and the system needs
to be restarted for the measurements to take effect.

::

 /etc/ima/ima-policy
    measure func=CRITICAL_DATA label=device-mapper template=ima-buf

The measurements will be reflected in the IMA logs, which are located at:

::

 /sys/kernel/security/integrity/ima/ascii_runtime_measurements
 /sys/kernel/security/integrity/ima/binary_runtime_measurements

Then IMA ASCII measurement log has the following format:

::

 <PCR> <TEMPLATE_DATA_DIGEST> <TEMPLATE_NAME> <TEMPLATE_DATA>

 PCR := Platform Configuration Register, in which the values are registered.
       This is applicable if TPM chip is in use.

 TEMPLATE_DATA_DIGEST := Template data digest of the IMA record.
 TEMPLATE_NAME := Template name that registered the integrity value (e.g. ima-buf).

 TEMPLATE_DATA := <ALG> ":" <EVENT_DIGEST> <EVENT_NAME> <EVENT_DATA>
                  It contains data for the specific event to be measured,
                  in a given template data format.

 ALG := Algorithm to compute event digest
 EVENT_DIGEST := Digest of the event data
 EVENT_NAME := Description of the event (e.g. 'dm_table_load').

Annotation

Implementation Notes