120 lines
5.3 KiB
Markdown
120 lines
5.3 KiB
Markdown
# 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 can display dry-run response plans
|
|
but does not execute containment commands.
|
|
- 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. |
|
|
| HTTPS read-only dashboard | Exposes evidence and dry-run plans 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.
|