Solaris 環境は、ユーザーベースとホストベースの 2 種類のアクセス制御機構をサポートするとともに、MIT-MAGIC-COOKIE-1 および SUN-DES-1 という 2 種類の認証プロトコルをサポートしています。この章では、これらのアクセス制御機構と認証プロトコルについて解説するほか、サーバーのアクセス制御を変更する方法およびクライアントの実行方法について説明します。その実行方法には、リモートで実行する方法と別のユーザーとしてローカルで実行する方法の 2 種類があります。
この章についての注意
この章の内容が問題となるのは、以下に示すいずれかのコンフィギュレーションでアプリケーションを実行する場合です。
OpenWindows 2.0 または X11R4 より前のバージョンの Xlib とリンクされたアプリケーションを実行する。詳細は、「ホストベース」を参照してください。
OpenWindows 2.0 ライブラリに静的にリンクされたアプリケーションを実行し、かつ SUN-DES-1 認証プロトコルを適用しようとする。詳細は、「SUN-DES-1」を参照してください。
リモートサーバー上でアプリケーションを実行する。詳細は、「クライアントをリモートで実行する場合とローカルで実行する場合」を参照してください。
上記のコンフィギュレーションのいずれも使用しない場合は、デフォルトのセキュリティの設定を変更する必要はありません。
どのクライアント (すなわちアプリケーション) が OpenWindows サーバーにアクセスできるかを制御するのがアクセス制御機構です。アクセスが許可されたクライアントだけがサーバーに接続でき、許可されていない X クライアントはすべて以下のエラーメッセージが表示され終了します。
Xlib: connection to hostname refused by server Xlib: Client is not authorized to connect to server
サーバーコンソールに以下のメッセージが表示されます。
AUDIT: <月日 時刻 年>: X: client 6 rejected from IP 129.144.152.193 port 3485 Auth name: MIT-MAGIC-COOKIE-1
アクセス制御機構には、ユーザーベースとホストベースの 2 種類があります。openwin とともに -noauth オプションを指定しなければ、その両方のアクセス制御機構がアクティブ状態となります。詳細は後述の 「サーバーに対するアクセスの操作」を参照してください。
ユーザーベース、すなわち認証ベースの制御機構では、あるユーザーに対し、任意のホスト上の特定ユーザーに対するアクセスが明示的に許可されます。すなわち、そのユーザーのクライアントがサーバーに認証データを渡し、そのデータがサーバーの認証データと一致すれば、アクセスが許可されます。
汎用機構としてのホストベース制御機構では、ユーザーに対して特定ホストへのアクセスが許可され、そのホスト上の全ユーザーがサーバーに接続できます。これはゆるやかなアクセス制御方式であり、サーバーに対するアクセス権がホストに与えられていれば、そのホスト上の全ユーザーがサーバーに接続できます。
ホストベース制御機構は、主に旧バージョンとの互換性を目的として使用されます。OpenWindows 2.0 または X11R4 より前のバージョンの Xlib とリンクされたアプリケーションは、新しいユーザーベースのアクセス制御機構に対応できません。それらのアプリケーションがサーバーに接続できるようにするためには、ホストベース機構に切り換えるか、あるいは新バージョンの Xlib とリンクし直さなければなりません。
旧バージョンの Xlib とリンクしたクライアントは、できれば新しいバージョンとリンクし直してください。これにより、新しいユーザーベースのアクセス制御機構の下でサーバーに接続できるようになります。
OpenWindows 環境では、MIT-MAGIC-COOKIE-1 および SUN-DES-1 の 2 種類の認証プロトコルをサポートしています。その 2 種類のプロトコルの違いは、使用する認証データの違いであり、アクセス制御機構に関しては同様です。
ユーザーベース機構を使用する MIT-MAGIC-COOKIE-1 プロトコルが OpenWindows 環境のデフォルト設定です。
MIT-MAGIC-COOKIE-1 は、MIT (マサチューセッツ工科大学) で開発された認証プロトコルです。マジッククッキーは、ランダムな値に生成されるバイナリ形式のパスワードです。サーバーのスタートアップ時に、そのサーバーおよびユーザー (システムを起動したユーザー) に関してマジッククッキーが作成されます。接続が要求されるたびに、そのユーザーのクライアントは、接続パケットの一部として、サーバーにマジッククッキーを送ります。そのマジッククッキーはサーバーのマジッククッキーと比較され、2 つが一致すれば接続が許可されます。2 つのマジッククッキーが一致しなければ、接続は許可されません。
SUN-DES-1 は Sun が開発した認証プロトコルです。Secure RPC (Remote Procedure Call) が基本になっており、DES (Data Encryption Software) サポートが必要です。認証データはユーザーのネット名、すなわちマシン独立のネットワーク名です。このデータは暗号化され、接続パケットの一部としてサーバーに送られます。サーバーはそのデータを暗号解読し、それが既知のネット名であれば接続が許可されます。
SUN-DES-1 認証プロトコルは、MIT-MAGIC-COOKIE-1 よりも高度なセキュリティを提供します。特定ユーザーのネット名 (マシン独立) を他のユーザーが使用してサーバーにアクセスすることは不可能です。しかし、他のユーザーがマジッククッキーを使用してサーバーにアクセスすることは可能です。
このプロトコルは、OpenWindows バージョン 3 以降の環境に入っているライブラリでしか使用できません。それより古い OpenWindows 環境の静的ライブラリ (特に Xlib) とリンクしているアプリケーションは、この認証プロトコルを使用できません。
後述の 「SUN-DES-1 を使用する場合のアクセス許可」で説明するように、特定ユーザーのアクセスリストにネット名を追加することによって、サーバーに対する他ユーザーのアクセスを許可することができます。
デフォルト認証プロトコルの MIT-MAGIC-COOKIE-1 を他のサポートされている認証プロトコルに変更することができます。また、ユーザーベースのアクセス制御機構を使用しないという変更も可能です。このデフォルト設定の変更には、openwin コマンドとともにオプションを指定します。詳しくは openwin(1)のマニュアルページを参照してください。
たとえば、MIT-MAGIC-COOKIE-1 から SUN-DES-1 に変更するには、OpenWindows を次のように起動します。
example% openwin -auth sun-des
ユーザーベースのアクセス機構なしで OpenWindows を実行する必要があるときは、コマンド行オプション -noauth を使用します。
example% openwin -noauth
-noauth を使用することによってセキュリティ機能が低下します。ホストベースのアクセス制御機構のみで OpenWindows を実行することに等しく、サーバーはユーザーベースのアクセス制御機構を非アクティブ状態とします。そのローカルマシン上でアプリケーションを実行できるすべてのユーザーに対してサーバーへのアクセスが許可されます。
openwin コマンドで -noauth オプションを指定しなければ (「デフォルト認証プロトコルの変更」を参照)、ユーザーベースとホストベースの両方のアクセス制御機構がアクティブ状態となります。サーバーは、最初にユーザーベース機構を調べ、次にホストベース機構を調べます。デフォルトのセキュリティコンフィギュレーションでは、ユーザーベース機構として MIT-MAGIC-COOKIE-1、ホストベース機構に対して空リストが使用されます。ホストベースのリストが空であるため、アクティブになるのはユーザーベース機構です。-noauth オプションを指定すると、サーバーはユーザーベースのアクセス制御機構をアクティブでない状態とします。また、ローカルホストを追加することによってホストのベースリストが初期化されます。
サーバーのアクセス制御機構を変更するためのプログラムとして、xhostとxauth の 2 つがあります。詳しくは xhost および xauth のマニュアルページを参照してください。これらのプログラムは、認証プロトコルによって作成された 2 つのバイナリファイルにアクセスします。これは、特定セッションの認証データを格納したファイルです。一方のファイルはサーバーが内部的に使用するためのもので、もう一方のファイルは下記のファイル名でユーザーの $HOME ディレクトリに配置されます。
表 7-1
.Xauthority |
(クライアント認証ファイル) |
サーバー中のホストベースアクセスリストを変更するには、xhost プログラムを使用します。これにより、アクセスリストに対するホストの追加および削除が可能です。最初にデフォルトのコンフィギュレーションである空のホストベースアクセスリストを使用し、xhost によってマシン名を追加するという方法は、セキュリティレベルを低下させます。すなわち、追加されたホストがアクセスを許可されるだけでなく、デフォルト認証プロトコルを指定するすべてのユーザーもアクセスが許可されます。ホストベースアクセス制御機構のセキュリティレベルが低いと見なされる理由は前述の 「ホストベース」の項で説明した通りです。
xauth プログラムは、.Xauthority クライアントのファイル中の認証プロトコルデータにアクセスします。アクセスを操作する側のユーザーは自分の .Xauthority ファイルからデータを抽出して、他のユーザーが自分の .Xauthority ファイルにそのデータを併合できるようにすることができます。これにより、操作側ユーザーのサーバーまたはそのユーザーが接続しているサーバーに対して他のユーザーがアクセス可能になります。
xhost および xauth の使用例は後述の「MIT-MAGIC-COOKIE-1 を使用する場合のアクセス許可」に示してあります。
クライアント認証ファイル .Xauthority のエントリには以下の形式があります。
表 7-2
connection-protocol |
auth-protocol |
auth-data |
デフォルト設定では、.Xauthority に auth-protocol として MIT-MAGIC-COOKIE-1 が格納され、ローカル表示に関するエントリが connection-protocol および auth-data としてのみ格納されます。たとえば、ホスト anyhost 上で .Xauthority ファイルに以下のエントリが格納されているという場合が考えられます。
表 7-3
anyhost:0 |
MIT-MAGIC-COOKIE-1 |
82744f2c4850b03fce7ae47176e75 |
localhost:0 |
MIT-MAGIC-COOKIE-1 |
82744f2c4850b03fce7ae47176e75 |
anyhost/unix:0 |
MIT-MAGIC-COOKIE-1 |
82744f2c4850b03fce7ae47176e75 |
クライアントのスタートアップ時に、connection-protocol に対応するエントリが .Xauthority から読み取られ、auth-protocol および auth-data が接続パケットの一部としてサーバーに送られます。デフォルトのコンフィギュレーションでは、xhost によって空のホストベースアクセスリストが戻され、認証が実行可能な状態であることを示します。
認証プロトコルをデフォルトから SUN-DES-1 に変更した場合、.Xauthority には auth-protocol として SUN-DES-1 が格納され、auth-data としてユーザーのネット名が格納されます。ネット名の形式は次の通りです。
unix.userid@NISdomainname
たとえば、ホスト anyhost 上で、.Xauthority ファイルに以下のエントリが格納されているという場合が考えられます。
表 7-4
anyhost:0 |
SUN-DES-1 |
"unix.15339@EBB.Eng.Sun.COM" |
localhost:0 |
SUN-DES-1 |
"unix.15339@EBB.Eng.Sun.COM" |
anyhost/unix:0 |
SUN-DES-1 |
"unix.15339@EBB.Eng.Sun.COM" |
この unix.15339@EBB.Eng.Sun.COM は、マシン独立であるユーザーのネット名です。
自分のネットワーク名、またはマシン独立のネット名が不明のときは、システム管理者に照会してください。
MIT-MAGIC-COOKIE-1 認証プロトコルを使用している場合、次の手順により、自分のサーバーに他のユーザーがアクセスできるようにすることができます。
サーバーを走らせているマシン上で xauth を実行し、hostname: 0 に対応するエントリを抽出してファイルに入れる。
例として、hostname が anyhost、ファイルが xauth.info である場合を示します。
myhost%$OPENWINHOME/bin/xauth nextract - anyhost:0 > $HOME/xauth.info
エントリが入っているファイルを、アクセスを要求しているユーザーに送る (メールツール、rcp またはその他のファイル転送プロトコルを使用する)。
認証情報が格納されたファイルの転送には、rcp よりもメールを使用した方がより安全です。rcp を使用する場合は、他のユーザーが容易にアクセスできるディレクトリにそのファイルを入れないようにしなければなりません。
他のユーザーはエントリを自分の .Xauthority ファイルに併合しなければならない。
例として、userhost が xauth.info を自分の .Xauthority ファイルに併合する場合を示します。
userhost%$OPENWINHOME/bin/xauth nmerge - <xauth.info
auth-data は特定セッションに対応します。したがって、それが有効とされるのはサーバーが再起動されるまでの間です。
SUN-DES-1 認証プロトコルを使用している場合、次の手順により、自分のサーバーに他のユーザーがアクセスできるようにすることができます。
サーバーを走らせているマシン上で xhost を実行し、サーバーに新しいユーザーを通知する。
例として、新しいユーザー somebody に myhost 上での実行を許可する場合を示します。
myhost%xhost +somebody@
新しいユーザーは、xauth を使用してエントリを自分の .Xauthority ファイルに追加しなければならない。
例として、新しいユーザー somebody のマシン独立のネット名が unix.15339@EBB.Eng.Sun.COM である場合を示します。
userhost%echo 'addmyhost:0SUN-DES-1 "unix.15339@EBB.Eng.Sun.COM"' | $OPENWINHOME/bin/xauth
X クライアントは、接続するサーバーの名前を取り出すために、環境変数 DISPLAY の値を使用します。
クライアントをリモートで実行するか、またはローカルで他ユーザーとして実行する場合の手順は次の通りです。
サーバーを走らせているマシン上で、他のユーザーにアクセスを許可する。
使用するプロトコルに応じて、前述の「MIT-MAGIC-COOKIE-1 を使用する場合のアクセス許可」または「SUN-DES-1 を使用する場合のアクセス許可」で説明した手順を実行します。
DISPLAY の値として、サーバーを実行しているホストの名前に設定する。
例として、ホストが remotehost である場合を示します。
myhost%setenv DISPLAYremotehost:0
クライアントプログラムを実行する。
クライアントはリモートマシン remotehost 上に表示されます。
myhost%client_program&