An AIDE alternative for when root is the adversary

People come looking for an AIDE alternative for two very different reasons. The first is ordinary: AIDE is noisy, the daily mail is unreadable, the database update dance is tedious. That's a usability complaint, and there are plenty of usability answers.

The second reason is the one worth writing about. Someone has thought carefully about their threat model, written down “attacker obtains root on the monitored host,” and then realised that the tool meant to detect exactly that is a userspace program on the host the attacker now owns. Once you've noticed it, no amount of tuning makes it go away. This post is for that second reason.

To be clear up front, because this is a criticism of a design and not of a project: AIDE, Tripwire and Samhain are careful, long-lived tools that do what they say. They compare files against known-good hashes and tell you what changed, and for the failure mode that actually happens most often — a botched deploy, a hand-edited config, a package that drifted — they work. What follows is about a specific adversary they were never structurally able to beat, and what a design has to change to beat it.

The move set

Five things root does, in the order it does them

Assume an attacker has just obtained root on a host running a classic on-host integrity checker. They aren't in a hurry, they've read the config, and they'd like their change to /usr/sbin/sshd to stay quiet. Here's the sequence, and for each move, what happens against a design that keeps the measurement in hardware and the verdict off the box.

# the modified binary is now the new "known good"
# aide --init
# mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# next scheduled run, from the checker's own point of view:
# aide --check
AIDE found NO differences between database and filesystem. Looks okay!!

The shape of the fix

What an alternative actually has to change

Walking the moves in order makes the requirement fall out. It isn't a better hash, a stealthier agent, or a cleverer local database — moves 01 through 05 go through all of those. It's three relocations, all in the same direction: take the thing being trusted off the machine being judged.

• The measurement moves into hardware. IMA hashes files in the kernel and extends into TPM PCR 10; the register is append-only, so history can't be rewritten (defeats 02 and 04).
• The evidence is signed by a key the host can't reach. A verifier sends a fresh random nonce and the agent returns a TPM quote: a signed statement of the current PCR values with that nonce folded in, signed by an attestation key whose private half never leaves the chip. Root can relay the real answer or refuse; it cannot compose a clean one, and the nonce means it can't replay a clean one captured before the compromise (defeats 03).
• The verdict is rendered elsewhere. A separate, independently administered verifier holds the baseline, does the comparing, and is the only place an alarm can fire (defeats 01 and 05).

The step that ties the cryptography to something a human can read is the one worth naming: the verifier replays the IMA measurement log and recomputes PCR 10, then checks the result against the value the TPM just signed. The log is the readable list of which files were measured and what they hashed to; the quote is the hardware's signature over the register. Replaying binds them. A host cannot hand over a tidy log that disagrees with its own signed PCR. If you want that argument in full — including why “tamper-proof” is the wrong word and tamper-evident is the right one — there's a separate post on it.

The boundary

What happens when the attacker gets into the kernel

Move 04 said IMA measures below userspace. The obvious next question is what happens when the attacker doesn't stay in userspace — and the honest answer is that a kernel-mode compromise is above IMA, because IMA is the kernel. An attacker executing in kernel context can stop new measurements from being extended. Pretending otherwise would be the same over-claim this post started by objecting to.

Two things remain true anyway, and they're worth being precise about. First, what is already in the PCR cannot be removed: a register that only extends has no undo, so the record up to the moment of the kernel compromise is fixed in hardware and already bound to signed quotes the verifier holds. Second, crossing into the kernel usually means loading a module or booting a new kernel — and the shipped IMA policy measures exactly those transitions (MODULE_CHECK, KEXEC_KERNEL_CHECK, KEXEC_INITRAMFS_CHECK, plus additions to the trust-anchor keyrings), alongside executions and reads. So the act of crossing the line tends to leave a permanent, hardware-anchored trace before the attacker is in a position to suppress anything. After that, their options narrow to going quiet — and going quiet is move 05, which the verifier already treats as a finding.

The rest of the boundary, stated plainly and unchanged from everywhere else we state it: this defends against remote and software-level root compromise. It does not defend against physical attacks — cold-boot, evil-maid, desoldering or interposing the TPM. It does not cover below-TPM firmware implants, or a compromised hypervisor presenting a virtual TPM, where the chip signs a truthful signature over a lie. And the verifier itself becomes a high-value target: compromise it and you can suppress alarms just as effectively as the model it replaces, which is why hardening it is its own piece of work.

The honest other side

Where AIDE still earns its keep

Which makes the pragmatic answer to “should I replace AIDE?” less dramatic than the framing suggests: run both, for a while, on the hosts that justify it. They fail in different directions. AIDE is excellent at the everyday drift question and costs nothing to keep; hardware-rooted attestation answers the question AIDE structurally cannot, on the subset of machines where an attacker with root is a threat you've actually written down. Running in parallel through one full patch cycle is also the most honest way to evaluate the newer thing — the disagreements between them are the interesting output.

The full feature-by-feature comparison, including where this design is behind, is on the comparison page.