AppArmor.

AppArmor は Linux Security Module (LSM) の一つで、SELinux が用いる inode ラベルではなく、ファイルパス・capability・ネットワークプリミティブで表現されるプログラム単位のプロファイルにより強制アクセス制御を実施します。起源は Immunix で、SUSE と Canonical が保守しており、2000 年代後半から Ubuntu と openSUSE の既定の MAC フレームワークであり、カーネルバージョン 2.6.36 以降はメインラインカーネルに組み込まれています。プロファイルは /etc/apparmor.d に置かれ、enforce モードまたは complain(ログのみ)モードで読み込め、aa-genprof、aa-logprof、aa-easyprof といった補助ツールが用意されています。パスベースの設計は一般に SELinux ポリシーよりも記述や監査が容易ですが、その代わりにリネーム、bind mount、chroot に対する意味論はやや弱くなります。

コンテナでは、--security-opt apparmor= で上書きしない限り、Docker はすべてのコンテナに対して enforce モードで docker-default プロファイルを生成し tmpfs へ読み込みます。これは /proc/sysrq-trigger や /sys といった機微なパスへの書き込みをブロックし、seccomp や剥奪した capability とともに多層防御として機能します。AppArmor は snapd、libvirt、LXD、Firefox でも利用されています。その限界は現実的です。ルールが基盤となるオブジェクトではなくパスにマッチするため、ハードリンクやマウントの細工によってプロファイルを回避できる場合があり、プロファイルの良し悪しはそのルール次第です。広すぎるグロブ(たとえば /** rwk を許可するなど)は、その意義そのものを台無しにします。CVE-2019-5736(runc のホストバイナリ上書き)は、コンテナ脱出が既定プロファイルのカバーしない領域で起こりうることを示しました。だからこそ AppArmor は単独で頼るのではなく、seccomp、ユーザー名前空間、読み取り専用マウントと組み合わせて層を成すのです。

flowchart TB
  P[プロセスの実行] --> K[カーネル LSM フック]
  K --> Q{プロファイルは読み込み済み?}
  Q -- No --> U[非拘束:通常の DAC]
  Q -- Yes --> M{操作はプロファイル内?}
  M -- enforce モード --> R{許可される?}
  R -- Yes --> A[許可]
  R -- No --> D[拒否 + 監査ログ]
  M -- complain モード --> L[許可 + 違反をログ記録]

典型的なワークフローでは、新しいプロファイルをまず complain モードで実行してアプリケーションを一通り動作させ、次に aa-logprof で記録されたアクセスをルールに変換してから enforce モードへ切り替えます。