コンテナと名前空間

現在の root 権限がホストのものかコンテナ内に限られるものかを調べ、共有マウントやホストのソケットも確認する。プロンプトに root と表示されても、ホストへの影響は別に検証する。

確認コマンド

追加確認例:

cat /proc/1/cgroup
tr '\0' ' ' < /proc/1/cmdline
tr '\0' '\n' < /proc/1/environ
mount
findmnt
cat /proc/self/mountinfo
ls -ld /.dockerenv /var/run/docker.sock 2>/dev/null
lsns
capsh --print
cat /proc/self/status | grep Cap
docker ps

目的: PID 1、cgroup、マウント、capability、Docker ソケット、内部ネットワークから、現在の権限の範囲を確認する。
前提条件: docker ps は Docker socket への権限が必要。capsh がない環境も多い。
何を確認しているか: /.dockerenv、PID 1、OverlayFS、bind mount、/var/run/docker.sock、capability、到達できる内部アドレス。
期待される出力: CapEff: 0000000000000000、ホストのファイルシステムを共有するマウント、Docker ソケットの有無、到達できる内部サービスのアドレス。
出力の解釈: コンテナ内の root や模擬クラウド環境の root は、ホストの root 権限を持つとは限らない。ホストへの影響は、マウント、capability、ソケット、ネットワーク、実ファイルの変化で確認する。
失敗した場合の切り分け: 最小構成のイメージ、名前空間の違い、/proc の制限、rootless コンテナ、Docker 以外のランタイムを考える。
代替コマンド: ls -la /, hostname, ip route, find /run -maxdepth 2 -type s -ls 2>/dev/null。
状態変更: 読み取り専用。docker ps は通常読み取りだが、Docker socket へのアクセス自体が監査対象になり得る。

ファイル capabilities の探索はファイルとディレクトリ権限の getcap を使う。プロセスの CapEff とは別に記録する。

container 内の root を host root と分けるときは、次をセットで残す。

ワーカーの CapEff が 0 でも、別のコンテナでは root に見えることがある。模擬クラウド API やビルド用コンテナでも、内部の root がホストの権限を持つとは限らない。
ホストへの到達を主張する際は、特権コンテナからホストの core_pattern などを変更できるか、実際の経路を確認する。コンテナ内の資格情報を使ってホストのユーザーとしてログインする経路は、別に記録する。
共有 bind mount では、コンテナ側の chmod がホスト側ユーザーの書き込み可否を変えることがある。
kernel や local exploit を使う場合は、exploit 名と別に、kernel version、namespace、capabilities、必要な kernel module の有無を残す。CapEff は grep Cap /proc/self/status または capsh --print で直接取る。

Docker ソケットが見つからない場合も、bind mount と内部サービスを確認する。内部の待ち受けはネットワークと IPCで調べる。