Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp
Aichi University
Kurozasa 370, Miyoshi-cho
Aichi, Japan

Security

2001/06/15 1998/09/02 1998/06/02
  1. 環境
  2. 管理者特権
  3. 端末の維持管理
  4. 特権プロセス
  5. 認証
  6. 認証方式
  7. 盗聴対策
  8. 機密性
  9. システムサービス
  10. 管理者パスワードの漏洩とシステム安全性
  11. アクセス空間
  12. 結論

環境

Plan9 がセキュリティを守る上で想定しているコンピュータ環境を下図に示す。

Plan9 はサーバ室の内と外を区別する。サーバ室はサーバを物理的に保護するだけではない。それは、管理業務の境界、信頼できるマシンとできないマシンの境界、さらに信頼できるユーザとできないユーザとの境界線である。


管理者特権

管理者は特権を必要とする。それらの特権は以下の目的の為に行使される。
  1. ユーザの登録/抹消、グループの編成、ファイルの削除
  2. ユーザパスワードの設定/再設定
  3. サービスの提供
などである。

UNIX の欠点の1つはこれらの作業が許される領域を限定できない事である。セキュリティの根幹に関わるこうした作業が海の彼方からも実行でき、そしてクラッキングによって実際に現実のものとなる。

管理業務領域を物理的に限定する事がシステムの安全維持にとって重要である。

上に分類した業務は Plan9 では

  1. はファイルサーバに関わる業務
  2. は認証サーバに関わる業務
  3. は CPUサーバに関わる業務
である。

Plan9 では業務 1 と 2 はサーバ室のマシンのキーを叩く事によってしか実行できない。業務3 は UNIX と同様、管理者パスワードによって、どこからでも実行できる。

サービスの提供業務に関しても管理者 bootes(注) がサーバ室の外から行える事は極めて限定されている。通常の設定では管理者はシステムファイルの変更を伴う業務を外からは実行できない。(外から行うにはグループ編成の変更が必要になるが、これは内部からしか実行できない。)

サービスの停止、再開などは管理者が外部から実行できる管理業務に含まれる。


端末の維持管理

いかなる OS であれサーバ室の外のマシンを守り切る事はできないと考えるべきである

その場合の唯一の防御は外のマシンの持つ情報に依存してシステムを運用しない事だ。Plan9 端末はこれを可能にする。

端末は以下の様に運用される。
端末のハードディスクはメモリ不足の時の一時退避(スワップ)に使用されるだけである。カーネルは認証サーバが提供する。その他のシステムソフトウェアはファイルサーバが提供する。端末のブートローダも信用できないかも知れない。その場合にはユーザは正しいローダが入ったフロッピーディスク一枚を持ち歩けばよい。(フロッピーディスクの管理はもちろんユーザの責任である。)

この方法は安全なばかりか、他のメリットを持つ。

  1. サーバ室の外のマシンの維持管理が極めて簡単である
  2. どの端末を使用してもユーザは同一のソフトウェア環境で作業できる
  3. システムソフトの更新は数台のサーバに対してだけ行えばよい
もっともこの方法の欠点が無い訳ではない。ネットワークの性能が極めて重要になり、現実に gzip などを実行すると遅さを感じるであろう。イーサネットが 100 Base になればこの問題はかなり解決する。


特権プロセス

Plan9 には特権プロセスが存在しない

UNIX の root のプロセスは次の特徴を持っている。
1. 誰のプロセスにも許可なく変身できる。
2. 如何なるファイルにも保護属性を無視してアクセスできる。
3. 誰のファイルであれ、保護属性を変更できる。
4. 誰のファイルであれ、所有者を変更できる。
すなわち root のプロセスは全能なのである。root のプロセスの持つ特権を root 特権と言う。

特徴 1 は、UNIX に於てはカーネルは認証に関知せず、認証を行うのは root のプロセスである事から発生している。

ファイルに関する特権(特徴 2, 3, 4) は I/O デバイスをファイルと見做す UNIX の便利な特徴と結びついている事に注意しよう。UNIX のこの特徴によって、(特権)ユーザが容易にデバイスへアクセスできるようになり、UNIX は大きな支持を得たのである。 UNIX に於てはハードディスクそのものがファイルであり、このファイルの所有者 root がハードディスクを間借りしているエンドユーザのファイルの使命を制しているのある。

特権プロセスが利用できる事によって、システムは柔軟性を持つが、同時に、

特権プロセスの存在はシステムのアキレス腱でもある。

それ故に攻撃者にとっての最高の目標は特権プロセスを生成する権利を手に入れる事である。この権利さえ手に入ればシステムは一挙に崩壊するのだ。(UNIX はこの権利を攻撃者に渡し易い幾つかの特徴を持っている。)

