test

Solaris のシステム管理 (第 2 巻)

第 15 章 認証サービスの使用手順

この章の最初の節では、Secure RPC で使用できる認証機構について説明します。Diffie-Hellman 認証と Kerberos Version 4 認証がサポートされます。2 番目の節では、Pluggable Authentication Module (PAM) フレームワークについて説明します。PAM は、認証サービスを「プラグイン」する方法を提供して、複数の認証サービスを使用できるようにします。

この章で説明する手順は次のとおりです。

Secure RPC の概要

Secure RPC は、ホストと、要求を依頼したユーザーの両方を認証する認証方法です。Secure RPC は、Diffie-Hellman 認証か Kerberos 認証のどちらかを使用します。これらの認証機構は両方とも DES 暗号化を使用します。Secure RPC を使用するアプリケーションには、NFS と NIS+ ネームサービスがあります。

NFS サービスと Secure RPC

NFS ソフトウェアを使用すると、複数のホストがネットワーク上でファイルを共有できます。NFS システムでは、サーバーは、複数のクライアントから利用できるデータと資源を格納します。クライアントは、サーバーがクライアントにエクスポートしたファイルシステムにアクセスできます。クライアントマシンにログインしたユーザーは、ファイルシステムをサーバーからマウントすることによって、そのファイルシステムにアクセスできます。このとき、クライアントマシン上のユーザーには、ファイルはクライアントのローカルファイルシステム上にあるように見えます。NFS 環境の最も一般的な使用形態として、システムを各オフィスにインストールして、すべてのユーザーファイルを 1 箇所で集中管理する方法が挙げられます。 mount -nosuid オプションなどのいくつかの NFS 機能を使用すると、権限のないユーザーがデバイスやファイルシステムにアクセスすることを禁止できます。

NFS 環境では Secure RPC を使用して、要求を出したユーザーをネットワーク上で認証します。これを Secure NFS と呼びます。認証機構 AUTH_DH は、Diffie-Hellman 認証で DES 暗号化を使用し、許可されたアクセスを確認します。AUTH_DH 機構は、AUTH_DES とも呼びます。AUTH_KERB4 機構は、Kerberos 認証で DES 暗号化を使用します。この機構は、AUTH_KERB とも呼びます。

『NFS の管理』には、Secure NFS を設定および管理する方法が説明されています。NIS+ テーブルの設定と cred テーブルへの名前の入力は、『Solaris ネーミングの管理』で説明しています。RPC 認証に含まれる手順の概要については、「Diffie-Hellman 認証の実装」を参照してください。

DES 暗号化

Data Encryption Standard (DES) 暗号化機能は 56 ビットの鍵を使用して、秘密鍵を暗号化します。資格を持つ 2 人のユーザー (主体) が同じ DES 鍵を知っている場合、彼らはその鍵を使用してテキストを暗号化または復号化することによって、プライベートに通信できます。DES は比較的高速な暗号化機構です。DES チップは暗号化をより高速にします。しかし、チップがなくても、ソフトウェアが実行します。

DES 鍵だけを使用する危険性とは、十分な時間をかけて、同じ鍵を使用して暗号化した暗号テキストメッセージを十分に収集すれば、鍵を発見し、メッセージを復号化できることです。この理由のため、Secure NFS などのセキュリティシステムは鍵を頻繁に変更します。

Diffie-Hellman 認証

Diffie-Hellman のユーザー認証方法は簡単には破られません。クライアントとサーバーは、それぞれ独自の非公開鍵 (秘密鍵とも呼ぶ) を持っていて、共通鍵が利用できるように公開鍵と組み合わせて使用します。クライアントとサーバーはお互いにこの共通鍵を使用し、両者で合意された暗号化復号化機能 (DES など) を使用して通信します。この方法は、以前の Solaris リリースの DES 認証と同じです。

認証は、送信側のシステムの共通鍵を使用して現在の時刻を暗号化する機能を利用します。受信側のシステムは、その現在の時刻を復号し、自分の時刻と照合します。クライアントとサーバーで時刻が同期していることを確認してください。

公開鍵と非公開鍵は、NIS または NIS+ のデータベースに格納されます。NIS では、publickey マップに鍵を格納します。NIS+ では、cred テーブルに鍵を格納します。これらのファイルには、すべてのユーザーの公開鍵と非公開鍵が入っています。

システム管理者は、NIS または NIS+ のテーブルを設定して、ユーザーごとに公開鍵と非公開鍵を生成する義務があります。公開鍵は、ユーザーのパスワードで暗号化されて格納されます。これによって、その公開鍵はそのユーザーだけが知っていることになります。

Diffie-Hellman 認証の実装

この節では、DH 認証 (AUTH_DH) を使用するクライアントサーバーセッションにおける一連のトランザクションを説明します。

公開鍵と秘密鍵の生成

トランザクションの前に、管理者は newkey コマンドか nisaddcred コマンドを使用して、公開鍵と秘密鍵を生成します (各ユーザーは一意の公開鍵と秘密鍵を持ちます)。公開鍵は公開データベースに格納されます。秘密鍵は、暗号化された形式で、同じデータベースに格納されます。鍵のペアを変更するには、chkey コマンドを使用します。

keylogin コマンドの実行

