Security Model

This document describes the security model for the Stella Ops eBPF runtime reachability evidence system: its trust boundaries, threat model, security controls, hardening guidance, and compliance mapping.

Audience: security engineers and operators assessing the integrity and threat posture of runtime evidence collection.

Scope note. This page is the target security model. Some controls below describe a standalone collector daemon and signing posture that the codebase does not yet fully implement — see the Operator Runbook, which marks the surfaces that exist today versus those on the roadmap. The schema, probe, and chain-verification details are reconciled in Evidence Schema and Probe Reference.

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 (via Attestor / local HMAC signer)  │    │
│  │  ├─ Rekor inclusion proofs (optional)                   │    │
│  │  └─ 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 (signed via the Attestor service, or a local HMAC signer in dev/air-gap deployments)
• Rekor transparency log provides tamper-evident timestamps (optional; routed through Attestor, which supports an internal mirror for on-prem/air-gap)
• Chain linkage (previous_chunk_id) detects deletions/insertions
• Verification CLI detects any modifications

Residual Risk: An attacker with access to the signing key could forge valid signatures (mitigated by holding keys in a KEK/secret backend such as Vault and by Rekor transparency).

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

Collector Controls

Evidence Controls

Hardening Recommendations

These recommendations describe the target deployment posture for a long-running collector host. The standalone stellaops-signals systemd unit is roadmap, not yet shipping (see the Operator Runbook); apply the equivalent sandboxing to whatever host process registers the in-process collection API today.

Collector Hardening

# Target unit drop-in for a long-running collector host
# /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 (OutputDirectory / ChainStateDirectory)
chmod 750 /var/lib/stellaops/evidence
chown stellaops:stellaops-readers /var/lib/stellaops/evidence

The collector is configured in code via EbpfEvidenceOptions (there is no free-standing signals.yaml); see the Operator Runbook — Configuration Reference.

Encryption at Rest

Evidence chunks are signed and chained, but the NDJSON bodies are not encrypted by the collector. Where evidence at rest must be encrypted, do it at the storage layer (for example LUKS/dm-crypt or an encrypted filesystem) with keys held in the deployment’s KEK/secret backend — Vault is the flagship for on-prem and air-gap deployments. Do not depend on a cloud-managed KMS as the default; this is self-hosted, sovereign-first software.

Compliance Mapping

SOC 2

NIST 800-53

PCI-DSS

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 through Stella Ops’ Coordinated Vulnerability Disclosure process: docs/security/coordinated-vulnerability-disclosure.md.

Product security intake: security@stella-ops.org.

Related

• Evidence Schema — record shape, determinism invariants, chunk attestation
• Probe Reference — per-probe attach points and limitations
• Operator Runbook — what exists today vs. roadmap, verification, configuration
• Coordinated Vulnerability Disclosure