rootlessコンテナとuser名前空間による非特権隔離

rootlessコンテナが解く矛盾

通常のコンテナランタイムは root（より正確には CAP_SYS_ADMIN などの capability）を要求します。名前空間の生成、overlay マウント、veth の配線といった操作が特権を必要とするからです。rootless コンテナは、これらを 一般ユーザーの権限だけで 実現します。狙いは攻撃面の縮小です。デーモンが root で常駐しないため、ランタイムやコンテナを踏み台にしてもホストの root は奪えません。

成立の鍵は user 名前空間（userns）一点に尽きます。unshare(CLONE_NEWUSER) だけは、非特権ユーザーでも呼べる（多くのディストリで kernel.unprivileged_userns_clone=1 相当が有効）よう設計されています。新しい userns の作成者は、その名前空間の中で全 capability を満たした状態になります。つまり「自分が作った userns の内側でだけ root」になれる。この内側 root を足場に、PID・mount・network といった他の名前空間を 追加の特権なしに 作っていく——これが rootless の基本構造です。詳しい ID 写像の原理は 名前空間の内部実装 で扱っています。

subuid/subgid：1ユーザーに複数IDを貸し与える

userns の中で root になれても、使える UID が自分の1個だけ では困ります。コンテナ内で複数のサービスユーザー（www-data、postgres など別 UID）を動かしたいのに、写せる外側 UID が1つなら全員が同じホスト UID に潰れ、隔離が崩れます。

これを解くのが /etc/subuid と /etc/subgid です。各行は ユーザー名:開始ID:個数 で、そのユーザーが 自分のもの以外に追加で使ってよい UID/GID の範囲 を管理者が事前に割り当てます。

# /etc/subuid   ユーザー名:開始サブUID:個数
alice:100000:65536
bob:165536:65536

この例では alice はホスト UID 100000〜165535 の 65536 個を、自分の権限として使ってよいことになります。重要なのは、この範囲が ユーザー間で重ならない よう割り当てられる点です。重なれば、alice のコンテナが書いたファイルを bob のコンテナが所有者として扱えてしまい、隔離が破れます。割り当て自体は useradd 時や usermod --add-subuids で行われ、ファイル所有権は実際にはこの「サブ ID」で記録されます。

newuidmap/newgidmap：マッピングを書き込むsetuidヘルパ

/etc/subuid に範囲があっても、それを実際の uid_map へ展開する権限 がユーザーにはありません。uid_map への複数行書き込みには特権が要るからです。ここで登場するのが newuidmap・newgidmap という小さな setuid root プログラム（shadow-utils 付属）です。

ランタイム（Podman、Buildah、rootlesskit 等）は、子プロセスで userns を作った後、newuidmap PID 0 1000 1 1 100000 65536 ... のように呼びます。各引数の組は 内側ID 外側ID 個数 で、uid_map の各行に対応します。

newuidmap は setuid root で動くものの、要求された各範囲が 本当にその呼び出しユーザーへ /etc/subuid で割り当てられているか を必ず検証してから書き込みます。承認外の ID を要求すれば拒否されます。これにより「特権が必要な操作を、検証付きの小さなヘルパへ閉じ込める」——最小権限の原則がそのまま設計に現れています。GID 側も同様で、gid_map 書き込み前に setgroups を deny にする規則（補助グループ悪用対策）も newgidmap が面倒を見ます。capability の境界そのものは Linuxケーパビリティによる特権分割 を参照してください。

fuse-overlayfs：非特権でレイヤを重ねる

イメージのレイヤ合成には OverlayFS が使われますが、ここで rootless の壁にぶつかります。カーネルの overlayfs を mount(2) で重ねる操作は、長らく特権（実質ホスト root）を要した からです。userns の内側で root でも、それは「その userns に属する資源」にしか効かず、ファイルシステムのマウントというホスト規模の操作はそのままでは許されません。

回避策が2系統あります。

• fuse-overlayfs: OverlayFS と同等のレイヤ重ね合わせを ユーザー空間（FUSE）で実装 したもの。FUSE のマウント自体は非特権で行えるため、カーネル overlayfs の特権要件を迂回できます。代償として、I/O がユーザー空間を往復する分のオーバーヘッドが乗ります。
• カーネル overlayfs の userns 対応: 比較的新しいカーネルでは、user 名前空間内からの overlayfs マウントが条件付きで許可されるようになりました。条件が揃えば FUSE を介さずネイティブ性能で動きます。

OverlayFS そのものの上位・下位レイヤや copy-up の原理は コンテナのオーバーレイファイルシステム で詳しく扱っています。rootless では、どちらの方式でも 下位レイヤのファイル所有者が subuid 経由でずれて見える 点に注意が必要です。イメージ内で UID 0 所有だったファイルが、ホスト上では subuid（例 100000）所有として記録されるためです。

rootlessの設計上の制約

rootless は万能ではありません。原理的に解けない、あるいは代償を伴う制約があります。

もう一つの本質的制約が カーネルそのものの攻撃面 です。userns は非特権ユーザーが大量のカーネルコード経路（特に過去に脆弱性が集中した領域）へ到達できるようにします。このため一部のディストリやセキュリティ方針では、非特権 userns を無効化したり、seccomp や LSM で締めたりします。rootless はホスト root の奪取を難しくしますが、カーネル LPE（ローカル権限昇格）の入口を増やしうる 両刃の側面を持つ、と理解しておく必要があります。

まとめ