Rootless war nie risikofrei: Ein CTO‑Playbook nach CopyFail (CVE-2026-31431)

Wenn Sie letzte Woche Linux-Knoten im Notfall patchen mussten, haben Sie die Botschaft bereits erhalten: Rootless bedeutet nicht harmlos. CopyFail (CVE-2026-31431) hat ein neues Loch durch User-Namespaces geschlagen und alle daran erinnert, dass der Kernel die eigentliche Angriffsfläche ist. Rootless-Container verringern den Blast-Radius; sie eliminieren das Kernel-Risiko nicht. Wenn Ihre Teams nicht vertrauenswürdigen Code in Rootless-Containern ausführen lassen, setzen Sie Ihren Cluster auf Hoffnung und eine Syscall-Tabelle.

Was sich mit CopyFail geändert hat (und warum es absehbar war)

Die US-Regierung veröffentlichte eine schwerwiegende Warnung zu CopyFail, die große Linux-Versionen betrifft, und Security-Teams gerieten in Alarmbereitschaft. Frühe Analysen zeigten, wie ein Bug in einem zentralen Kernel-Pfad einen Container-Escape ermöglichen konnte – selbst unter "Rootless"-Setups, die viele von uns als Sicherheitsdecke für Entwicklerrechner, CI-Sandboxes oder Multi-Tenant-SaaS-Funktionen genutzt haben.

Das ist kein Einzelfall. Das haben wir schon erlebt: Dirty COW (CVE-2016-5195), Dirty Pipe (CVE-2022-0847), runc’s Container-Ausbruch (CVE-2019-5736) und ein stetiger Takt an Merkwürdigkeiten rund um User-Namespaces und overlayfs. Die Überschrift ist jedes Mal dieselbe: Wenn der Kernel Teil Ihrer Vertrauensgrenze ist, werden Sie irgendwann an einem Kernel-Bug verlieren. Rootless hilft, ist aber keine Sandbox. Es ist nur ein anderer Satz an Fußangeln.

Parallel dazu nutzen Angreifer andere Schwachstellen massenhaft aus (siehe die cPanel-Bug-Welle). Wenn es einen breit nutzbaren Pfad zu Root oder zum Escape gibt, wird das Internet zu Ihrem Red Team. Rechnen Sie mit einem 24–72-Stunden-Fenster vom PoC bis zur breiten Scan-Welle. Wenn Ihr Patch-Prozess langsamer ist, haben Sie kein Vulnerability-, sondern ein Operations-Problem.

Für CTOs: Machen Sie daraus eine klare Isolationsentscheidung

Ihre Aufgabe ist es nicht, Kernel-Experte zu werden. Ihre Aufgabe ist, eine Policy festzulegen: welche Workloads welche Isolation bekommen, wie schnell Sie patchen und was Sie tun, wenn die Sandbox versagt. Hier ist ein konkretes Framework, das wir mit Kunden verwenden.

1) Workloads nach Vertrauensstufe und Blast-Radius klassifizieren

• Tier 0 (Vertrauenswürdige interne Services): Ihre eigene App und Infrastruktur, Single-Tenant, kein vom Kunden gelieferter Code oder Binaries.
• Tier 1 (Von Partnern erweiterte Codepfade): Plugins, WASM-Filter, Datentransformationen, gebaut von vertrauenswürdigen Partnern mit Verträgen und Audits.
• Tier 2 (Vom Kunden gelieferte Logik/Daten mit Ausführung): Kundenfunktionen, Report-Generatoren, SQL UDFs, Modell-Adapter, PR-Preview-Builds.
• Tier 3 (Internet-feindlich/nicht vertrauenswürdig): Öffentliche Einsendungen, CI für externe Repos, flüchtige Sandboxes, Agents, die beliebige Tools ausführen, alles, was Benutzerinput in großem Maßstab parst bzw. parst+ausführt.

Die Entscheidungsgrenze ist simpel: Wenn ein Bug im Kernel oder Runtime es einem Tier-2/3-Workload ermöglichen könnte, den Host oder einen anderen Tenant zu erreichen, verschieben Sie ihn jetzt in eine stärkere Sandbox.

2) Isolation passend zur Stufe wählen

