Security · Threat model

Linux Identity threat model

We modelled threats before writing code. This page is the public version: trust zones, attacker capabilities, twelve threats with mitigations, detection, and recovery. If something is wrong or unclear, email security@linuxidentity.com.

Back to Security overviewLast reviewed May 2026 (founder-approved)

Trust model — three zones

01 · most sensitive

Customer fleet

Linux hosts running our agent and the customer’s sshd. Trusts the SSH CA public key (installed via agent registration), the agent binary’s signature, and OpenSSH cert validation.

02 · sensitive, recoverable

Linux Identity control plane

Multi-tenant SaaS. Holds the SSH CA private key in a managed KMS, the audit log, customer config, and billing. Compromise is bad; recovery is well-rehearsed.

03 · external dependency

Identity provider

Customer’s existing OIDC IdP (Okta / Google / Entra). We trust SSO assertions; we don’t store passwords. We verify token signatures on every cert request.

Attacker capabilities we model against

We enumerate the attackers, not just the attacks. Each threat below is grounded against one or more of these.

Who	Capabilities
External unauthenticated	Network access to control-plane endpoints; ability to attempt OIDC flows; can discover us via DNS and certificate transparency.
Authenticated tenant (other customer)	Valid account in their own tenant; can call any API.
Authenticated user (insider in customer org)	Valid SSO; valid cert-issuance flow; basic shell access on enrolled hosts.
Compromised host	Root on one customer host; agent binary readable; agent local cache readable.
Compromised agent supply chain	Malicious code injected into agent release.
Compromised Linux Identity operator (us)	Any single Linux Identity engineer with production access.
Stolen vendor credentials (Linear, GitHub, cloud)	One vendor account compromised.

Twelve threats, four themes

STRIDE-derived. Each entry names the threat, the mitigation we’ve already built, how we’d detect a regression, and how we’d recover.

Key custody and cert lifecycle

SSH CA private key disclosure

Mitigation: Key never leaves the managed KMS. Signing operations are asymmetric-sign API calls. No code path reads key material into process memory.
Detection: Audit trail on KMS Sign calls; alert on volume anomalies; quarterly access review.
Recovery: Key rotation runbook; bulk re-issuance of trusted CA keys to all enrolled hosts.

Cert revocation lag

Mitigation: OpenSSH KRL (Key Revocation List) pushed to all hosts within 60s of revocation. Default TTL is 4 hours to bound worst-case exposure if KRL push fails. TTL configurable 1 min – 24h via the admin portal.
Detection: Revocation latency metric; alert if median >5s or p99 >60s.
Recovery: Force re-pull on hosts; rotate CA if the revocation system itself is compromised.

T10

OIDC token impersonation

Mitigation: ID token signature verified against the IdP's JWKS on every cert issuance. We check iss, aud, exp, nonce. Weak algorithms (none, HS-with-shared-secret) rejected outright. Cert principals bind to the verified email or sub claim.
Detection: Failed-token-validation metric; alerts on misconfig.

Tenant isolation and data access

Cross-tenant data leak via control plane bug

Mitigation: All Postgres queries run through row-level security views keyed on tenant_id, injected from the authenticated principal. No raw WHERE clauses in app code. A tenant_id mismatch returns 404, not 403, so existence isn't leaked.
Detection: Integration tests prove cross-tenant SELECT returns empty; fuzzing on tenant boundaries in staging.
Recovery: Incident process; customer notification within 72 hours per DPA.

T11

Insider access (Linux Identity operator)

Mitigation: Production access requires 4-eyes approval (PR + deploy review). All admin queries logged. Customer audit logs will be encrypted with customer-derived keys in a future release.
Detection: Internal audit-query log review monthly.

T12

Stolen vendor credentials

Mitigation: Hardware-backed MFA on all founder and employee accounts. SSO required where available. Cloud access via SSO-federated, short-lived credentials only. No long-lived static keys to any production system.
Detection: Audit logs in every vendor portal; anomaly alerts.

Host agent and audit integrity

Agent crash locks out engineers

Mitigation: The agent is deliberately not in the SSH critical path. sshd's TrustedUserCAKeys references the CA public key directly. Agent dying does not block existing SSH or new SSH logins. The sudo plugin gracefully degrades — if it can't reach the control plane, sudo continues to work via OS defaults; only logging is degraded.
Detection: Chaos test: kill agent during e2e SSH login → must succeed.
Recovery: N/A — failure is contained.

Compromised host extracts secrets

Mitigation: Agent stores no long-term secrets. SSH cert requests are on-demand via the SSO flow. Audit log is uploaded then deleted from the local cache. Agent uses host attestation (TPM where available; agent registration token otherwise, short-lived).
Detection: Anomalous control-plane API usage from the host's IP / agent token.
Recovery: Revoke agent token; force re-enrollment.

Audit log tampering

Mitigation: Audit log writes use an append-only Postgres role (no UPDATE/DELETE privilege). sha256 hash chain over rows: each row includes prev_hash. Session recordings stored in WORM object storage with compliance-mode immutability.
Detection: Hash chain verification job runs hourly; alert on break.
Recovery: Forensic investigation; customer notification if impact warrants.

Supply chain and runtime integrity

Sudo plugin / PAM module compromise on host

Mitigation: Plugin compiled from the same source as the agent, signed; signature verified by sshd on init. Plugin runs in the sudo process, not as a root daemon. PAM stack tested on each supported distro.
Detection: Integrity monitoring on the plugin file; alert on unexpected modification.
Recovery: Push fixed plugin via signed agent update; rollback path always available.

Malicious agent release (supply chain)

Mitigation: Releases signed with cosign; signatures verified by hosts on update. Reproducible builds documented. Build infrastructure uses GitHub OIDC to short-lived cloud credentials; no static credentials in CI. SBOM published with each release.
Detection: Unexpected release tag; signature verification failure on update.
Recovery: Revoke compromised cosign key; ship reverted release; force update.

Self-update RCE via tampered manifest

Mitigation: Update manifests signed; signature verified before exec. Version downgrades rejected. Update window opt-in per customer (not silent).
Detection: Signature-verification metric.
Recovery: Rollback path; documented in runbook.

Deliberately out of scope (today)

We list these so you can decide whether the gap is acceptable for your environment. None are forgotten; each has a triggering condition that promotes it to in-scope.

Customer-managed encryption keys for audit data
Needed for Module 3 (compliance) for some regulated segments; deferred until the first regulated customer asks.
FIPS 140-2 / 140-3 in-process modules
Managed KMS provides FIPS-validated crypto for signing. Agent crypto uses Go stdlib; boringcrypto build tag deferred until needed.
TPM-based host attestation (mandatory)
Best-in-class but adds deployment friction. v1 uses agent registration tokens; TPM is optional and supported when available.

When we re-review this

Before each new phase of SSH core work: re-review T1, T3, T5, T10.
Before pen test: independent reviewer walks the full threat model.
Before GA: re-review every threat; close any deferred item deemed GA-blocking.

Have a threat we missed? Email security@linuxidentity.com. We credit reporters.