XSECURITY(3)

名前
Xsecurity - X ディスプレイアクセス制御

書式

X は多くのアクセス制御システムの実装用の機構を提供する。 サンプル実装は 5 つの機構を含んでいる。
       Host Access	単純なホストベースのアクセス制御。
       MIT-MAGIC-COOKIE-1	共有する平文の"クッキー"。
       XDM-AUTHORIZATION-1	安全な DES ベースの個人キー。
       SUN-DES-1	Sun の Secure RPC システムベース。
       MIT-KERBEROS-5	Kerberos バージョン 5 ユーザ対ユーザ認証。

アクセスシステムの説明

ホストアクセス
    ホストアクセス制御リスト内のホスト上の任意のクライアントは X サーバへ のアクセスが許可される。このシステムは全員が全員を信頼している環境、ま たは一人だけが与えられたマシンにログインしていて、そのマシンの使用して いるホストのリストが小さく使いやすい時には十分うまく動作する。 このシステムは複数の人が一つのホストにログインしていて、相互に信頼していない 場合にはうまく稼働しない。 許可されているホストのリストは X サーバに格納されており、これは xhost コマンドで変更することができる。 以下にあげるもっと安全な機構を使う場合は、ホストのリストは通常は空に設 定しておき、認証されたプログラムだけがディスプレイに接続できるようにす る。

MIT-MAGIC-COOKIE-1
    MIT-MAGIC-COOKIE-1 を使用するときは、クライアントは接続設定情報と一緒に 128 ビットの"クッキー"を送信する。 クライアントから送られたクッキーが X サーバの持っているクッキーと一致 する場合、接続はアクセスが許可される。 クッキーには予想困難なものが選ばれる。 この形式のアクセス制御を用いるときには、xdm が自動的にそのような クッキーを生成する。 ユーザが持つクッキーのコピーは通常、ホームディレクトリ内の .Xauthority ファイルに格納されるが、XAUTHORITY 環境変数を 使って別の場所を指定することもできる。 xdm は新しいログインセッション毎に自動的にクッキーをサーバに渡し、 ログイン時にユーザファイルにそのクッキーを格納する。

    クッキーは暗号化されずにネットワーク上で転送されるので、ネットワーク盗 聴者がデータを得ることと、そのデータを使って X サーバへのアクセス権を 得ることを防ぐ手立てはない。このシステムは多くのユーザが同じマシンでア プリケーションを実行していて、他のユーザから干渉を避けたい場合に便利で ある。ただし、この制御はせいぜい物理ネットワークに対するアクセス制御と 同じ程度である。 ネットワークレベルの盗聴が難しい環境であれば、このシステムは十分うまく 動作する。

XDM-AUTHORIZATION-1
    アメリカ国内のサイトは XDM-AUTHORIZATION-1 と呼ばれる、DES を基にした アクセス制御機構を使用できる。 この機構は、キーが .Xauthority ファイルに格納され、X サーバと共 有される点において MIT-MAGIC-COOKIE-1 に似ている。 しかし、このキーは 2 つの部分、すなわち 56 ビット DES 暗号キーと認証に 使用する 64 ビットのランダムなデータから構成される。

    X サーバに接続するとき、アプリケーションは(00:00 1/1/1970 GMTからの)秒 に換算した現在時刻と識別子を組み合わせて 192 ビットのデータを生成する。 TCP/IP 接続の場合は、識別子はアドレスとポート番号を足したものである。 ローカル接続の場合は、これはプロセス ID と(同一のプロセスから同一のサー バへの複数の接続の場合)32 ビットのユニークな ID となる。そして、192 ビッ ト長のパケットは DES キーを用いて暗号化される。これにより、同じ DES キー で復号し、認証側と追加データ確認することで、リクエスト側が認証されるか どうか確認することができる。 このシステムは、ホストベースのアクセス制御が不適当でネットワークセキュ リティが確保できない多くの環境で役に立つ。