通常、ログインパスワードは Secure RPC パスワードと同じです。この場合、keylogin は必要ありません。パスワードが異なる場合、ユーザーはログインしてから明示的に keylogin を実行しなければなりません。

keylogin プログラムは、Secure RPC パスワードを求めるプロンプトをユーザーに出して、そのパスワードを使用して秘密鍵を復号します。keylogin プログラムは、復号した秘密鍵をキーサーバーというプログラムに渡します (キーサーバーは、すべてのコンピュータ上にローカルインスタンスを持つ RPC サービスです)。キーサーバーは、復号された秘密鍵を保存して、ユーザーがサーバーで Secure RPC トランザクションを発行するのを待ちます。

パスワードが同じ場合は、ログインプロセスが秘密鍵をキーサーバーに渡します。パスワードが異なる必要があり、ユーザーが常に keylogin を実行しなければならない場合は、keylogin プログラムをユーザーの環境の構成ファイル (‾/.login、‾/.cshrc、‾/.profile など) に入れておいて、ユーザーがログインするたびに自動的に実行されるようにします。

対話鍵の生成

ユーザーがサーバーとのトランザクションを開始すると、次の動作が行われます。

  1. キーサーバーはランダムに対話鍵を生成します。

  2. カーネルはこの対話鍵を使用して、クライアントのタイムスタンプを暗号化します (他の動作も行います)。

  3. キーサーバーは公開鍵データベースでサーバーの公開鍵を検索します (publickey(4) のマニュアルページを参照してください)。

  4. キーサーバーはクライアントの秘密鍵とサーバーの公開鍵を使用して、共通鍵を作成します。

  5. キーサーバーは共通鍵を使用して対話鍵を暗号化します。

サーバーとの最初の接触

次に、暗号化したタイムスタンプと暗号化した対話鍵を含む伝送データがサーバーに送信されます。伝送データには資格とベリファイアが含まれます。資格は、次の 3 つの構成要素を持ちます。

この場合の「ウィンドウ」とは、クライアントが主張する、サーバーの時刻とクライアントのタイムスタンプとの許容されるべき差のことです。サーバーの時刻とクライアントのタイムスタンプとの間の差がウィンドウより大きい場合、サーバーはクライアントの要求を拒否します。クライアントは RPC セッションを開始する前にサーバーと同期を取るため、通常の状態では、このような事態は発生しません。

クライアントのベリファイアは、次の構成要素を持ちます。

ウィンドウベリファイアが必要な理由は次の場合です。誰かが別のユーザーになりすまそうとして、資格とベリファイアの暗号化されたフィールドに書き込む代わりに、ランダムなビットだけを埋め込むプログラムを書いたと仮定します。サーバーはこの対話鍵をなんらかのランダム鍵に復号化し、それを使用してウィンドウとタイムスタンプを復号化しようと試みます。その結果、乱数が生成されるだけです。しかし、数千回の試行を重ねるうちには、このランダムなウィンドウタイムスタンプのペアが認証システムを通過することが十分ありえます。ウィンドウベリファイアは、正しい資格の解読をより困難にします。

対話鍵の復号化

サーバーがクライアントから伝送データを受信すると、次の動作が行われます。

  1. サーバーのローカルなキーサーバーが、公開鍵データベースでクライアントの公開鍵を検索します。

  2. キーサーバーは、クライアントの公開鍵とサーバーの秘密鍵を使用して、共通鍵を計算します。この共通鍵はクライアントが計算したものと同じです。共通鍵を計算するためには、どちらか一方の秘密鍵を知っている必要があるため、これを行えるのはサーバーとクライアントだけです。

  3. カーネルは共通鍵を使用して、対話鍵を復号します。

  4. カーネルはキーサーバーを呼び出して、復号された対話鍵によりクライアントのタイムスタンプを復号します。

サーバーへの情報の格納

サーバーは、クライアントのタイムスタンプを復号した後、次の 4 種類の情報を資格テーブルに格納します。

サーバーは、最初の 3 つの情報を将来の使用のために格納します。サーバーはタイムスタンプを格納して、同じタイムスタンプが再度使用できないようにします。サーバーは、最後に参照したタイムスタンプよりも時間的に後のタイムスタンプだけを受け付けるため、同じタイムスタンプのトランザクションはすべて拒否されることが保証されます。

注 -

この手順において暗黙的に仮定されているのは呼び出し側の名前であり、何らかの方法でこの名前を認証しなければなりません。キーサーバーは、この目的には DES 認証を使用できません。DES 認証を使用すれば、デッドロックが発生するからです。キーサーバーは、 UID ごとに秘密鍵を格納し、ローカルの root プロセスへの要求だけを許可することによってこの問題を解決します。

クライアントに返されるベリファイア

サーバーは、ベリファイアをクライアントに返します。ベリファイアは、次の構成要素を持ちます。

タイムスタンプから 1 を引く理由は、これを無効化して、クライアントのベリファイアとして再利用できないようにするためです。

クライアントによるサーバーの認証

クライアントがベリファイアを受信し、そのサーバーを認証します。クライアントは、このベリファイアを送信できるのはサーバーだけであることを知っています。その理由は、クライアントが送信したタイムスタンプの内容を知っているのはサーバーだけだからです。

