git.stella-ops.org/docs/reachability/security-model.md

Security Model

Overview

This document describes the security model for the eBPF reachability evidence system, including threat model, trust boundaries, and mitigations.

Trust Boundaries

┌─────────────────────────────────────────────────────────────────┐
│                    Untrusted Zone                                │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │            Monitored Workloads                           │    │
│  │  (containers, processes generating events)               │    │
│  └─────────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────────┘
                              │
                    ══════════╪══════════  Trust Boundary 1
                              │
┌─────────────────────────────────────────────────────────────────┐
│                    Kernel Space (Trusted)                        │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │  eBPF Verifier (enforces safety)                        │    │
│  │  ├─ Memory bounds checking                              │    │
│  │  ├─ No unbounded loops                                  │    │
│  │  └─ Restricted kernel API access                        │    │
│  └─────────────────────────────────────────────────────────┘    │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │  eBPF Programs (verified safe)                          │    │
│  │  └─ Ring buffer output only                             │    │
│  └─────────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────────┘
                              │
                    ══════════╪══════════  Trust Boundary 2
                              │
┌─────────────────────────────────────────────────────────────────┐
│                    Collector (Trusted Component)                 │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │  RuntimeSignalCollector                                  │    │
│  │  ├─ Privileged (CAP_BPF, CAP_PERFMON, CAP_SYS_PTRACE)   │    │
│  │  ├─ Reads ring buffer                                    │    │
│  │  └─ Writes signed evidence                               │    │
│  └─────────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────────┘
                              │
                    ══════════╪══════════  Trust Boundary 3
                              │
┌─────────────────────────────────────────────────────────────────┐
│                    Evidence Storage                              │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │  Signed NDJSON Chunks                                    │    │
│  │  ├─ DSSE signatures (Fulcio/KMS)                        │    │
│  │  ├─ Rekor inclusion proofs                              │    │
│  │  └─ Chain linkage (previous_chunk_id)                   │    │
│  └─────────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────────┘

Threat Model

Threat 1: Malicious Workload Evasion

Description: Attacker attempts to hide malicious activity from evidence collection.

Attack Vectors:

• Disable/bypass eBPF probes
• Use syscalls not monitored
• Operate from unmonitored namespaces

Mitigations:

• Collector runs with elevated privileges, not accessible to workloads
• Comprehensive probe coverage (syscalls + uprobes)
• Namespace filtering ensures coverage of target workloads
• Kernel-level capture cannot be bypassed from user space

Residual Risk: Novel syscalls or kernel exploits may evade monitoring.

---

Threat 2: Evidence Tampering

Description: Attacker attempts to modify evidence after collection.

Attack Vectors:

• Modify NDJSON files on disk
• Delete evidence chunks
• Break chain linkage

Mitigations:

• DSSE signatures on each chunk (Fulcio ephemeral keys or KMS)
• Rekor transparency log provides tamper-evident timestamps
• Chain linkage (previous_chunk_id) detects deletions/insertions
• Verification CLI detects any modifications

Residual Risk: Attacker with Signer key access could forge valid signatures (mitigated by Fulcio/OIDC).

---

Threat 3: Collector Compromise

Description: Attacker gains control of the collector process.

Attack Vectors:

• Exploit vulnerability in collector code
• Compromise host and access collector credentials
• Supply chain attack on collector binary

Mitigations:

• Minimal attack surface (single-purpose daemon)
• Capability-based privileges (not full root)
• Signed releases with provenance attestations
• Collector cannot modify already-signed chunks

Residual Risk: Zero-day in collector could allow evidence manipulation before signing.

---

Threat 4: Denial of Service

Description: Attacker overwhelms evidence collection system.

Attack Vectors:

• Generate excessive events to overflow ring buffer
• Exhaust disk space with evidence
• CPU exhaustion through complex enrichment

Mitigations:

• Ring buffer backpressure (events dropped, not crash)
• Rate limiting configurable
• Disk space monitoring with rotation
• Bounded caches prevent memory exhaustion

Residual Risk: Sustained attack could cause evidence gaps (documented in chain).

---

Threat 5: Privacy/Data Exfiltration

Description: Evidence contains sensitive information exposed to unauthorized parties.

Attack Vectors:

• File paths reveal sensitive locations
• Command arguments contain secrets
• Network destinations reveal infrastructure