• Normale Container (rootful oder rootless) auf gemeinsamem Kernel: Für Tier 0 akzeptabel, wenn Sie Härtung durchsetzen (seccomp, AppArmor/SELinux, read-only Root, keine Privilege Escalations). Setzen Sie Rootless gezielt auf Entwickler-Laptops und für leichte CI ein, betrachten Sie es aber als Bequemlichkeit, nicht als Sicherheitsgrenze.
• gVisor (runsc) / GKE Sandbox / Azure Kata-WSL2-Äquivalent: Eine Syscall-Kompatibilitäts-Sandbox, die die Kernel-API abfängt. Gut für Tier 1–2. Typischer Overhead: 10–30% bei syscall-lastigen Workloads, nahezu nativ bei CPU-gebundenen, kleiner p99-Latenzaufschlag (+0,5–2 ms) für netzwerkintensive Microservices. Zahlen variieren; messen Sie an Ihrem Code.
• Kata Containers mit Firecracker/KVM-MicroVMs: Hardware-Virtualisierung mit MicroVMs pro Pod. Gut für Tier 2–3. Nahezu native CPU (3–10% Overhead), Memory-Aufschlag ~50–120 MB pro Sandbox, Cold Starts +150–400 ms. Starke Mandantenisolation bei moderat vorhersagbaren Kosten.
• Volle VMs oder Managed FaaS mit gehärteten Sandboxes: Für das wirklich Feindliche. Wenn Sie öffentliche Codeausführung, Malware-Analyse oder Agent-Marktplätze betreiben, ist das Ihr Default. Mehr Ops-Aufwand, es sei denn, Sie nutzen einen Managed Service.

Realitätscheck: Wenn ein Workload Tier 2 oder 3 ist und Sie immer noch auf Rootless-Containern bleiben, weil „es einfacher ist“, akzeptieren Sie einen Blast-Radius bei Kernel-Bugs, den CopyFail gerade sehr greifbar gemacht hat.

3) Den Overhead erwachsen budgetieren

Isolation ist nicht gratis. Planen Sie sie ein:

• CPU: Kata/Firecracker fügt in typischen Microservices ~3–10% hinzu; gVisor 10–30% bei syscall-schweren Pfaden. Bei rechenlastiger Inferenz oder Kompression kann der Overhead unter 5% liegen.
• Memory: MicroVMs kosten ~50–120 MB/Pod mehr als normale Container. 100 solcher Pods ≈ 5–12 GB zusätzliche RAM-Belegung über den Node-Pool hinweg. Auf speichergebundenen Nodes ist das der begrenzende Faktor.
• Latenz: gVisor fügt oft unter 2 ms p99 hinzu; Kata-Cold-Starts kosten pro Pod +150–400 ms, sofern Sie Sandboxes nicht poolen oder vorwärmen. Langlebige Services amortisieren das; bei burstigem Traffic brauchen Sie warme Pools.

Übersetzen Sie das in Geld. Wenn Ihr Cluster $80k pro Monat an Compute kostet, könnten 20% der Pods auf Kata umzustellen 5–8% Mehrkosten bedeuten ($4–6k/Monat). Das ist günstiger als ein einziger Sicherheitsvorfall mit Host-Kompromittierung und Kundenbenachrichtigungen.

Ihr 6-Punkte-Härtungsplan für 2026

1) Kernel- und OS-Strategie

• Auf LTS-Kernels pinnen mit Vendor-Backports (Ubuntu LTS HWE, RHEL, Bottlerocket). Vermeiden Sie, zwei unterschiedliche Kernel-Zweige im selben Cluster zu betreiben – Vielfalt verkompliziert Notfall-Patching.
• Runbook: Exploit wie einen Ausfall behandeln: Behandeln Sie eine kritische Container-Escape-CVE wie ein Sev-1. Automatisch drainen und innerhalb von 24 Stunden patchen. Bei internet-exploitable Bugs Ziel: 6 Stunden. Üben Sie das zweimal im Jahr.
• Exotische Filesystem- und Namespace-Kombos vermeiden sofern nicht unter Last getestet (idmapped mounts, overlayfs-Edge-Features). Sie vergrößern Ihre Kernel-Angriffsfläche.

2) Laufzeitkontrollen, die tatsächlich wirken

• Standard-seccomp-Profile: Gefährliche Syscalls für alles blockieren. Docker und containerd liefern brauchbare Defaults; pro Service anpassen. Wenn ein Team unbeschränkte Syscalls fordert, wird das zur Ausnahme mit Genehmigung.
• SELinux/AppArmor enforcing: Eines auswählen und eingeschaltet lassen. Deaktivierte LSMs sind ein Frühwarnzeichen für eine lasche Kultur.
• No-new-privileges, read-only root, Capabilities standardmäßig droppen: CAP_SYS_ADMIN, CAP_NET_RAW, CAP_SYS_MODULE überall verweigern, außer es gibt ein Ticket und eine zeitlich befristete Ausnahme.
• „Rootless“ richtig absichern: userns remap verwenden, Host-Mounts einschränken und Rootless als Komfortschicht für Entwicklerrechner behandeln – nicht als Policy-Ausnahme für untrusted Workloads.

3) Kubernetes-Policies, die die richtigen Pods in die richtigen Sandboxes routen