追加のトランザクション

一番目以降のすべてのトランザクションごとに、クライアントは 2 番目のトランザクションでインデックス ID をサーバーに返し、もう 1 つの暗号化されたタイムスタンプを送信します。サーバーは、クライアントのタイムスタンプから 1 を引いたものを対話鍵で暗号化して、返送します。

Kerberos Version 4

Kerberos は、マサチューセッツ工科大学 (MIT) で開発された認証システムです。Kerberos は DES 暗号化を使用して、システムのログイン時にユーザーを認証します。認証は、送信側のシステムが共通鍵を使用して現在の時刻を暗号化する機能を利用します。受信側のシステムは、その現在の時刻を復号し、自分の時刻と照合します。Kerberos Version 4 は、Solaris 2.6 リリースでサポートされています。

Kerberos は、ユーザーのログインパスワードを認証することによって動作します。ユーザーは、kinit コマンドを入力します。このコマンドは、Kerberos 認証サーバーから、セッション時間 (デフォルトのセッション時間は 8 時間) の間だけ有効であるチケットを取得します。ユーザーがログアウトするとき、このチケットは (kdestroy コマンドで) 削除できます。

Kerberos ソフトウェアは、MIT プロジェクト Athena から入手できます。Kerberos ソフトウェアは SunOS 5.x ソフトウェアの一部ではありません。SunOS 5.x ソフトウェアが提供するものは、次のとおりです。

「NFS による Kerberos 認証の実装」に、Kerberos 認証手順の動作の概要を示します。

注 -

Solaris は、Kerberos 機能に接続できる機能を提供します。Solaris は Kerberos パッケージを提供しません。ただし、ユーザー名として anonymous を、パスワードとして電子メールのアドレスを使用することによって、athena-dist.mit.edu から Kerberos 4 のソースを ftp で入手できます。このソースは、ディレクトリ pub/kerberos にあります。

NFS による Kerberos 認証の実装

次の手順では、MIT プロジェクト Athena から公開されている Kerberos キー配布センターのソースを使用して、Kerberos キー配布センター (KDC) がすでにネットワーク上にインストールされていると仮定しています。

  1. /usr/sbin/kerbd デーモンが NFS クライアントとサーバー上で動作していなければなりません。

    このデーモンは、通常、inetd によって必要に応じて起動されます。rpcinfo コマンドを使用すれば、kerbd サービスが登録されていることを確認できます。kerbd はユーザーモードデーモンです。kerbd は、カーネル RPC および KDC とインターフェースを取ります。kerbd は、認証チケットを生成してその妥当性を検査します。

  2. システム管理者は、Kerberos 認証を使用するように NFS サーバーを設定します。

    MIT Kerberos ソフトウェアは、Kerberos サーバー上で Kerberos キー配布センター (KDC) に主体名を登録するのに使用されます。次のエントリが必要です。

    • root.hostname (NFS クライアントごとに必要)

    • nfs.hostname (NFS サーバーごとに必要)

  3. ユーザーは、共有ファイルシステムをマウントします。

    共有ファイルシステムをマウントするために、クライアント上のユーザーは、クライアント上で root 用のチケットを取得しなければなりません。

  4. ユーザーは、kinit コマンドを使用して、Kerberos サービスにログインします。

    Kerberos 認証サーバーは、要求を認証して、チケット譲与サービス用のチケットを与えます。

  5. ユーザーは、マウント済みディレクトリにアクセスします。

    kerbd デーモンは、クライアントのために、ファイルシステムをエクスポートしている NFS サーバー用のチケットを自動的に取得します。この時点で、2 つの有効なチケットがあります。オリジナルのチケット譲与チケットと、サーバー用のチケットです。

  6. ユーザーは、セッションの終わりにチケットを削除して、誤用と悪用を防ぎます。

    kdestroy コマンドは、チケットを含むファイルにゼロを書き込むことによって、ユーザーのアクティブな Kerberos 認証チケットを削除します。kdestroy コマンドを .logout ファイルに置いておけば、システムからログアウトするときに、すべての kdestroy チケットを自動的に破壊できます。

  7. セッションが終了する前にチケットが削除されていた場合、ユーザーは kinit コマンドで新しいチケットを要求しなければなりません。

Diffie-Hellman 認証の管理

システム管理者は、ネットワークを安全にするためのポリシーをネットワーク上に実装できます。必要なセキュリティのレベルはサイトによって異なります。この節では、ネットワークセキュリティに関連するいくつかの作業手順を説明します。

キーサーバーを再起動する方法

  1. スーパーユーザーになります。

  2. keyserv デーモン (キーサーバー) が動作していることを確認します。 

       # ps -ef | grep keyserv
   root  100 		   1		 16	  Apr 11 ?			   0:00 /usr/sbin/keyserv
   root	2215   2211			 5  09:57:28 pts/0 0:00 grep keyserv

  3. キーサーバーが動作していない場合は、キーサーバーを起動します。 


    # /usr/sbin/keyserv

Diffie-Hellman 認証明に NIS+ 資格を設定する方法

NIS+ セキュリティの詳細は、『Solaris ネーミングの管理』を参照してください。

