PAM 構成のリファレンス

言語:

このセクションでは、PAM に関する追加の詳細 (PAM スタックを含む) を提供します。

PAM 構成ファイル

PAM フレームワークを使用するシステムアプリケーション (login や ssh など) は、/etc/pam.d ディレクトリ内の PAM 構成ファイルで構成されます。また、/etc/pam.conf ファイルも使用できます。これらのファイルへの変更は、システム上のすべてのユーザーに影響を与えます。

さらに、/etc/security/pam_policy ディレクトリにも PAM 構成ファイルが保持されています。これらのファイルは複数のサービスを対象とし、またユーザーごとの割り当て用に設計されています。このディレクトリ内のファイルを変更してはいけません。

/etc/pam.d ディレクトリ – ワイルドカードファイル other を含む、サービス固有の PAM 構成ファイルが含まれています。アプリケーション用のサービスを追加するには、そのアプリケーションによって使用されているサービス名である 1 つの service-name ファイルを追加します。必要に応じて、アプリケーションは、other ファイル内の PAM スタックを使用できます。

/etc/pam.d ディレクトリ内のサービスファイルは、ほとんどの PAM 実装でのデフォルト構成を提供します。pkg(5) のマニュアルページで説明しているように、これらのファイルは IPS メカニズムを使用して自己アセンブルされます。このデフォルト設定により、ほかのクロスプラットフォームの PAM アプリケーションとの相互運用性が簡略化されます。詳細は、pam.conf(4) のマニュアルページを参照してください。
/etc/pam.conf ファイル – レガシー PAM 構成およびポリシーファイル。このファイルは、空で配信されます。PAM を構成するための推奨されるメカニズムは、/etc/pam.d ディレクトリ内のファイルの使用です。詳細は、pam.conf(4) のマニュアルページを参照してください。
/etc/security/pam_policy ディレクトリ – 複数のサービスのためのポリシーを含む PAM ポリシーファイルが含まれています。これらのファイルは、必要に応じて、個人、個人のグループ、またはすべてのユーザーに割り当てることができます。このような割り当ては、pam.conf または /etc/pam.d ディレクトリ内のシステム PAM 構成ファイルよりも優先されます。これらのファイルを変更しないでください。ユーザーごとのファイルを追加するには、サイト固有の PAM 構成ファイルを作成する方法を参照してください。ユーザーごとのファイルについては、pam_user_policy(5) のマニュアルページを参照してください。

セキュリティー管理者は、すべての PAM 構成ファイルを管理します。エントリの順序が正しくない、つまり PAM スタックが正しくないと、予期しない副作用が発生する場合があります。たとえば、不適切に構成されたファイルによってユーザーがロックアウトされ、修復のためにシングルユーザーモードが必要になることがあります。詳細は、PAM スタックおよびPAM 構成のエラーをトラブルシューティングする方法を参照してください。

PAM 構成の検索順序

アプリケーションが PAM フレームワークを呼び出すと、構成された PAM サービスが次の順序で検索されます。

サービス名が /etc/pam.conf ファイル内で検索されます。
特定のサービスが /etc/pam.d/service-name ファイル内で使用されています。
サービス名 other が /etc/pam.conf ファイル内でチェックされます。
/etc/pam.d/other ファイルが使用されます。

この順序によって、既存の /etc/pam.conf ファイルが /etc/pam.d ディレクトリ内のサービスごとの PAM 構成ファイルと連携できるようになります。

PAM 構成ファイルの構文

pam.conf ファイルと PAM ユーザーごとのファイルは、pam.d ディレクトリ内のサービス固有のファイルとは異なる構文を使用します。

/etc/pam.conf ファイルと /etc/security/pam_policy ファイル内のエントリの形式は、次の 2 つのうちのどちらかです。
```
service-name module-type control-flag module-path module-options
```
```
service-name module-type include path-to-included-PAM-configuration
```
/etc/pam.d ディレクトリ内の service-name ファイル内のエントリでは、サービス名が省略されます。各ファイルの名前がサービス名を指定します。
```
module-type control-flag module-path module-options
```
```
module-type include path-to-included-PAM-configuration
```

PAM 構成ファイルの構文の項目は次のとおりです。

service-name

サービスの大文字と小文字が区別されない名前 (login や ssh など)。アプリケーションは、自身が提供するサービスごとに異なるサービス名を使用できます。たとえば、sshd(1M) のマニュアルページで PAM という単語を検索して、sshd デーモンが提供するさまざまなサービスのサービス名を探します。