Plan9 の CPU サーバにも CPU サーバの中で特権を振うプロセスが存在する。これは CPU サーバを立ちあげた管理者のプロセスである。このプロセスは CPU サーバのハードウェアへのアクセス特権を持っている。この特徴は UNIX の特徴そのもので、これによって Plan9 が UNIX と同様に制御し易いシステムになっているのである。

ユーザプロセスとしてデバイスにアクセスできる UNIX の使い易さを受け継ぎながら、かつ過度な特権を如何なるプロセスにも与えない為にはどのようにすれば可能であろうか?

Plan9 はシステムの分散化でこの問題に対処した。即ち、

  1. CPU サーバのカーネルは認証抜きのプロセス生成を行わない事とし、それとともに認証サーバを分離した。(CPU サーバが認証業務を行えば、CPU サーバの特権プロセスは認証を歪める道が開けてくる。)
  2. ファイルシステムの管理を分離し、それによって CPU サーバの特権プロセスである bootes の影響から切り離した。ファイルサーバは CPU サーバからくるアクセス要求の正当性を確認して処理を行う。
Plan9 が特権プロセスを排除できているのは分散化の御蔭である。Plan9 は単体システムとしても使用可能である。この場合には UNIX と同様にファイルシステムの使命を制する特権プロセスが存在する事になる。

ファイルサーバのファイルシステムはもはやファイルと見做されない事に注意せよ。仮にファイルシステムがファイルと見做された場合にはそれを所有するプロセスが特権を振るう事になる。


認証

権利の行使には認証が必要である

Plan9 ではこの当たり前の事が守られている。(但し厳密にはサーバ室の外からのアクセスに関してである。)

UNIX の場合にはこれが守られない幾つかの抜け道が存在した。

  1. root 特権の存在
  2. ファイルにおけるSUID 属性の存在
  3. ネットワークからのプロセス生成
などである。これらの1つ1つがセキュリティへの脅威となって来た。

root 特権の問題は既に述べた通りである。

UNIX の SUID はユーザにとって必要ないばかりか、セキュリティ上の脅威である。 Plan9 では当然ながら UNIX から SUID を受け継がなかった。Plan9 では認証なしに如何なるプロセスも勝手に他人のプロセスに変身できない。

rlogin や rsh 等によるネットワークからのアクセスに関しては UNIX は相手の名乗る IP とユーザ名をそのまま信用し認可する。即ち UNIX はユーザがその都度パスワードを入力しなくても遠方のマシンで自分のプログラムを実行できる便利な機構を備えており、こうした事がセキュリティ上の問題を発生させる。

リモート実行に関しては、実行の都度にユーザがパスワードを入力しなくても、認証を可能にするメカニズムを持つ必要がある。このメカニズムはUNIXの現状の認証機構からはでてこない。


認証方式

UNIX は相手が名乗るホスト名(IPアドレス)とユーザ名を信用して認可する機構を持っている(UNIX 式認証)。例えば rlogin や rsh それから NFS などである。しかしホスト名(IPアドレス)とユーザ名は自己申告であり容易に偽造可能である。
    双方向の通信が必要な場合は IPアドレスの偽造による攻撃は簡単には成功しない。今 mars が venus を名乗り UNIX ホスト vega に接続を試みたとせよ。 vega が (venus だと信じて) mars へ返すメッセージは通常は mars に届かない。届かない理由はルータの介在である。ルータはセグメントに接続されるマシンの IP アドレスの集合を定めている。
    従って mars は vega からの返事を通常は受け取れない。しかし、mars と venus が同じセグメントに存在し、venus が休眠していれば話は別である。

    TCP の接続は(ユーザが意識しなくても)双方向の通信が内部で発生する。従って venus の外部セグメントからの攻撃は困難である。(しかしそれでも現実的な可能性があると言う。文献)
    UDP の接続はこの点で極めて危険である。NFS や SUN RPC では UDP が使用されている。(最近は SUN RPC を足がかりにした攻撃が流行っています。筆者のホストも頻繁に ポート 111 への接続が試みられます。)

Plan9 は全ての認証を暗号に基づいて行う。

サーバ室の外部のマシンを信用しないので暗号に基づく認証だけが本人を確認する手段である。

Plan9 の認証は UNIX のようにパスワードを相手に送る方式ではない。もっと複雑なものである。しかしながら最終的にはパスワードの問題に帰着される。

ユーザ X が alice として認証され、alice としての権利の行使を認可されると言うことは X が alice のパスワードを知っている事と等価である。Alice がパスワードを盗まれない限り今や誰も alice にはなれないのだ。


