CrackArmor
2026年3月、セキュリティ企業 Qualys が Linux カーネルの AppArmor（Linux Security Module）に複数の脆弱性を発見し、これらをまとめて 「CrackArmor」 と命名して公表しました（アドバイザリ日：2026-03-13）。
AppArmor とは、プロセスごとにアクセス可能なファイルやシステムコールを制限するセキュリティ機構で、Ubuntu・Debian・SUSE などの主要ディストリビューションでデフォルト有効化されています。Proxmox VE もその例外ではありません。
今回発見された脆弱性は合計 9件（CVE は 11件割り当て：CVE-2026-23268～CVE-2026-23411）で、すべて ローカルの非特権ユーザーによるアクセスが前提となっています。
Proxmox
Proxmox Virtual Environment（Proxmox VE）は、オープンソースの仮想化プラットフォームです。KVM（カーネルベース仮想マシン）と LXC（Linux コンテナ）を統合したハイパーバイザーであり、Debian Linux をベースとして構築されています。
データセンターや中小規模のサーバー環境で広く採用されており、Web UIから仮想マシンやコンテナの管理・監視・スナップショット取得などをまとめて行えるのが特徴です。Proxmox はデフォルトでカスタムビルドの Linux カーネル（proxmox-kernel）を使用しており、このカーネルには AppArmor が有効な状態で組み込まれています。
脆弱性の内容
1. Confused Deputy 問題（CVE-2026-23268）：根本的な権限昇格の起点
すべての攻撃の起点となる脆弱性です。
AppArmor がプロファイルを読み込み・置換・削除するための疑似ファイル（/sys/kernel/security/apparmor/.load、.replace、.remove）が、パーミッション 0666（誰でも書き込み可能） として公開されています。実際の書き込みは権限チェックによって弾かれますが、su コマンドの PTY モード（-P オプション）を悪用することで、非特権ユーザーでも任意の AppArmor プロファイルをロード・置換・削除できることが判明しました。
この脆弱性単体で以下が可能になります。
- 既存プロファイルの削除（sshd や rsyslogd などの保護を外す）
- 新たな制限プロファイルのロード（sshd を完全に機能停止させるなど）
- Ubuntu のユーザー名前空間制限のバイパス
2. AppArmor + sudo + Postfix による root 権限昇格
上記の Confused Deputy を起点に、sudo の脆弱性（CVE-2026-35535）と Postfix を組み合わせることで、非特権ユーザーから root への完全な権限昇格が実証されています。
攻撃の流れは以下の通りです。
- CAP_SETUID を拒否するカスタム AppArmor プロファイルを sudo に適用する
- sudo が権限降格（setuid）に失敗したまま、ユーザー制御の環境変数（MAIL_CONFIG）付きで /usr/sbin/sendmail（Postfix）を root 権限のまま 実行してしまう
- Postfix が root として任意のコマンドを実行する
3. カーネル空間の脆弱性群
Qualys はカーネルコード内にさらに複数の深刻な脆弱性を発見しています。
無制限な再帰（Uncontrolled Recursion）
深くネストされたサブプロファイル階層（1024段など）を作成してプロファイルを削除すると、カーネルスタックが枯渇し、システムがクラッシュします。DoS（サービス妨害）として機能します。
境界外読み取り（Out-of-Bounds Read）（CVE-2026-23269）
DFA（決定性有限オートマトン）のマクロに起因するバグにより、ファイル名バッファの 8KB 境界を超えて最大 64KB のカーネルメモリを読み取れます。KASLR でランダム化されたカーネルポインタの漏洩につながります。
Use-After-Free
AppArmor のプロファイルロードデータ管理に競合状態があり、解放済みメモリへのアクセスが発生します。Qualys はこれを利用して /etc/passwd のページキャッシュを改ざんし、root への権限昇格を実証しました（Ubuntu 24.04.3 で確認）。
Double-Free
aa_replace_profiles() 内での名前空間名の二重解放バグです。Debian 13.1 上で root への権限昇格が実証されています。
起こりうる被害
CrackArmor が悪用された場合、影響は段階的に拡大します。
サービス妨害（DoS）
AppArmor プロファイルを悪意ある内容に差し替えることで、sshd やその他のサービスを強制停止させられます。また、無制限再帰の脆弱性によるカーネルパニックでシステム全体がクラッシュします。
セキュリティ制御の無効化
既存の AppArmor プロファイルを削除することで、アプリケーションへの強制アクセス制御が外れます。Ubuntu のユーザー名前空間制限もバイパスされます。
カーネルメモリの漏洩
境界外読み取りにより、KASLR のランダム化を突破するための情報が取得でき、以降の攻撃の足がかりになります。
root への権限昇格
Use-After-Free または Double-Free を利用して、プロセスの認証情報（cred 構造体）を root として書き換えることができます。これにより、システム上のあらゆる操作が可能になります。
コンテナエスケープ（理論上）
Proxmox のようなコンテナ実行環境では、悪意あるコンテナイメージが Confused Deputy を必要とせず直接カーネル脆弱性を突ける可能性があります。コンテナからホストへの脱出シナリオが理論的に成立します（執筆時点では未実証）。
対処法
Proxmox VE の場合
Proxmox は 2026-03-13 にセキュリティアドバイザリ（PSA-2026-00010-1）を公開し、修正済みカーネルを提供しています。以下のバージョン以降に更新してください。
| 対象環境 | 修正済みカーネルバージョン |
|---|---|
| Bookworm ベース | proxmox-kernel-6.8.12-20-pve または proxmox-kernel-6.14.11-6-bpo12-pve |
| Trixie ベース | proxmox-kernel-6.14.11-6-pve または proxmox-kernel-6.17.13-2-pve |
更新コマンド：
apt update && apt full-upgrade
# 更新後に再起動が必要
reboot
RHEL系（Rocky Linux / AlmaLinux / RHEL）の場合
RHEL系ディストリビューションは CrackArmor の影響を受けません。
理由は、RHEL系が AppArmor ではなく SELinux（Security-Enhanced Linux） を MAC（強制アクセス制御）機構として採用しているためです。CrackArmor は AppArmor のカーネルコードに存在するバグ群であり、SELinux のコードとはまったく別物です。
RHEL 系で現在 SELinux が有効になっているかは以下で確認できます。
# SELinux の状態確認
$ sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux mount point: /sys/fs/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 33
# AppArmor が存在しないことを確認（RHEL系では通常このコマンドは存在しない）
$ aa-status
-bash: aa-status: command not found
AppArmor と SELinux の違い
CrackArmor を理解する上で、両者の設計思想の違いを押さえておくことが有益です。
| 観点 | AppArmor | SELinux |
|---|---|---|
| 主な採用ディストリ | Ubuntu / Debian / SUSE / Proxmox | RHEL / Rocky / Alma / Fedora / Android |
| ポリシーの基準 | ファイルパスベース | ラベル（セキュリティコンテキスト）ベース |
| 設定の容易さ | 比較的シンプル | 複雑だが細かな設定が可能 |
| プロファイル管理 | /sys/kernel/security/apparmor/ 以下の疑似ファイル | semanage / audit2allow などのツール経由 |
| CrackArmorの影響 | 疑似ファイルへの不正書き込みが起点 | 影響なし |
AppArmor のファイルパスベースのアプローチは設定が直感的である反面、今回問題となった疑似ファイルへの書き込み権限チェックのタイミングという設計上の隙が生まれやすい構造でもあります。SELinux はポリシーをラベルに紐づけて管理するため、同様の「Confused Deputy」問題は構造的に発生しにくいとされています。
ただし、SELinux も万能ではなく、ポリシーの設定ミスや別系統のカーネル脆弱性による攻撃は引き続き存在します。「RHEL系だから安全」というわけではなく、カーネルアップデートの継続適用は変わらず重要です。
共通の確認コマンド（Proxmox / Debian 系）
# 現在のカーネルバージョンを確認
uname -r
# インストール済みカーネルを確認
dpkg -l 'linux-image*' | grep ^ii
# sudo / util-linux のバージョンを確認
dpkg -l 'sudo*' 'util-linux' | grep ^ii
暫定的な緩和策（カーネル更新が難しい場合）
AppArmor の疑似ファイルへのアクセスを制限するか、su の PTY モードの利用を監視・制限することで攻撃面を縮小できます。ただし、根本的な解決にはカーネルの更新が必須です。
まとめ
CrackArmor は、セキュリティ機構であるはずの AppArmor 自体の実装に潜む脆弱性群であり、影響範囲が Linux 全体に及ぶ点で非常に深刻です。Proxmox VE 環境においても同様で、修正済みカーネルへの早期アップデートを強く推奨します。
「セキュリティ機構はそれ自体が攻撃対象になりうる」という事実は、以前から指摘されていましたが、今回の CrackArmor はまさにその実例となりました。インフラ担当者としては、セキュリティパッチの適用を習慣的に行うとともに、コンテナ環境では特にカーネルアップデートの優先度を高く保つことが重要です。
