Linux Integrity Measurement Architecture is often described as a way to verify files. The short description hides two different functions. Measurement records what was executed or accessed according to an IMA policy. Appraisal compares a file's current integrity value with a reference value stored on the system. Measurement can support later evidence; appraisal can block a file whose value does not match.
The IMA project documentation describes measurement, appraisal, and audit as related aspects that can be configured and used independently. IMA appraisal stores a good value in the security.ima extended attribute and validates the file against it. A measurement list can be signed or used with a TPM quote, but a list by itself does not prove that every file was appraised. It records what the policy measured.
This distinction matters during incident response. An operator who sees a file in the measurement log knows that the kernel evaluated it under the active policy. That is not the same as knowing the file's hash matched a trusted reference, that the trust anchor was protected, or that the application used only appraised files. A file with no appraisal result may be outside the policy, may be treated as a special case, or may have failed a check that the response team has not located.
Appraisal also depends on key management. The integrity subsystem needs trusted keys or a policy that accepts an appropriate origin. A compromised signing key can authorize a malicious file. A missing or wrong key can block a legitimate update. The team should inventory the keyring used for appraisal, the policy that selects files, and the update path that writes security.ima.
The signing boot path needs separate evidence. UEFI Secure Boot, a TPM measurement, IMA measurements, and a remote attestation service do not automatically prove one another. A TPM quote covers selected PCRs and a nonce. IMA may extend a PCR through its policy and measurement log, but a verifier still needs to inspect the event log and know which values are expected. A signed measurement list without a trusted log source is evidence with a dependency, not a conclusion.
A useful verification plan asks:
- 1.
Which IMA policy is active, and which files does it select?
- 2.
Are measurements being produced for the expected operations?
- 3.
Which files are appraised, and what key or policy anchors trust?
- 4.
Can a test binary with an invalid reference value be prevented from executing?
- 5.
Can an authorized update receive a new reference value and pass?
- 6.
Does the attestation verifier validate the nonce, log, and expected PCR state?
The strongest deployment combines measurement, appraisal, protected logs, and key lifecycle controls. The weakest one displays a green integrity status while quietly running unaudited files. The response plan should be based on the actual policy and the evidence it can produce.