YLUGのカーネル読書会で、POSIX capabilityについて話してきた。
capability自体は 2.4.x カーネルの頃から存在した機能だが、最近のカーネル(2.6.24〜)で、大幅な拡張が加えられている。
説明した内容は、以下の３つ。
■ FILE POSIX Capability (2.6.24 merged)
- SetUIDを置き換える F(permitted)
- RBACを実現する F(inheritable)
■ Per-Process Capability Bounding-Set (2.6.25 coming soon)
- 特定セッションでは、rootの特権がマスクされる。
■ Per-Process SecureBits support (now in -mm tree)
- 特定セッションでは、rootが特権をもてなくする。
この辺を組み合わせて利用すると、Linuxでもうまく『最小特権』を実現できる(ハズ)。
SELinux他との住み分けをどの様に説明するかというのが、一つの問題だが、基本的には次のように考えている。
■データ保護機能 ... SELinux, POSIX ACLなど
- プロセス(Subject)とデータ(Object)の間の操作(Action)を規定する。
- アクセス制御や情報フロー制御が目的で、S-V-Oの組み合わせに対して許可/禁止の判断を行う。
■特権制御 ... POSIX Capability
- プロセス(Subject)の特権を細分化し、個々にon/offする。
- "DAC無視"というのは、特権の一つであり、本質ではない。
- プロセス(Subject)が、操作(Action)に紐付けられた特権を持っているかどうかが本質で、S-Vの組み合わせで許可/禁止が決まる。
- アクセス制御の対象であるデータ(Object)は登場しない。
講演の終わった後でのレセプションでは、プレゼンが分かり易かったというコメントをもらう。伝わりやすいプレゼントいうのは、最近のテーマなだけに嬉しい。本当は準備不足だったんだけどね。
あと、質疑応答の中で、新しいパッチのアイデアが出された。
曰く、capabilityを縮退させる操作に CAP_SETPCAP が必要なのはおかしいとのこと。
例えば、SetUIDプログラムの/bin/pingは、RawSocketを作った後 setuid() によって一般ユーザに戻っているが、POSIX capabilityを適用する場合にはこのような手法は不可。しかし、そのために余計な特権を持たせるのも本末転倒。そもそも、特権を捨てるのに特権が必要というのはどうよ？という疑問が。
個人的にも同感なので、軽井沢から帰ってきたらパッチ書いてみる。
