A file can have ordinary read or execute permission and still fail an integrity check at the kernel boundary. Linux Integrity Measurement Architecture (IMA) appraisal can apply policy rules at selected hooks and require file content to agree with integrity metadata before the covered operation proceeds. This adds a content-integrity condition to access decisions without turning Unix mode bits or application authorization into integrity mechanisms.
IMA contains related but distinct functions. Measurement records file state in an integrity measurement list and can extend measurements into a TPM. Appraisal evaluates a file against integrity metadata and can reject access when policy and enforcement mode require a valid result. Audit records security-relevant state. A deployment that only measures files gains evidence about observed state; it does not automatically gain the blocking behavior associated with appraisal.
Policy selects the files and hooks that receive appraisal
IMA policy is the boundary that determines which objects are subject to a given action. Rules can select operations and object attributes such as filesystem identity, file ownership, or other supported policy fields. Appraisal is therefore not a universal property attached to every file merely because IMA is enabled in the kernel.
The hook matters because integrity is checked in relation to an operation. Policies can cover execution, memory mapping for execution, file reads, module loading, firmware loading, and other supported function classes depending on kernel configuration and policy syntax. A claim such as “executables are appraised” is only as broad as the rules and hooks that actually select those accesses.
This scope is especially important on systems with multiple filesystems. A policy may intentionally exclude pseudo-filesystems or mutable data areas while requiring appraisal for a controlled software tree. The resulting security property is selective: access through a covered hook to a covered object receives appraisal. Objects outside that selection remain governed by the other access-control mechanisms in the system.
security.ima carries the integrity value used by appraisal
IMA commonly stores integrity metadata in the security.ima extended attribute. Depending on policy and configuration, that metadata can represent a file hash or a digital signature over a file hash. The appraisal path calculates or obtains the current file digest and evaluates it against the expected integrity information.
A hash xattr can detect content changes relative to the stored digest, but the digest and file may be writable by an actor with sufficient authority. A signature changes that trust model. With signature appraisal, the verifier relies on a trusted key and a valid signature rather than accepting an arbitrary replacement digest as authoritative.
That distinction separates integrity checking from authenticity. A matching mutable hash can establish consistency between two values under the assumptions of the deployment. A signature can bind the approved digest to possession of a signing key, provided the verification key is trusted and the signing key remains controlled. Neither form proves that the file is safe software; it proves only the integrity property represented by the selected metadata and trust anchors.
Keyrings define which signatures count as trusted
Signature appraisal depends on keys available to the kernel through the relevant integrity keyrings. The exact key-loading path depends on boot configuration, kernel configuration, platform trust, and deployment tooling. A signature produced by an arbitrary key does not become acceptable merely because its cryptography is valid.
This places key enrollment inside the security boundary. If an attacker can add an untrusted signing key to a keyring accepted for appraisal, valid signatures no longer separate approved content from attacker-controlled content. Conversely, a system that cannot load the required verification key may reject correctly signed files once enforcement is active.
Operational key rotation therefore has two sides: distributing new signatures and arranging trust in the corresponding verification key. Removing an old key before all required files have migrated can create availability failures. Retaining obsolete keys longer than intended expands the set of signatures the system may still accept.
Appraisal failure behavior depends on enforcement state
IMA can be deployed in modes that record appraisal problems without necessarily blocking the operation, as well as configurations that enforce appraisal failures. This difference is central during rollout. Audit evidence that a file would fail appraisal is not equivalent to a kernel-enforced rejection.
Enforcement also exposes metadata lifecycle problems quickly. A legitimate package update changes file contents, so integrity metadata must be updated through an authorized path. Copying files through tools or filesystems that do not preserve required extended attributes can leave content present but appraisal metadata absent. Restoring from backup can produce the same mismatch if integrity xattrs are omitted.
For that reason, package installation, image construction, backup, restore, and filesystem migration all participate in the integrity pipeline. The kernel can enforce the final condition, but it cannot make an incomplete software distribution process produce valid metadata.
Mutable files require a different integrity model
Static executable trees are a natural fit for signature appraisal because approved content can be signed before deployment and then treated as immutable by policy. Frequently modified application data has different requirements. Requiring a pre-existing signature after every legitimate write would need a trusted signing path for each update, which can be incompatible with the application’s threat model.
IMA policy can separate these classes rather than applying one rule to every object. That separation also prevents an integrity mechanism intended for trusted software from becoming a general-purpose substitute for file ownership, application-level authorization, or database consistency controls.
Writable executable locations deserve particular attention. If a privileged update service can replace an executable, the security boundary includes both the appraisal requirement and the path that supplies new valid integrity metadata. Restricting writes without controlling signature issuance leaves a different boundary from controlling signatures without restricting replacement operations.
Appraisal and EVM protect different integrity surfaces
IMA appraisal primarily addresses file content integrity represented by IMA metadata. Extended Verification Module (EVM) addresses integrity of selected file metadata, including security-sensitive extended attributes, using an HMAC or signature depending on configuration. The two mechanisms can be combined, but they are not interchangeable.
This matters when the security decision depends on metadata that could otherwise be altered independently of file contents. Protecting a content digest does not by itself authenticate every inode attribute. Likewise, protecting metadata does not replace a content appraisal rule. Deployment claims need to identify which properties are covered by IMA, which are covered by EVM, and which remain protected by filesystem permissions or another kernel subsystem.
Integrity enforcement is only as broad as its trust chain
IMA appraisal can move a content-integrity decision into the kernel path for selected file operations. Its effective boundary spans more than the digest calculation: policy chooses the hooks, security.ima supplies integrity metadata, keyrings define trusted signers for signature appraisal, update tooling maintains valid metadata, and enforcement state determines whether failure blocks access.
A system can therefore have IMA enabled while providing a much narrower property than its operators expect. Measurement without appraisal, appraisal without enforcement, incomplete policy coverage, or uncontrolled signing authority each changes the result materially. Precise deployment claims should state the covered operations, protected file set, integrity metadata form, key trust path, and failure mode.
The useful security property is not simply that a file has a hash or signature. It is that a policy-covered operation reaches a kernel appraisal point where the current object must satisfy integrity metadata anchored in a trust path the deployment actually controls.