• RuntimeClass: Klassen wie native, gvisor, kata definieren. Admission control (Kyverno/Gatekeeper) sollte erzwingen, dass Tier 2–3 Namespaces nur deployen zu kata oder gvisor.
• Pod security: baseline oder restricted Policies cluster-weit durchsetzen. hostNetwork, hostPID, hostIPC und privileged per Default verbieten. readOnlyRootFilesystem: true verlangen.
• Node pools & taints: Separate Node-Pools für sandboxed Runtimes. Mit Taints versehen, sodass nur Pods, die die passende RuntimeClass anfordern, dort schedulen.
• Managed options first: GKE Sandbox (gVisor) ist schlüsselfertig. AKS unterstützt Kata via Confidential Containers. EKS unterstützt Kata mit containerd und Bottlerocket. Nutzen Sie die Plumbing der Cloud, es sei denn, Sie brauchen maßgeschneiderte Kontrolle.

4) Supply-Chain-Entscheidungen, die den Blast-Radius verkleinern

• Distroless/minimale Images: Weniger Binaries, weniger Subsysteme, weniger Überraschungen. Nach setuid-Dateien scannen; blockieren.
• Signieren und verifizieren: Sigstore/cosign verwenden und Verifizierung bei Admission erzwingen. SBOMs pflegen und bei Drift alarmieren.
• Unveränderliche Basis-Images: Monatlicher Refresh mit Security-Backports. Wenn ein Image älter als 60 Tage ist, Deployment ohne Ausnahme verweigern.

5) Observability, die „unmögliches“ Verhalten erkennt

• Syscall-Anomalieerkennung: Falco oder eBPF-Sensoren können Container-zu-Host-Pivots erkennen. Verlassen Sie sich nicht als Schild darauf; nutzen Sie es, um die Time-to-Know zu verkürzen.
• Golden Signals pro Runtime: Cold Starts, RSS pro Sandbox und p99-Deltas vs. Baseline tracken. Wenn Kata auf einem Pfad mit einem 200-ms-SLO 300 ms addiert, ist das ein Designproblem, kein Sicherheitsproblem.
• Exploit-Canaries: Halten Sie in Non-Prod einen Test-Pod vor, der bekannte Sandbox-Escape-Verhaltensweisen versucht. Alarmieren Sie, wenn nach einem Patch-Zyklus irgendetwas Atypisches gelingt.

6) Menschen und Prozesse: Geschwindigkeit ist Ihr Burggraben

• Ein Patch-SLO festlegen: Kritische Container-Escape-CVEs innerhalb von 24 Stunden gepatcht. Wie Uptime auditieren.
• Ausnahmeprozess mit Kill Switch: Wenn ein Team hostNetwork oder zusätzliche Caps braucht, läuft die Ausnahme nach 14 Tagen ab und Security wird bei Verlängerung benachrichtigt.
• Enablement für Nearshore-Teams: Remote-Ingenieuren Self-Service-Sandboxes mit der richtigen RuntimeClass bereitstellen. Lassen Sie Bequemlichkeit sie nicht zurück zu „einfach docker mit --privileged laufen lassen“ treiben.

Wo Rootless weiterhin Sinn ergibt

Werfen Sie Rootless nicht komplett weg. Es bringt weiterhin spürbare Sicherheit auf Entwicklerrechnern und einigen CI-Runnern:

• Entwickler-Laptops: Rootless + User-Namespace-Remapping bedeutet weniger unbeabsichtigte Host-Modifikationen und weniger riskante Mount-Muster. Gepaart mit einer dedizierten Dev-VM sinkt der Blast-Radius weiter.
• Basale CI für Ihren eigenen Code: Rootless ist in Ordnung zum Bauen und Testen Ihres Services mit unveränderlichen Basen und ohne Drittanbieter-Compiler oder -Interpreter, die während des Builds aus dem Internet ziehen. In dem Moment, in dem Sie untrusted PRs oder beliebige Toolchains akzeptieren, steigen Sie auf Kata oder gVisor um.

Das Gedankenmodell: Rootless ist ein scharfes Stemmeisen im vertrauten Holz. MicroVMs sind die Schutzhandschuhe, wenn Sie das Stemmeisen einem Fremden in die Hand geben.

So rollen Sie das ohne Rewrite aus

Wochen 0–2: Entscheiden und beweisen

• 10 Services taggen als Tier 2 oder 3. Wählen Sie zwei für die erste Migration – einen latenzsensitiven, einen CPU-lastigen.
• Einen Sandbox-Pool aufbauen: Eine Node-Gruppe mit Kata und eine mit gVisor (wo möglich managed). RuntimeClass-Objekte definieren und die Nodes tainten.
• Vorher/Nachher messen: Baseline für p50/p99-Latenz, CPU, RSS, Cold Start und Fehlerraten dieser zwei Services erheben. Akzeptieren Sie, dass +5–10% der Preis fürs Geschäft mit feindlichem Code sind.

