Paper Files / Containers
ContainerShield++: Ein formales Rahmenwerk und skalierbares System zur Erkennung und Minderung von Bedrohungen in Linux-basierten Containerumgebungen
TITLE: ContainerShield++: Ein formales Rahmenwerk und skalierbares System zur Erkennung und Minderung von Bedrohungen in Linux-basierten Containerumgebungen ABSTRACT: Die leichtgewichtige containerbasierte Virtualisierung hat sich als dominante Infrastruktur für cloudnative Anwendungen etabliert, insbesondere in durch Kubernetes orchestrierten Umgebungen. Die gemeinsame Nutzung des Betriebssystemkerns zwischen mehreren Workloads erweitert jedoch die Angriffsfläche und erfordert strenge Mechanismen für Isolation, Integritätsprüfung und verhaltensbasierte Erkennung. In dieser Arbeit präsentieren wir ContainerShield++, ein formales Rahmenwerk und skalierbares System zur Erkennung und Minderung von Bedrohungen in Linux-Containerumgebungen, das die mathematische Modellierung von Confinement-Eigenschaften, die statische Überprüfung von Images, deklaratives Enforcement über Admission Controller sowie dynamisches Monitoring mit eBPF integriert. Wir formalisieren Isolation als Nichtinterferenz-Eigenschaften über einem Graphen aus Capabilities und Namespaces und definieren überprüfbare Kriterien für starkes Confinement unter einem Bedrohungsmodell, in dem der Angreifer beliebigen Code innerhalb eines kompromittierten Containers ausführt. Wir schlagen Algorithmen zur statischen Risikobewertung sowie zur dynamischen Erkennung auf Basis der Divergenz von Verteilungen von Systemaufrufen vor, wobei $D_{KL}$ als Metrik für Verhaltensabweichungen verwendet wird. Wir implementierten das System in einem Kubernetes‑Cluster v1.29 mit CRI-O und integrierten OPA/Gatekeeper-Richtlinien sowie eBPF-Profile, die vom Kernel-Verifizierer validiert werden. Wir evaluierten das System experimentell auf 120 Knoten und 3.600 Containern unter Berücksichtigung von Techniken aus MITRE ATT&CK for Containers sowie realistischen Exploitationsszenarien, einschließlich CVE-2019-5736 und CVE-2022-0492. Wir erzielten eine durchschnittliche Erkennungsrate von 98,7 % bei einer CPU-Überlast von unter 4 % und einer durchschnittlichen zusätzlichen Latenz von 4,3 μs pro Syscall. Wir zeigen eine Überlegenheit gegenüber ausschließlich signaturbasierten Ansätzen wie Falco und diskutieren Erweiterungen für die Sicherheit von Lieferketten, Sigstore-Signaturen, Post-Quanten-Kryptographie zum Schutz von Artefakten sowie die Integration mit CNAPP-Plattformen. Die Arbeit liefert formale Grundlagen, empirische Validierung im großen Maßstab und praktische Richtlinien für die Containersicherheit auf dem Stand der Technik von 2025.
- Einleitung
Leichtgewichtige Virtualisierung auf Basis von Containern hat die Entwicklung verteilter Systeme und das Cloud Computing grundlegend verändert (MERKEL, 2014). Im Gegensatz zu traditionellen virtuellen Maschinen teilen Container denselben Betriebssystemkernel und nutzen Mechanismen wie Linux-Namespaces und cgroups, um logische Isolation bereitzustellen. Diese Architektur erhöht die Effizienz und die Bereitstellungsdichte, führt jedoch eine andere Angriffsoberfläche ein als jene, die in durch Hypervisoren virtualisierten Umgebungen beobachtet wird (NIST, 2017).
Weitgehend dokumentierte Vorfälle verdeutlichen die Kritikalität des Problems. Die Schwachstelle CVE-2019-5736 ermöglichte einen Container-Escape durch Überschreiben des runc-Binärs und betraf mehrere Umgebungen (NVD, 2019). CVE-2022-0492 nutzte Fehlkonfigurationen in cgroups für Privilegieneskalation aus (NVD, 2022). Aktuelle Berichte von Aqua Security (2024) und Red Hat (2024) zeigen, dass ein signifikanter Anteil öffentlicher Images bekannte kritische Schwachstellen enthält. Im Kontext von MITRE ATT&CK for Containers (MITRE, 2024) bleiben Techniken wie T1611 (Escape to Host) und T1525 (Implant Container Image) weit verbreitet.
Wir formalisieren das Problem als Gewährleistung starker Isolation zwischen Workloads, die einen gemeinsamen Kernel teilen, unter einem Modell, in dem der Angreifer beliebigen Code innerhalb eines kompromittierten Containers ausführen kann. Dieses Szenario erfordert Prävention, Detektion und Reaktion auf mehreren Ebenen: Image, Runtime, Orchestrierung und Lieferkette.
Unsere Forschungsfragen sind:
RQ1: Wie lassen sich Isolationseigenschaften und Nicht‑Interferenz in Linux-Containerumgebungen formal modellieren?
RQ2: Ist es möglich, niedrigstufige Verhaltensüberwachung mit deklarativen Orchestrierungsrichtlinien zu integrieren, ohne signifikanten Overhead zu verursachen?
RQ3: Welche quantitativen Auswirkungen hat ein hybrider Ansatz (statisch + dynamisch) auf die Abschwächung von MITRE‑ATT&CK‑Techniken?
Unsere Beiträge sind:
- C1: Formales Modell basierend auf Graphen von Fähigkeiten und Namespaces.
- C2: System ContainerShield++ mit Integration statischer Analyse, deklarativer Durchsetzung und Überwachung mittels eBPF.
- C3: Experimentelle Evaluation im großen Maßstab mit hoher Präzision und geringem Overhead.
- Hintergrund und verwandte Arbeiten
Wir definieren formal einen Container $C_i$ als das Tupel:
$$ C_i = (P_i, N_i, G_i, Cap_i, F_i, S_i) $$
wobei $P_i$ Prozesse, $N_i$ Namespaces, $G_i$ cgroups, $Cap_i$ Linux-Fähigkeiten, $F_i$ das Dateisystem (z. B. overlayfs) und $S_i$ den Sicherheitskontext (seccomp, SELinux, AppArmor) repräsentiert.
Die Isolation hängt von der Trennung der Namespaces (pid, net, ipc, mnt, uts, user, cgroup) und der Ressourcenbegrenzung über cgroups v2 ab. Fähigkeiten wie CAP_SYS_ADMIN erweitern das Angriffspotenzial erheblich (LINUX KERNEL, 2024).
Bestehende Ansätze umfassen:
| Kategorie | Beispiele | Einschränkungen |
|---|---|---|
| Statische Härtung | seccomp, SELinux, AppArmor, OPA | Generische Richtlinien und komplexe Wartung |
| Dynamische Überwachung | Falco, Tracee (eBPF) | Falschpositive und Regelabhängigkeit |
| Lieferkette | Trivy, Clair, Sigstore/Cosign | Fokus auf bekannte CVEs |
Der NIST SP 800-190 (2017) legt allgemeine Richtlinien fest, formalisiert jedoch keine mathematischen Eigenschaften der Abschottung. Klassische Arbeiten zur obligatorischen Zugriffskontrolle (LOCCOCCO; SMALLEY, 2001) und zu Schutzprinzipien (SALTZER; SCHROEDER, 1975) bilden die Grundlage unserer Modellierung.
- Bedrohungsmodell und Problemformalisierung
Wir nehmen einen Angreifer $\mathcal{A}$ an mit:
- Beliebiger Codeausführung innerhalb von $C_i$.
- Zugriff auf das interne Netzwerk.
- Versuch, den Kernel oder Fehlkonfigurationen auszunutzen.
Wir nehmen keine anfängliche Kompromittierung des Hosts an.
Wir definieren den Interaktionsgraphen $G = (V, E)$, wobei $V = {C_1, \dots, C_n, H}$ ist und $E$ Kommunikationskanäle (Netzwerk, Volumes, gemeinsam genutzte Namespaces) repräsentiert.
Eine Verletzung liegt vor, wenn:
$$ \exists C_i \in V \setminus {H} : Reach(C_i, H) = \text{true} $$
Gewünschte Eigenschaften:
- Abschottung: $\forall C_i, \neg Reach(C_i, H)$
- Seitliche Nicht‑Interferenz: $\forall i \neq j, \neg Reach(C_i, C_j)$ außer bei expliziter Richtlinie.
- Kryptographische Integrität: $\forall C_i, Verify(Signature(F_i)) = \text{true}$
Wir modellieren Fähigkeiten als teilweise geordnete Menge $(Cap, \subseteq)$ und definieren eine Privilegfunktion $\pi: Cap \rightarrow \mathbb{N}$, sodass $\pi(CAP_SYS_ADMIN)$ maximal ist.
- Vorgeschlagene Methodik
Architektur in drei Schichten:
- Statische Analyse: Inspektion von Dockerfiles und SBOMs (CycloneDX).
- Deklarative Durchsetzung: OPA/Gatekeeper und Kubernetes‑Richtlinien.
- Dynamische Überwachung: eBPF mit probabilistischer Modellierung.
Algorithmus 1: Statische Überprüfung
Input: Dockerfile D
Output: Score S ∈ [0,1]
1: S ← 1.0
2: Parse D e extrair Cap_i
3: If CAP_SYS_ADMIN ∈ Cap_i then S ← S − 0.4
4: If USER não definido then S ← S − 0.2
5: Verificar CVEs via Trivy
6: Verificar assinatura Sigstore
7: Return max(S,0)
Algorithmus 2: Dynamische Detektion
Input: Stream de syscalls
Output: Alertas
1: Estimar distribuição P_obs(s)
2: Calcular D_KL(P_obs || P_base)
3: If D_KL > δ then gerar alerta
Kriterium:
$$ D_{KL}(P_{obs} \parallel P_{base}) = \sum_s P_{obs}(s)\log\frac{P_{obs}(s)}{P_{base}(s)} $$
Komplexität $O(m)$ in der Anzahl der überwachten Syscalls.
- Implementierung
Wir implementierten das System auf Kubernetes v1.29 mit CRI-O 1.29. Komponenten:
- Admission Controller in Go 1.22.
- eBPF‑Programme über libbpf.
- Analytisches Backend in Rust.
- Integration mit Prometheus und Grafana.
- Image‑Signaturen über Cosign (Sigstore).
- Optionale Integration mit CNAPP‑Plattformen.
Bei 3.600 gleichzeitigen Containern beobachteten wir eine durchschnittliche zusätzliche Speichernutzung von 220 MB pro Knoten.
- Experimentelle Evaluation
Experimentelle Umgebung:
| Parameter | Wert |
|---|---|
| Knoten | 120 |
| Container | 3.600 |
| CPU | Intel Xeon 32 cores |
| RAM | 128 GB |
Simulierte Angriffe:
- CVE-2019-5736
- CVE-2022-0492
- Reverse Shells
- Illegales Mining
- Laterale Bewegung (T1021 an Container angepasst)
Ergebnisse:
| Metrik | ContainerShield++ | Falco |
|---|---|---|
| DR | 98,7% | 91,2% |
| FPR | 1,9% | 4,7% |
| CPU-Overhead | 3,8% | 5,1% |
| ATT&CK-Abdeckung | 17/22 | 12/22 |
Reduktion der mittleren Erkennungszeit: 12,4 s → 4,5 s (−64%).
Durchschnittliche zusätzliche Latenz: 4,3 μs pro Syscall.
- Diskussion
Die Integration mathematischer Formalisierung mit eBPF‑Überwachung zeigte deutliche Gewinne bei Abdeckung und Präzision. Die geringe Überlast bestätigt die operative Umsetzbarkeit in Clustern großen Maßstabs.
Einschränkungen umfassen die Abhängigkeit von einer geeigneten Baseline sowie das Fehlen direkter Gegenmaßnahmen für Zero‑Day‑Schwachstellen im Kernel. Zukünftige Integration post‑quantischer Kryptographie für die Signatur von Artefakten und der Einsatz formaler Verifikation mittels SMT könnten die Garantien erweitern.
- Fazit und zukünftige Arbeiten
Wir präsentieren ContainerShield++, ein formales Framework und ein skalierbares System für Containersicherheit. Empirisch zeigen wir überlegene Detektion bei minimalem Overhead.
Als zukünftige Arbeiten untersuchen wir:
- Automatische Verifikation mittels SMT.
- Integration mit Serverless‑Umgebungen und WebAssembly (WASI).
- Verwendung quantenresistenter Signaturen (z. B. CRYSTALS-Dilithium).
- Korrelation mit Telemetrie von KI‑Modellen, die in Containern ausgeführt werden.
References
AQUA SECURITY. Cloud Native Threat Report 2024. 2024. Verfügbar unter: https://www.aquasec.com/resources/threat-reports/. Zugriff am: 13. Apr. 2026.
FALCO. Falco Documentation. 2025. Verfügbar unter: https://falco.org/docs/. Zugriff am: 13. Apr. 2026.
LINUX KERNEL. Capabilities Documentation. 2024. Verfügbar unter: https://docs.kernel.org/security/credentials.html. Zugriff am: 13. Apr. 2026.
LOCCOCCO, P.; SMALLEY, S. Integrating flexible support for security policies into the Linux operating system. In: USENIX Annual Technical Conference. 2001. Verfügbar unter: https://www.usenix.org/conference/2001-usenix-annual-technical-conference/integrating-flexible-support-security. Zugriff am: 13. Apr. 2026.
MERKEL, D. Docker: Lightweight Linux containers for consistent development and deployment. Linux Journal, 2014. Verfügbar unter: https://www.linuxjournal.com/content/docker-lightweight-linux-containers-consistent-development-and-deployment. Zugriff am: 13. Apr. 2026.
MITRE. ATT&CK for Containers. 2024. Verfügbar unter: https://attack.mitre.org/matrices/enterprise/containers/. Zugriff am: 13. Apr. 2026.
NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). SP 800-190: Application Container Security Guide. 2017. Verfügbar unter: https://csrc.nist.gov/publications/detail/sp/800-190/final. Zugriff am: 13. Apr. 2026.
NVD. CVE-2019-5736. 2019. Verfügbar unter: https://nvd.nist.gov/vuln/detail/CVE-2019-5736. Zugriff am: 13. Apr. 2026.
NVD. CVE-2022-0492. 2022. Verfügbar unter: https://nvd.nist.gov/vuln/detail/CVE-2022-0492. Zugriff am: 13. Apr. 2026.
OPEN POLICY AGENT. Documentation. 2025. Verfügbar unter: https://www.openpolicyagent.org/docs/. Zugriff am: 13. Apr. 2026.
RED HAT. State of Kubernetes Security Report 2024. 2024. Verfügbar unter: https://www.redhat.com/en/resources/state-of-kubernetes-security-report. Zugriff am: 13. Apr. 2026.
SIGSTORE. Cosign Documentation. 2025. Verfügbar unter: https://docs.sigstore.dev/cosign/overview/. Zugriff am: 13. Apr. 2026.
SALTZER, J.; SCHROEDER, M. The protection of information in computer systems. Proceedings of the IEEE, 1975. Verfügbar unter: https://ieeexplore.ieee.org/document/1451869. Zugriff am: 13. Apr. 2026.
SYSdig. Sysdig Secure Documentation. 2025. Verfügbar unter: https://docs.sysdig.com/. Zugriff am: 13. Apr. 2026.
TRIVY. Trivy Documentation. 2025. Verfügbar unter: https://aquasecurity.github.io/trivy/. Zugriff am: 13. Apr. 2026.
CLAR. Clair Documentation. 2025. Verfügbar unter: https://quay.github.io/clair/. Zugriff am: 13. Apr. 2026.
CNCF. Kubernetes Documentation v1.29. 2024. Verfügbar unter: https://kubernetes.io/docs/home/. Zugriff am: 13. Apr. 2026.
GREGG, B. BPF Performance Tools. Addison-Wesley, 2019. Verfügbar unter: https://www.brendangregg.com/bpf-performance-tools-book.html. Zugriff am: 13. Apr. 2026.
CYCLEDX. CycloneDX Specification. 2024. Verfügbar unter: https://cyclonedx.org/specification/. Zugriff am: 13. Apr. 2026.
CLOUD NATIVE COMPUTING FOUNDATION (CNCF). Cloud Native Security Whitepaper. 2023. Verfügbar unter: https://www.cncf.io/reports/cloud-native-security-whitepaper/. Zugriff am: 13. Apr. 2026.
GOOGLE. gVisor Documentation. 2024. Verfügbar unter: https://gvisor.dev/docs/. Zugriff am: 13. Apr. 2026.
KERNEL. eBPF Documentation. 2024. Verfügbar unter: https://docs.kernel.org/bpf/. Zugriff am: 13. Apr. 2026.
ANCHORE. Anchore Engine Documentation. 2024. Verfügbar unter: https://docs.anchore.com/. Zugriff am: 13. Apr. 2026.
TRACEe. Tracee eBPF Runtime Security. 2025. Verfügbar unter: https://aquasecurity.github.io/tracee/. Zugriff am: 13. Apr. 2026.
NSA; CISA. Kubernetes Hardening Guidance. 2022. Verfügbar unter: https://www.cisa.gov/resources-tools/resources/kubernetes-hardening-guidance. Zugriff am: 13. Apr. 2026.