Oprogramowanie10 lis 2026, 21:11 UTC·2 min czytania

Ubuntu 26.04: aktualizacja jądra z AppArmor psuje kontenery

Poprawka bezpieczeństwa w jądrze Ubuntu 26.04 zmienia stackowanie profili AppArmor. Kontenery odmawiają sygnałów, a gosu, PostgreSQL i pody Percona zawieszają się.

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

Poprawka bezpieczeństwa w jądrze Ubuntu 26.04 może nieoczekiwanie unieruchomić kontenery na produkcji. Zmiana w AppArmor sprawia, że procesy wewnątrz kontenerów dostają błąd Permission denied przy wysyłaniu sygnałów, nawet do własnych procesów z tym samym uid. Problem dotyczy m.in. Kubernetesa, k3s, RKE2 i hostów Docker.

Jak objawia się awaria

Problem wystąpi na Ubuntu 26.04 lub na jądrze z backportem z wersji 7.0.0-41+, także w buildach chmurowych, takich jak linux-aws i linux-azure. Dodatkowo parametr kernel.apparmor_restrict_unprivileged_unconfined=1 (w 26.04 domyślny) musi być włączony, a środowisko musi używać containerd lub Dockera ze standardowym profilem AppArmor.

W dzienniku jądra pojawiają się wpisy w rodzaju apparmor="DENIED" operation="signal" z peer="cri-containerd.apparmor.d//&unconfined". PostgreSQL zgłasza błąd could not signal for checkpoint: Permission denied. Z kolei gosu, a także każdy program w Go wywołujący setuid, zajmuje 100% CPU, ale usługa nie startuje i nie ma logów. Autor opisuje to na przykładzie podów PXC (Percona Operator for MySQL), które nie wstały po zmianie zasobów węzłów w klastrze Kubernetes, a potem aplikacji, która nigdy nie stała się Ready.

Przyczyna

Od lutego 2025 roku Ubuntu włącza parametr, który uniemożliwia procesowi unconfined bez CAP_MAC_OVERRIDE zwykłą zmianę profilu; nowy profil jest nakładany stosem na unconfined. Commit 08c2f7c8d4b1 (CVE-2026-90231) zamknął obejście tego ograniczenia i zaczął wymuszać stack także przy exec.

runc najpierw zrzuca capabilities, a potem wykonuje exec procesu kontenera. W efekcie każdy kontener ze standardowym profilem działa pod etykietą cri-containerd.apparmor.d//&unconfined (w Dockerze docker-default//&unconfined). Szablon profilu containerd zezwala jednak na sygnały tylko od dokładnej nazwy cri-containerd.apparmor.d, więc złożona etykieta nie pasuje i jądro odrzuca sygnały nawet między wątkami jednego kontenera.

Obejścia i chronologia

Doraźnie pomaga wyłączenie AppArmor w CR PerconaXtraDBCluster albo wysłanie sygnału z węzła jako root, po znalezieniu host-PID przez crictl inspect. Ostatnim nietkniętym jądrem jest według autora linux 7.0.0-38.38. Wersja 7.0.0-42.42 trafiła do resolute-security, więc instaluje ją też unattended-upgrades. Wersja 7.0.0-43.43 nadal ma objawy, a 7.0.0-44.44 jest w proposed. Zgłoszono błąd LP #2172422 i containerd#14485, a poprawkę profilu zaproponowano w PR #14487. Dane są nieco rozbieżne: część raportów wskazuje jako pierwszą wadliwą wersję 7.0.0-41, część sprawdzała tylko -42.