サーバへのアクセスを制御する (Solaris ユーザーズガイド (上級編))

Solaris ユーザーズガイド (上級編)

サーバへのアクセスを制御する

Xsun を -noauth オプションとともに使用していない場合は (デフォルトの認証プロトコルの変更を参照してください) 、ユーザベースとホストベースのアクセス制御機構が両方ともアクティブ状態になります。サーバは最初にユーザベースの制御機構をチェックした後、ホストベースの制御機構をチェックします。デフォルトのセキュリティ構成では、MIT-MAGIC-COOKIE-1 がユーザベースの制御機構として使われ、空のアクセスリストがホストベースの制御機構として使われます。ホストベースのアクセスリストは空であるため、実質的にはユーザベースの制御機構だけが有効になります。-noauth オプションを指定すると、サーバはユーザベースのアクセス制御機構を無効にし、ホストベースのアクセスリストにローカルホスト名を追加してリストを初期化します。

以下の 2 つのプログラムのどちらかを使って、サーバのアクセス制御機構を変更できます。 xhost または xauthです。詳細は、マニュアルページを参照してください。これらのプログラムは、認証プロトコルによって作成される 2 つのバイナリファイルにアクセスします。これらのファイルには、各セッション固有の認証データが入っています。一方のファイルは、サーバから内部的に使用するためのもので、もう一方のファイルは下記のファイル名でユーザの $HOME ディレクトリにあります。

.Xauthority
(クライアント認証ファイル)

サーバ上にあるホストベースのアクセスリストを変更するには、xhost プログラムを使用します。これにより、アクセスリストに対するホストの追加と削除ができます。デフォルトの構成 (空のホストベースのアクセスリスト) で OpenWindows を起動した場合は、xhost を使ってアクセスリストにマシン名を追加すると、セキュリテレベルを低下させます。つまりサーバは、デフォルトの認証プロトコルで指定されるユーザのほかに、リストに追加されたホストに対してもアクセスを許可します。ホストベースのアクセス制御機構のセキュリテレベルが低いと見なされる理由については、ホストベースを参照してください。

xauth プログラムは、.Xauthority クライアントのファイル内の認証プロトコルデータにアクセスします。アクセスを操作する側のユーザは自分の .Xauthority ファイルからデータを抽出して、ほかのユーザがそのデータを自分の .Xauthority ファイルにマージできるようにします。これにより、操作側ユーザのサーバまたはそのユーザが接続しているサーバに対してほかのユーザがアクセスできるようになります。

xhost と xauth の使用例は、MIT-MAGIC-COOKIE-1 を使用する場合のアクセス許可を参照してください。

クライアント認証ファイル

クライアント用の許可ファイル .Xauthority には、次の形式のエントリがあります。

connection-protocol          auth-protocol          auth-data

デフォルト設定では、.Xauthority ファイルに auth-protocol として MIT-MAGIC-COOKIE-1 が格納され、ローカル表示に関するエントリが connection-protocol および auth-data としてのみ格納されます。たとえば、ホスト anyhost 上の .Xauthority ファイルに次のエントリが格納されている場合が考えられます。

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 によって、空のホストベースのアクセスリストが戻され、認証が実行可能な状態であることを示します。

認証プロトコルをデフォルトの MIT-MAGIC-COOKIE-1 から SUN-DES-1 に変更した場合、.Xauthority ファイルのエントリには、auth-protocol として SUN-DES-1 が格納され、auth-data としてユーザのネットワーク名 (netname) が格納されます。netname の形式は次のとおりです。

unix.userid@NISdomainname

たとえば、ホスト anyhost 上で .Xauthority ファイルに次のエントリが格納されている場合が考えられます。この unix.15339@EBB.Eng.Sun.COM は、マシンに依存しないユーザの netname です。

anyhost:0        SUN-DES-1            ”unix.15339@EBB.Sun.COM”

localhost:0      SUN-DES-1            ”unix.15339@EBB.Sun.COM”

anyhost/unix:0   SUN-DES-1            ”unix.15339@EBB.Sun.COM”

注 –

自分のネットワーク名、またはマシンに依存しないネットワーク名が不明な場合は、システム管理者に問い合わせてください。

`MIT-MAGIC-COOKIE-1` を使用する場合のアクセス許可

MIT-MAGIC-COOKIE-1 認証プロトコルを使用している場合は、次の手順により自分のサーバにほかのユーザがアクセスできるようにすることができます。

サーバを実行しているマシン上で xauth を実行し、hostname:0 に対応するエントリを抽出して、ファイルに入れます。

例として、hostname が anyhost、ファイルが xauth.info の場合を示します。
myhost% /usr/openwin/bin/xauth nextract - anyhost:0> $HOME/xauth.info
アクセスを要求しているユーザに、手順 1 で作成したエントリが入っているファイルを送ります。

この送信には、電子メールツールや rcp コマンドなどのファイル転送プログラムを使用します。

注 –
認証情報が入っているファイルの転送には、rcp よりもメールを使用するほうがより安全です。rcp を使用する場合は、ほかのユーザが簡単にアクセスできるディレクトリにそのファイルを入れないようにしてください。
ほかのユーザは、エントリを自分の .Xautority ファイルにマージしなければなりません。

例として、userhost が xauth.info を自分の .Xauthority ファイルにマージする場合を示します。
userhost% /usr/openwin/bin/xauth nmerge - < xauth.info
注 –
auth-data は特定のセクションに対応します。したがって、サーバが再起動されるまでの間有効です。

`SUN-DES-1` を使用する場合のアクセス許可

SUN-DES-1 認証プロトコルを使用している場合は、次の手順により自分のサーバにほかのユーザがアクセスできるようにすることができます。

サーバを実行しているマシン上で xhost を実行しサーバに新規ユーザを通知します。

例として、新規ユーザ somebody に myhost 上での実行を許可する場合を示します。
myhost% xhost + somebody@
新規ユーザは、xauth コマンドを使用して自分の .Xauthority ファイルにエントリを追加します。

例として、新規ユーザの、マシンに依存しないネット名が unix.15339@EBB.Sun.COM の場合を示します。下記のコマンドは、途中に Return キーなどを入れずに 1 行に入力しなければならないことに注意してください。パイプ記号のあとに、空白と続いてコマンドの残りの部分を入力します。
userhost% echo 'add myhost:0 SUN-DES-1 “unix.15339@EBB.Sun.COM”' | $OPENWINHOME/bin/xauth