事前に定義されたサービス名「other」は、特定のサービス構成が提供されていない場合のデフォルトのサービス名です。

module-type

サービスのタイプ、つまり auth、account、session、または password を示します。

control-flag

サービスの成功または失敗の値の決定におけるモジュールの役割を示します。有効な制御フラグは、PAM スタックで説明されています。

module-path

そのモジュールタイプを実装するモジュールへのパス。パス名が絶対パスでない場合、そのパス名は、/usr/lib/security/$ISA/ の相対パスであると見なされます。$ISA マクロ (トークン) は、PAM フレームワークに対して、モジュールパスのアーキテクチャー固有のディレクトリ内を探すように指示します。

module-options

サービスモジュールに渡すことができる、nowarn や debug などのオプション。モジュールのマニュアルページでは、そのモジュールのオプションが説明されています。

path-to-included-PAM-configuration

/usr/lib/security ディレクトリを基準にした、PAM 構成ファイルまたはファイル名へのフルパスを指定します。

PAM スタック

アプリケーションが次のいずれかの関数を呼び出すと、PAM フレームワークは PAM 構成ファイルを読み取って、どのモジュールがこのアプリケーションの PAM サービス名を実装するかを決定します。

pam_authenticate(3PAM)
pam_acct_mgmt(3PAM)
pam_setcred(3PAM)
pam_open_session(3PAM)
pam_close_session(3PAM)
pam_chauthtok(3PAM)

構成ファイルに 1 つのモジュールしか含まれていない場合は、そのモジュールの結果によってこの操作の結果が決定されます。たとえば、passwd アプリケーションのデフォルトの認証操作には、/etc/pam.d/passwd ファイル内に 1 つのモジュール pam_passwd_auth.so.1 が含まれています。

auth required           pam_passwd_auth.so.1

これに対して、サービスが複数のモジュールで実装されている場合は、これらのモジュールをスタックと呼びます。つまり、そのサービス名に対して PAM スタックが存在します。たとえば、サンプルの /etc/pam.d/login サービス内のエントリを考えてみます。

auth definitive         pam_user_policy.so.1
auth requisite          pam_authtok_get.so.1
auth required           pam_unix_auth.so.1
auth required           pam_dhkeys.so.1
auth required           pam_unix_cred.so.1
auth required           pam_dial_auth.so.1

これらのエントリは、login サービス名の auth スタックを作成します。このスタックの結果を決定するには、個々のモジュールの結果コードに対して「統合プロセス」を実行する必要があります。

統合プロセスでは、各モジュールがファイル内の順序に従って実行されます。それぞれの成功または失敗コードが、モジュールの制御フラグに従って、全体的な結果に統合されます。制御フラグによっては、スタックの早期終了が発生する可能性があります。たとえば、requisite または definitive モジュールの失敗によってスタックが終了します。その前に失敗がない場合は、sufficient、definitive、または binding モジュールの成功によってもスタックが終了します。スタックが処理されたあと、個々の結果が、アプリケーションに配信される 1 つの全体的な結果に結合されます。フローの図解については、図 2および図 3を参照してください。

制御フラグは、成功または失敗の決定において PAM モジュールが果たす役割を示します。制御フラグとその効果は、次のとおりです。

binding – binding モジュールの要件を満たすことに成功すると、以前の失敗が記録されていない場合は、成功がただちにアプリケーションに返されます。これらの条件が満たされると、後続のモジュールは実行されません。

失敗すると、required 失敗が記録され、モジュールの処理が継続されます。
definitive – definitive モジュールの要件を満たすことに成功すると、以前の失敗が記録されていない場合は、成功がただちにアプリケーションに返されます。

以前の失敗が記録されている場合は、その失敗がただちにアプリケーションに返され、モジュールはそれ以上実行されません。失敗するとすぐにエラーが返され、後続のモジュールは実行されません。
include – 別の PAM 構成ファイルから、PAM スタック内のこの時点で使用される行を追加します。このフラグは成功または失敗の動作を制御しません。新しいファイルが読み取られると、PAM の include スタックが 1 増やされます。新しいファイル内でのスタックチェックが完了すると、include スタックの値が 1 減らされます。ファイルの最後に達したときに、PAM の include スタックが 0 である場合は、スタックの処理が終了します。PAM の include スタックの最大数は 32 です。
optional – optional モジュールの要件を満たすことに成功することは、サービスを使用するために必要ではありません。