NIS+ クライアント上で root 用の新しい鍵を設定するには

  1. スーパーユーザーになります。

  2. /etc/nsswitch.conf ファイルを編集して、次の行を追加します。

       publickey: nisplus

  3. NIS+ クライアントを起動します。

       # nisinit -cH hostname

    hostname は、そのテーブルにクライアントマシン用のエントリを持つ、信頼されている NIS+ サーバー名です。

  4. 次のコマンドを入力して、クライアントを cred テーブルに追加します。 

       # nisaddcred local
   # nisaddcred des

  5. keylogin コマンドを使用して、設定を確認します。

    パスワードを求めるプロンプトが出たら、この手順は成功です。

例 - NIS+ クライアント上で root 用の新しい鍵を設定する

次の例は、ホスト pluto を使用して、earth を NIS+ クライアントとして設定しています。警告は無視できます。keylogin コマンドが受け付けられて、earth が Secure NIS+ クライアントとして正しく設定されていることを確認しています。 

# nisinit -cH pluto
NIS Server/Client setup utility.
This machine is in the North.Abc.COM. directory.
Setting up NIS+ client ...
All done.
# nisaddcred local
# nisaddcred des 
DES principal name : unix.earth@North.Abc.COM
Adding new key for unix.earth@North.Abc.Com (earth.North.Abc.COM.)
 
Network password: xxx <Press Return>
Warning, password differs from login password.
Retype password: xxx <Press Return>
 
# keylogin
Password:
#

NIS+ ユーザー用の新しい鍵を設定するには

  1. 次のコマンドを入力して、ユーザーを root マスターサーバー上の cred テーブルに追加します。 

       # nisaddcred -p unix.UID@domainname -P username.domainname. des

    この場合、「username-domainname」はドット (.) で終了しなければなりません。

  2. クライアントとしてログインし、keylogin コマンドを入力して、設定を確認します。

例 - NIS+ ユーザー用の新しい鍵を設定する

次の例は、DES セキュリティ認証をユーザー george に与えています。

# nisaddcred -p unix.1234@North.Abc.com -P george.North.Abc.COM. des
DES principal name : unix.1234@North.Abc.COM
Adding new key for unix.1234@North.Abc.COM (george.North.Abc.COM.)
 
Password:
Retype password:
 
# rlogin rootmaster -l george
# keylogin
Password:
#

Diffie-Hellman 認証で NIS 資格を設定する方法

クライアント上でスーパーユーザー用の新しい鍵を作成するには

  1. クライアント上でスーパーユーザーになります。

  2. /etc/nsswitch.conf ファイルを編集して、次の行を追加します。


    publickey: nis

  3. newkey コマンドを使用して、新しい鍵ペアを作成します。

       # newkey -h hostname

    hostname は、クライアント名です。

例 - Diffie-Hellman セキュリティを使用するように NIS+ クライアントを設定する

次の例は、earth を Secure NIS クライアントとして設定しています。

# newkey -h earth
Adding new key for unix.earth@North.Abc.COM
New Password:
Retype password:
Please wait for the database to get updated...
Your new key has been successfully stored away.
#

ユーザー用の新しい鍵を作成するには

  1. サーバーにスーパーユーザーとしてログインします。

    ユーザー用の新しい鍵を作成できるのは、NIS+ サーバーにログインしたシステム管理者だけです。

  2. ユーザー用の新しい鍵を作成します。

       # newkey -u username

    username はユーザー名です。システムはパスワードを求めるプロンプトを出します。システム管理者は汎用パスワードも入力できます。非公開鍵は汎用パスワードで暗号化されて格納されます。

       # newkey -u george
   Adding new key for unix.12345@Abc.North.Acme.COM
   New Password:
   Retype password:
   Please wait for the database to get updated...
   Your new key has been successfully stored away.
   #

  3. ログインして chkey -p コマンドを入力するように、ユーザーに伝えます。

    これによって、そのユーザーは自分だけが知っているパスワードを使用して、自分の非公開鍵を再び暗号化できます。

       earth% chkey -p
   Updating nis publickey database.
   Reencrypting key for unix.12345@Abc.North.Acme.COM
   Please enter the Secure-RPC password for george:
   Please enter the login password for george:
   Sending key change request to pluto...
   #
    注 -

    chkey コマンドを使用すると、新しい鍵ペアをユーザーに作成できます。

Diffie-Helman 認証でファイルを共有およびマウントする方法

前提条件

Diffie-Hellman の publickey 認証がネットワークで有効にされていなければなりません。「Diffie-Hellman 認証明に NIS+ 資格を設定する方法」と 「Diffie-Hellman 認証で NIS 資格を設定する方法」を参照してください。

Diffie-Hellman 認証でファイルシステムを共有するには

  1. スーパーユーザーになります。

  2. Diffie-Hellman 認証でファイルシステムを共有します。 


    # share -F nfs -o sec=dh /filesystem
Diffie-Hellman 認証でファイルシステムをマウントするには

  1. スーパーユーザーになります。

  2. Diffie-Hellman 認証でファイルシステムをマウントします。

       # mount -F nfs -o sec=dh server:resource  mountpoint

    -o sec=dh オプションは、AUTH_DH 認証でファイルシステムをマウントします。

Kerberos Version 4 認証の管理