Wochen 3–6: Policy durchsetzen

• Admission control an: Gatekeeper/Kyverno-Regeln, die Tier 2/3 Namespaces auf kata oder gvisor zwingen; privilegierte Flags blockieren; readOnlyRootFilesystem verlangen.
• Leitplanken in der Supply Chain: Cosign-Verifizierung verpflichtend; Images älter als 60 Tage abgelehnt; keine setuid-Dateien in Images erlaubt.
• Patch-SLO live: Das Drain-and-Patch-Runbook üben. Mean Time to Patch tracken und so sichtbar machen wie Uptime.

Wochen 7–12: Optimieren und ausweiten

• Pools richtig dimensionieren: Speicher ist bei Kata Ihr Engpass. Wenn jede Sandbox +80 MB kostet und Sie 300 Pods pro Node-Gruppe schedulen, sind das +24 GB. Nodes entsprechend skalieren oder Pod-Dichte reduzieren.
• Sandboxes vorwärmen: Für burstige Systeme einen Pool warmer Kata-VMs bereithalten oder diese Pfade auf gVisor umstellen, wenn Latenz König ist.
• Abdeckung ausweiten: Den Rest von Tier 2 und alle Tier 1 Services migrieren, die komplexe, angreiferkontrollierte Formate parsen (PDFs, Archive, Bilder, Model Weights).

Was Sie nicht tun sollten

• Vertrauen Sie nicht auf „privileged but careful“. Privilegierte Container sind eine Host-Shell mit Marketing. Wenn Sie sie brauchen, isolieren Sie sie in einen dedizierten Node-Pool hinter einem Jump Host und behandeln Sie sie wie ein Haustier.
• Gehen Sie nicht davon aus, dass Monitoring Sie rettet. Detection verkürzt den Blast-Radius nach der Kompromittierung; sie verhindert sie nicht. Bugs der CopyFail-Klasse erfordern Prävention und schnelles Patching.
• Vermischen Sie nicht Dev-Bequemlichkeit und Prod-Policy. Rootless ist lokal großartig. Das macht es nicht zu einer Multi-Tenant-Strategie.

Rückbindung an Ihre Roadmap (und Ihr Budget)

Dieser Wandel braucht kein Plattform-Rewrite. Es ist eine Runtime-Entscheidung plus operative Disziplin:

• Runtime-Entscheidung: Tiers auf RuntimeClass und Node-Pools abbilden. Zuerst die Managed-Optionen der Cloud nutzen.
• Operative Disziplin: Security-Defaults durchsetzen, schnell patchen und den Overhead messen. Planen Sie 5–10% mehr Compute-Kosten für den Anteil der Workloads ein, die wirklich stärkere Isolation brauchen.
• Business-Ausrichtung: Sagen Sie Product und Finance: Wir kaufen eine Klasse von Extremrisiko für einen mittleren fünfstelligen Betrag pro Jahr herunter. Das ist günstiger als ein einziger Breach mit Incident Response, Gutschriften und Vertrauensverlust.

CopyFail hat die Physik von Containern nicht geändert; es hat die Erzählung, dass „Rootless gleich sicher genug“ sei, zerstochen. Die richtige Reaktion ist kein Panikmodus. Es ist Klarheit. Entscheiden Sie, welchem Code Sie tatsächlich vertrauen. Geben Sie dem Rest eine echte Sandbox. Und üben Sie Patching, bis es langweilig ist.

Wichtigste Erkenntnisse

• Rootless reduziert den Blast-Radius, sandboxed den Kernel aber nicht. Behandeln Sie es bei untrusted Code als Bequemlichkeit, nicht als Sicherheit.
• gVisor für Tier 1–2 und Kata/Firecracker für Tier 2–3 Workloads einsetzen; je nach Workload 3–30% Overhead einkalkulieren.
• RuntimeClass, Pod-Sicherheit und Admission-Regeln durchsetzen, damit die richtigen Pods standardmäßig auf der richtigen Isolation landen.
• Auf LTS-Kernels pinnen, ein 6–24-Stunden-Patch-SLO für Container-Escape-CVEs einüben und exotische Kernel-Features meiden, die Sie nicht brauchen.
• Zusätzliche 50–120 MB RAM pro Kata-Sandbox und +150–400 ms Cold Starts erwarten; zum Einhalten von SLOs vorwärmen oder poolen.
• Images signieren, Distroless-Basen verwenden und Images, die älter als 60 Tage sind oder setuid-Dateien enthalten, ablehnen.
• Isolationsoverhead an Ihrem eigenen Code messen; die Zahlen veröffentlichen, damit Teams darum herum designen können.