ソフトウェア2026/11/10 21:11 UTC·3 分で読めます

Ubuntu 26.04のカーネル更新でAppArmor変更、コンテナ障害

Ubuntu 26.04のカーネルに入ったセキュリティ修正でAppArmorのスタック動作が変わり、コンテナ内のシグナルが拒否される。gosuやPostgreSQLが停止する。

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

SUMO：数字パズル

Dialo：話して学ぶ語学アプリ

ediviewer：EDIファイルを文書のように読む

giftdetect：数分でぴったりの贈り物

Ubuntu 26.04のカーネル更新に含まれるAppArmorのセキュリティ修正(CVE-2026-90231)が、コンテナ環境で障害を引き起こしている。コンテナ内でのシグナル送信が「Permission denied」で拒否され、gosu、PostgreSQL、Percona Operator for MySQL(PXC)のPodなどが起動できなくなる。

影響を受ける環境

対象はUbuntu 26.04、または7.0.0-41以降のバックポートを含むカーネル(linux-awsやlinux-azureなどのクラウド向けビルドも含む)。kernel.apparmor_restrict_unprivileged_unconfined=1(26.04では既定値)で、containerdまたはDockerが標準のAppArmorプロファイルを使う構成が該当し、ほぼすべてのKubernetes、k3s、RKE2、Dockerホストが当てはまる。

症状として、uidが同じでseccompが無効でもkillが拒否される。gosuはCPU 100%で回り続けるがサービスは起動せず、ログも出ない。PostgreSQLは「could not signal for checkpoint: Permission denied」を出力し、カーネルログにはpeer="cri-containerd.apparmor.d//&unconfined"を含むDENIEDが記録される。

原因

このパラメータは2025年2月からUbuntuで有効で、CAP_MAC_OVERRIDEを持たないunconfinedプロセスがプロファイルを切り替える代わりに、unconfinedの上にスタックする仕組みだ。コミット08c2f7c8d4b1はこの制限の回避策を塞ぎ、exec時にも強制スタックを適用するようにした。runcはcapabilitiesを落としてからexecするため、標準プロファイルのコンテナはすべてcri-containerd.apparmor.d//&unconfined(Dockerではdocker-default//&unconfined)で動く。

containerdのプロファイルテンプレートにあるsignal (receive)とptraceのルールは、完全一致のpeer=cri-containerd.apparmor.dのみが対象で、複合ラベルには合致しない。このため同一コンテナ内のプロセス間やスレッド間でもシグナルが拒否される。Goではsetuidがsched_yieldのループに陥って固まる。

経緯と対処

7.0.0-38.38が影響のない最後のカーネルとされる。7.0.0-42.42がresolute-updatesに公開された同日にLP #2172422とcontainerd#14485が起票され、その後resolute-securityに入ってunattended-upgradesで自動適用され、ノード再起動後に障害が表面化した。7.0.0-43.43でも症状は残り、7.0.0-44.44はproposedにある。最初の不具合版を-41とする報告と、-42のみを確認した報告があり、情報に食い違いがある。

暫定策として、PerconaXtraDBClusterのCRでAppArmorを外すか、ノード上でrootとしてホストPIDにシグナルを送る方法がある。containerdのプロファイル修正はPR #14487で提案されている。