Skip to content
LinuxDeep Dive Published Updated 7 min readViews unavailable

Linux IMA Appraisal: Policy-Gated File Integrity and Measurement Records

Separate Linux IMA measurement, audit, and appraisal; inspect policy and records, then stage signature enforcement without locking out updates.

Linux’s Integrity Measurement Architecture (IMA) is a kernel framework for measuring selected files and, when configured, appraising their integrity against policy. Those are related but different operations. Measurement records a digest and associated template data; appraisal evaluates whether a file satisfies an integrity rule at a selected kernel hook. A runtime measurement list is not by itself a verdict that the machine is trustworthy, and a hash stored beside a file is not automatically proof of who published it.

IMA is also not the same layer as dm-integrity or fs-verity. dm-integrity protects block-device data structures, and fs-verity verifies reads of files explicitly enabled for it. IMA chooses kernel events and policy actions and can use ordinary file digests or, in supported configurations, fs-verity digests and signatures. Choose the component based on the threat model; stacking features does not remove the need to provision keys, define covered files, and plan recovery.

Separate the policy actions

IMA policy rules match hooks and conditions such as access type, owner, filesystem, or LSM labels. The kernel ABI documents actions including measure, appraise, and audit, along with exclusions such as dont_measure and dont_appraise. A rule’s action and match conditions determine which accesses are considered; the existence of IMA support in the kernel does not mean that every file is measured or appraised.

Action Operational meaning What it does not prove
measure Collect a file measurement and add a template record to the runtime list; a configured TPM path can extend a PCR aggregate. It does not reject the file or identify an authorized publisher by itself.
appraise Check the file’s integrity metadata against the collected content measurement and any required signature type at the selected hook. It does not cover files, hooks, or access paths excluded by policy.
audit Request integrity-related audit handling for matching events. It is not a replacement for measurement or signature enforcement.

The kernel’s policy ABI is the source of truth for rule syntax. For example, func=BPRM_CHECK selects the binary-execution check, while FILE_CHECK covers selected file operations. Conditions can constrain rules by fields including filesystem UUID, owner, access mask, and LSM subject or object labels. appraise_type can specify the accepted IMA signature format, and digest_type=verity selects an fs-verity digest where supported.

An illustrative pair of rules is:

measure func=BPRM_CHECK
appraise func=BPRM_CHECK appraise_type=imasig

This is syntax to study, not a production policy. The second rule can make execution depend on valid signatures for the selected hook, and a machine without the expected file metadata and trusted public keys may fail to start services or run updates. The exact effective policy can include built-in rules, boot-time configuration, and rules loaded through securityfs. Inspect the target kernel and distribution policy before changing any input.

Understand what the xattr and key prove

Appraisal commonly uses the security.ima extended attribute. A hash form can be compared with the file’s current measurement; a signature form can be verified using an appropriate trusted IMA key. The kernel appraisal implementation calls EVM xattr verification for security.ima and, following successful verification, compares the xattr’s hash with the collected measurement. This is a check of the bytes and metadata presented to the kernel under the active policy.

A hash-only xattr does not establish publisher identity. If an attacker can replace both file contents and the expected unsigned digest, matching values do not prove that the replacement was authorized. Signature appraisal adds a trust decision based on keys available to the kernel. Plan the trust chain separately: who holds the signing private key, how public keys reach the kernel’s trusted IMA keyring, how revocation is handled, and which package or image process regenerates signatures after legitimate updates.

EVM is related but has a separate role in protecting integrity metadata. Do not assume that enabling IMA automatically gives every extended attribute an authenticated provenance, or that every filesystem supports the required xattr operations. Test the filesystem and deployment tooling that will carry the files. Where fs-verity is used, the IMA policy can select its digest, but that does not make IMA’s policy identical to fs-verity’s per-file read verification.

Inspect the running policy before changing it

Record the exact kernel, command line, and securityfs state first:

uname -a
cat /proc/cmdline
test -r /sys/kernel/security/ima/policy &&
  sed -n '1,100p' /sys/kernel/security/ima/policy
test -r /sys/kernel/security/ima/ascii_runtime_measurements &&
  sed -n '1,12p' /sys/kernel/security/ima/ascii_runtime_measurements

The paths may be absent when the kernel lacks IMA support or securityfs is unavailable or not mounted. Absence is not proof that the distribution has no integrity controls; inspect the kernel configuration and boot documentation as well. The kernel parameter reference lists ima_appraise= modes (off, enforce, fix, and log) and built-in policies selected with ima_policy=. These parameters are conditional on kernel support and must be read together with the policy. Do not infer enforcement from a single command-line token or change a boot parameter on a production system without a tested rollback route.

The ASCII measurement list is a runtime record, not a pass/fail report. IMA templates determine which fields appear; for example, the ima-ng format includes a digest and a name, while signature templates add signature data. A changed template changes record shape and can affect downstream parsers. Preserve the template, kernel version, policy, and PCR selection alongside an exported log so a verifier can interpret the evidence.

When TPM measurement is configured, IMA can maintain an aggregate in a platform configuration register and remote attestation can use a quote tied to that register. Attestation still requires validating the quote, reconstructing the expected measurement sequence, and evaluating policy outside the machine. Reading a local text file does not provide the same assurance: a privileged local attacker may alter the environment or the evidence collector.

Stage appraisal as a policy rollout

Start in a disposable VM or image built from the same kernel and package sources as the intended target. Inventory the selected policy hooks, filesystems, keyrings, signed artifacts, and application update path. Use a narrow test rule against a noncritical fixture before considering boot-critical executables, modules, firmware, or initramfs content. Keep an out-of-band console, known-good kernel entry, and recovery image available before any enforcing experiment.

Test at least four states: an unchanged valid file, a modified file with a stale digest, a missing security.ima attribute, and a file signed by a key that is not trusted by the test kernel. Capture both the access or execution result and the kernel audit/integrity messages. Then exercise a legitimate package update and reboot: the updater must install the new content and matching metadata in the correct order, and the boot policy must accept it. A clean test on one executable is not evidence that every service or module path is covered.

Use ima_appraise=log as a deliberate non-enforcing observation phase in an isolated environment; do not mistake a successful observation run for a signature rollout. Do not group fix with observation modes: the upstream implementation inspected here can write a replacement unsigned digest to security.ima when appraisal metadata is absent or does not match. On the no-label path, it can also update security.evm with an HMAC when EVM fix-mode prerequisites are met. This mutates filesystem metadata; it does not create publisher signatures or prove provenance. Test ima_appraise=fix only as an intentional repair operation on a controlled writable fixture or image, after preserving a baseline of its original xattrs. Distro-specific setup, initramfs generation, and key provisioning remain part of the system’s deployment contract.

For each rollout, save a read-only baseline of the active policy, kernel version/configuration, boot parameters, trusted key identifiers, and a bounded measurement sample. Define expected denials and a way to distinguish them from ordinary DAC, LSM, filesystem, or application failures. Monitor the update and rescue paths as closely as normal execution. The useful result is not “IMA is enabled”; it is a known set of hooks and files whose measurements and appraisal decisions can be explained and recovered.

Related:

Sources:

Comments