Osegi
Software·2 Min. Lesezeit

Ubuntu 26.04: Kernel-Update legt Container per AppArmor lahm

Ein Sicherheitspatch im Ubuntu-26.04-Kernel ändert das AppArmor-Stacking. Folge: Container verweigern Signale, gosu, PostgreSQL und Percona-Pods hängen.

Server rack with terminal output showing AppArmor denied signal errors from a container running on an Ubuntu host.
Bild: Хабр

Ein aktuelles Kernel-Update für Ubuntu 26.04 kann containerisierte Dienste ohne Vorwarnung lahmlegen. Ein Entwickler, der beim Anpassen einer Kubernetes-Node-Gruppe darauf stieß, beschreibt, wie ein AppArmor-Sicherheitsfix dazu führt, dass Container selbst Signale zwischen Prozessen desselben Nutzers ablehnen.

Was passiert

Betroffen sind Ubuntu 26.04 oder Kernel mit dem Backport ab 7.0.0-41, auch Cloud-Builds wie linux-aws und linux-azure. Voraussetzung ist die Einstellung kernel.apparmor_restrict_unprivileged_unconfined=1, die in 26.04 Standard ist, sowie containerd oder Docker mit dem Standard-AppArmor-Profil. Das trifft nahezu jeden Kubernetes-, k3s-, RKE2- oder Docker-Host.

Typische Symptome: Permission denied bei kill im Container trotz gleicher uid und ohne seccomp; gosu und andere Go-Binaries mit setuid laufen mit 100 % CPU, ohne Logs und ohne Dienststart; PostgreSQL meldet «could not signal for checkpoint: Permission denied». Im Kernel-Log steht apparmor="DENIED" operation="signal" mit dem Peer cri-containerd.apparmor.d//&unconfined.

Aufgefallen war es dem Autor, als mehrere Pods des Percona Operator for MySQL (PXC) nach dem Neustart der Nodes nicht starteten. Als schnelle Abhilfe half das Abschalten von AppArmor in der Custom Resource oder das Senden des Signals als root vom Node aus. Danach hingen die Anwendungs-Pods, weil gosu nie fertig wurde; ein Helm-Chart musste angepasst werden.

Der Mechanismus

Seit Februar 2025 verhindert Ubuntu, dass unconfined-Prozesse ohne CAP_MAC_OVERRIDE einfach das Profil wechseln; stattdessen wird das neue Profil über unconfined gestapelt. Der Commit 08c2f7c8d4b1 (CVE-2026-90231) schloss eine Umgehung und erzwingt das Stacking nun auch bei exec. Da runc vor dem exec die Capabilities entfernt, läuft jeder Container mit Standardprofil unter dem zusammengesetzten Label cri-containerd.apparmor.d//&unconfined (bei Docker docker-default//&unconfined).

Die Profilvorlage von containerd erlaubt Signale und ptrace nur vom exakten Namen cri-containerd.apparmor.d. Das kombinierte Label passt nicht, daher blockiert der Kernel Signale sogar zwischen Threads desselben Containers.

Zeitplan und Stand

Der letzte unbetroffene Kernel ist 7.0.0-38.38. Version 7.0.0-42.42 erschien in resolute-updates; am selben Tag wurden Fehlerberichte und containerd#14485 eröffnet, ein Profil-Fix liegt als containerd-PR #14487 vor. Als 7.0.0-42.42 in resolute-security landete, installierte unattended-upgrades sie automatisch, und nach Node-Neustarts kam es zu Ausfällen. 7.0.0-43.43 zeigt dieselben Symptome, 7.0.0-44.44 liegt in proposed. Unklar ist, ob 7.0.0-41 oder erst -42 die erste fehlerhafte Version ist.

Apps, die sich lohnen

SUMO: das Zahlenrätsel

Tippe die richtigen Felder, addiere, triff das Ziel. Leicht zu lernen, schwer zu meistern. Kostenlos, für jedes Alter.

Schlagwörter:ubuntuapparmorkubernetescontainerdlinux kerneldocker

Mehr von diesem Tag

Alle anzeigen →

Mehr aus: Software

Alle anzeigen →