市場からショップへ (Ⅱ)

目次

• 1.0.0 ブレークスルー
• 1.1.0 wrapper 方式の問題点
• 1.2.0 Plan 9 from Bell-Labs
• 2.0.0 Pegasus
• 3.0.0 Pegasus が見る名前空間の基本構造
• 4.0.0 サンドボックス化の難易度
• 5.0.0 プロセスの権限比較
• 5.1.0 補足
• 6.0.0 セキュリティモデルの比較
• 7.0.0 chroot 対 bind
• 8.0.0 Unix/Linux の現状
• 9.0.0 問題解決の歴史(2)
• 10.0.0 SBOX と Pegasus
• 10.1.0 SBOX の構想
• 10.2.0 Pegasus の構成
• 10.3.0 作業スペース
• 10.4.0 補足
• 11.0.0 CGI の自由が欲しい! 他の解決法
• 12.0.0 補足: Unix/Linux の Real UID と Effective UID
• 12.1.0 ruid と euid
• 12.2.0 setuid 属性を持つ実行可能プログラム
• 12.3.0 ありえる間違い

ブレークスルー

wrapper 方式の問題点

Unix/Linux の wrapper 方式には次のような問題が含まれていた。

• 途中に root による SUID が含まれるために、リスクが高い
  
• 設定が httpd と wrapper の両方に発生し、整合性が必要なために、複雑・煩雑になる
  
• CGI に問題があった場合に、CGI のオーナーが所有するファイルが全滅するリスクを負う
  
• CGI プログラムからシステムが丸見えである
  

これらの問題を全て一挙に解決できる可能性が生まれた。Bell-Labs からリリースされた Plan 9 である。

Plan 9 from Bell-Labs

Bell-Labs は Unix を生み出したことでも知られている。その同じグループが Unix の問題点を克服するために Plan 9 を生み出した。Plan 9 は Unix の良い面を継承し発展させながら、Unix とは異なる革新的な技術に支えられている。その一つが per-process name space (プロセス毎の名前空間)である。

name space とはファイルの名前のなす空間であり、これがプロセス毎に異なっていても構わないようにしたのである。
(Unix など、これまでのOSでは、名前空間はどのプロセスから見ても同じである。もっとも Unix には 、その例外として、chroot の仕組みがあるが特権を必要とする。)
他のプロセスからは新たに生成された名前空間は見えない。つまり影響を与えない。そして、新しい名前空間の構成には特権が要らない!

さらに Plan 9 には名前空間を自由に構成するための道具が備わってる。仕切の無い「市場(いちば)」から、壁で区切られている「ショップ」方式で Web サーバーを構成できる可能性が開けたのである。

Pegasus

ここで言うサンドボックとはセキュリティ用語であり、悪意を含んだプログラムの次のような動作

• システムの破壊
  
• 不正な書き込み
  
• 外部への不正なデータ転送
  

• 弱い権限でプログラムを実行する
  
• アクセス可能空間を限定する
  
• アクセス可能空間のファイルを保護する
  

「アクセス空間の限定」に関して、Pegasus では次の図のようになっている。

図で、real space とは、本来の名前空間である。httpd space とは httpd が見る名前空間であり、それは CGI プログラムが見る名前空間でもある。Plan 9 以外の OS では real space と httpd space は一致する。Pegasus では httpd space は、ユーザ毎に異なる。
例えばクライアントが alice のドキュメントにアクセスしている場合には httpd が見る名前空間は、alice がホームページを公開するために必要とするファイルに限定されている。bob についても同様である。

なお、ここで言う「ユーザ」とは Web ドキュメントを管理するシステムのユーザのことである。彼らが管理するドキュメントは、例えば筆者のサーバーであれば、

• http://ar.aichi-u.ac.jp (real host document)
  
• http://plan9.aichi-u.ac.jp (IP based virtual host document)
  
• http://cpa.aichi-u.ac.jp (name based virtual host document)
  
• http://ar.aichi-u.ac.jp/~arisawa (personal document)
  

Pegasus が見る名前空間の基本構造

Pegasus が見る名前空間の基本構造は、real host, virtual host, user page を問わず共通である。
これによってサーバーコードが簡単になり、また CGI プログラムのポータビリティを可能にしている。
名前空間の基本構造を同じにできるのは、Pegasus の場合にはサンドボックス化を前提として設計されているからである。
この事情は Apache と対照的である。Apache は継ぎはぎ的な設計によって現在に至っている。real host,
virtual host, user page の構造はどれも互いに異なっている。この複雑さはシステム設定を難しくし、一方を立てれば他方が立たなくなるというジレンマを抱え込んでいる。

サンドボックス化の難易度

環境準備

• Unix/Linux: 関連する全てのファイルのコピーが(ユーザ毎に)必要
  
• Plan9: 必要に応じてダイナミックに構成可能(コピーは不要)
  

プロセスの権限比較

user alice の CGI が実行される場合

注1: http も web も仮想ユーザ

注2: サービスは可能な限り弱い権限で行うのが原則 (破滅的な事故を防ぐ)

注3: alice として実行される CGI は alice の全てのファイルを破壊する威力を持っている

注4: Pegasus のシンプルな仕組みが設定ミスを防ぐ

補足

