The one host that actually holds the trust.

One fact worth knowing before anything else: etminan-verifier never listens for inbound network connections at all — it only ever connects out to each agent (mTLS) and, if you use it, to fetch the plugin catalog. That means the firewall section near the bottom of this page isn't a compromise; a verifier host genuinely needs zero inbound ports open except whatever you use for administration (SSH, almost always).

Every trust-changing etminan-verifier command is signed and audited — but only if it's actually reached through the CLI. A full interactive shell on this box can bypass all of that: edit baseline.db directly with sqlite3, read the operator signing key off disk, or tamper with state.json, none of which the signed/audited command surface would ever allow. If an operator account only ever needs to run etminan-verifier commands remotely, don't give it a general- purpose login shell at all.

The simplest version: an SSH Match block that forces every connection for that account straight into etminan-verifier, regardless of what the client actually requested:

Match User etminan-operator
    ForceCommand /usr/bin/etminan-verifier $SSH_ORIGINAL_COMMAND
    X11Forwarding no
    AllowTcpForwarding no
    PermitTTY no

$SSH_ORIGINAL_COMMAND is whatever the client asked for after ssh operator@host — e.g. ssh etminan-operator@verifier-host baseline review arrives here as baseline review, and ForceCommand runs exactly etminan-verifier baseline review, nothing else. An empty original command (a bare interactive ssh, no arguments) still only ever reaches etminan-verifier with no arguments — which, per its own usage banner, just prints help and exits, never a shell.

PermitTTY no closes the one gap ForceCommand alone doesn't: without it, a client can still request a pseudo-terminal and get an interactive-feeling session driving the forced command, which matters little for a one-shot CLI but costs nothing to close.

This recipe follows standard, documented sshd_config mechanics (Match/ForceCommand are long-established OpenSSH features) but hasn't been re-verified against a live login as part of writing this page — treat it as a correct starting recipe to test yourself before relying on it, not as something this session confirmed end-to-end on a real host.

deploy/etminan-verifier.service already runs as a dedicated, unprivileged user with NoNewPrivileges=true and only the two capabilities it actually needs (CAP_SETUID/CAP_SETGID, to drop plugin children to their own sandboxed user — see the Plugin API). It doesn't yet use systemd's own filesystem/ namespace sandboxing directives, which cost nothing extra to add and meaningfully shrink what a compromised etminan-verifier process could reach even before an attacker gets anywhere near a real shell:

[Service]
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/etminan-verifier
ProtectKernelModules=true
ProtectKernelLogs=true
ProtectControlGroups=true
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
MemoryDenyWriteExecute=true
LockPersonality=true

ProtectSystem=strict makes the entire filesystem read-only to this unit except ReadWritePaths — the one directory it actually writes to (baseline.db, state.json). MemoryDenyWriteExecute blocks the classic write-then-execute exploitation pattern in-process, on top of the filesystem-level noexec /tmp above.

audit_log's hash chain proves nothing was quietly edited or reordered within the file as it exists now — but an attacker with raw write access to baseline.db itself could delete a row and recompute every hash after it into a fully self-consistent replacement chain that baseline verify-signatures would never flag. This is a stated, accepted limitation of the design (see Architecture & design), not an oversight — the fix is to periodically publish the chain's current head hash somewhere outside this file, so a rewrite has to explain away a value it can no longer reach back and change:

--print-chain-head doesn't exist in etminan-verifier today — this section documents the intended shape of the fix (per the residual-risks note it closes), not a shipped command. Filed as its own roadmap item; the recipe above is what to wire up once it lands.

As noted at the top of this page, etminan-verifier only ever makes outbound connections (to each agent, and to the plugin catalog if you use it) — it has no listening socket of its own to protect. A default-deny inbound firewall that allows only SSH is the correct posture, not an inconvenience:

#!/usr/sbin/nft -f
flush ruleset
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 ct state new limit rate 10/minute accept
  }
  chain forward { type filter hook forward priority 0; policy drop; }
  chain output { type filter hook output priority 0; policy accept; }
}

output stays permissive here on purpose — this host needs to reach every enrolled agent's address, which isn't a fixed, enumerable list this firewall should try to hardcode. If your environment can enumerate every agent's address ahead of time, restricting outbound to exactly those destinations is a further, legitimate tightening beyond this baseline.