stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 3 Releases Wiki Activity

test fixes and new product advisories work

Browse Source
This commit is contained in:
master
2026-01-28 02:30:48 +02:00
parent 82caceba56
commit 644887997c
288 changed files with 69101 additions and 375 deletions
Download Patch File Download Diff File Expand all files Collapse all files

311
docs/reachability/security-model.md Normal file
View File

@@ -0,0 +1,311 @@
# 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
```ini
# /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
```bash
# 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
```yaml
# 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](https://keys.stella.ops/security.asc)