Secure Programming for Linux and Unix HOWTO
Prev	Chapter 6. プログラムのインタフェースと内部構成をきちんとすること	Next

6.4. 特権を最小限に

以前にも書いたように、一般的な原則は、プログラムには処理に必要となる特権を最低限にしか与えないことです(特権をできるだけ持たせない)。そうすればそのプログラムが壊れても、ダメージは広がりません。最も極端な例は、単に安全が必要となるプログラムをまったく書かないことです。そうできれば、そうすべきです。たとえば、可能ならプログラムに setuid や setgid をかけないでください。ただの一般プログラムにして、管理者には動かす前にログをとるように依頼してください。

Linux や Unix において、まずプロセスの特権を決定するのは、そのプロセス id の組み合わせです。プロセスそれぞれには、ユーザやグループ両者の実、実効、保存 id があります。 (古い Unix には「保存」id がないものもあります)。 Linux には特別な拡張機能として、ファイルシステムとは独立した uid と gid が、プロセスそれぞれに用意してあります。これらの値を操作するのは、特権を最小限に抑える上で欠くことができませんし、それらを最小限に抑える方法もいくつかあります(下記で論じます)。 chroot(2)も利用でき、プログラムから見えるファイルを最小限にできます。 Linux や Unix には、他にも特権を決める値がいくつかあります。たとえば、 POSIX ケイパビリティ(Linux 2.2 以上でサポートされ、他の Unix ライクなシステムでもサポートしているものがあります)がそれに当たります。

6.4.1. 許可される特権を最小限に

もちろん最も効果的なやり方は、許可される最高の特権を素直に最小限にする方法です。特に、できるだけ root の特権を許可するのは避けてください。ほんのわずかなファイル群にアクセスする必要があるだけで、プログラムに setuid root をかけないでください。機能毎に独立したユーザやグループアカウントの作成を検討してください。

よく行う方法は、特別なグループを作成し、ファイルのグループのオーナーをそのグループに変更する方法があります。そしてプログラムをそのグループに setgid します。できるなら setuid するよりも setgid した方が賢明です。そうしておいて、グループのメンバーにはほとんど権限を認めないようにします (特にファイルのパーミッションを変更する権限を認めない)。

これは、ゲームソフトのハイスコアを記録する場合によく使われている方法です。ゲームは普通 games に setgid して、スコアファイルは games グループが所有しています。そしてプログラム自体や設定ファイルは、別のユーザ(root 等)が所有しているのが普通です。こうしておけば、ゲームを通じて侵入者が入ってきても、ハイスコアをいじることはできたとしても、ゲームの実行形式や設定ファイルには手を付けられません。後者は重大です。攻撃者がゲームの実行形式や設定ファイル(どの実行形式を動かすかを制御している)を変更できたなら、ゲームを動かしているユーザをコントロールできるかもしれないからです。

新しいグループを作るだけでは不十分な場合は、新しい仮のユーザ(実際に特別な役割を持つ)を作成し、関連するリソースを管理してください。これの典型的な例は Web サーバです。Web サーバは特別なユーザ(「nobody」)で設定してあるので、他のユーザから独立していられます。実際、Web サーバからは教えられることが多くあります。Web サーバは普通は起動時に root の特権を必要としますが(80 番ポートを利用するからです)、起動してしまうとすべての特権を外して、「nobody」というユーザで動きます。繰り返しますが、通常仮のユーザは最初に動かすプログラムを所有していないので、アカウントに潜り込んでも、プログラム自体を変更できません。結果的には、動作している Web サーバに侵入しても、それだけでシステムすべてのセキュリティは侵せません。