システム管理者は、ネットワークを安全にするためのポリシーをネットワーク上に実装できます。必要なセキュリティのレベルはサイトによって異なります。この節では、ネットワークセキュリティに関連するいくつかの作業手順を説明します。

Kerberos 認証でファイルを共有およびマウントする方法

前提条件

Kerberos Version 4 認証がネットワークで有効にされていなければなりません。

Kerberos 認証でファイルシステムを共有するには

  1. スーパーユーザーになります。

  2. Kerberos 認証でファイルシステムを共有します。

       # share -F nfs -o sec=krb4 /filesystem
Kerberos 認証でファイルシステムをマウントするには

  1. スーパーユーザーになります。

  2. Kerberos 認証でファイルシステムをマウントします。

       # mount -F nfs -o sec=krb4 server:resource mountpoint

    -o sec=krb4 オプションは、AUTH_KERB 認証でファイルシステムをマウントします。

クライアント上でスーパーユーザー用の Kerberos チケットを取得する方法

アクセスする必要がある NFS ファイルシステムがマウントされていない場合、マウントする前に、クライアント上でスーパーユーザー用のチケットを取得する必要があります。

マウントしていないファイルシステム用のチケットを取得するには

  1. スーパーユーザーになります。

  2. クライアント上で Kerberos チケットを取得します。

       # kinit root.hostname

    hostname はクライアントシステム名です。

       # kinit root.earth
   Password:
   #
マウント済みファイルシステム用のチケットを取得するには

/etc/srvtab 構成ファイルにクライアント用のエントリ root.hostname が入力されている場合、ksrvtgt コマンドを使用して、スーパーユーザー用のチケットを取得できます。この場合、スーパーユーザーのパスワードを指定する必要はありません。/etc/srvtab ファイルの初期化については、MIT のマニュアルを参照してください。

  1. スーパーユーザーになります。

  2. マウント済みファイルシステム用のチケットを取得します。 

       # ksrvtgt root.hostname

例 - クライアント上でスーパーユーザー用の Kerberos チケットを取得する

   # ksrvtgt root.earth
   #

Kerberos サービスにログインする方法

    Kerberos サービスにログインするには、kinit -l username コマンドを使用します。 


    earth% kinit -l username

    kinit コマンドは、チケットの生存期間 (-l オプションを指定した場合) とパスワードを求めるプロンプトを出します。冗長モード (-v オプション) を使用すれば、チケットの状態が出力されます。

例 - Kerberos サービスにログインする

earth% kinit -l jjones
SunOS (earth)
Kerberos Initialization for "jjones"
Kerberos ticket lifetime (minutes): 480
Password:
earth%

Kerberos チケットをリストする方法

    klist と入力します。

例 - Kerberos チケットをリストする

earth% klist
Ticket file: /tmp/tkt8516
Principal: jjones@North.Abc.COM
  Issued            Expires          Principal
  Jan 14 20:40:54   Jan
15:04:40:54  krbtgt.North.Abc.COM@North.Abc.COM

Kerberos 認証でディレクトリにアクセスする方法

    cd /mountpoint と入力します。

    他のマウント済みディレクトリと同様に、マウント済みディレクトリにアクセスします。ls コマンドでディレクトリ中のファイルをリストしたり、klist コマンドで Kerberos チケットをリストしたりできます。

例 - Kerberos 認証でディレクトリにアクセスする

次の例では、ユーザー jjones はマウント済みの mntkrb ディレクトリに移動して、このディレクトリ内のファイルをリストしています。

kerbd デーモンは、ユーザーの代わりに、ファイルシステムをエクスポートしている NFS サーバー用のチケットを自動的に取得します。この時点で、2 つの有効なチケットがあります。オリジナルのチケット譲与チケットとサーバー用のチケットです。klist でこれら 2 つのチケットをリストします。

earth% cd /mntkrb
earth% ls -l /mntkrb
-rw-r--r-- 1 marks  staff  29 Jul 14 12:22 sports
drwxr-xr-x 3 jjones staff 512 Sep 13 13:44 market
 
earth% klist
Ticket file: /tmp/tkt8516
Principal: jjones@North.Abc.COM
  Issued            Expires          Principal
  Jan 14 20:40:54   Jan
15:04:40:54  krbtgt.North.Abc.COM@North.Abc.COM
  Jan 14 20:43:21   Jan 15:04:43:21  nfs.pluto@North.Abc.COM

Kerberos チケットを削除する方法

    kdestroy を入力します。

    セッションが終了するときは、Kerberos チケットを削除します。これは、認証されていないユーザーがアクセスできないようにするためです。Kerberos 認証を再発行するには、kinit コマンドを使用します。

例 - Kerberos チケットを削除する

次の例は、Kerberos チケットを削除する方法を示しています。削除後、ユーザーが Kerberos で保護されたディレクトリに移動したり、そのディレクトリの内容をリストしたりしようとすると、チケットサーバーがアクセスを拒否します。

earth% kdestroy
Tickets destroyed
earth% ls /mntkrb
Can't get Kerberos key: No ticket file (tf_util)
NFS getattr failed for server pluto: RPC: Authentication error
can not access directory /mntkrb.

PAM について

