enodia-sentinal/docs/THREAT_MODEL.md

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`
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.