PAM の構成 (参照)

PAM サービスを使用する (ssh などの) システムアプリケーションは、PAM 構成ファイルで構成されます。詳細は、pam.conf(4) のマニュアルページを参照してください。これらの構成ファイルには、/etc/pam.conf ファイルや、/etc/pam.d 内に配置されているサービス固有のファイルが含まれています。これらのファイルへの変更は、システム上のすべてのユーザーに影響を与えます。サービス固有の PAM 構成ファイルは、その粒度のために、ファイル内に誤りがあってもそのサービスにしか影響を与えないため、PAM を構成するための推奨されるメカニズムです。また、新しい PAM サービスの追加も 1 つのファイルのコピーに簡略化されます。/etc/pam.d はほとんどの PAM 実装でデフォルト構成になっているため、サービス固有のファイルにより、ほかのクロスプラットフォーム PAM アプリケーションとの相互運用性を向上させることができます。

さらに、PAM ポリシーファイルを使用すると、個々のサービスの認証ポリシーを作成し、必要に応じて、これらのポリシーを個人、個人のグループ、すべてのユーザーのいずれかに割り当てることができます。デフォルトの PAM ポリシーファイルは、/etc/security/pam_policy にあります。PAM ポリシーファイルは、1 人または複数のユーザーの認証ポリシーを安全で、信頼性の高い方法で設定または変更する機能を提供します。

システム管理者は、PAM 構成ファイルを管理します。これらのファイル内のエントリの順番が間違っていると、予期しない副作用が発生する場合があります。たとえば、ファイルの構成が不適切であると、ユーザーがロックアウトされ、修復のためにシングルユーザーモードが必要になる場合があります。順番の設定方法については、「PAM スタックのしくみ」を参照してください。

PAM 構成の検索順序

PAM 構成ファイル内の PAM 構成情報は、次の順序で PAM ライブラリによって収集されます。

/etc/pam.conf 内でサービス名が検索されます。
/etc/pam.d/service がチェックされます。
/etc/pam.conf 内でサービス名 other がチェックされます。
/etc/pam.d/other ファイルがチェックされます。

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

PAM 構成ファイルの構文

/etc/pam.conf ファイルと PAM ポリシーファイルは、サービス固有のファイルとは異なる構文を使用します。次に、これらの各ファイルの構文について説明します。

/etc/pam.conf ファイルまたは PAM ポリシーファイル内のエントリの形式は次のいずれかです。

service-name module-type control-flag module-path module-options

service-name module-type include path-to-included-PAM-configuration

service-name

サービスの大文字小文字を区別しない名前。たとえば、login や passwd などです。アプリケーションは、自身が提供するサービスごとに異なるサービス名を使用できます。たとえば、Oracle Solaris Secure Shell デーモンが使用するサービス名は次のとおりです。sshd-none、 sshd-password、 sshd-kbdint、 sshd-pubkey、 sshd-hostbased。

サービス名 other は、ワイルドカードのサービス名として使用される、事前に定義された名前です。特定のサービス名が構成ファイル内で見つからない場合は、other の構成が使用されます。

module-type

サービスのタイプ。具体的には auth、account、session、password のいずれかです。

control-flag

サービスの統合された成功または失敗の値を決定するうえで、そのモジュールの果たす役割を示します。有効な制御フラグは、binding、 definitive、 include、 optional、 required、 requisite、および sufficient です。制御フラグの使用方法については、「PAM スタックのしくみ」を参照してください。

module-path

サービスを実装しているライブラリオブジェクトへのパス。パス名が絶対パスでない場合、そのパス名は /usr/lib/security/$ISA/ に対する相対パスとみなされます。libpam による検索が、アプリケーションの特定のアーキテクチャーに対するディレクトリ内で行われるように、アーキテクチャーに依存するマクロ $ISA を使用します。

module-options

サービスモジュールに渡されるオプション。各モジュールのマニュアルページには、そのモジュールで使用できるオプションの説明があります。標準的なモジュールオプションには、nowarn や debug などがあります。

path-to-included-PAM-configuration

個別の PAM 構成ファイルへのフルパスか、または /usr/lib/security ディレクトリに相対的なパス名を指定します。

/etc/pam.d にあるサービスごとの構成ファイルは pam.conf と同じ構文を使用しますが、サービス名は含まれていません。サービスごとの構成ファイルを使用している場合は、そのファイルの名前がサービス名です。たとえば、/etc/pam.d/cron には、cron コマンドの PAM 構成が含まれています。

ユーザーごとの認証ポリシー