Pluggable Authentication Module (PAM) フレームワークを使用すると、login、ftp、telnet などのシステムに入るためサービスを変更しなくても、新しい認証技術を「プラグイン」できるようになります。また、PAM を使用すれば、 UNIX ログインを DCE や Kerberos のような他のセキュリティ機構と統合できます。また、アカウント、セッション、およびパスワードの管理機構もプラグインできます。

PAM を使用する利点

PAM フレームワークを使用すると、システム管理者は任意のシステムに入るため、サービス (ftp、login、telnet、rsh など) とユーザー認証用を組み合わせることができます。次に PAM の利点をいくつか挙げます。

PAM の概要

PAM は、実行時に取り外しが可能なモジュールを使用して、システムに入るためのサービスに認証を提供します。これらのモジュールは、その機能に基づき、4 つの異なるタイプに分かれます。認証、アカウント管理、セッション管理、およびパスワード管理です。スタッキング機能によって、複数のサービス経由でユーザーを認証できます。また、パスワードマッピング機能によって、ユーザーは複数のパスワードを覚えておく必要がありません。

PAM モジュールのタイプ

モジュールタイプはモジュールのインターフェースを定義するため、PAM モジュールのタイプを理解することは重要です。実行時 PAM モジュールには、次の 4 つのタイプがあります。

スタッキング機能

PAM フレームワークは、「スタッキング機能」を使用して、複数のサービスでユーザーを認証する方法を提供します。構成によって、認証方法ごとにパスワードを求めるプロンプトをユーザーに出すことも可能です。認証サービスが使用される順序は、PAM 構成ファイルで決定されます。

パスワードマッピング機能

スタッキング機能をを使った方法では、ユーザーが複数のパスワードを覚えておかなければなりません。「パスワードマッピング機能」を使用すれば、主要パスワードから他のパスワードを復号できるので、ユーザーは複数のパスワードを覚えたり入力したりする必要はありません。各認証機構間でパスワードの同期を取るためのオプションもあります。スタック内で使用される最も安全性の低いパスワードによって各機構のセキュリティが制限されてしまうので、この方法はセキュリティの危険性を増大してしまうことに注意してください。

PAM の機能

PAM ソフトウェアは、ライブラリ、いくつかのモジュール、および構成ファイルからなります。いくつかのシステムに入るためのコマンドまたはデーモンの新しいバージョンは、PAM インタフェースを利用できます。

図 15-1 は、アプリケーション、PAM ライブラリ、pam.conf ファイル、および PAM モジュール間の関係を示しています。

図 15-1 PAM の動作

Graphic

アプリケーション (ftp、telnet、および login) は、PAM ライブラリを使用して、適切なモジュールにアクセスします。pam.conf ファイルは、使用するモジュールを定義して、各アプリケーションがモジュールを使用する順番を定義します。モジュールからの応答は、ライブラリ経由でアプリケーションに戻されます。

次の節では、この関係について説明します。

PAM ライブラリ

PAM ライブラリ /usr/lib/libpam は、適切なモジュールをロードして、スタッキング手順を管理するためのフレームワークを提供します。また、すべてのモジュールを取り外すことができる汎用構造も提供します。

PAM モジュール

各 PAM モジュールは、特定の機構を実装します。PAM 認証を設定するときは、モジュールとモジュールタイプの両方を指定する必要があります。モジュールタイプは、モジュールが実行する処理を定義します。複数のモジュールタイプ (auth、account、session、または password) を各モジュールに関連付けることができます。

次のリストで各 PAM モジュールについて説明します。

PAM 構成ファイル

PAM 構成ファイル /etc/pam.conf は、使用する認証サービスとそれらを使用する順序を決定します。このファイルを編集すれば、システムに入るためのアプリケーションごとに認証機構を選択できます。

構成ファイルの構文

PAM 構成ファイルは、次の構文のエントリからなります。


service_name module_type control_flag module_path module_options

service_name

サービス名 (たとえば、ftp、login、telnet など)

module_type

サービスのモジュールタイプ 

control_flag

モジュールの継続または失敗の意味を決定する 

module_path

サービス機能を実装するライブラリオブジェクトのパス 

module_options

サービスモジュールに渡される特定のオプション 

pam.conf ファイルにコメントを追加するには、その行を # (ポンド記号) で始めます。フィールドを区切るには、空白を使用します。

注 -

次の 3 つの状態のいずれかが存在する場合、PAM 構成ファイル内のエントリは無視されます。(1) 行のフィールド数が 4 つより少ない。(2) module_type または control_flag に無効な値が指定されている。(3) 指定したモジュールが見つからない。

有効なサービス名

表 15-1 は、有効なサービス名、そのサービスで使用できるモジュールタイプ、およびサービス名に関連するデーモンまたはコマンドを示しています。

サービスごとに適切でないモジュールタイプもいくつかあります。たとえば、password モジュールタイプは、passwd コマンドだけに指定できます。このコマンドは認証には関連しないので、このコマンドに関連する auth モジュールタイプはありません。

表 15-1 /etc/pam.conf の有効なサービス名

サービス名 

デーモンまたはコマンド 

モジュールタイプ 

dtlogin

/usr/dt/bin/dtlogin

auth、account、session

ftp

/usr/sbin/in.ftpd