SUN-DES-1
    最新バージョンの SunOS(とその他のシステム)は、安全な公開鍵リモートプロ シージャ呼び出しシステムを持っている。このシステムはネットワークプリン シパルの概念、つまりユーザ名と NIS ドメインのペアに基づくものである。 このシステムを使用すると、X サーバはリクエストを行ったプロセスの実際の ユーザ名を安全に知ることができる。この方法ではデータを X サーバの公開 鍵で暗号化するので、そのために X サーバを開始したユーザの身分証明が必 要になる。この身分証明は .Xauthority ファイルに格納される。 このネットワークプリンシパルを含むように「ホストアドレス」の考え方を拡 張することにより、この形式のアクセス制御は非常に使いやすくなる。 【訳注：RFC 1507 DASS Distributed Authentication Security Service より
           principal
           Abstract entity which can be authenticated by name.
           In DASS there are user principals and server principals.
           プリンシパル
           名称で認証できる絶対的な実体。
           DASS (分散型認証セキュリティサービス) ではユーザプリンシパルと
           サーバプリンシパルがある。 】

    新しいユーザによるアクセスを許可するには、xhost を使用する。 例えば、
        xhost keith@ ruth@mit.edu
    のようにすると、 ローカルマシンの NIS ドメインからの "keith" と、"mit.edu" NIS ドメイン内の "ruth" が追加される。keith または ruth のディスプレイへの 接続が成功するためには、サーバを開始したプリンシパルを彼らの .Xauthority に追加しなければならない。例えば、
        xauth add expo.lcs.mit.edu:0 SUN-DES-1 unix.expo.lcs.mit.edu@our.domain.edu
    とする。 このシステムは Secure RPC をサポートしているマシンだけで、かつ適切な公 開鍵/個人鍵の組をシステム上に設定した場合のみ動作する。詳細は Secure RPC の文書を参照すること。 リモートホストからディスプレイをアクセスする場合は、最初にリモートホス ト上で keylogin を行わなければならない。

MIT-KERBEROS-5
    Kerberos は Athena プロジェクトのために MIT によって開発されたネットワーク ベースの認証機構である。これを使うと、第三者である Kerberos を信頼して いる限り、互いに信頼関係にないプリンシパルを互いに認証させることが可能 になる。それぞれのプリンシパルは自分と Kerberos しか知らない秘密鍵を持 つ。プリンシパルは FTP サーバや X サーバや人間のユーザを含み、それらの キーはパスワードである。ユーザは Kerberos サーバからのサービス用の Kerberos チケットを得ることによってアクセス権を手に入れる。従って X サー バは秘密鍵を格納する場所を持たないので、ログインするユーザと秘密鍵を共 有する。このように、X の認証は Kerberos バージョン 5 のユーザ対ユーザ の機構を使用する。

    xdm 経由でログインするとき、xdm はパスワードを最初の Kerberos チケットから取得して使用する。xdm はそのチケットを資格証明キャッ シュファイルに格納し、KRB5CCNAME 環境変数がこのファイルを指すよ うに設定する。チケットの有効期限が来る前にチケットが盗まれる可能性を減 らすため、資格証明キャッシュはセッションが終了すると破棄される。

    SUN-DES-1 プロトコルと同じく、Kerberos はユーザベースの認証プロトコル なので、ディスプレイの所有者は特定のユーザまたは Kerberos プリンシパル を有効にしたり無効にしたりできる。 認証を有効にしたり無効にしたりするためには xhost クライアントを 用いる。 例えば、
        xhost krb5:judy krb5:gildea@x.org
    のようにすると ローカルマシンの Kerberos の領域から "judy" が追加され、"x.org" 領域か ら "gildea" を追加される。

認証ファイル

ホストアクセス制御を除いて、これらの各システムは .Xauthority ファ イルに格納されたデータを用いて接続設定時に X サーバに渡す正しい認証情 報を生成する。MIT-MAGIC-COOKIE-1 と XDM-AUTHORIZATION-1 は秘密データを そのファイルに格納するため、このファイルを読めれば誰でも X サーバへの アクセス権を得ることができる。SUN-DES-1 はサーバを開始したプリンシパル の身分証明だけを格納しているので(xdm がサーバを開始した時は unix.hostname@domain)、サーバに接続する認証をされていない 人には使用できない。

