第1節：コンテナの本質：プロセスレベルの仮想化

Last updated at 2026-05-15Posted at 2026-05-15

第1章：コンテナ技術の深層と隔離のメカニズム

レッドチームとしてターゲットに侵入した際、そのアーキテクチャの本質を理解しているかどうかは、攻撃の成否を分けます。

仮想マシン（VM）が Hypervisor を介してハードウェアをエミュレートし、ゲストOSを丸ごと動かすのに対し、コンテナは全く異なります。コンテナはホストOSのカーネルを直接共有して動作します。

「コンテナの本質は、制約を課せられた単なるLinuxプロセスである」

このプロセスに「自分は独立した環境で動いている」という錯覚（隔離環境）を抱かせるために、Linuxカーネルは主に2つの技術を提供しています。

Linuxカーネルは複数のNamespaceを提供しており、それぞれが特定のシステムリソースを分離します。レッドチームにとって、これらの設定ミスや欠如を見抜くことがエスケープの第一歩となります。

Namespaceの種類	隔離されるリソース	レッドチームの視点：隔離が不完全な場合
PID	プロセスID	ホスト上の全プロセスを視認・Kill可能になる。
NET	ネットワークデバイス・IP・ポート	ホストのトラフィックをスニッフィング、ローカルサービスへ接続可能。
MNT	マウントポイント（ファイルシステム）	ホストの敏感なファイル（`/etc/shadow`等）へアクセス可能。
UTS	ホスト名・ドメイン名	ホスト名の改ざん、フィッシング等への悪用。
IPC	プロセス間通信	ホストや他コンテナのプロセス通信を妨害・傍受。
USER	ユーザー/グループID	コンテナ内Rootをホストの非Rootにマップ（特権昇格の鍵）。

Red Team Note: コンテナエスケープの本質は、多くの場合、設定ミスやカーネルの脆弱性を突いて、ホスト側の特定のNamespaceへのアクセス権を「奪還」することにあります。

Namespaceが「幻術」だとすれば、Cgroups は「物理的な檻」です。CPU、メモリ、ディスクI/Oなどのリソース使用量を制限します。

防御側の視点：プログラムのバグや、植え付けられたマイニングマルウェアがホストのリソースを食いつぶす（DoS）のを防ぐ。
レッドチームの視点：
- Cgroupの特殊なファイル（release_agentなど）を利用した古典的な特権エスケープ手法が存在する。
- リソース制限が緩い場合、フォーク爆弾（Fork Bomb）等でホストを機能不全に追い込むことが可能。

コンテナ技術は突然現れたものではなく、数十年にわたる試行錯誤の歴史があります。

chroot (1979)：最古の「監獄」。ルートディレクトリのみを分離。教訓：.. 操作だけで簡単に脱獄可能だった。
LXC (2008)：Namespaceを統合した近代的なコンテナの雛形。教訓：デフォルト権限が強く、攻撃対象領域が広かった。
Docker (2013)：レイヤー化イメージと標準APIを導入。教訓：Docker DaemonがRoot権限で動作するため、そのソケット（Unix Socket）が最大の攻撃対象となった。
OCI標準 (2015)：runc 等の標準策定。現状：標準化により、runc の脆弱性がプラットフォームを問わず共通の脅威となった。

コンテナ内へのシェル奪取直後、攻撃者はまず以下の問いを立てるべきです。

次節では、コンテナ最大の「宿命」である共有カーネルの危うさについて深掘りします。