Unix/Linux では閉じ込めには特権が必要になり、wrapper は欠かせない。しかし実際問題として閉じ込めを困難にしているのは、閉じ込めた空間の環境準備である。

閉じ込めた空間には、CGI を実行する Perl や Python などのプログラムの他に、ライブラリなど(さらにダイナミックリンクライブラリなど)を含める必要がある。必要なものはスクリプト言語毎に異なる。Python に至っては /etc/passwd が必要である! もっとも必要としているのは、その一部である。

Stein の SBOX の時代と異なり、現在ではディレクトリのハードリンクはサポートされていない。そのために、必要なファイルはユーザ毎にコピーをして準備しなくてはならない。これは現実的な方法ではない。

セキュリティモデルの比較

注2: ファイルサーバーにおいては、(記憶デバイスにファイルが作成されるので)特権は file に及ぶ。ただし特権を与える方法が Unix/Linux と異なる。ファイルサーバーのコンソールから特別に許可するのである。CPU サーバー(サービスを行っている) にはファイルに及ぶ特権プロセスは存在しない。

Plan 9 は CPU サーバーとファイルサーバーを分離することによって、root のような特権プロセスを排除したのである。

chroot 対 bind

	mount --bind dir1 dir2

	bind dir1 dir2

Plan 9 の bind はさらに多才である。

	bind -a dir1 dir2

	bind -b dir1 dir2

	bind dir2 / && cd /

Unix/Linux の現状

言語プロセッサレベルの対策としては、Perl の taint モードが存在するが、完全にガードを固めるのは難しいであろう。ユーザは自分の好みの言語プロセッサを使いたいであろう。そして、好みは多様である。従って言語プロセッサに依存しない対策が欲しい。願わくば機械語レベルでの対応である。

Apache について言えば、サーバーレベルで

• mod_chroot
  
• mod_unixd
  
• mod_privilege
  

クライアントからのリクエストを特権モードを抱え込んだままで処理するのはあまりにも危険である。Apache は太りすぎであり、どこに深刻なバグが含まれているかわからない。Apache が採り得る方法は、クライアントのリクエストを受け取る前に特権を必要とする chroot を行い、その後で特権モードを解除するぐらいであろう。この場合、ユーザ毎の閉じ込めはできないが、我慢するしかないであろう。実際に、Apache の仕様では、chroot を行うディレクトリは1つに固定されている。(もっとも Apache2.4.9 は、これすらバグがあって働いていない)

mod_privilege は、suexec の代わりのはずであるが、これはまだ実験的な位置づけである。mod_privilege の存在は、Apache は将来 wrapper 方式から脱却しようとしていることを示唆している。

問題解決の歴史(2)

SBOX と Pegasus

SBOX は全体として Unix 系の wrapper としては良くできている。もっとも wrapper と CGI の置き場所との関係は cgiwrap の方が良い。(SBOX は wrapper と CGI を共に cgi-bin に置かせるので、ややこしくなる)

筆者は Pegasus が完成してから SBOX の存在を知ったのであるが、両者を比較してみるとディレクトリの基本構造に関する考え方が驚く程よく似ている。

SBOX の構想

	$home/www/bin
	$home/www/cgi-bin
	$home/www/etc
	$home/www/lib
	$home/www/html
	$home/www/tmp
	$home/www/…

Pegasus の構成

	$home/www/bin
	$home/www/etc
	$home/www/doc

CGI の実行に必要な他のファイル、例えば

	$home/www/lib
	$home/www/tmp
	$home/www/…

作業スペース

クライアントはサーバーの(通常は80番窓口に)処理を依頼する。込み合った場合には、前の処理が終わらないうちに、次の処理依頼が来る。その結果、ユーザ alice の処理が複数の CGI によって同時並行的に行われる事がありえる。SBOX のように作業スペースを共有していると、CGI が乗っ取られた場合にセキュリティ上の問題が発生する。

幸いな事に Plan 9 では RAM ディスクを自由に生成できる。Pegasus では作業スペースとして RAM ディスクが使われている。従って初めから準備する必要はなく、しかも、その内容は他のプロセスからは見えない。
いや、それ以上に多くのメリットを持っている。

RAM ディスクは(それを作成した)プロセスの消滅と共に消える。CGI が生成した作業ファイルを、わざわざ CGI 自ら消しに行かなくても、自動的に消えてくれるのである。不要な作業ファイルの削除は Unix/Linux では頭の痛い問題であるが、Plan 9 ではプログラムのエラーによって CGI がクラッシュした場合にも、RAM ディスクで作業をしていれば自動的に消える!

補足

CGI の自由が欲しい! 他の解決法

Apache に代表される Web サーバーのサンドボックス化に関して、この10年間、Unix/Linux では遅々として進歩が無かったのであるが、対照的に仮想マシンに関しては大きな進歩があった。

• Xen
  
• QEMU, WMware, VirtualPC,...
  

補足: Unix/Linux の Real UID と Effective UID

ruid と euid

管理者(root) が実行したプログラムでは(通常は)

	(ruid,euid) = (0,0)

この意味について解説する。

	(ruid,euid) = (0,1000)

	(ruid,euid) = (0,0)

setuid 属性を持つ実行可能プログラム

	(ruid,euid) = (1000, X)

ありえる間違い