データベースシステムを利用しているなら(つまり、そのクエリ・インタフェースを呼び出している)、そのアプリケーションを利用しているデータベース・ユーザの権限に、制限をかけてください。たとえば、ユーザが定義したほんのいくつかのクエリを使ったアクセスだけが必要なユーザに対して、システムのストアド・プロシジャすべてにアクセスを許すようなことはしないでください。実行できるのは、ストアド・プロシジャだけです。そうしておけば、たとえ誰かが任意の文字列をクエリに無理やり入れ込んだとしても、ダメージは限られた範囲で収まります。直接標準的な SQL クエリをクライアントのデータとして提供しなければならないなら、その動作を制限するようにラッパをかけてください(たとえば、sp_sqlexec のような)。 (データベースについてのアドバイスをしてくれた、SPI Labs に感謝します)。

プログラムに root が確保している特権を持たせなければならないなら、POSIX ケイパビリティの利用を早急に検討してください。そして、プログラムが利用できる特権を最小限に押えるようにしてください。 POSIX ケイパビリティは、Linux 2.2 や他の Unix ライクなシステムの多くで利用できます。起動後すぐに cap_set_proc(3)や Linux 固有の capsetp(3)ルーチンを呼び出せば、その後はずっとそのプログラムの機能を下げたままにして、本当にプログラムが必要としている機能に押えられます。たとえば、ネットワーク時刻デーモン(ntpd)は、以前から root で実行してきました。それは、現在の時刻をあわせるためです。しかし、ntpd が CAP_SYS_TIME という 1 つのケイパビリティだけで動くパッチが開発されました。パッチを当てれば、攻撃者が ntpd を乗っ取っても、そのプログラムにつけ込むのが以前よりやや難しくなりました。

「ある程度制限をかけて」と言っているのには、理由があります。それは他に手段を用いずに POSIX ケイパビリティを使って特権を維持すると、プロセスが root ユーザの id を使い続けるからです。重要なファイル(設定ファイルやバイナリ等)は root が所有しているケースが多いので、攻撃者はケイパビリティで制限がかかっていても、依然としてプログラムをコントロールできます。つまり、システムの鍵となるファイルを修正でき、root レベルの特権をすべて取得できてしまいます。 Linux カーネルの拡張(2.4.X と 2.2.19+ のバージョンで利用できます)は、利用可能な特権に制限をかけるのに、もっと優れた方法を提供しています。プログラムを rootで起動し(POSIX ケイパビリティを使って)、本当に必要なケイパビリティにまで絞りこんで、prctl(PR_SET_KEEPCAPS,1)を呼び出します。そして、setuid() を使って root 以外のプロセスに変更します。 PR_SET_KEEPCAPS はプロセスにマークをつけ、プロセスが setuid を 0 以外の値にした時に、ケイパビリティはクリアされません(通常はクリアされます)。このプロセスの設定は、exec() するとクリアされます。しかし、PR_SET_KEEPCAPS は Linux 特有の拡張機能で、最近のバージョンの Linux カーネルで採用されている点に注意してください。

Linux 特有のツールの 1 つに SuSE が開発した「コンパートメント」があります。これを使えば、許可する特権を簡単に最小限にできます。このツールは、ファイルシステムのルートや uid、gid、もしくはケイパビリティを設定してからプログラムを動かします。他のプログラムを修正することなしに、実に手軽に実行できます。下記がバージョン 0.5 の書き方です。
Syntax: compartment [options] /full/path/to/program Options: --chroot path chroot to path --user user change UID to this user --group group change GID to this group --init program execute this program before doing anything --cap capset set capset name. You can specify several --verbose be verbose --quiet do no logging (to syslog)

つまり下記のようにすれば、より安全な anonymous ftp サーバが運用できます。
compartment --chroot /home/ftp --cap CAP_NET_BIND_SERVICE anon-ftpd

このドキュメントを書いている時点では、まだ未完成で、代表的な Linux ディストリビューションでは利用できません。しかし状況はすぐに変わるでしょう。このプログラムは、 http://www.suse.de/~marc からからダウンロードできます。