pam_user_policy PAM モジュールを使用すると、システム管理者は、ユーザーごとに PAM 構成を指定できます。ユーザーの pam_policy 鍵は、ユーザー固有の PAM 構成ファイルへのパスを提供する必要があります。詳細は、pam_user_policy(5) のマニュアルページを参照してください。

ユーザーごとの認証ポリシーを確立するためのいくつかの方法を次に示します。

ユーザーの新しい PAM ポリシーファイルを作成してから、usermod コマンドを使用してそのポリシーをユーザーに割り当てます。この手順は、「ユーザーにカスタマイズされた PAM ポリシーを割り当てる方法」で説明されています。
usermod コマンドを使用して、事前に定義されたポリシーをユーザーに割り当てます。
usermod コマンドの -P オプションを使用して、pam_policy 鍵を含む権利プロファイルをユーザーに割り当てます。
pam_policy 鍵を /etc/security/policy.conf 内の PROFS_GRANTED 鍵に追加することによって、その鍵を含む権利プロファイルをすべてのユーザーに割り当てます。この手順は、「すべてのユーザーに新しい権利ポリシーを割り当てる方法」で説明されています

PAM スタックのしくみ

アプリケーションが次のいずれかの関数を呼び出すと、libpam は PAM 構成ファイルを読み取って、どのモジュールがこのサービスの操作に参加するかを決定します。

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

passwd  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 モジュールが成功したりする可能性があります。スタックの処理が完了すると、個々の結果が組み合わされて単一の総合結果が算出され、それがアプリケーションに渡されます。

制御フラグは、サービスへのアクセスを決定するうえで PAM モジュールが果たす役割を示します。制御フラグとその効果は、次のとおりです。

binding – binding モジュールの要件を満たすことに成功すると、以前のどの required モジュールも失敗していない場合は、成功がただちにアプリケーションに返されます。これらの条件が満たされると、後続のモジュールは実行されません。失敗すると、required 失敗が記録され、モジュールの処理が継続されます。
definitive – definitive モジュールの要件を満たすことに成功すると、以前のどの required モジュールも失敗していない場合は、成功がただちにアプリケーションに返されます。以前の required モジュールが失敗した場合は、モジュールをそれ以上実行せずに、その失敗がただちにアプリケーションに返されます。失敗するとすぐにエラーが返され、後続のモジュールは実行されません。
include – この時点で使用される個別の PAM 構成ファイルの行を PAM スタック内に追加します。このフラグは成功または失敗の動作を制御しません。新しいファイルが読み取られると、PAM のインクルードスタックが 1 増やされます。新しいファイル内でのスタックチェックが完了すると、インクルードスタック値が 1 減らされます。ファイルの末尾に到達し、かつ PAM インクルードスタックが 0 であれば、スタック処理は終了します。PAM インクルードスタックの最大数は、32 です。
optional – optional モジュールの要件を満たすことに成功することは、サービスを使用するために必要ではありません。失敗すると、optional 失敗が記録されます。
required – required モジュールの要件を満たすことに成功することは、サービスを使用するために必要です。失敗すると、このサービスの残りのモジュールの実行完了後に、エラーが返されます。サービスの最終的な成功が返されるのは、binding または required モジュールがどれも失敗を報告しなかった場合だけです。
requisite – requisite モジュールの要件を満たすことに成功することは、サービスを使用するために必要です。失敗するとすぐにエラーが返され、後続のモジュールは実行されません。あるサービスのすべての requisite モジュールが成功を返さないと、この機能がアプリケーションに成功を返すことができません。
sufficient – 以前のどの required の失敗も発生していない場合は、sufficient モジュールが成功すると、モジュールをそれ以上実行せずに成功がただちにアプリケーションに返されます。失敗すると、optional 失敗が記録されます。

次の 2 つの図は、統合プロセスでアクセスがどのように決定されるかを示しています。最初の図は、制御フラグのタイプごとに成功または失敗がどのように記録されるのかを示しています。2 番目の図は、統合された値の決定方法を示しています。

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

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

図 14-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 モジュールを使用して、ユーザーのセキュリティーポリシーがチェックされます。definitive 制御フラグは、この時点ではほかのどのモジュールもチェックされていないため、セキュリティーポリシーの評価が成功した場合はサービスがアプリケーションに成功を返すことを選択します。リクエストが失敗した場合は、失敗メッセージがアプリケーションに送信され、それ以上のチェックは実行されません。ユーザーに対してポリシーが設定されていない場合は、次のモジュールが実行されます。

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

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

ナビゲーションリンクをスキップ
印刷ビューの終了
	Oracle Solaris 11.1 の管理: セキュリティーサービス Oracle Solaris 11.1 Information Library (日本語)