Mitigations:

• Path filtering (denylist sensitive paths)
• Argument truncation and filtering
• Network CIDR filtering
• Evidence access controlled by filesystem permissions
• Encryption at rest (optional)

Residual Risk: Metadata leakage possible even with filtering.

---

Threat 6: Replay/Injection Attacks

Description: Attacker injects fabricated evidence or replays old evidence.

Attack Vectors:

• Inject false events into evidence stream
• Replay signed chunks from different time period
• Forge DSSE envelopes

Mitigations:

• Ring buffer is kernel-only write
• Timestamps from kernel (monotonic, not settable by user space)
• Chain linkage prevents replay (previous_chunk_id)
• Rekor timestamps provide external time anchor
• DSSE signatures with certificate transparency

Residual Risk: Attacker with collector access could inject events before signing.

Security Controls

Kernel-Level Controls

Control	Description
eBPF Verifier	Validates program safety before loading
BTF	Type-safe kernel access without hardcoded offsets
Capability Checks	BPF_PROG_LOAD requires CAP_BPF
LSM Hooks	AppArmor/SELinux can restrict BPF operations

Collector Controls

Control	Description
Minimal Privileges	Only CAP_BPF, CAP_PERFMON, CAP_SYS_PTRACE
Sandboxing	Systemd hardening (NoNewPrivileges, ProtectSystem)
Input Validation	Bounds checking on all kernel data
Secure Defaults	Signing enabled, Rekor submission enabled

Evidence Controls

Control	Description
DSSE Signing	Cryptographic integrity for each chunk
Chain Linking	Tamper-evident sequence
Rekor Inclusion	Public timestamp and immutability
Offline Verification	No trust in online services required

Hardening Recommendations

Collector Hardening

# /etc/systemd/system/stellaops-signals.service.d/hardening.conf
[Service]
# Prevent privilege escalation
NoNewPrivileges=yes

# Protect system directories
ProtectSystem=strict
ProtectHome=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes

# Allow only necessary capabilities
CapabilityBoundingSet=CAP_BPF CAP_PERFMON CAP_SYS_PTRACE

# Restrict syscalls
SystemCallFilter=@system-service
SystemCallFilter=~@privileged

# Network isolation (if not needed)
PrivateNetwork=yes

# Read-only evidence directory (write via tmpfs)
ReadWritePaths=/var/lib/stellaops/evidence

Access Control

# Evidence directory permissions
chmod 750 /var/lib/stellaops/evidence
chown stellaops:stellaops-readers /var/lib/stellaops/evidence

# Configuration permissions
chmod 640 /etc/stellaops/signals.yaml
chown root:stellaops /etc/stellaops/signals.yaml

Encryption at Rest

# Enable encrypted evidence storage
signals:
  encryption:
    enabled: true
    key_id: arn:aws:kms:us-east-1:123456789:key/abc-123

Compliance Mapping

SOC 2

Control	Implementation
CC6.1 Logical Access	Capability-based privileges
CC6.6 System Boundaries	Trust boundaries documented
CC7.2 System Monitoring	Comprehensive event capture
CC8.1 Change Management	Signed collector releases

NIST 800-53

Control	Implementation
AU-3 Content of Audit Records	Rich event schema
AU-9 Protection of Audit Information	DSSE signing, Rekor
AU-10 Non-repudiation	Chain linkage, transparency log
SI-4 System Monitoring	eBPF-based collection

PCI-DSS

Requirement	Implementation
10.2 Audit Trails	Syscall/uprobe logging
10.5 Secure Audit Trails	Cryptographic signing
10.7 Audit History	Configurable retention

Incident Response

Evidence Integrity Alert

If chain verification fails:

1. Isolate affected evidence chunks
2. Preserve surrounding chunks and Rekor proofs
3. Analyze verification report for failure cause
4. Report gap in audit trail to compliance
5. Investigate root cause (crash, attack, bug)

Collector Compromise

If collector compromise suspected:

1. Stop collector immediately
2. Preserve last signed chunk for forensics
3. Rotate signing keys if KMS-based
4. Audit Rekor for unexpected submissions
5. Reinstall collector from verified source
6. Resume collection with new chain

Security Contacts

Report security issues to: security@stella.ops

PGP Key: keys.stella.ops/security.asc