差分

このページの2つのバージョン間の差分を表示します。

--- linux:kernel:namespace:more_on_user_namespaces [2013/11/19 12:01] – [ユーザ名前空間と他の名前空間の同時使用] tenforward
+++ linux:kernel:namespace:more_on_user_namespaces [2013/11/20 05:46] (現在) – [ケーパビリティふたたび] tenforward
@@ 行 107: / 行 107: @@
 カーネルはユーザ名前空間内の初期プロセスに全てのケーパビリティを与えるが，これは，その後でプロセスがシステムワイドでスーパーユーザの特権を持つことは意味しない．(しかし，従来は root だけがアクセスできたカーネルコード内の弱点にアクセスできるようになったことは意味するかもしれない．[[http://lwn.net/Articles/540083/|このメール]]にある tmpfs のマウントの問題に存在した脆弱性のような．)新しい IPC，マウント，ネットワーク，PID，UTS 名前空間が clone() か unshare() で作られた際，カーネルは新しい名前空間に対して作成するプロセスのユーザ名前空間を記録する．プロセスが名前空間が管理しているグローバルリソースの操作をしようとするときはいつでも，カーネルがその名前空間に関連付けたユーザ名前空間内のプロセスのケーパビリティによってパーミッションチェックが実行される．
+例えば，clone(NEW_USER) を使ってユーザ名前空間を作成すると仮定しよう．生成される子プロセスは新しいユーザ名前空間内ではフルセットのケーパビリティを持つ．これは，例えば，他のタイプの名前空間を作成することが可能になることと，自身のユーザ，グループ ID と名前空間内でマッピングされる他の ID を変えることが可能になることを意味する．(このシリーズの前の記事にあるように，我々は親の名前空間内の特権プロセスのみが，名前空間を作成するプロセスの実効ユーザ，グループ ID 以外の ID へのマッピングを作成することができることを見ているので，ここにはセキュリティ的な抜け道は存在しない．)
+一方で，子プロセスはファイルシステムをマウントできない．子プロセスはまだ初期のマウント名前空間に留まっており，その名前空間内でファイルシステムをマウントするためには，マウント名前空間と関連付いたユーザ名前空間内でケーパビリティを持つ必要がある (すなわち，初期のユーザ名前空間内でのケーパビリティが必要ということである)．このケーパビリティは子プロセスは持っていない．同様のことが IPC, ネットワーク，PID，UTS 名前空間で隔離されたグローバルリソースに対しても言える．
+その上，子プロセスは名前空間が (現時点では) 持っていないケーパビリティが必要な特権操作を行うことはできない．それゆえ，例えば，子プロセスは自身のリソースのハードリミットを上げたり，システム時間を設定したり，プロセスの優先度を設定したり，カーネルモジュールをロードしたり，<del>システムをリブートしたり</del>といったようなことを行うことはできない．これらの操作は全て，ユーザ名前空間の階層構造の外部に存在するケーパビリティが必要であり，事実上，これらの操作は呼び出し元が初期のユーザ名前空間内でケーパビリティを持っていることが必要となる．
+名前空間に対するケーパビリティの効果を隔離することによって，ユーザ名前空間は以上のように，特権のないユーザが，従来は root に限定されていた機能へのアクセスを，安全性を保証しながら実行することを可能にした．これにより，新しい種類のユーザ空間アプリケーションに対する面白そうな可能性が創りだされた．例えば，今後は非特権ユーザが root 特権なしで Linux コンテナを実行できるようになったり，[[http://dev.chromium.org/developers/design-documents/sandbox|Chromeスタイルのサンドボックス]]を setuid 使用の助けを借りずに構築可能になったり，[[http://fakeroot.alioth.debian.org/|Fakeroot]]タイプのアプリケーションをダイナミックリンクのトリックを使わずに実装出来るようになったり，プロセスの隔離のための[[http://lwn.net/Articles/252794/|chrootベースのアプリケーション]]を実装できるようになったりした．カーネルのバグがなければ，特権が必要なカーネルの機能にアクセスするためにユーザ名前空間を採用したアプリケーションは，setuid ベースの伝統的なアプリケーションに比べてよりセキュアになった．ユーザ名前空間ベースのアプローチで，アプリケーションがセキュリティ侵害を受けたとしても，システム全体にダメージを与えるのに使えるような特権は持っていない．
+著者は，このシリーズを書く過程の名前空間に関する実験で生じた多数の質問への回答に対して，Eric Biederman に感謝を述べたい．