要約

  • RFC 2307は、Unixのアカウントやグループ、ネットワークリソースをLDAPで表現する案を示した。posixAccountクラスには、OSの検索関数が読むユーザー番号uidNumberが含まれた。
  • 同RFCのセキュリティ節は、書き込み権限の誤設定が招く結果を明示した。利用者がuidNumberを変更できれば、そのアカウントをスーパーユーザーと同等にできる。

名前の検索は整数から始まる

Unixのプロセスは、ディレクトリーに人物の説明を求めるわけではない。数値をCライブラリに渡し、対応するアカウント情報を受け取る。RFC 2307はgetpwuid()を例に挙げ、ユーザーIDからログイン名を引く方法を示した。LDAP案では、プログラムから渡された数値とuidNumberが一致するposixAccountを検索する。

ファイル上では一つの欄に見える。ソフトウェアはそれを本人識別として扱う。

LDAP以前から、UnixネットワークはNetwork Information Service（NIS）でアカウントやホスト情報を共有できた。Sunの管理ガイドによると、NISマップはキーと値の二列で構成される。各ドメインにマスターサーバーがあり、スレーブサーバーはマップの複製を保持し、クライアントはどちらにも問い合わせられる。passwd.bynameはログイン名で、passwd.byuidはユーザーIDをキーにアカウントを探す。管理者はマスター上でローカルファイルからマップを生成し、スレーブへ配布した。

こうしてローカルファイルの編集がネットワークの答えになった。入力ファイルを変えてマップを再作成すれば、ドメイン内のクライアントに新しい記録が届く。検索コードは番号の妥当性を投票で決めない。届いた値をそのまま使う。

SunOSの1999年のマニュアルには、社名ならぬサービス名の小話もある。NISは以前Sun Yellow Pagesと呼ばれていたが、名称変更後も機能は同じだった。呼び名が変わっても、アカウントマップの重みは変わらない。

LDAPは保管先を変えた。権限は別の問題だ

1997年のLDAPv3仕様は、X.500のディレクトリーにDAPほどの資源を使わずアクセスする方法を定義した。その3か月後に出たRFC 2307は、An Approach for Using LDAP as a Network Information Serviceと題し、UnixとTCP/IPの情報をLDAPのクラスと属性に収める案を示した。

対象はホスト名だけではない。ユーザーやグループ、サービス名とプロトコル番号、RPC識別子、起動パラメーター、ネットワークアドレス、NISネットグループも扱う。posixAccountにはログイン名、表示名、uidNumber、gidNumber、ホームディレクトリー、ログインシェルを保存できる。RFCは/etc/passwdのような一行をディレクトリー属性にした例も載せた。

接続には実務上の理由があった。UnixアプリケーションはすでにCライブラリにアカウント情報を尋ねていた。参照先をローカルファイルからネットワークディレクトリーに切り替えられる。RFC 2307の実装欄には、LDAPをローカルファイルの代わりに使うNISサーバー、Cライブラリの参照実装、/etc/passwdや/etc/hostsをLDAPに読み込むスクリプトが記されている。

RFC 2307は全Unixサイトに移行を命じた文書ではない。Experimentalとして公開された組織向けネームサービスの案だ。文書はすでに一定の実装があったと述べるが、導入数や普及率は示していない。

番号が権限の境界になった

RFC 2307のセキュリティ節は、ディレクトリー属性が持つOS上の力を率直に記す。OSのエンティティを表す項目は管理者だけが変更すべきだとし、その理由を続ける。利用者が自身のuidNumberを変えられるなら、アカウントをスーパーユーザーと同等にして安全性を損なえる。

RFC 2307は条件付きのリスクと制御点を明記した。Unixソフトウェアは番号とアカウントを結び付け、ディレクトリーはその対応を多数のクライアントに配れる。書き込み権限を持つ人が、クライアントに見える身元を変えられる。Unixソフトウェアが番号とアカウントを結び付け、ディレクトリーはその対応を多数のクライアントに配れる。書き込み権限を持つ人が、クライアントに見える身元を変えられる。スキーマは形式を決める。誰がその意味を変更できるかはアクセス制御が決める。

同じ節は、検索と特権の別の衝突も指摘する。crypt()のような広く知られた方式で暗号化したパスワードを非特権ユーザーに見せれば、辞書攻撃や総当たり攻撃にさらされる。RFCは既存Unixとの互換性のためにこの形を提案し、セキュリティが重要な環境では強い認証サービスを勧めた。共有ディレクトリーは検索を簡単にする一方、機密性のあるアカウント情報をより多くのクライアントに届かせる可能性がある。

この資料が示すのは設計案と、文書自身が記したリスクであり、LDAP方式の普及規模ではない。RFC 2307の実装欄は一つの実装を記録するが、この資料にはUnix全体への採用状況を測る統計がない。

重要な変化はデータベースにスキーマが増えたことではない。OSが、ローカルな問いへの答えをネットワークから受け取るようになったことだ。uidNumberは表の一列でも、それを読むプロセスが意味を与える。/etc/passwdからNISやLDAPへ移れば、制御点も動く。どの情報源が正本か、どの複製に最新マップが届いたか、誰が識別番号を変更できるかを管理しなければならない。

出典