盗聴対策

UNIX は login 認証などの際にネットワークにパスワードが流れる。このパスワードは盗聴可能である。

Plan9 は裸のパスワードのみならず暗号化されたパスワードもネットワークに流さない。

但し端末からのパスワードの変更の時には、一時キーによって暗号化されたパスワードがネットワークに流れるがこれは例外である。

Plan9 が認証を行う方法は Challenge/Response 方式である。ホストが(乱数で生成された)数字を端末ユーザに見せる。ユーザはこの数字を基に解答をホストに渡す。パスワードを知っているユーザのみ提起された数字から解を計算する事ができる。

Plan9 端末からのアクセスに関してはユーザは Challenge/Response が行われている事を意識しない。login 時に使用されたパスワードがそのあと様々な認証の際に自動的に使用されているからだ。

UNIXワークステーションから Plan9 ホストへ telnet でアクセスした場合にはユーザは直接 Cahllenge/Response を行う事になる。

UNIXワークステーション venus の前に座っている Alice は Plan9 のホスト plan9 に telnet 接続を試みる。

	venus$ telnet plan9
	Trying 202.250.160.122... Connected to plan9.
	Escape character is '^]'.
	user: alice
	challenge: 11765
	response: 
Alice は 自分のパスワードと提起された数字 11765 から回答を導き出すために、プログラム netkey を venus の他のウィンドウで実行する。
	venus$ netkey
	password: xxxxxxx
	challenge: 11765
	response: 1216a6e1
こうして Alice は netkey に助けて貰って得た解答 1216a6e1 をホストに送る。

Alice が打ち込んだパスワード情報は venus の内部に留まりネットワークに流れない事に注意する。


機密性

Plan9 は認証サーバを独自に持ち、認証サーバのローカルディスクにのみ依存して運用可能である。

認証サーバを独自に持つメリットは非常に大きい。認証サーバはサービスプログラムやユーザから隔離されている。認証サーバは認証業務のみに専念し、それ以外の外部からのアクセスを許さない事によって高度な安全性を維持できる。

認証に必要な情報を認証サーバのローカルディスクに格納すれば、ユーザ認証に関する秘密情報を保持するのは認証サーバのみとなる。外部からのアクセスを禁止しておけば高度な機密性を維持できる。即ち、

認証に関する基礎情報は閉ざされている。

暗号化された個人データである /adm/keys はファィルサーバに持つ必要は無く、認証サーバのローカルなファイルシステムに持つのが良い。そうすればユーザのパスワード情報を完全に他のシステムと切り離すことができる。そして認証サーバのサービスを認証業務に限定するのである。 (筆者はブートサーバーと兼ねている。端末やCPUサーバに信頼できるカーネルを提供することは認証と同じ程度にセキュリティ上重要である。)

サーバ室のマシンは他人が勝手に立ち上げない様にマシンキーを持っている。 サーバ室の外のどのマシンにも秘密情報は与える必要はない。


システムサービス

特権プログラムのバグは屡々アクセス権の設定を無意味にする。UNIX の場合には重要なファイルは root の所有とされ、管理者以外のユーザは root の権限を持つ事を禁じられている。それにも関わらず屡々 root のファイルが攻撃され変造される。それらの殆どは管理上の手落ちやサービスプログラムのバグから発生している。すなわち UNIX は、正しく管理され、正しいプログラムだけが動くシステムでは問題が発生しなくとも、現実は厳しいと言う事だ。

UNIX では質の悪い事に多くのサービスプログラムが root 特権を抱えたまま動いている。このようなプログラムのバグが攻撃者に root 特権を与えてしまうのである。また root 特権を与えないにせよ、UNIX はサービスプログラムのアクセス範囲を限定するのが上手ではない。そして UNIX は1つのマシンで完結しているために重要な情報の全てがアクセス範囲に存在するのである。

Plan9 に於ても管理者 ID である bootes は同時に CPU サーバのオーナーであり bootes の権限をもってすれば CPU サーバの記憶装置にアクセスできる。(注: Plan9 の CPU サーバは記録装置を持たずに運用するのが普通である)

しかしながら、

Plan9 ではCPUサーバの全てのサービスプログラムがユーザ none のプロセスとして実行されている。

none は UNIX の nobody に相当する。従って攻撃者はサービスプログラムのバグを通じて bootes の権利を行使する事はできない。


管理者パスワードの漏洩とシステム安全性

UNIX への攻撃のターゲットが root であるように Plan9 への攻撃のターゲットは管理者 ID であるbootesであろう。

