Linux IMA: building evidence for file integrity, not just alerts
A Linux host can detect that a process opened a dangerous file after the event, but detection alone does not answer whether the executable or configuration file was the version the system expected. The Integrity Measurement Architecture, or IMA, gives Linux a way to collect and, when configured, enforce evidence about file integrity. Its value comes from separating measurement from appraisal and from connecting both to a trust decision.
IMA is implemented in the kernel and uses policy to decide which files are measured or appraised. Measured files produce records that can be stored in a measurement list and extended into a TPM PCR. Appraisal evaluates a file against trusted metadata, such as a signature, before allowing access. These are related controls, but they answer different questions.
Measurement records what happened
An IMA measurement record describes a file and its digest. The measurement list can be read locally, while a TPM quote can attest to the state of the PCR that contains the measurement chain. That makes a measurement useful for evidence: an administrator or remote verifier can compare the measured boot and runtime state with a known-good baseline.
Measurement does not block a modified file by itself. If an attacker changes a binary and the host policy measures it, the resulting record may expose the change during later analysis, but the file may already have run. Measurement also depends on policy coverage. Files that the policy does not select will not appear in the log simply because the system has IMA enabled.
The operational question is therefore not “is IMA on?” It is “which files are covered, where is the evidence retained, who can verify it, and what happens when it differs from the baseline?”
Appraisal makes trust explicit
IMA appraisal checks a file's integrity metadata against keys that the kernel trusts. A signed file or a file whose extended attributes match a known digest can pass appraisal; a file that does not meet the policy can be denied. The exact rules depend on kernel configuration, policy, and the tools used to sign or label files.
This control is strongest when the trusted key set is managed separately from the files being protected. If an attacker can alter both a file and the key used to validate it, appraisal becomes a consistency check rather than a trust boundary. Protect signing keys, kernel command-line settings, policy files, and the root of trust used to establish the boot state.
Appraisal also creates an availability risk. A package update, configuration-management change, or emergency patch can invalidate a signature or metadata label. A strict policy may then prevent a critical daemon from starting. Teams need a tested recovery path that does not require disabling appraisal across the fleet.
Start with a narrow file set
Begin with a small set of high-value files whose owners and update processes are known: privileged executables, system authentication components, security agents, and critical configuration files. Record the baseline digest for each item and identify the process that is allowed to update it.
Use measurement first to learn how the files change during normal operations. Package updates, container image changes, and configuration management may produce expected differences. A baseline that treats every change as malicious will quickly become noise.
When the evidence is stable, introduce appraisal for a subset and define the failure behavior. Test updates in a representative environment, including recovery from a failed boot or a denied service. Confirm that logs identify the file, policy result, and reason without exposing sensitive file contents.
Keep attestation and authorization separate
A valid TPM quote can show that a set of measurements was recorded by a TPM, but it does not automatically decide whether a device should receive access to a sensitive application. The authorization system still needs a policy that maps measurements, device identity, user context, and network posture to an allowed action.
Store the measured baseline and verification policy outside the machine being evaluated. If the endpoint can rewrite the baseline and the rule that accepts it, the evidence is not independent. Limit who can update the reference values, log changes, and retain enough history to distinguish a planned deployment from an unexpected modification.
There is also a timestamp and freshness problem. A quote proves the state at the time of the quote. A verifier should reject stale evidence and bind the response to a challenge so that a previously valid response cannot be replayed. Record the challenge, quote, policy version, and decision together.
Investigate differences with a timeline
When a file fails appraisal or appears with an unexpected measurement, collect the package history, change tickets, process execution records, and login activity around the event. Compare the file path and digest with the deployment record rather than relying only on the file name. Attackers can replace a trusted path or leave the original file in place while changing a dependency.
Check whether the key used for appraisal changed, whether the IMA policy was reloaded, and whether the TPM quote verifies against the expected PCR values. A failure in any of those layers can look like a file-integrity event even when the file itself is unchanged.
Preserve the original measurement log and quote before remediation if policy allows. Removing a suspicious file without retaining evidence may make the cause impossible to determine.
Use IMA as one layer
IMA supports measurement, appraisal, and attestation, but it does not replace least privilege, package provenance, secure boot, or runtime monitoring. It tells you about selected files and the chain of measurements that the kernel and TPM can support. It does not prove that every process is benign or that an approved binary has no exploitable behavior.
A mature deployment pairs IMA with a maintained file inventory, signed software delivery, protected update credentials, centralized evidence retention, and a review process for trust-anchor changes. The control becomes useful when the evidence has a named consumer and the organization can act on a mismatch without guessing.
Top comments (0)