Linuxケーパビリティによる特権分割

なぜrootを「分割」する必要があるのか

伝統的なUNIXの権限判定は二分法でした。実効UIDが0（root）なら、カーネルの大半の権限チェックを丸ごと素通りする。ping が生のICMPソケットを開きたいだけでも、setuid root にして すべての特権 を与えるしかありませんでした。問題は、そのプログラムに脆弱性があれば、攻撃者も同じ全権を握る点です。必要なのは「生ソケットを開く」一片だけなのに、ファイルを上書きする権限も、カーネルモジュールを読み込む権限も、ついてきてしまう。

Linuxケーパビリティ（capabilities）は、この UID 0が持つ単一特権を、約40個の独立したケーパビリティへ分解 する仕組みです。CAP_NET_RAW（生ソケット）、CAP_NET_BIND_SERVICE（1024未満のポートへのbind）、CAP_SYS_ADMIN（多数の管理操作）、CAP_DAC_OVERRIDE（ファイルパーミッション無視）のように、特権が機能単位の名前を持ちます。プロセスは必要な一片だけを保持し、カーネルの権限チェックは「UID == 0 か」ではなく「該当ケーパビリティを実効集合に持つか」を見るようになります。これはカーネルモードとユーザーモードの権限境界を、より細かい粒度で再定義する試みです。

5つのケーパビリティ集合

各スレッドは、ケーパビリティの状態を5つのビット集合で保持します。task_struct の資格情報（struct cred）内に置かれ、それぞれ役割が異なります。

基本の運用は、PにありEに無いケーパビリティは「持っているが今は休眠中」という状態です。プログラムは capset(2)（や libcap の cap_set_proc）で、必要な瞬間だけPからEへ上げ、用が済めばEから落とす。権限を行使する区間を最小化する 特権分離（privilege separation） の基本動作です。Permittedにあるものは、自分の判断でいつでもEffectiveへ出し入れできます。逆にPに無いものは、execveを経ない限り後から増やせません。

ファイルケーパビリティとexecveの遷移式

ファイルケーパビリティは、実行ファイルの 拡張属性 security.capability に格納されます。setcap 'cap_net_raw+ep' /bin/ping を実行すると、この属性にPermitted集合・Inheritable集合・Effectiveフラグが書き込まれます。これはELFローダが解釈するファイル内容とは別の、ファイルシステムのメタデータです。属性に含まれる3要素を、慣例で F(permitted)、F(inheritable)、F(effective) と表記します。

execve(2) の瞬間、カーネルは旧スレッドの集合とファイル属性から、新スレッドの集合を計算します。中核となる遷移式は次の擬似コードのとおりです（P' が新プロセス側、P が呼び出し元側）。

P'(ambient)     = (file caps or setuid/setgid なら) 空集合 : P(ambient)
P'(permitted)   = (P(inheritable) & F(inheritable))
                  | (F(permitted) & P(bounding))
                  | P'(ambient)
P'(effective)   = F(effective) が真なら P'(permitted) : P'(ambient)
P'(inheritable) = P(inheritable)        # 変化しない
P'(bounding)    = P(bounding)           # 変化しない

ここで読み取るべき原理は3つあります。第一に、新しいPermittedは2系統から得られます——呼び出し元のInheritableとファイルのInheritableの 論理積（I & F(inheritable)）、そしてファイルのPermitted。前者が「呼び出し元が渡そうとし、かつファイルが受け取りを許可した」交差点で、特権の受け渡しに 両者の合意 を要求する設計です。第二に、どちらの経路も最後に bounding（天井）とANDされ、上限を超えられません。第三に、Effectiveフラグがファイル側で立っていれば、起動直後に全Permittedが有効化されます。

setuid rootの代替としての設計

ケーパビリティの最大の動機は、setuid root の置き換えです。両者の振る舞いの差を整理します。

setuid root が実効UIDを0へ変える副作用に対し、ファイルケーパビリティは UIDを一切変えずに特定の権限ビットだけ を渡します。ping を cap_net_raw+ep で配れば、実効UIDは一般ユーザーのまま、ファイルを書き換える CAP_DAC_OVERRIDE も持たない。万一 ping に脆弱性があっても、攻撃者が得るのは生ソケットを開く能力に限られます。攻撃面（attack surface）を最小化する 最小権限の原則 の、具体的な実装手段です。

ambient集合とboundingの実務

初期のケーパビリティ設計には穴がありました。Inheritableは「ファイル側のInheritableとのAND」を要求するため、ファイルケーパビリティを持たないスクリプトやインタプリタ には権限が一切渡りませんでした。シェルスクリプト経由で特権を子へ引き継ぎたい非特権ユースケースが書けなかったのです。これを埋めるのが ambient集合 です。

ambientにあるケーパビリティは、ファイルケーパビリティ無しのexecveでも P'(permitted) と P'(effective) の両方へ生き残ります（前掲の遷移式の P'(ambient) 経由）。ただし安全のため厳しい制約があります——ambientへ立てられるのは「PermittedかつInheritableの両方にあるケーパビリティ」だけで、setuid/setgidバイナリやファイルケーパビリティ付きバイナリをexecveすると ambientは即座に空へクリア されます。特権昇格バイナリと継承経路が混ざって意図せぬ権限漏れが起きるのを防ぐためです。

一方 bounding集合 は天井として働きます。prctl(PR_CAPBSET_DROP, ...) でケーパビリティを落とせますが、これは 不可逆 で、一度落とすと自分も子孫も二度とそのケーパビリティをPermittedへ得られません。コンテナランタイムが起動時に不要なケーパビリティをboundingから一括ドロップするのは、たとえコンテナ内のプロセスがファイルケーパビリティ付きバイナリをexecveしても、天井を超える権限は決して得られない保証を作るためです。名前空間の内部実装で見たユーザー名前空間と組み合わせると、内側のrootが持つケーパビリティはその名前空間内の資源にしか効かず、boundingがさらに上限を縛る、という二重の封じ込めになります。

まとめ