Plan9端末を認証サーバに変更する

1.0.0 NVR の確保
2.0.0 カーネルの変更
3.0.0 サーバとしての認証情報を設定する事
4.0.0 認証サーバとしてのサービスを行う事
5.0.0 ユーザの認証情報を登録する事
6.0.0 ユーザの認証情報の管理
7.0.0 セキュリティ

2002/08/28

前提
この段階で読者は Plan9 端末の運用にある程度慣れている事を想定する。
特に /lib/ndb/local の設定によって
1. ネームサーバの設定
2. ホストの IP アドレスの設定
ができると仮定する。
この端末はディスクベースで運用されていたはずであるので、その事も前提にしよう。

さて現在運用している Plan9 端末を認証サーバに変更する事を考えよう。目標は

NVR (non-volatile RAM)の代わりに使用するディスク領域を確保する事
カーネルを 9pcauth に変更すること
サーバとしての認証情報を設定する事
認証サーバとしてのサービスを行う事
ユーザの認証情報を登録する事
ユーザの認証情報の管理
セキュリティ上の要点を把握しておく事

などである。

NVR の確保

スワップ領域から1セクター(512B)を切り取り、それを NVR とする。この作業は失敗すると大事である。関連する Plan9 のドキュメントをよく読んでから実行すべきである。

以下は筆者のメモである。参考になるかも知れない。(sdC0 を使用している)

	term% cd /dev/sdC0
	term% disk/prep plan9
		9fat                  0 20482      (20482 sectors, 10.00 MB)
		fs                20482 11876073   (11855591 sectors, 5.65 GB)
		swap           11876073 12031929   (155856 sectors, 76.10 MB)
	>>> d swap
	>>> p
		9fat                  0 20482      (20482 sectors, 10.00 MB)
		fs                20482 11876073   (11855591 sectors, 5.65 GB)
		empty          11876073 12016620   (140547 sectors, 68.63 MB)
	>>> a swap 11876073 12031928
	?end sector out of range
	>>> a swap 11876073 12016619
	>>> a nvram 12016619 12016620
	>>> p
		9fat                  0 20482      (20482 sectors, 10.00 MB)
		fs                20482 11876073   (11855591 sectors, 5.65 GB)
	' swap           11876073 12016619   (140546 sectors, 68.63 MB)
	' nvram          12016619 12016620   (1 sectors, 512 B )
	>>> w
	?warning: partitions could not be updated in devsd
	>>>

この最後の warning は swap を使ったまま作業を行ったために発生したらしい。前もって swap を禁止しておくべきである。sawp の起動は /bin/termrc で行われている。

カーネルの変更

カーネルを 9pcauth に変更する。しかし、いつでも 9pcdisk に戻せるようにするのがよい。カーネルの置き場所は 9fat が良いであろう。
コマンド

	9fat:

を実行すると

	/n/9fat

にカーネルが置かれているのが分かるであろう。例えば筆者の場合には

	term% 9fat:
	term% ls /n/9fat
	/n/9fat/9load
	/n/9fat/9pc
	/n/9fat/9pccpu
	/n/9fat/9pcauth
	/n/9fat/9pcdisk
	/n/9fat/plan9.ini

であるが、読者のものはこれとは異なるかも知れない。
9fat に 9pcauth が無ければ /386/9pcauth をコピーする。

FD の plan9.ini の中に次の行を入れる。

	bootfile=sdC0!9fat!9pcdisk
	bootfile=sdC0!9fat!9pcauth

この行を入れる事によって、ブート時にどちらを使用するのかを聞いてくれる。

サーバとしての認証情報を設定する事

さてカーネルをCPUサーバのものに変更して立ち上げると、

	password
	authid
	authdom

の入力を要求される。
筆者の場合には

	password: XXXXXX
	authid: bootes
	authdom: aichi-u.ac.jp

としている。
これらの情報は NVR に書き込まれる。

[注意]: authid の bootes は Plan9 の標準的なもので、この名前にしておいた

方がよい。(他の名前にしても問題は無いかと思って最初は他の名前にしたが、結局 bootes にした記憶がある。)

認証サーバとしてのサービスを行う事

CPUサーバでは (/bin/termrc ではなく) /bin/cpurc が最初に実行される。
/bin/cpurc の中には次の行がある。

	# run these instead of the above two if you are an auth server
	# also be sure to remove /rc/bin/service/il566 and tcp567
	#
	# auth/keyfs -wp -m /mnt/keys /adm/keys >/dev/null >[2=1]
	# aux/listen -q -d /rc/bin/service -t /rc/bin/service.auth il
	# aux/listen -q -d /rc/bin/service -t /rc/bin/service.auth tcp
	# auth/cron >>/sys/log/cron >[2=1] &