Plan9 において仮に何かの状況で攻撃者が bootes の権限を手に入れたとしよう。例えば、管理者がパスワードのメモを落とすとか、bootes として実行されているプロセスのバグを巧みに攻撃されるような状況である。この場合システムはどの程度保護されているか?

UNIX の場合にはシステムは壊滅する。しかしながら Plan9 においてはそうではない。

Plan9 においても CPU サーバは壊滅的な打撃を受けることは間違いない。しかしながら CPU サーバの中には復旧に困るようなファイル資源は何もない。

CPU サーバは内部のハードディスクを単にスワップの為の作業場として使っているだけである。 (もっともCPUサーバの内部のハードディスクをファイルシステムとして使用することも可能であるが、それは特殊な使用法である。)

Plan9 の運用において以下の事を守れば管理者パスワードの漏洩は認証サーバやファイルサーバへの攻撃へとは波及しないのである。

  1. 認証サーバは、認証に関わらないネットワークサービスを行わない
  2. 管理者 ID である bootes に遠隔からのシステムファイルの更新権を与えない

Plan9 標準設定では認証サーバは必要以上のネットワークサービスを行っている。しかし、ネットワークサービスは厳選した方がよい、

Plan9 のシステムファイルのオーナーは adm と sys であり、これらは通常のユーザではない。(認証されない)

/adm/usersは標準では以下のようになっている。
(/adm/usersはUNIX における /etc/passwd と/etc/groupを兼ねたファイルである)

	-1:adm:adm:
	0:none:adm:
	1:tor:tor:
	2:glenda:glenda:
	9999:noworld::
	10000:sys::
	10001:upas:upas:alice
	10002:bootes:bootes:
bootes が sys のファイルを変更できるためには bootes は sys のグループメンバになる必要がある。即ち、
	10000:sys::bootes
に変更されなくてはならない。この変更は
newuser sys +bootes
をファイルサーバのコンソールから打ち込む事によってのみ可能である。

もちろん、こうした厳格な運用は、全てのシステムに要求されるわけではないだろう。 サーバの業務の重要性に応じて考えれば良い。例えば、 システム管理専用の ID を作成し(例えば bob とせよ )、bob を sys のグループメンバに恒常的に設定しておく方法も考えられる。


アクセス空間

インターネットの急速な発展は多数のサービスプログラムを作りあげた。それらは新しいサービスを競い、そして同時に多数のセキュリティホールを作りあげた。この傾向はこれからも続くのである。

我々はサービスプログラムにはバグがあるものと覚悟しなければならない。バグによる被害を如何にすれば最小限に押さえられるかを問題にする必要がある。Plan9 はこの問題に対して、システムの分散化とユーザ none で全てのサービスが実行できる仕組みの他にもう一つ特筆すべき仕組みを提供している。

サービスプログラムのアクセス空間を自由にコントロールする仕組みである。

この仕組みはたった一つのコマンド bind によって達成される。

例えば ftpd や httpd を考えて見よう。UNIX においてはこれらのサービスプログラムは2つの役割を果たしている。1つの役割はアクセスするユーザにアクセスの便宜を図っていることである。もう1つの役割はアクセスするユーザのアクセス空間を制限することである。つまり対立する2つの役割が同時に1つのサービスプログラムで行われているのである。もしも ftpd や httpd がアクセスの便宜だけを図っているのなら、攻撃者はこれらを攻撃する意味が無い。

Plan9 においてはサービスプログラムのアクセス空間の制限はサービスプログラムによってではなく bind によって行われる。ftpd や httpd は bind によって閉ざされた空間の中でサービスを実行しているのである。 (この様子は http://ar/env.html にアクセスする事によって知ることができる。env.html は実は CGI スクリプトである。)

サービスプログラムはいかなるバグも発生し得ると覚悟すべきである。従ってアクセス空間は厳重にコントロールすべきである。UNIX は金庫と金庫破りの七つ道具が同居している世界である。大切な事は、攻撃の目標を与えない事、攻撃に必要な道具を与えない事、攻撃の為の作業場を与えない事である。Plan9で動いている筆者の httpd は個人によるフリーソフトである。セキュリティ上最も重要なサーバに個人のフリーソフトを使う気にさせているのは、このサービスプログラムが完全に閉ざされた空間の中で動いているからである。


結論

Plan9 は UNIX と異なり、システムに開いた1つの穴が壊滅に結びつく事はない。

船に例えてみると UNIX は安全性が考慮されていない船である。 安全な船は船底に開いた穴の影響が他に波及しない構造を持っているのである。

Plan9 のこの性質は、ある部分はシステムの分散化による効果であり、他は Plan9 独自の工夫である。