Logo address

認証

目次

2001/06/28 改訂
2001/06/02 改訂
1998/08/27 改訂

注意: ここの記事は現在では古い。
現在では認証に factotum が重要な役割を果たしている。

認証方式

Plan9 は認証に challenge/response 方式を採る。Plan9 は telnet や ftp などの旧いプロトコルを使用したサービスに対する認証に際して challenge/response をあからさまにユーザに見せている。

bash$ telnet ar
Trying 202.250.160.40... Connected to ar.
Escape character is '^]'.
user: arisawa			# input
challenge: 65215		# output
response: 76e2b5fc		# input

最後の 76e2b5fc は別のウィンドウで

bash$ netkey
password: XXXXXXXX		# input
challenge: 65215		# input
response: 76e2b5fc		# output
challenge:

を実行する事によって得られる。(入力とその結果を # 記号の後にコメントしておいた)

netkey が行っている事は(大ざっぱに言えば) DES のブロック暗号関数(これを des とする)を使って

	response=des(key,challenge)
を計算していると考えて良い。

サーバへの response において DES の1ブロックである8バイトの情報を渡さないのは、
ネットワークで盗聴された場合に辞書攻撃を受ける可能性に配慮しているからである。

challenge は原理的には8バイトのデータで構わないのであるが、telnet や ftp のリモートログインで渡されるのは5桁程度の数字である。これは手で打ち込む事を想定した数字である。

Plan9 で動くコンピュータ相互の認証に関しては、challenge/response はユーザが気付かない所で行われている。

この方式のメリットは

他方ディメリットは
にある。

認証方式を公開キー方式にした時に発生する問題に関して Rob Pike は 9fans で話題にした事があった。
公開キーにした場合には cron を実現できないと...

公開キー方式を採用した場合には cron をユーザの責任で行う事になる。

パスワードとDESキー

全ての認証は 56 ビットの DES キーに基づいて行われる。
DES キーは人間にとって記憶しにくいので、パスワードから DES キーが生成される。
入力されたパスワードはその場で DES キーに変換される。この変換においてパスワードの全ての文字が利用される。

DES キーは秘密にしなくてはならない。DES キーの管理は認証サーバが行っている。
さらに CPU サーバは NVRAM に DES キーを保持している。

管理者はユーザのDESキーを知る立場にある。実際的に問題なのは、それによってユーザのパスワードを知る事ができるか否かであろう。なぜなら多くのユーザはいろいろな所に共通のパスワードを使用しているからである。(覗かれたくないファイルは暗号化するしかない。多分どの OS でも管理者による覗きの問題は暗号化以外の真の解決はないであろう。)

注釈: マニュアルにはパスワードは安全のため8文字以上必要と書いてあるが、これは
正しくない。8文字のパスワードは DES キーから容易に復元可能である。DES キーから元のパスワードを推測されたくない場合には 9 文字以上を必要とする。

サーバ認証

サーバは相互の正当性を challenge/response に基づく認証によって確認する。

他のサーバに示すために DES キーを保有し、challenge/response による認証に使用する。これをホストキーと言う。ホストキーは NVRAM に保持されている。
サーバはその正当性を他のサーバに示すために DES キーを保有し、challenge/response による認証に使用する。これをホストキーと言う。ホストキーは NVRAM に保持されている。

Plan9のサーバは、サービスを開始する前にパスワードの入力を促す。
このパスワードは全てのサーバに共通で、これをマシンパスワードと言う。
(UNIXのように自動的にサービスを開始する訳ではない)

パスワードは二重にチェックされる。
1つは、各サーバが持っているNVRAMと呼ばれるディスク上の記憶領域の中の情報との比較によって、もう一つは、サーバ相互の接続に際して。

注意: NVRAM を持たないとサーバは立ち上げの時に
password
hostid
authdomain
の入力を要求する。
これを正しく入れてやれば、サーバは取り敢えずサービスを開始するのだが、完全ではない。
telnet などでリモートログインする場合に他のマシンから提供されるファイルサーバへのアクセスがユーザ none の権限でしか許されないのである。

CPUサーバの管理者のユーザ名はデフォルトの設定では bootes である。

bootes をユーザとして登録し、ユーザとしてのパスワードを設定する必要がある。この時に登録するパスワードはマシンパスワードと同一である必要がある。

(注意: デフォルトの設定である bootes は変更しない方がよい。他の名前にするとファイルサーバを構築する時に困る。)

ユーザのDESキーなどの情報は bootes のDESキーによって暗号化され認証サーバの /adm/keys に格納される。

管理者はユーザのDESキーをも知る立場にある。

他方Plan9はエンドユーザが端末のOSを改竄してもサーバのセキュリティは破られないようにしている。このへんがUNIXのNFSとの大きな違いである。

認証サーバ

認証サーバはユーザ認証に使用される。Plan9はファイルシステムがマウントされる時に認証を要求する。認証は、CPUサーバが起動した時や端末が起動した時に要求されるパスワードから計算されたDESキーに基づいて行われる。

(ftp や telnet でアクセスした時には challenge/response方式の認証をとる。)
ユーザのDESキーはbootesのDESキーによってマスクされ /adm/keys
に納められている。

Plan9ではCPUサーバは認証サーバと兼ねる事が可能であるが、その場合以下の問題が発生する。

CPUサーバはPlan9端末にCPUパワーを提供するだけではなく、ftpやWebなどのサービスをも提供する。これらサービスはCPUサーバの管理者であるbootesが行う。そのためCPUサーバは起動の際、bootesの名義でファイルサーバをマウントする。その際、認証が発生する。所がCPUサーバが認証サーバを兼ねていると認証しようにも認証に必要なファイルはファイルサーバ側にあるので認証できない。

(もっともローカルなファイルシステム、即ち、 kfs ベースのファイルシステムで運用するなら可能である)

Plan9はこの問題を煩わしい手順で処理し、単にマシンパスワードをブート時に入力すれば立ち上がると言う訳には行かなくなる。この問題を避ける為に
筆者のシステムでは認証サーバとCPUサーバが分離している。この場合認証サーバはローカルディスクのデータを参照して認証を行う。

認証サーバを独立に持つ事によってセキュリティを大幅に向上させる事が可能である。
ユーザのパスワード情報が(暗号化された情報をも含めて)一切外から見えないようにするのである。これは行う価値がある。

認証サーバの指定は /lib/ndb/localの中の

	auth=認証サーバ名
で指定する。
認証サーバとファイルサーバは同一内容の/lib/ndb/local を保持する必要がある。

ユーザ認証に関係するファイルは以下の通りである。(これらのファイルは認証サーバの中にあればよく、ファイルサーバに存在する必要は無い。)

認証コントロールは /lib/ndb/authで行われる。

デフォルトは
hostid=bootes
    uid=!sys uid=!adm uid=*
であり、ユーザsysとadmに対する認証を拒否し、その他の全てのユーザを認証の対象とする。

認証に関係していそうなファイルは他に /adm/netkeys, /adm/netkeys.who があるが、それらはPlan9 が生まれた初期に使われていただけであり、現在では使用されていない。

認証サーバはパスワード登録をしたユーザのみを認証する。この事は、そうあるべきであるが、別の理由も存在する。 /adm/users はグループ管理を兼ねている。Plan9 においてはユーザ名とグループ名の間に本質的な違いは存在しないのである。グループは一般にパスワード登録はされないので、認証の対象にはされないのである。

認証サーバは最小限必要なサービスに止めるのがよい。デフォルトの設定は

aux/listen -q -t /bin/service.auth -d /bin/service il
aux/listen -q -t /bin/service.auth -d /bin/service tcp
であるが、telnet 等でリモートアクセスをする気がないなら
aux/listen -q -t /bin/service.auth il
aux/listen -q -t /bin/service.auth tcp
にしたほうが安心できる。

第二版の tftpd にはセキュリティ上の問題があった。そのために筆者は 9tftpd を作成したが、第三版では強化されており、もはや 9tftpd は必要はないであろう。

アダムとイブ

第3版の途中から Plan9 のセキュリティモデルの一部が変更された。それまでユーザ none に対する扱いが寛容であった(寛容過ぎた)が、この変更によって厳しく制限されるようになった。

新しく登場したのがアダム(adm)とイブである。アダムはファイルサーバの管理者であり、イブはホストオーナー(端末あるいはCPUサーバを立ち上げたユーザ)である。
端末あるいはCPUサーバはイブが全権を握る。そして

イブだけがユーザ none になる事ができるように変更されたのである。

ユーザ none

ホストオーナーは認証なしにユーザ none になることが可能である。
そこで問題になるのはファイルサーバに存在するユーザ none のファイルへのアクセス権である。

端末のユーザ none のプロセスは CPU サーバのユーザ none のプロセスと同様にファイルサーバの none のファイルへのアクセス権を持つのだろうか?

この疑問に対する Plan9 の現在のリリースにおける回答は以下のようである。

ユーザ none のプロセスは(それが端末のプロセスであれCPUサーバのプロセスであれ)ファイルサーバのユーザ none のファイルのオーナーではない。

ただし、ユーザ none のプロセスが、ファイルを作成できた場合にはユーザ none のファイルを作成する。

すなわちファイルサーバのユーザ none のファイルは誰のファイルでもないのである。
ユーザ none のプロセスは、そのプロセスが実行されているCPUサーバあるいは端末のローカルファイルシステム(kfs)の中にあるユーザ none のファイルに対してのみ正当なアクセス権を持っている。

筆者にはこの制限は強すぎるように思える。CPU サーバで行われるユーザ none によるサービスプログラムは、 none にだけアクセス権を与えられたファイルがあったほうが望ましい場合がある。その場合にローカルファイルシステムを使用しなくてはならないのはサーバの運用上きつい条件である。CPU サーバの none のプロセスはファイルサーバの none のファイルのオーナーとして認めた方が良いのではないだろうか?

ユーザ認証

サーバへのログイン
ファイルシステムのマウント
POP や IMAP
noworldグループ