サーバはどこからでも接続できるというわけではありません。誰彼となく 自分のディスプレイにウィンドウを表示されたくはないでしょう？ また入力したものを読む時、キーボードはディスプレイの一部なのだということを 忘れないで下さい。 ディスプレイ上にアクセスできるということがセキュリティリスクを生じさせる ということを理解しているひとはほとんどいません。 ディスプレイにアクセスできる人は、スクリーン上でものを読んだり書いたり できるのです。またあなたのキーストロークやマウスの動きを読むことだって できてしまいます。 ほとんどのサーバには２つの認証接続の方法があります。 hostリスト機構(xhost)とマジッククッキー(magic cookie)機構(xauth)です。 またssh(secure shell)があればX接続を転送することもできます。
Xhostはhost名にもとづいてアクセスを行います。サーバは、接続を認められたhost のリストを管理します。hostのチェックを完全に無効にすることもできます( 注意：無効にするとチェックが行われなくなるので全てのhostが接続できてし まいます！)。
xhost プログラムを使ってサーバのhostリストをコントロールすることが できます。上の例でこの機能を使うには
light$ xhost +dark.matt.er
とします。
これはdark.matt.erからの接続を全て許可します。Xクライアントが接続され
ウィンドウが表示されたらすぐにセキュリティの為に接続許可を取り消します。
light$ xhost -dark.matt.er
light$ xhost +
とすればhostチェックしません。
これはhostのアクセスチェックを無効にして誰でも接続できるように
しています。ユーザーが信用できない場合(例えばインターネットに接続している
場合)はこのような許可は決してしないでください。
light$ xhost -
"xhost -"とするだけではアクセスリストから全てのhostを削除
できません(これはあまり使えません。どこからも接続できず、ローカルホスト
さえからも接続できません)。
xhostはとても危なっかしい仕組みであると言えます。リモートホスト上のユーザー
を区別できないし、host名(アドレスも同様)を偽って使うこともできてしまいま
す。もし十分信用できるネットワークに接続していない(PPPでインターネットに接続
しているなど)のならこれは良くないことです。
Xauthは機密を知っているユーザーにアクセスを許可するものです。そのような
機密は認証レコード(authorization record)あるいはマジッククッキー
(magic cookie)と呼ばれます。
異なるディスプレイ用のクッキーは~/.Xauthorityに用意されています。
~/.Xauthorityはグループユーザーおよび他ユーザーにはアクセスできない
ようにしておきます(訳注：chown 600 .Xauthorityとしておきます)。
セッションを始める際、サーバはクッキーを-authで指定したファイルから
読みます。その後サーバは同じクッキーだと判断したクライアントからの接続のみ
を許可します。~/.Xauthorityのクッキーが変更された時、サーバはこの
変更を取り出すことはしません。
最近のサーバはすぐにリクエストしたクライアント用のクッキーを作ります。
クライアントが~/.Xauthorityにクッキーを追加しない限り
~/.Xauthorityには入りませんが、クッキーはサーバ内に保存されます。
David Wiggins氏によると：
より新しい機能が X11R6.3で追加されました。たぶん読者にも興味あることでしょう。 新しいセキュリティ拡張機能を通して、Xサーバはすぐに新しいクッキーを作って返しま す。さらにクッキーは「信用されない」ものに対しても指定できるので、 クッキーのような接続を行うアプリケーションはそれに関する操作のみに制限 されます。例えばキーボード/マウスの入力やウィンドウに表示されている ことなどを他の信用できるクライアントからでさえも盗み見ることはできなくなりま す。xauthで少なくともこの機能を使うための新しいサブコマンドがあります。
xauthはxhostに比べてセキュリティ的に優れています。また特定のコンピュータの 特定のユーザだけにアクセスを制限することができます。xhostのようなでたらめな アドレスからの接続はできません。必要ならxauthの後でxhostによる接続ができます。
もしxauthを使いたいのであれば、-auth (認証ファイル)を引数に付けてXサーバ
を起動する必要があります。startxスクリプトをつかっている場合はそこに書いても
よいでしょう。以下のようにしてstartxスクリプトに認証レコード(authorization
record)を書いて下さい。もしurandomデバイスがない場合はほかのランダムデータ
を生成するものを使います。ps -axlが多分それでしょう(訳注：たいていの
配布パッケージにはurandumデバイスがあります。特にないという場合はMAKEDEVして
下さい)。
/usr/X11R6/bin/startxからの引用：
dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"
これは著者のstartxから引用したものです。startxスクリプトの
カスタマイズについてはmanページの、
tartx(1x), xinit(1x), xauth(1x), md5sum(1)を参照して下さい。
もしxauthが"不適切な行が追加されています(illegal add line)"
と警告したら、md5sumのバージョン(訳注：md5sumはMD5の計算とチェックを行う
プログラムです)にダッシュ(-)が(標準入力を計算するchecksumに)追加されている
可能性があります
md5sumダッシュ(-)を使えない場合はsedを使って取り外す(strip)ことができます。
以下のようにsedコマンドの引数を変更してみて下さい。これは
ダッシュを追加しないmd5sumsと同じように動作すべきですが、わかりやすい
ものではないでしょう。
(Thanks Jeffrey)
... 's/^\([0-9a-f]*\).*$/add :0 . \1/' ...
rootにはなれなくてstartx スクリプトを編集できない場合はシステム管理者に
変更してもらうように言うか、代わりにxdmを設定するように言ってみて下さい。
管理者がそれをしない/できない時は、~/.xserverrcスクリプトを
作ることもできます。このスクリプトは実際のXサーバの代わりに
xinitによって実行されます。そこで適当な引数でこのスクリプトからXサーバを
起動します。そうするために~/.xserverrcでクッキーを作るための
マジッククッキーの行を追加してXサーバを起動します。
#!/bin/sh
dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"
Xセッションを操作するためにxdmを使う時は簡単にxauthが使えます。
/etc/X11/xdm/xdm-configのDisplayManager.authDir リソースを
定義して下さい。xdmはXサーバが起動する時に -auth 引数を パスするように
なります。詳しくは xdm(1) を参照して下さい。例えば著者の
/etc/X11/xdm/xdm-configでは以下の行が書かれています：
DisplayManager.authDir: /var/lib/xdm
light.uni.verse サーバホストでXセッションを開始して ~/.Xauthority
のクッキーを取得します。クッキーをクライアントホスト(dark.matt.er)に転送し
ます。
light(サーバ)とdark(クライアント)ホストがホームディレクトリを共有している
時は話は簡単です。 ~/.Xauthorityファイルは同じなので、クッキーを
転送する必要はありません。
共有されていない場合はrshによる方法でクッキーを転送できます。
rshを使ってリモートシェルで
light$ xauth nlist :0 | rsh dark.matt.er xauth nmerge -
としてクッキーを転送します。これは
~/.Xauthorityからクッキーを引用する(xauth nlist :0)。~/.Xauthorityに置く(xauth nmerge -)。light$ echo $DISPLAY :0 light$ xauth list $DISPLAY light/unix:0 MIT-MAGIC-COOKIE-1 076aaecfd370fd2af6bb9f5550b26926 light$ rlogin dark.matt.er Password: dark% setenv DISPLAY light.uni.verse:0 dark% xauth add $DISPLAY . 076aaecfd370fd2af6bb9f5550b26926 dark% xfig & [15332] dark% logout light$詳しくはrsh(1)、xauth(1x)を参照して下さい。
xfigといったdark.matt.er(クライアント)上のXアプリケーションは
認証に使うクッキーを自動的に~/.Xauthorityから読みます。
認証レコードは暗証化されずに転送されます。誰かが接続をのぞくという心配がある ならssh(secure shell)を使って下さい。これは暗証化された接続を経由してXを フォワードします。もちろん他にもよい方法はあります。 システムに構造上よい発展を補うものです。 sshホームページの http://www.cs.hut.fi/ssh/を見てみて下さい。
誰かX接続や認証方法について他に何か知っていませんか？kerberosかな？
[訳注： Kerberosについて、うえやま るいさん、岡本さんからのコメントをまとめました：
ケルベロスはギリシャ神話に出てくる冥界の支配者ハデスの飼い犬で３つの 頭をもち冥界の門を守る番犬です。"Kerberos" は MIT の "Athena" 計画の一貫 として研究開発されました。RFC 1510 が 1993 年に発行されてます。
Kerberos は信頼できないネットワークで安全な認証・通信を行うために、信頼でき る第三者を使うシステムです。内部の暗号は 対称鍵暗号DESを使います。DESなので あまり強くはありません。しかし、チケットという仕組で認証を行うので運用が簡単 で、安全な認証と通信ができます。鍵配布センターを階層化して、大規模なシステム にも対応することもできるようです。
ふつうの方法だと、クライアントがサーバを利用するときは相手が本当に本物であ るか互いに分かりません。そこで、お互いが信頼している第三者に身元保証しても らえばよいという考えに基づいています。その第三者が鍵配布センターというもの で、その鍵配布センターにサーバを利用するためのチケットを発行してもらいます。 だれでもチケットを発行してもらえるわけはなくクライアントとサーバの鍵を登録 しておく必要があります。 鍵配布センターに発行してもらったチケットは、クライアント(発行してもらう側) の鍵で暗号化されているので、これを復号できるということは、クライアントは確かに 本人であることがわかります(本人じゃなければチケットを取りだせないので、 サーバを利用することはできません)。
チケットは復号化した中に入っていて、このチケットはサーバの鍵で暗号化されて います。そこで「サーバがチケットを復号化できる = サーバも確かに本人である」 ということになります(復号化した中にセッション鍵が入っていて、それ以降の 通信でこのセッション鍵を使うのため、本人以外は続行できません)。
この欠点は、チケットの再利用ができてしまうところです。攻撃者はチケットの内容 を見れませんが、流れているチケットを拾ってそのままもう一回サーバに送れば本人 のふりをできます。そのために、タイムスタンプを暗号化して一緒に送ります。 古いタイムスタンプ付きのチケットは使えません。それに、サーバはタイムスタンプ を記録しているので、まったく同じスタンプを持つチケットは無効です。
システム全体での欠点は、鍵配布センターが存在することです。 鍵すべてを登録しているので、ここを破られると安全もなにもありません。
XFree86 のマニュアルの翻訳(岡本さん)が JF にあります。
X の認証関係の参考にしてください。また、国内では OPEN DESIGN No.14 CQ 出版社
ISBN4-7898-1806-3 C3055 \1748Eの
「集中特集最新の暗号によるセキュリティの実現」が参考になります。
ポインタ：