auth、account、session

init

/usr/sbin/init

session

login

/usr/bin/login

auth、account、session

passwd

/usr/bin/passwd

password

rexd

/usr/sbin/rpc.rexd

auth

rlogin

/usr/sbin/in.rlogind

auth、account、session

rsh

/usr/sbin/in.rshd

auth、account、session

sac

/usr/lib/saf/sac

session

su

/usr/bin/su

auth、account、session

telnet

/usr/sbin/in.telnetd

auth、account、session

ttymon

/usr/lib/saf/ttymon

session

uucp

/usr/sbin/in.uucpd

auth、account、session

制御フラグ

認証プロセス中にモジュールの処理を継続するか失敗するかを決定するには、エントリごとに 4 つの制御フラグの 1 つを選択しなければなりません。制御フラグは、各モジュールで正常終了と異常終了がどのように処理されるかを示します。これらのフラグはすべてのモジュールに適用されますが、次の説明では、これらのフラグは認証モジュールで使用されていると仮定します。制御フラグは、次のとおりです。

汎用 pam.conf ファイル

次の例は、汎用 pam.conf ファイルを示しています。

# PAM configuration
# Authentication management
#
login	auth	required	/usr/lib/security/pam_unix.so.1
login	auth	required	/usr/lib/security/pam_dial_auth.so.1
rlogin	auth	sufficient	/usr/lib/security/pam_rhost_auth.so.1
rlogin	auth	required	/usr/lib/security/pam_unix.so.1
dtlogin	auth	required	/usr/lib/security/pam_unix.so.1
telnet	auth	required	/usr/lib/security/pam_unix.so.1
su	auth	required	/usr/lib/security/pam_unix.so.1
ftp	auth	required	/usr/lib/security/pam_unix.so.1
uucp	auth	required	/usr/lib/security/pam_unix.so.1
rsh	auth	required	/usr/lib/security/pam_rhost_auth.so.1
OTHER	auth	required	/usr/lib/security/pam_unix.so.1
#
# Account management
#
login	account	required	/usr/lib/security/pam_unix.so.1
rlogin	account	required	/usr/lib/security/pam_unix.so.1
dtlogin	account	required	/usr/lib/security/pam_unix.so.1
telnet	account	required	/usr/lib/security/pam_unix.so.1
ftp	account	required	/usr/lib/security/pam_unix.so.1
OTHER	account	required	/usr/lib/security/pam_unix.so.1
#
# Session management
#
login	session	required	/usr/lib/security/pam_unix.so.1
rlogin	session	required	/usr/lib/security/pam_unix.so.1
dtlogin	session	required	/usr/lib/security/pam_unix.so.1
telnet	session	required	/usr/lib/security/pam_unix.so.1
uucp	session	required	/usr/lib/security/pam_unix.so.1
OTHER	session	required	/usr/lib/security/pam_unix.so.1
#
# Password management
#
passwd	password	required	/usr/lib/security/pam_unix.so.1
OTHER	password	required	/usr/lib/security/pam_unix.so.1

この汎用 pam.conf ファイルは、次の内容を指定しています。

  1. login を実行するとき、pam_unix モジュールと pam_dial_auth モジュールの両方による認証が成功しなければなりません。

  2. rlogin を実行するとき、pam_unix モジュールによる認証が失敗した場合は、pam_rhost_auth モジュールによる認証が成功しなければなりません。

  3. sufficient 制御フラグは、rlogin の場合は、pam_rhost_auth モジュールによる認証が成功すれば十分であり、次のエントリが無視されることを示しています。

  4. 認証を必要とする他のほとんどのコマンドの場合、pam_unix モジュールによる認証が成功しなければなりません。

  5. rsh の場合、pam_rhost_auth モジュールによる認証が成功しなければなりません。

OTHER サービス名を使用すれば、認証を必要とするがこのファイルには含まれていない他のコマンドに対するデフォルトとして設定できます。OTHER オプションを使用すると、同じモジュールを使用する多数のコマンドを 1 つのエントリだけでカバーできるので、ファイルの管理が簡単になります。また、OTHER サービス名を「すべてを捕捉する」と言う意味で使用すると、1 つのモジュールですべてのアクセスをカバーできます。通常、OTHER エントリは、各モジュールタイプのセクションの最後に指定します。

ファイル内の残りのエントリは、アカウント、セッション、およびパスワードの管理を制御します。

デフォルトサービス名 OTHER を使用すると、汎用 PAM 構成ファイルは、次のように簡単になります。

# PAM configuration
#
# Authentication management
#
login	auth	required	/usr/lib/security/pam_unix.so.1
login	auth	required	/usr/lib/scurty/pam_dial_auth.so.1
rlogin	auth	sufficient	/usr/lib/security/pam_unix.so.1
rlogin	auth	required	/usr/lib/security/pam_rhost_auth.so.1
rsh	auth	required	/usr/lib/security/pam_rhost_auth.so.1
OTHER	auth	required	/usr/lib/security/pam_unix.so.1
#
# Account management
#
OTHER	account	required	/usr/lib/security/pam_unix.so.1
#
# Session management
#
OTHER	session	required	/usr/lib/security/pam_unix.so.1
#
# Password management
#
OTHER	password	required	/usr/lib/security/pam_unix.so.1