この最後の4つのコメントを外す。
もっとも筆者は次のように行っている。

	switch($sysname){
	case ar
			ip/ipconfig ether /net/ether0 add 202.250.160.122 $ipmask
			aux/listen  -d /rc/bin/service il
			aux/listen  -d /rc/bin/service tcp
			if(test -e /n/kfs/adm) disk/kfscmd listen
	case al
			aux/listen  -d /rc/bin/service il
			aux/listen  -d /rc/bin/service tcp
			if(test -e /n/kfs/adm) disk/kfscmd listen
	case hera
			auth/keyfs -wp -m /mnt/keys /adm/keys >/dev/null >[2=1]
			aux/listen  -d /rc/bin/service.hera -t /rc/bin/service.auth il
			aux/listen  -d /rc/bin/service.hera -t /rc/bin/service.auth tcp
			auth/cron >>/sys/log/cron >[2=1] &
			ip/dhcpd
			ip/tftpd
	}

ここに hera が認証サーバの名称である。
単に sysname で場合分けしただけではなく、認証サーバにおけるネットワークサービスを厳しく限定するために一般的に CPU サーバとは別のディレクトリ

	/rc/bin/service.hera

を指定しているのである。

サービスの具体的に内容は listen の d オプションと -t オプションで指定されたディレクトリを見れば分かる。必ず見るべきである。(これらのディレクトリは UNIX の /etc/inetd.conf に相当する)
また

	netstat -n

を実行してみる事によって、実際に実行されているネットワークサービスがわかる。

ユーザの認証情報を登録する事

認証サーバでユーザのパスワードなどを設定する。
例えばユーザ alice のパスワード設定するには

	cpu% auth/changeuser arisawa

を実行する。

	Password: XXXXXXXX
	Confirm password: XXXXXXXX
	assign Inferno/POP secret? (y/n) y
	make it the same as the plan 9 password? (y/n) y
	Expiration date (YYYYMMDD or never)[return = never]:
	Post id:
	User's full name: Kenji Arisawa
	Department #:
	User's email address: arisawa@aichi-u.ac.jp
	Sponsor's email address:
	user arisawa installed for Plan 9

パスワードは9文字以上にしましょう。Plan9 のドキュメントには8文字以上と書いてあるが、8文字のパスワードは容易に解読されます。(もっとも管理者が解読可能と言う意味です。認証サーバの運用を正しく行えは
Plan9 は暗号化されたパスワードですらネットワークに流さない。)

ユーザの認証情報の管理

ユーザの認証情報は認証サーバの

	/adm/keys
	/adm/keys.who

に、bootes のキーで暗号化されて納められている。

これらのファイルは keyfs によって管理されており、認証サーバのコンソールから

	/mnt/keys

にアクセスすると、keyfs が解読した /adm/keys の内容がファイル形式で読み取れる。

	cpu% ls /mnt/keys/arisawa
	key
	log
	secret
	status
	expire

このうち、secret は POPやIMAPなどの認証を行う場合に使用され、認証サーバのコンソールからは生のパスワードが見える。従って認証サーバの物理的な管理が必要である。(注: この問題は factotum と secstore によって解決されるはずである。)

ユーザの削除は

	cpu% rm -rf /mnt/keys/alice

のようにファイルの操作として行う。

セキュリティ

Plan9 は認証サーバにパスワードを登録していないユーザを認証しない。(UNIX のようにノーパスワードで入れると言う意味ではなく、入れない)

/lib/ndb/auth に

	#          hostid=bootes
	#               uid=!sys uid=!adm uid=*

となっているが、このコメントを外しておく。
この意味は「ホストオーナーが bootes であるシステム(ここではサーバ)ではユーザ sys, ユーザ adm を認証しない」

認証サーバでは、特に tcp のサービスは可能な限り止めた方がよい。

Plan9 の認証方式は challenge/respose 方式である。この方式の利点はネットワークにパスワード情報(暗号化されたパスワードも)流さない事である。
Plan9 では生のパスワードを暗号化し DES キーとしている。これを認証サーバが保管し認証に使用している。この内容は認証サーバのコンソールから仮想ファイルとして

	/mnt/keys/*/key

の中にを見ることができる。
challenge/response 方式の欠点は、この DES キーが盗まれると(生のパスワードを解読できなくても)認証して貰える方法が存在すると言うことである。(従って認証サーバは物理的に隔離する必要がある。)

Plan9 ではユーザの DES キーは bootes の DES キーによってさらに暗号化されているので、/adm/keys の内容が盗まれても容易には解読されないであろうがそれでも辞書攻撃などで bootes のパスワードが破られる可能性がある。