Add platform docs; reposition as host security platform

Add docs/ (SPECIFICATION, ROADMAP, OPERATIONS, COMMAND_REFERENCE,
THREAT_MODEL) describing the current v0.7 agent and the phased path from
local HIDS to a host security platform. Reframe README, package metadata,
and CLI/module descriptions from "intrusion-detection daemon" to "Linux
host security platform", and surface the v0.7 signed-package verify
(pkgdb_pkgverify*) and anti-rootkit (rootcheck_*) knobs in the sample
config. Also wrap the pacman.conf read in pkgdb.siglevel_alert in a
context manager to avoid a leaked file handle.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/THREAT_MODEL.md

@@ -0,0 +1,119 @@
+# Enodia Sentinel Threat Model
+
+This document describes what Enodia Sentinel is meant to catch, what it can only
+make evident, and what it does not claim to solve.
+
+## Assets
+
+Sentinel protects and records evidence about:
+
+- Running processes and process ancestry.
+- Network sockets and remote peers.
+- File descriptors and executable paths.
+- SUID/SGID inventory and privilege-escalation artifacts.
+- Persistence locations: cron, systemd units, SSH keys, shell startup files, and
+  sensitive account/sudo configuration.
+- Package-owned binaries and local package database integrity.
+- Sentinel's own binaries, config, systemd units, hook, baselines, logs, and
+  heartbeat.
+
+## Adversary Model
+
+Sentinel is designed to help against:
+
+| Adversary | Examples | Expected Sentinel value |
+|---|---|---|
+| Opportunistic remote shell | Webshell, exposed service RCE, stolen SSH key | Detect reverse shell, suspicious egress, new listeners, persistence writes. |
+| Local privilege escalation | New SUID helper, dropped setuid shell, writable path abuse | Detect new SUID/SGID and critical writable-directory placement. |
+| Fileless or short-lived execution | Deleted executable, memfd payload, fast `curl|sh` | Detect deleted executables and eBPF exec rules where available. |
+| Package/file tampering | Trojaned binary, rewritten package DB checksums | Detect FIM drift, package DB tamper, and signed-package mismatches. |
+| Common rootkit hiding | LD_PRELOAD tricks, `/proc` hiding, module-list hiding, hidden listener | Detect LD_PRELOAD and cross-view inconsistencies. |
+| Sensor tampering | Stop daemon, edit config, remove hook, modify baseline | Detect self-integrity changes and stale heartbeat via external watchdog. |
+
+## Trust Boundaries
+
+### Local Root Is Not Fully Trusted
+
+The daemon runs as root so it can inspect the host. If an attacker gains root,
+they share that privilege. Sentinel therefore does not claim that local files,
+local baselines, or local process views are unforgeable.
+
+The design goal is layered tamper-evidence:
+
+- Package signatures are harder for a local attacker to forge than the local
+  package DB.
+- Immutable bits force visible state changes before local files can be edited.
+- External watchdogs notice silence.
+- Future external anchors and signed logs should make retroactive rewriting
+  harder.
+
+### Optional eBPF Expands Privilege
+
+The default service is hardened and read-mostly. Enabling the bcc eBPF monitor
+requires additional capabilities and memory permissions. That tradeoff is
+explicit: stronger event visibility for a wider runtime permission set.
+
+## Detection Assumptions
+
+Sentinel assumes:
+
+- Attackers need a process, socket, file, package, persistence location, or
+  privilege transition somewhere on the host.
+- High-confidence host behaviors are more useful than broad noisy rules.
+- Many attacks are visible from more than one view: `/proc`, `/sys`, `ss`,
+  package metadata, logs, and filesystem hashes.
+- Snapshots captured immediately are more useful than asking an operator to
+  reconstruct state after the process exits.
+
+## Important Limitations
+
+- A custom kernel implant that hooks every view consistently can evade
+  user-space cross-view checks.
+- A local root attacker can delete or rewrite local logs unless external anchors
+  or immutable controls are in place.
+- Signed-package verification depends on a populated package cache and valid
+  package signature policy.
+- `pacman -Qkk` trusts the local package database; it is useful but not an
+  independent root of trust.
+- The dashboard is read-only by design; it is not a remote response console.
+- The current product does not perform automatic containment.
+
+## Security Controls Already Present
+
+| Control | Purpose |
+|---|---|
+| Hardened systemd unit | Limits daemon write surface and runtime privilege where possible. |
+| Cooldown deduplication | Prevents alert storms from one persistent condition. |
+| Snapshot retention | Preserves evidence while bounding local disk growth. |
+| FIM self-watch | Detects changes to Sentinel's own files and service definitions. |
+| Package DB anchor | Flags package checksum DB edits outside package transactions. |
+| Signed-package verification | Checks files against package manifests independent of the local DB. |
+| Rootcheck | Finds common hiding artifacts by comparing independent views. |
+| Heartbeat + watchdog | Makes a silent sensor observable from another machine. |
+| Read-only dashboard | Exposes evidence without adding a remote write path. |
+
+## Response Safety
+
+Sentinel should remain conservative:
+
+- Detection may be automatic.
+- Evidence capture may be automatic.
+- Notification may be automatic.
+- Triage suggestions may be automatic.
+- Destructive response should require an explicit operator action.
+
+Future response features should produce dry-run plans first, log all changes,
+and avoid shell-string execution where structured APIs exist.
+
+## Abuse Considerations
+
+Some security tools can become dual-use. Enodia should avoid:
+
+- Stealth, hiding, or rootkit-like self-defense.
+- Persistence mechanisms that are hard for the owner to inspect.
+- Automated deletion of suspicious files without review.
+- Covert exfiltration of host data.
+- Cloud dependence for local detection.
+
+The correct defensive posture is visibility, evidence, and explicit operator
+control.