132 lines
6.6 KiB
Markdown
132 lines
6.6 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. |
|
|
| Credential harvesting | Shadow file reads, private SSH key theft, browser credential database access, keylogging | Detect credential file access and non-allowlisted input/HID event readers. |
|
|
| 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, process-tool hiding, `/proc` hiding, module-list hiding, hidden TCP/UDP/raw/SCTP/packet sockets, tainted modules | Detect LD_PRELOAD, `/proc` vs `ps` disagreement, mapped hide libraries, cross-view inconsistencies, known LKM names, raw ICMP/SCTP-style sockets, unusual protocol families, and kernel/module taint. |
|
|
| Memory-resident payloads | Encrypted heap/code, packed memfd stages, RWX shellcode, deleted mapped payloads | Detect executable anonymous/memfd/deleted mappings and writable+executable pages; optional eBPF syscall telemetry catches short-lived RWX transitions and memfd staging. |
|
|
| 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.
|
|
- Sentinel's IPS scope is explicit prevention workflow: posture hardening,
|
|
containment planning, and future reviewed `--apply` actions. It is not an
|
|
inline network appliance and does not silently rewrite host state.
|
|
|
|
## Security Controls Already Present
|
|
|
|
| Control | Purpose |
|
|
|---|---|
|
|
| Hardened systemd unit | Limits daemon write surface and runtime privilege where possible. |
|
|
| Explicit IPS workflow | Turns detections into reviewed prevention/containment plans without automatic remediation. |
|
|
| 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.
|
|
|
|
Current CLI response planning already leaves a local audit trail: generated
|
|
dry-run plans are saved under `response-plans/`, and
|
|
`response-audit.log` records who/what generated the plan and where it was
|
|
stored. This is a review/handoff record only; it does not prove containment
|
|
commands were executed.
|
|
|
|
## 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.
|