実行ファイルの「ケーパビリティ」はどのように表現されるべき？

※ 以下は、ケーパビリティに関する過去の記事からの抜粋 （ChangeLog 訳は初公開）です。

実行ファイルのための「ケーパビリティ」は、 どのように表現されるのが最も良いのでしょうか？ 「ケーパビリティ」とは、 （最初は何年も前に他の OS で使用された） 古い「特権」の概念を Linux で実装したものです。

この概念は、 --- root なら何でもできるという --- 現在の権限の仕組みを、 より適切な粒度の仕組みで置き換えるものです。 従って例えば、若い番号のソケットを バインドできなければならないネットワークデーモンは、 ただそれだけを実行するケーパビリティが与えられるようになります。 もし誰かがそのデーモンを 攻撃する方法を見つけたとしても、 そのシステム自体へ、 それ以上のアクセスを得られる可能性は非常に低くなります。

今週、次期 ext3 ファイルシステムに ケーパビリティマスクを統合する作業が 進行していることが伝えられました。 従ってファイルシステムは、 setuid スキームを「setcapability」メカニズムへ 拡張することをサポートすることになります。 これにより 信用された実行ファイルは、必要なケーパビリティとともに インストールされることができるようになります。 これは、 UNIX の世界で何年にも渡り行われてきた方法を 論理的に拡張したものだと考えることができます。

でも本当にそれで良いのでしょうか？ Albert Cahalan 氏を筆頭とする反対意見を持つ方々によって、 違ったスキームが提案されています。 「ケーパビリティヘッダ」を、 実行ファイルそのものに埋め込むという方法は、どうでしょうか？ カーネルは、プログラムを実行する前に、 ケーパビリティをそのヘッダから読み取ることになります。 ただしこれは、プログラムが setuid が root としてインストールされている場合に限り 行われます。

このスキームには、支持者が指摘する多くの長所があります。 ファイルシステムをハックするのは、 いつだってちょっとビビらされますが、 このアプローチでは、 ファイルシステムを変更する必要はありません。 また、ケーパビリティヘッダは、 自動的にバックアップされ、 dump や tar のようなプログラムによって 変更されることなく復元されます。 そして、 ケーパビリティ対応以前の古いカーネルからシステムがブートされている場合でも、 setuid バイナリは、古いモードで機能できるはずです。 さらに、この方法は NFS を介しても機能します。 等々の長所があります。

逆向きの議論は少し曖昧になりがちです。 ケーパビリティヘッダには、 いくらか「ボルト止め的なバグ修正」っぽい性質があり、 一部の人には嫌われています。 また、安全に行なえるようであっても、 実行ファイルがシステムにそれ自体のケーパビリティを伝える、 という概念には、いくらか気持ち悪さがあります。

結局、もちろんこれは 2.3 の問題です。 2.2 にはいくらか基本的なケーパビリティのサポートがあるとはいえ、 ファイルシステムと実行ファイルローダの両方（または、どちらか一方）に 変更が必要だとなると、 安定カーネルシリーズに受け入れられる可能性が高いとは言えません。 （John Wojtowicz氏の ケーパビリティの働きについての説明 （英語） もご覧下さい。）

ケーパビリティを巡る２つの派閥

※ 以下は、ケーパビリティに関する過去の記事からの抜粋 （ChangeLog 訳は初公開）です。

「ケーパビリティ」は、数多くの議論を巻き起こし続けています。 意見の不一致を概観するには、 先週の記事（英語。日本語（上記記事））をご覧下さい。 状況は大きくは変わっていません。

けれども、徐々に進展はしているようで、 Linux システムにおけるセキュリティがどのように機能するべきかについての、 より一般的な意見の違いが浮かび上がってきました。 「純ケーパビリティ・システム」派が目指す世界とは、 これ以上「特権ユーザ」を増やさずに済み、 root アカウントはもはや存在せず、UID 0 は単にユーザ ID の一つであるような ものです。 この世界では、すべての特権 (「ケーパビリティ」) は特定のプログラムに帰属します。 ユーザは、これらのプログラムへのアクセス権をどの程度持っているかによってのみ、区別されます。

root ユーザが存在しないため、root に setuid されたファイルに依存するケーパビリティ方式は機能しません。

※ setuid - 一般のユーザが root 権限を必要とする処理を行えるようにするための 仕掛け。setuid されたプログラムは、プログラムを実行したユーザの権限ではなく、 プログラムの所有者 (root 等) の権限で動作します。

※ メタデータ - ファイルそのものに含まれるもの以外のデータ。 例えば Linux におけるテキストファイルは、文字の列としてのデータそのものと別に、 ファイルの更新日付やパーミッション, 所有者等の情報を持っています。 これらは「メタデータ」の一種と考える事が出来ます。

対する別の派の方々は、ケーパビリティのことを （サーバプログラムなどが持つ特権を減らすことにより） セキュリティを向上させる手段、といったように考えています。 彼らは、 root アクセスを廃止する必要はない、 また、本当に必要である以上に、 システムを非互換にするような方式を導入する必要もないと考えています。 こちらの方々は、ケイパビリティ情報を それを適用するプログラムの実行ファイル自体に埋め込むことを主張しています。 そして、setuid または sticky protection ビットを、 システムにケイパビリティ情報を示すフラグにしようとしています。

※ sticky ビット - /tmp ディレクトリ等、複数ユーザの間で共有される ディレクトリにおいて、ファイルの作成者以外に削除を禁止するフラグ。 初期の UNIX では、プログラムをスワップファイル中に貼りつかせる (stick) ことで、プログラム起動を高速化する為に用いられましたが、 そんな小技を必要としなくなった現在では全く異なる用途に使用されています。

これは Linux の未来への道標となる、重要な討論です。 結論が出そうにないのは、残念です。 そろそろ Linus にも土俵に上がってもらって、 風がどちらに向かっているのかを示してもらう頃でしょう。

ケーパビリティの議論は白熱

※ 以下は、ケーパビリティに関する過去の記事からの抜粋 （ChangeLog 訳は初公開）です。

ケーパビリティの議論は乱戦模様を呈しています。 ここではその詳細についてさらに触れることはしません。 本当に興味のある方は、たぶん直接議論に参加されているでしょうから。 しかしながら、Ted T'so 氏が、いつも通りその明解な切り口でまとめた、 議論の概要 (英語) を見ておくことは有益です。 ケーパビリティについて、いくつかの異なる見方をまとめた上で、 ケーパビリティ情報はファイルシステムに保存されるべきであることが 主張されています。

ついに Linus の登場

※ 以下は、ケーパビリティに関する過去の記事からの抜粋 （ChangeLog 訳は初公開）です。

ついに Linus がケーパビリティの議論に参入しました。 ケーパビリティに関する議論を覚えておいででしょうか？ これは、ケーパビリティ（特権）情報を、 ファイルシステムに保存することを望む方々と、 ELF 実行形式ファイルのヘッダ情報に埋め込むことを望む方々との 間で起こっている議論です。

※ ELF (Executable and Linkable Format) - 現在 Linux で主流の実行ファイル形式。 プログラムはこの形式のファイルとしてディスクに格納されています。 フリー／商用を問わず、ほとんどの UNIX で採用されています。 ELF ファイル形式は柔軟性に富み、新しい情報をヘッダに埋め込む事が比較的容易です。

カーネルの分野では、一般に物事は Linus が望んでいる方向に進むので、 ELF ヘッダー方式がこれ以上進展することはないかもしれません。