.Xauthority ファイル内のそれぞれのエントリーは正当な接続ファミリ (TCP/IP, DECnet, ローカル接続)と X のディスプレイ名(ホスト名とディスプ レイ番号)である。これを使うと、異なるディスプレイに対するエントリーで 同じデータファイルを共有することができる。特別な接続ファミリ(値 65535 を持つ FamilyWild)はエントリーをすべてのディスプレイをマッチさせ るので、そのエントリーを全ての接続に対して使うことになってしまう。 それぞれのエントリーには、認証名および接続時に認証のタイプに基づいて正 しい情報を生成するために必要な全ての秘密認証データが含まれる。

xauth プログラムは .Xauthority ファイルフォーマットを操作 する。 xauth プログラムは接続ファミリとアドレスフォーマットの意味を理 解して、理解しやすい書式でこれらを表示する。xauth はまた、 SUN-DES-1 と MIT-KERBEROS-5 が認証データに対して用いる文字列値を理解 し、これらを適切に表示する。

X サーバ(ワークステーションで実行しているとき)は、認証情報をコマンド行 の-auth オプション(Xserver オンラインマニュアルを参照)を 使って渡されたファイルから読み込む。そのファイル内の認証エントリーはサー バへのアクセス制御に用いられる。上記のそれぞれの認証機構では、認証機構 を初期化するサーバが必要とするデータは、クライアントが適切な認証情報を 生成するために必要とするデータとまったく同じなので、両方のプロセスで同 じファイルを使うことができる。これは xinit を使うときに特に便利 である。

MIT-MAGIC-COOKIE-1
    このシステムはユーザと X サーバの両方で共有する 128 ビットのデータを使 用する。任意のビットの集合を使うことができる。xdm は暗号学的に安全な 疑似乱数発生器を使用してこれらのキーを生成するので、次のセッションへのキー は現在のセッションのキーからは計算できない。

XDM-AUTHORIZATION-1
    このシステムは 2 つの情報をする。1つ目は 64 ビットのランダムなデータで ある。2つ目は8バイトに格納される 56 ビットの DES 暗号キー(これもランダムなデー タ)であり、最後のバイトは無視される。xdm はこれらのキーを MIT-MAGIC-COOKIE-1 で使用するものと同じ乱数発生器を使用して生成する。

SUN-DES-1
    このシステムは、関連する X サーバを識別するプリンシパルの文字列表現を 必要とする。 クライアントの認証情報を X サーバに送信するときに、この情報を使って認 証情報を暗号化する。 xdm が X サーバを起動するときには、そのマシンで実行する root プ リンシパル(unix.hostname@domain, 例えば unix.expire.lcs.mit.edu@our.domain.edu")を使用する。正しいプリンシパル 名を .Xauthority ファイルに格納すると、Xlib は secure RPC ライブ ラリを使用して適切な認証情報を生成する。

MIT-KERBEROS-5
    Kerberos は KRB5CCNAME 環境変数が示すキャッシュからチケットを読 むので、.Xauthority ファイルのデータは全く使用しない。その場合で も、クライアントに MIT-KERBEROS-5 が使用可能であることを知らせるため、 データを持たないエントリーが存在しなくてはならない。

    クライアント用の .Xauthority ファイルと異なり、xdm がローカルの X サーバに渡す認証ファイル(xdm(1) のオンラインマニュアルの ``-auth filename'' を参照)は、資格証明キャッシュの名前を 持たない。なぜなら、X サーバには KRB5CCNAME 環境変数がセットされ ていないからである。 MIT-KERBEROS-5 のエントリーのデータは資格証明キャッシュ名であり、 ``UU:FILE:filename'' という形式である。ここで filename は xdm が作成する 資格証明キャッシュのファイル名である。繰り返しになるが、 この形式はクライアントでは使用されない点に注意すること。

ファイル
.Xauthority

関連項目
X(1), xdm(1), xauth(1), xhost(1), xinit(1), Xserver(1)