通常、module_path のエントリには「ルートからのパス名」を指定します。module_path に入力したファイル名がスラッシュ (/) で始まらない場合、そのファイル名の前にパス /usr/lib/security/ が付きます。モジュールが他のディレクトリにある場合は、フルパスを使用しなければなりません。

module_options の値については、そのモジュールのマニュアルページ (たとえば、pam_unix(5)) を参照してください。

pam_unix モジュールでサポートされている use_first_pass オプションと try_first_pass オプションを使用すると、ユーザーは認証用の同じパスワードを再入力しなくても再利用できます。

login が pam_local と pam_unix の両方による認証を指定した場合、ユーザーは、モジュールごとにパスワードを入力するようにプロンプトが表示されます。パスワードが同じ場合、use_first_pass モジュールオプションを使用すれば、パスワードの入力を求めるプロンプトは 1 度だけ表示されます。そのパスワードを両方のモジュールで使用して、ユーザーを認証します。パスワードが異なる場合、認証は失敗します。通常、このオプションは、次に示すように、optional 制御フラグといっしょに使用して、依然としてユーザーのログインが可能なようにします。

# Authentication management
#
login	auth	required	/usr/lib/security/pam_unix.so.1
login	auth	optional	/usr/lib/security/pam_local.so.1	use_first_pass

try_first_pass モジュールオプションを代わりに使用すると、パスワードが一致しなかった場合またはエラーが発生した場合、ローカルモジュールは、2 番目のパスワードを求めるプロンプトを表示します。必要なすべてのツールにアクセスするために、ユーザーが両方の認証方法を必要とする場合、このオプションを使用すると 1 つのタイプの認証だけでアクセスできるので、ユーザーが混乱する場合があります。

PAM の構成

この節では、PAM のフレームワークを完全に機能させるために必要な作業について説明します。特に、PAM 構成ファイルに関連するセキュリティのいくつかの問題について注意する必要があります。

PAM の計画

どのように PAM を使用すればユーザーのサイトに最適であるかを決定するために、次の問題から始めます。

ここで、構成ファイルを変更する前に考慮すべき問題を示します。

/etc/pam.conf ファイルの変更後、スーパーユーザーとしてログインしている間にできるだけ調査します。変更によって影響を受けるコマンドは、すべてテストします。たとえば、新しいモジュールを telnet サービスに追加した場合、telnet コマンドを使用して、行なった変更が期待どおりに動作しているかどうかを確認します。

PAM モジュールを追加する方法

  1. スーパーユーザーになります。

  2. 使用される制御フラグやオプションを決定します。

    モジュールについては、「PAM モジュール」を参照してください。

  3. 新しいモジュールを /usr/lib/security にコピーします。

  4. モジュールファイルの所有者が root で、そのアクセス権が 555 になるように、アクセス権を設定します。

  5. PAM 構成ファイル /etc/pam.conf を編集して、このモジュールを適切なサービスに追加します。

確認

構成ファイルが間違って構成されていた場合などのために、システムをリブートする前にテストすることは非常に重要です。システムをリブートする前に、rlogin、su、および telnet を実行します。サービスが、システムがブートするときだけに生成されるデーモンの場合は、システムをリブートしなければ、モジュールが正しく追加されていることを確認できません。

PAM を使用して、リモートシステムからの認証されていないアクセスを防ぐ方法

PAM 構成ファイルから「rlogin auth rhosts_auth.so.1」エントリを削除します。これによって、rlogin セッション中、‾/.rhosts ファイルは読み込まれなくなります。したがって、リモートシステムからローカルシステムへの認証されていないアクセスを防ぐことができます。‾/.rhosts ファイルまたは /etc/hosts.equiv ファイルの存在またはその内容にかかわらず、すべての rlogin アクセスにはパスワードが必要になります。

注 -

‾/.rhosts ファイルへの認証されていない他のアクセスを防ぐには、rsh サービスも無効にする必要があります。サービスを無効にする最良の方法は、/etc/inetd.conf からサービスエントリを削除することです。PAM 構成ファイルを変更しても、サービスを無効にはできません。

PAM のエラー報告を有効にする方法

  1. /etc/syslog.conf を編集して、次の PAM のエラー報告に関するエントリを追加します。

    • auth.alert - 即座に修正しなければならない状態についてのメッセージ

    • auth.crit - 致命的なメッセージ

    • auth.err - エラーメッセージ

    • auth.info - 情報通知用メッセージ

    • auth.debug - デバッグ用メッセージ

  2. syslog デーモンを再起動するか、SIGHUP シグナルをこのデーモンに送信して、PAM のエラー報告を有効にします。

例 - PAM のエラー報告を有効にする

次の例では、警戒メッセージはすべてコンソールに表示されます。致命的なメッセージは root に電子メールで送信されます。情報メッセージとデバッグ用メッセージは、/var/log/pamlog ファイルに追加されます。

auth.alert	/dev/console
auth.crit	'root'
auth.info;auth.debug	/var/log/pamlog

ログ内の各行は、タイムスタンプ、メッセージを生成したシステム名とメッセージ自身からなります。pamlog ファイルには、大量の情報が記録される可能性があります。