Security model

What Genos protects against, what it only makes visible, and what it can't do. Read this before deciding how much to rely on it.

The short version

• Genos is tamper-evident, not tamper-proof. Root on a host can stop the enforcer. When that happens, the host goes quiet and the dashboard flags it within about 90 seconds.
• The fleet server can't touch your hosts. It only receives. Taking it over gives an attacker telemetry, not control.
• What the server shows is authenticated. Every daemon message is signed by a key that never leaves its host, so it can't be forged in transit or replayed.

What each part trusts

flowchart LR
  subgraph host["Host (trusts itself)"]
    key["Agent key<br/>never leaves"]
    d["Daemon"]
    s["Scanner"]
  end
  subgraph srv["Fleet server"]
    v["Verifies every<br/>signature"]
  end
  d -- "signed · HTTPS · server key pinned" --> v
  s -- "unsigned · checked against<br/>signed heartbeats" --> v

What Genos defends against

• Writes into protected directories without approval. A new file, rename or hard link into /etc/sudoers.d is denied in the kernel, before it happens. That's a common way to turn a foothold into full root.
• A stopped or disabled enforcer going unnoticed. Missed heartbeats, restarts and enforcing: false all raise alerts.
• Forged or replayed telemetry. Rejected, and counted as an alert.
• A planted baseline. A baseline uploaded for someone else's hostname doesn't match that host's signed heartbeats, and shows as Mismatch.

What it doesn't defend against

These are known, stated limits, not oversights:

• Unrestricted root on the host. Root can stop the daemon (the hooks detach and enforcement fails open), replace its key, or block its network. Genos turns that into a visible silence; it can't prevent it. Root can also forge telemetry for its own host, since it holds that host's key.
• Changes the enforcer doesn't cover. Today it guards one directory and three operations. Overwriting an existing file, deleting files and other sudo config locations aren't covered yet. See Remaining issues.
• Kernel, boot, firmware or hypervisor compromise.
• The scanner's plain-HTTP transport. Until the scanner supports HTTPS, its download and upload can be read or altered on the network. Its tarball hash only helps if the script itself arrived intact. The baseline cross-check catches an altered upload once the daemon reports, but use the scanner on trusted networks only for now.
• Events lost while the daemon can't reach the server. They aren't queued. The gap itself shows up as missed heartbeats.

The approval path

Approving a blocked change on the dashboard is the one place the "server only receives" rule bends, and it's bent carefully:

• The server still never connects to a host. The daemon pulls approvals from a read-only endpoint; it decides whether to honor them.
• Every approval is signed with an approver key and verified on the host against a public key provisioned out of band. A random approval the host didn't ask for, or one that fails the host's wasm policy, is rejected.
• An approval opens exactly one file for a bounded window (at most 15 minutes), not the directory.

PoC caveat: for now the approver private key lives on the fleet server, so taking over the server could approve changes. Before production the signing must move to an approver that isn't the server. Until then, the approval feature is for demos and trusted operators only.

Data the server holds

The server never receives file contents, secrets or command output. The scanner reads metadata only.