第 3 章 認証サービスの使用 (手順)

この章では、最初に Secure RPC で使用できる Diffie-Hellman 認証メカニズムについて説明します。次に、Pluggable Authentication Module (PAM) フレームワークについて説明します。PAM は、認証サービスを「プラグイン」する方法を提供して、複数の認証サービスを使用できるようにします。

この章で説明する内容は次のとおりです。

• 「Secure RPC の概要」

• 「Diffie-Hellman 認証の管理」

• 「PAM (概要)」

• 「PAM (手順)」

• 「PAM (参照)」

Secure RPC の概要

Secure RPC は、サービスを要求するホストとユーザーを認証するための認証方式です。Secure RPC では、Diffie-Hellman 認証メカニズムを使用しています。この認証メカニズムは 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 とも呼びます。

• Secure NFS の設定と管理については、『Solaris のシステム管理 (資源管理とネットワークサービス)』の「Secure NFS システムの管理」を参照してください。

• NIS+ テーブルの設定と cred テーブルへの名前の入力については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。

• RPC 認証手順の概要については、「Diffie-Hellman 認証の実装」を参照してください。

DES 暗号化

データ暗号化規格 (Data Encryption Standard、DES) 暗号化機能は 56 ビットの鍵を使用して、データを暗号化します。資格を持つ 2 人のユーザー (プリンシパル) が同じ DES 鍵を知っている場合、その鍵を使用してテキストを暗号化または復号化することによって、プライベートに通信できます。DES は比較的高速な暗号化メカニズムです。DES チップは暗号化をより高速にします。ただし、チップがなくても、ソフトウェアで代用できます。

DES 鍵を使用する上での問題点は、同じ鍵で暗号化された多数のテキストメッセージを侵入者が収集することによって、鍵が発見されメッセージが解読される危険性があるということです。このため、Secure NFS などのセキュリティシステムは鍵を頻繁に変更します。

Kerberos 認証

Kerberos は、マサチューセッツ工科大学 (MIT) で開発された認証システムです。Kerberos は DES 暗号を使用します。Kerberos V4 は、Secure RPC ではサポートされていません。クライアント側には、RPCSEC_GSS を使用する Kerberos V5 がこのリリースに実装されています。詳細は、第 6 章「SEAM について」を参照してください。

Diffie-Hellman 認証

