FAQ

Frequently asked questions about deploying and operating Etminan. See the Glossary for terms.

What problem does Etminan actually solve?

It gives you host-integrity attestation that survives a full root compromise of the monitored host. The whole design defends one property: a fully root-compromised monitored host cannot forge a "genuine" verdict, nor silently suppress an alarm. It does this by splitting the job across two independently administered binaries and never letting a host judge itself.

How is that different from AIDE, Tripwire, or Samhain?

Those tools run on the host they check, so a root attacker can disable them or feed them a doctored view. Etminan measures from the kernel (Linux IMA) and seals the result in hardware (the TPM), and the pass/fail decision is made by a separate verifier device that replays the log and compares it to the TPM-signed quote. The host never judges itself.

Do both machines need a TPM?

No. The agent runs on each monitored host and needs a TPM 2.0. The verifier needs no TPM — quote verification is pure offline signature math. The verifier even builds and runs on macOS for development.

Does the verifier open any inbound ports?

No. etminan-verifier only ever connects out — to each agent, and optionally to fetch the plugin catalog. A verifier host correctly needs zero inbound ports except whatever you use for administration (SSH). See Hardening.

What happens if the verifier itself is compromised?

That is the accepted trust boundary: DB + operator access on the verifier host is where the design stops defending — a fully compromised verifier can suppress alarms regardless. Two things mitigate it: harden that specific host (Hardening), and the action log is hash-chained with its head anchored outside the database in a .audit-head file, so rewriting history or rolling back the log is tamper-evident and detectable. See The audit log.

Is Standard open source?

No. Standard is free of charge and self-hosted, but it is not open source and not "open core" — the source repository is private. See Editions.

What do I get with Enterprise?

SIEM output (CEF/LEEF over syslog) and dual control / four-eyes approval. It is one codebase — Enterprise is a compile-time feature that strictly adds capability; Standard behaviour is unchanged. (RBAC and the admin/operator/viewer roles are part of Standard, not Enterprise.) See the capability matrix.

Which distributions are supported?

Packaged builds target .deb for Debian 12/13 and Ubuntu LTS 22.04/24.04, and .rpm for Enterprise Linux 9/10 (Alma, Rocky, RHEL). EL8 is dropped — its tpm2-tss is too old. The verifier is portable; the agent is built per distro.

Can I run more than one verifier against the same host?

Not active-active. The per-host IMA-log cursor is a single position; two verifiers polling the same host would double-advance and desync it — a correctness hazard, not a scaling knob. The committed resilience model is a replicated warm standby with manual fenced failover, not two live verifiers.

Why did my first check right after enrollment report PcrDigestMismatch?

That is the known enroll → first-check cursor gap: the verifier replays from its stored cumulative value while the agent sends the full log from offset 0. It self-corrects (the verifier resets to 0 on an offset regression) — re-run check. Persistent mismatches across cycles are genuine findings. See Troubleshooting.

A host keeps saying it's "catching up" — is that bad?

A genuine backlog clears in a finite number of cycles. A host still catching up past ETMINAN_MAX_CATCHING_UP_CYCLES is a wedged agent — or a compromised host feeding a fabricated log_truncated delta to suppress the mismatch alarm — and Etminan alarms rather than staying silent. Investigate that agent.

Why does the agent need CAP_DAC_READ_SEARCH instead of just running as root?

The IMA measurement log is root:root 0440 by kernel design; no group membership grants read access. Rather than run the whole agent as root, the systemd unit grants exactly AmbientCapabilities=CAP_DAC_READ_SEARCH — the narrowest capability that bypasses the read-permission check. The agent otherwise runs as an unprivileged tss-group user and uses /dev/tpmrm0.

How do I test that alerts actually fire before a real incident?

Use etminan-verifier notify-preview (renders templates, sends nothing) and etminan-verifier notify-test --channel <name> (sends one synthetic finding through the real plugin and reports its exit status). run also re-verifies every plugin each cycle, so a broken channel alarms on its own.

What must I back up, and what can't be recovered?

Back up the verifier trust store (a WAL-safe baseline.db snapshot + its .audit-head, state.json, tls/, /etc/etminan-verifier) and, separately and off-host, the etminan-verifierd daemon signing key. TPM AK/EK material cannot be backed up — a TPM clear forces re-enrollment of that host regardless. See Backup & restore.

How do I rotate certificates and keys?

• Agent TLS: etminan-agent keygen-tls, then op rotate-tls on the verifier to re-pin.
• Verifier's own TLS: keygen-tls, update ETMINAN_VERIFIER_CERT_FINGERPRINT in every agent's agent.env, then restart each agent — in that order.
• Host AK (same TPM): op rotate-ak.

Both rotations are op-mediated trust-changing actions, authenticated by peer-UID and appended to the signed audit log.

Where is the authoritative reference for a command or setting?

The CLI reference and Configuration reference here, plus <binary> <subcommand> --help in the terminal and the man pages for the deepest detail.