すべての Unix ライクなシステムが POSIX ケイパビリティを実装しているわけではない点と PR_SET_KEEPCAPS は現状では Linux 独自の拡張である点に注意してください。つまり、この解決方法は移植性がありません。しかし、利用できる環境下でオプションの安全策の単なる 1 つとして利用するなら、この方法を採用することによって、実際には移植性は損なわれません。また、Linux カーネルが 2.2 より新しいバージョンなら、低レベルのシステムコールは用意してあります。しかし、利用しやすい C レベルのライブラリをインストールしていないディストリビューションもありますので、アプリケーションで使うにはちょっと面倒です。 Linux の POSIX ケイパビリティについてさらに詳しい情報は、 http://linux.kernel.org/pub/linux/libs/security/linux-privs を見てください。

FreeBSD には jail()という関数があり、これで特権を制限しています。詳しい情報は、 jail documentation を見てください。特権を制限するのに、特別なツールや機能拡張がたくさんあります。 Section 3.10を見てください。

6.4.2. 特権を使っている時間を最小限に

早急に特権を永久に捨て去ってください。 Linux を含む Unix ライクなシステムの中には、「保存」id を実装して、「以前の」値を記録しているものがあります。最も単純な解決方法は、補助グループがどれも適切なら、そのグループを再設定することです(たとえば、setgroups(2)を使って)。 setuid や setgid したプログラムは、特別な理由がない限り、普通は実効 gid と uid に実 id を設定してください。特に fork(2)した後には必ず。 root から他の特権に落とす場合は、まず gid を変更しなければいけないことを忘れないでください。そうしないと動かなくなります。一度 root の特権を落としてしまうと、それ以上変更のしようがなくなります。あるシステムでは、プロセスが特権を持った補助グループに属していると、グループの変更だけでは十分ではないケースがあるのも忘れないでください。

既知のバグで気をつけなければいけないものに、POSIX ケイパビリティを利用して、権限の最小化を妨げるものがあります。このバグは、Linux カーネルの 2.2.0 から 2.2.15 に影響があり、POSIX ケイパビリティを持っている他の Unix ライクなシステムの多くにもおそらく影響があると思います。 http://www.securityfocus.com にある Bugtraq の id 1322 にさらに詳しい情報があります。要約を挙げておきます。

POSIX 「ケイパビリティ」は最近になって Linux カーネルに実装されました。これらの「ケイパビリティ」は特権を制御する方法として加わったものの 1 つで、特権を持つプロセスの実行に対して、きめ細かな制御をかけることができます。ケイパビリティは 3 つ(かなり大きな)ビットフィールドとして実装してあり、ビットフィールドのそれぞれのビットが、特権を持つプロセスが実行できる機能を表わしています。特定のビットを設定することで、特権を持ったプロセスの動作を制御できます。必要となるプログラムの特定の一部に限定して、さまざまな機能を利用するアクセスを許可できます。これはセキュリティの指標となります。問題は、ケイパビリティは fork()を実行するとコピーされる点にあります。つまり親プロセスがケイパビリティをいじると、子が継承してしまいます。これに付け入るには、3 つのビットフィールドそれぞれで、ケイパビリティすべてにゼロ(すべてのビットをオフにすることを意味します)を設定する方法があります。そうしておいてから、コードを実行する前に特権を落とそうとする setuid したプログラムを root で実行します。これは危険です。sendmail がしていることがまさにこれです。sendmail は setuid(getuid())を使って特権を落とそうとしますが、そうするのに必要なケイパビリティのビットフィールドの設定とその返り値のチェックをしなければ、その試みは失敗に終わります。そのままスーパーユーザの特権を持ったまま実行し続け、あるユーザの .forward ファイルを root として動かすことが可能になり、非常に危ない状況に陥ります。

sendmail が使っている解決方法の一つに setuid(getuid())した後には setuid(0) を試みる、というものもあります。通常これは失敗するはずです。成功したとしても、プログラムは停止してしまうでしょう。さらに詳しい情報は、http://sendmail.net/?feed=000607linuxbug を見てください。他のプログラムであれば、短期的には良いアイディアだと思いますが、長期的にみれば、信頼あるシステムへのアップグレードが好ましいのに違いありません。