Diffie-Hellman (DH) のユーザー認証方式は簡単には破られません。クライアントとサーバーは、それぞれ独自の非公開鍵 (秘密鍵とも呼ぶ) を持っていて、共通鍵が利用できるように公開鍵と組み合わせて使用します。クライアントとサーバーはお互いにこの共通鍵を使用し、両者で合意された暗号化機能および復号化機能 (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 トランザクションを開始するのを待機します。

ログインパスワードと RPC パスワードが一致している場合は、ログインプロセスは秘密鍵をキーサーバーに渡します。これらのパスワードが異なり、ユーザーが常に keylogin コマンドを実行する必要がある場合は、keylogin コマンドをユーザーの環境構成ファイル ( ~/.login、 ~/.cshrc、~/.profile ファイルなど) に設定することができます。この場合、ユーザーがログインしたときに、keylogin コマンドが自動的に実行されます。

対話鍵の生成

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

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

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

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

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

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

サーバーとの最初の接触

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

• クライアントのネット名

• 共通鍵で暗号化された対話鍵

• 対話鍵で暗号化された「ウィンドウ」

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

クライアントベリファイアは、次の要素で構成されます。

• 暗号化されたタイムスタンプ

• 指定したウィンドウの暗号化されたベリファイアから 1 を引いた値

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

対話鍵の復号化

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

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

2. キーサーバーは、クライアントの公開鍵とサーバーの秘密鍵を使用して、共通鍵を計算します。この共通鍵はクライアントが計算したものと同じです。共通鍵の計算は、秘密鍵を知っている必要があるため、そのサーバーとクライアント以外は計算できません。

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

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

サーバーへの格納情報

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

• クライアントのコンピュータ名

• 対話鍵

• ウィンドウ

• クライアントのタイムスタンプ

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

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

ベリファイアをクライントに返す

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

• サーバーが自分の資格キャッシュに記録するインデックス ID

• クライアントのタイムスタンプから 1 を引いた値。対話鍵によって暗号化される

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

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

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

追加のトランザクション

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

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 のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。

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 <Return キーを押す>

Warning, password differs from login password.
Retype password: xxx <Return キーを押す>
 
# keylogin
Password:
#

Diffie-Hellman 認証のために NIS+ の資格を使用する新しいユーザー鍵を設定する方法

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

   # nisaddcred -p unix.UID@domain-name -P username.domain-name. des

   この場合、username.domain-name の終わりにピリオド (.) を付けてください。

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

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

次の例では、george という名前のユーザーに対して、DES セキュリティ承認を許可します。

# 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+ の資格を使用して root 鍵を設定する方法

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.
#

Diffie-Hellman 認証と NIS+ の資格を使用する新しいユーザー鍵を設定する方法

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-Hellman 認証でファイルを共有およびマウントする方法

前提条件

Diffie-Hellman の publickey 認証がネットワークで有効である必要があります。「Diffie-Hellman 認証のために NIS+ の資格の鍵を設定する方法」と 「Diffie-Hellman 認証と NIS+ の資格を使用して root 鍵を設定する方法」を参照してください。

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 認証でファイルシステムをマウントします。

PAM (概要)

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

PAM を使用する利点

PAM を使用すると、ユーザー認証用のシステムエントリサービス (ftp、login、telnet、rsh など) を任意に組み合わせて選択することができます。PAM には次の利点があります。

• 柔軟な構成ポリシー

  • アプリケーションごとの認証ポリシー

  • デフォルトの認証メカニズムを選択する機能

  • 高度なセキュリティシステムにおける複数のパスワード

• 一般ユーザーにも使いやすい

  • メカニズムが異なってもパスワードが同じであれば、パスワードを再入力する必要がない

  • 各認証方式に関連するパスワードが異なっている場合でも、パスワードの割り当て機能により、複数の認証方法に単一のパスワードを使用できる

  • ユーザーが複数のコマンドを入力しなくても、複数の認証方式のパスワードを求めるプロンプトを表示できる

• オプションパラメタをユーザー認証サービスに渡す機能

PAM の構成要素

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

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

図 3-1 PAM の動作

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

次の節では、PAM の構成要素とアプリケーションの関係について説明します。

PAM ライブラリ

PAM ライブラリ /usr/lib/libpam は、適切なモジュールをロードして、スタックプロセスを管理するためのフレームワークを提供します。また、すべてのモジュールがプラグインできる汎用構造になっています。

スタッキング機能

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

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

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

Solaris 9 リリースにおける PAM への変更

Solaris 9 では、PAM サービスがいくつかの点で拡張されています。ここでは、最も重要な変更点について説明します。

• スタッキングを適切に行うために、pam_unix モジュールが個々の単一サービスモジュールに分割されました。これらのモジュールの機能は、既存のモジュールと同等です。これらは、pam_authtok_get、pam_authtok_check、 pam_authtok_store、pam_unix_auth、 pam_dhkeys、および pam_passwd_auth のモジュールで提供されます。新しいモジュールについては、「PAM モジュール」を参照してください。

• 新しい PAM サービスとして、cron、 dtsession、ppp、および ssh が含まれました。新しいサービスについては、「有効なサービス名」を参照してください。

• PAM 構成ファイルが、新しいモジュールとサービスを含むよう更新されました。構成ファイルについては、「一般的な pam.conf ファイル」を参照してください。

PAM (手順)

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

PAM (作業マップ)

PAM の計画

ユーザーの環境に最適な PAM の使用方法を決定するために、次の問題から始めます。

• 何が必要か、特にどのモジュールを選択するかを決定する

• 特別な注意が必要なサービスを確認する。適宜、OTHER を使用する

• モジュールを実行する順番を決定する

• 各モジュールに対する制御フラグを選択する

• 各モジュールに必要なオプションを選択する

ここで、PAM 構成ファイルを変更する前に次のことを考慮することをお勧めします。

• すべてのアプリケーションを指定しなくてもいいように、モジュールタイプごとに OTHER エントリを使用する

• sufficient 制御フラグと optional 制御フラグのセキュリティへの影響を確認する

• モジュールに関連するマニュアルページを参照して、各モジュールの機能、使用できるオプション、およびスタック中のモジュール間の相互作用について理解する

  ---

  注意 -

  PAM 構成ファイルの構成を間違えたり壊したりすると、スーパーユーザーでもログインできなくなる可能性があります。この場合、sulogin コマンドは PAM を使用しないので、スーパーユーザーは、マシンをシングルユーザーモードでブートして問題を解決する必要があります。

  ---

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

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

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

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

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

   Solaris 8 の場合は、/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 シグナルを syslog デーモンに送信して、PAM のエラー報告を有効にします。

例 - PAM のエラーレポートを開始する

次の例では、すべての警告メッセージを画面に表示します。致命的なメッセージはスーパーユーザーに電子メールで送信されます。情報メッセージとデバッグ用メッセージは、/var/log/pamlog ファイルに追加されます。

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

ログ内の各行は、タイムスタンプ、メッセージを生成したシステム名、およびメッセージ本体で構成されます。pamlog ファイルには、大量の情報が記録される可能性があります。

PAM (参照)

PAM は、実行時に取り外しが可能なモジュールを使用して、システムエントリサービスの認証を提供します。これらのモジュールは、その機能に基づき、4 つの異なるタイプに分かれます。

• 認証

• アカウント管理

• セッション管理

• パスワード管理

スタッキング機能を利用すると、複数のサービスを使用してユーザーを認証できます。また、パスワードマッピング機能を利用すると、ユーザーは複数のパスワードを覚える必要がなくなります。

PAM モジュール

各 PAM モジュールは、特定のメカニズムを実装します。PAM 認証を設定するときは、モジュールとモジュールタイプの両方を指定する必要があります。モジュールタイプは、モジュールが実行する処理を定義します。複数のモジュールタイプ (認証、アカウント管理、セッション管理、またはパスワード管理) を各モジュールに関連付けることができます。

次の表では、各 PAM モジュールについて、モジュール名、モジュールファイル名、および説明を示します。各モジュールのパスは、インストールされている Solaris で使用できる命令によって異なります。モジュールのデフォルトのパスは、/usr/lib/security/ $ISA です。$ISA の値は、sparc または i386 です。詳細は、isalist(5) のマニュアルページを参照してください。

セキュリティ上の理由から、これらのモジュールファイルの所有者は root である必要があり、また、group と other に書き込み権があってはなりません。ファイルの所有者が root でない場合、PAM はモジュールをロードしません。

PAM モジュールのタイプ

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

• 「認証モジュール」は、ユーザーの認証を提供して、資格を設定、更新、または削除する。認証モジュールは、ユーザーを識別するための管理ツールを提供する。

• 「アカウントモジュール」は、パスワードの有効期限、アカウントの有効期限、およびアクセス時間制限を確認する。アカウントモジュールは、認証モジュールでユーザーを識別したあと、そのユーザーにアクセス権を与えるべきかどうかを決定する。

• 「セッションモジュール」は、認証セッションの開閉を管理する。セッションモジュールは、動作を記録したり、セッション終了後のクリーンアップを実行したりできる。

• 「パスワードモジュール」によって、実際のパスワードを変更する。

PAM 構成ファイル

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

PAM 構成ファイルの構文

PAM 構成ファイルは、次の構文のエントリで構成されます。

service_name module_type control_flag module_path module_options

pam.conf ファイルにコメントを追加するには、コメント行の最初に # (ポンド記号) を入力します。フィールドを区切るには、空白またはタブを使用します。

行のフィールド数が 4 つ未満の場合、module_type または control_flag に無効な値が指定されている場合、または指定したモジュールが存在しない場合は、PAM 構成ファイル内のエントリは無視されます。

有効なサービス名

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

各サービスに対して、すべてのモジュールタイプを適用できるわけではありません。たとえば、password モジュールタイプは、passwd コマンドだけに適用できます。また、passwd コマンドは認証と関連がないため、このコマンドに関連付けられた auth モジュールタイプはありません。

制御フラグ

認証プロセス中のモジュールの動作 (続行または失敗) を決定するには、PAM 構成ファイル /etc/pam.conf の各エントリに対して、4 つの制御フラグのいずれかを選択する必要があります。制御フラグは、各モジュールで成功と失敗がどのように処理されるかを示します。これらのフラグはすべてのモジュールに適用されますが、次の説明では、これらのフラグは認証モジュールで使用されていると仮定します。制御フラグは、次のとおりです。

• required - 認証が成功するには、この制御フラグを適用したモジュールが成功する必要があります。

  すべてのモジュールに required フラグを付けた場合、ユーザーの認証が成功するには、すべてのモジュールの認証が成功する必要があります。

  一部のモジュールが失敗した場合、最初に失敗したモジュールのエラー値が報告されます。

  required フラグを付けたモジュールが失敗しても、スタック中のすべてのモジュールは継続して処理されますが、失敗が返されます。

  どのモジュールにも required フラグを付けなかった場合、ユーザーの認証が成功するには、そのサービスの少なくとも 1 つのエントリが成功する必要があります。

• requisite - 後続の認証を続行するには、この制御フラグを適用したモジュールが成功する必要があります。

  requisite フラグの付いたモジュールが失敗した場合、すぐにエラーがアプリケーションに返され、それ以上認証は行われません。スタック中で、このモジュールより前に required というラベルの付いたモジュールが失敗していなければ、このモジュールからのエラーが返されます。このモジュールより前に、required というラベルの付いたモジュールが失敗している場合は、required モジュールからのエラーメッセージが返されます。

• optional - この制御フラグを適用したモジュールが失敗した場合、このスタック内の他のモジュールが成功を返せば、最終的に成功になります。

  optional 制御フラグは、ユーザーを認証するにはスタック内の他のモジュールのどれかが成功すれば十分であるという場合に使用します。このフラグは特定のモジュールが成功するということがそれほど重要でない場合に使用します。

  ユーザーが作業を行う上で、特定のメカニズムでアクセス権を取得する必要がある場合はこのフラグを使用しないでください。

• sufficient - この制御フラグを適用したモジュールが終了した場合、スタック内の残りのモジュールはスキップされます。この場合、required フラグを適用したモジュールも省略されます。

  sufficient 制御フラグは、1 つの認証が成功すると、ユーザーにアクセス権を与えてもかまわないことを示します。

これらの制御フラグの詳細については、次の節を参照してください。次の節では、デフォルトの /etc/pam.conf ファイルについて説明します。

一般的な pam.conf ファイル

一般的な /etc/pam.conf ファイルには、次の動作が指定されています。

1. login コマンドを実行したときは、pam_authtok_get、pam_dhkeys 、pam_auth_unix、および pam_dial_auth モジュールの認証が成功する必要があります。

2. rlogin コマンドを実行したときは、pam_rhost_auth の認証に失敗した場合、pam_authtok_get、pam_dhkeys、および pam_auth_unix モジュールの認証が成功する必要があります。

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

4. 認証を必要とするその他のコマンドが実行されたときは、ほとんどの場合、pam_authtok_get、 pam_dhkeys、および pam_auth_unix モジュールの認証が成功する必要があります。

5. rsh コマンドが実行されたときは、pam_rhost_auth モジュールの認証には sufficient フラグが適用されます。pam_rhost_auth モジュールの認証が成功した場合は、それ以外の認証は必要ありません。

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

通常、module_path のエントリには「ルートからのパス名」を指定します。module_path に入力したファイル名がスラッシュ (/) で始まらない場合、そのファイル名の前にパス /usr/lib/security/$ISA が付きます。モジュールが他のディレクトリにある場合は、フルパスを使用する必要があります。module_options の値は、そのモジュールのマニュアルページに記載されています。たとえば、UNIX モジュールは、pam_unix(5) のマニュアルページに記載されています。

login   auth required           pam_authtok_get.so.1
login   auth required           pam_dhkeys.so.1
login   auth required           pam_unix_auth.so.1
login   auth required           pam_dial_auth.so.1

この例の login サービスでは、4 つの認証モジュールの認証がすべて必須になっています。login コマンドは、いずれかのモジュールからエラーが返されると失敗します。