失敗すると、optional 失敗が記録されます。
required – required モジュールの要件を満たすことに成功することは、スタックが成功するために必要です。スタックの最終的な成功が返されるのは、どの binding または required モジュールも失敗を報告しなかった場合だけです。

失敗すると、このサービスの残りのモジュールの実行完了後に、エラーが返されます。
requisite – requisite モジュールの要件を満たすことに成功することは、スタックが成功するために必要です。スタックがアプリケーションに成功を返せるようにするには、スタック内のすべての requisite モジュールが成功を返す必要があります。

失敗するとすぐにエラーが返され、後続のモジュールは実行されません。
sufficient – 以前のどの required の失敗も記録されていない場合は、sufficient モジュールが成功するとただちに成功が返され、モジュールはそれ以上実行されません。

失敗すると、optional 失敗が記録されます。

次の 2 つの接続図は、統合プロセスで結果がどのように決定されるかを示しています。

最初の図は、制御フラグのタイプごとに成功または失敗がどのように記録されるかを示しています。これらの結果は、2 番目の図に示されています。
2 番目の図は、統合された値の決定方法を示しています。optional の失敗と required の失敗は失敗を返し、成功は成功を返します。アプリケーションは、これらのリターンコードを処理する方法を決定します。

図 2 PAM スタック: 制御フラグの効果

image:このフロー図は、制御フラグが PAM スタックにどのような影響を与えるのかを示しています。

図 3 PAM スタック: 統合された値の決定方法

image:このフロー図は、PAM スタックにおける統合された値の決定方法を示しています。

PAM スタックの例

次の例は、サンプルの /etc/pam.d/other ファイル内の認証管理のためのデフォルトの定義を示しています。これらの定義は、サービス固有の認証定義が構成されていない場合に認証に使用されます。

##
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
auth definitive         pam_user_policy.so.1
auth requisite          pam_authtok_get.so.1
auth required           pam_dhkeys.so.1
auth required           pam_unix_auth.so.1
auth required           pam_unix_cred.so.1

最初に、pam_user_policy.so モジュールを使用して、ユーザーの PAM ポリシーがチェックされます。この時点ではほかのどのモジュールもチェックされていないため、definitive 制御フラグは、構成された PAM スタックの評価が成功した場合は成功がアプリケーションに返されることを示します。構成された PAM スタックの評価が失敗した場合は、失敗コードがアプリケーションに返され、それ以上のチェックは実行されません。このユーザーにユーザーごとの PAM ポリシーが割り当てられていない場合は、次のモジュールが実行されます。

このユーザーにユーザーごとの PAM ポリシーが割り当てられていない場合は、pam_authtok_get モジュールが実行されます。このモジュールの制御フラグは、requisite に設定されています。pam_authtok_get が失敗した場合は、認証プロセスが終了し、失敗がアプリケーションに返されます。

pam_authtok_get が失敗しなかった場合は、次の 3 つのモジュールが実行されます。個々の失敗が返されたかどうかには関係なく統合プロセスが続行されるように、これらのモジュールは required 制御フラグで構成されています。pam_unix_cred が実行されたあと、残っているモジュールはありません。この時点で、すべてのモジュールが成功した場合は、成功がアプリケーションに返されます。pam_dhkeys、pam_unix_auth、pam_unix_cred のいずれかが失敗を返している場合は、失敗がアプリケーションに返されます。

PAM サービスモジュール

このセクションでは、選択された PAM サービスモジュールを一覧表示します。モジュールはそれぞれのマニュアルページで一覧表示され、そのあとにいつ、どこで使用されるかに関する簡単な説明を示します。詳細は、マニュアルページを参照してください。

Oracle Solaris が提供するすべての PAM サービスモジュールのリストについては、各マニュアルページのセクション 5 を参照してください。新しいモジュールが定期的に追加されます。たとえば、このリリースでは、Windows システムでの認証のためのモジュールがいくつか追加されています。また、各サイトでサードパーティーの PAM モジュールを追加することもあります。

pam_allow(5)

すべての呼び出しに対して PAM_SUCCESS を返します。pam_deny(5) のマニュアルページも参照してください。

pam_authtok_check(5)

パスワード変更のためにパスワードトークンを検証します。

pam_authtok_get(5)