10.2. PAM 設定ファイルについて

PAM 対応アプリケーションまたは サービス はそれぞれ /etc/pam.d/ ディレクトリーにファイルがあり、これにはファイルがアクセスを制御するサービスと同じ名前が付けられています。たとえば、login プログラムはサービス名を login と定義し、/etc/pam.d/login という名前の PAM 設定ファイルをインストールします。

警告

PAM の設定には、PAM 設定ファイルを手動で編集するのではなく、authconfig ツールを使用することが強く推奨されます。

10.2.1. PAM 設定ファイルの書式

各 PAM 設定ファイルには、モジュール (認証設定エリア) を定義するディレクティブとその制御もしくは属性が含まれています。
ディレクティブの構文はすべて簡単なもので、モジュールの目的 (インターフェース) とモジュールの設定を特定します。 
module_interface	control_flag	module_name module_arguments
PAM 設定ファイルでは、モジュールインターフェースは以下のように最初のフィールドで定義されます。 
auth	required	pam_unix.so
PAM インターフェースとは、本質的にはその特定のモジュールが実行可能な認証アクションのタイプのことです。PAM モジュールインターフェースでは 4 つのタイプが利用可能で、それぞれが認証および承認プロセスの別の要素に対応しています。
  • auth — このモジュールインターフェースは、ユーザーを認証します。たとえば、パスワードの有効性を要求したり検証したりします。このインターフェースがあるモジュールは、グループメンバーシップといった認証情報も設定できます。
  • account — このモジュールインターフェースは、アクセスが許可されたことを確認します。たとえば、ユーザーアカウントの期限が切れたか、またはユーザーが 1 日の特定の時間にログインを許可されるかどうかをチェックします。
  • password — このモジュールインターフェースは、ユーザーのパスワード変更に使用されます。
  • session — このモジュールインターフェースは、ユーザーセッションを設定、管理します。このインターフェースのあるモジュールは、ユーザーのホームディレクトリーをマウントしたり、ユーザーのメールボックスを利用可能にするなど、アクセスの許可を必要とする追加タスクも実行できます。
個別のモジュールは、いずれかのインターフェース、またはすべてのインターフェースを提供できます。たとえば、pam_unix.so は 4 つすべてのモジュールインターフェースを提供します。
pam_unix.so といったモジュール名は、指定されたモジュールインターフェースのライブラリー名を PAM に提供します。ディレクトリー名は省略されています。アプリケーションが適切なバージョンの libpam にリンクされており、これがモジュールの適切なバージョンを見つけることができるためです。
PAM モジュールはすべて、呼び出されると成功か失敗の結果を生成します。制御フラグ が PAM に結果をどのように処理するかについて指示します。モジュールは特定の順番で記載することができ (スタック)、ユーザーのサービスへの認証全体において特定モジュールの成功もしくは失敗の重要性を制御フラグが判断します。
フラグには簡単なものがいくつかあり[2]、これらの設定にはキーワードのみを使用します。
  • required — 認証を継続するには、モジュール結果が成功する必要があります。この時点でテストが失敗すると、該当インターフェースを参照するすべてのモジュールテストの結果が完了するまでユーザーには通知されません。
  • requisite — 認証を継続するには、モジュール結果が成功する必要があります。ただし、この時点でテストが失敗するとユーザーに直ちに通知され、そのメッセージには最初に失敗した required または requisite モジュールテストが反映されます。
  • sufficient — モジュール結果は失敗した場合でも無視されます。ただし、sufficient のフラグの付いたモジュールが成功して、かつ required のフラグが付いたモジュールがそれまでに失敗していなければ、それ以上の結果は要求されず、ユーザーはサービスに認証されます。
  • optional — モジュール結果は無視されます。optional のフラグのついたモジュールは、他のモジュールが該当インターフェースを参照しない場合にのみ、認証成功に必要となります。
  • include — 他の制御とは違い、これはモジュール結果の処理には関係しません。このフラグは、特定パラメーターと合致する設定ファイル内のすべての行を取得し、それらを引数としてモジュールに追加します。
モジュールインターフェースのディレクティブは、重ねて配置することで スタック化 が可能なので、複数のモジュールをまとめて 1 つの目的に使用することができます。

注記

モジュールの制御フラグが sufficient または requisite の値を使用している場合、モジュールの記載順序は認証プロセスで重要になります。
スタックを使用する場合に、管理者はユーザーを認証するための固有の条件が必要になります。たとえば、setup ユーティリティーは通常、PAM 設定ファイルにあるように、複数のスタック化されたモジュールを使用します。 
[root@MyServer ~]# cat /etc/pam.d/setup

auth       sufficient	pam_rootok.so
auth       include	system-auth
account    required	pam_permit.so
session	   required	pam_permit.so
  • auth sufficient pam_rootok.so — この行は pam_rootok.so モジュールを使用して、現行ユーザーの UID が 0 であることを確認して、ユーザーが root かどうかをチェックします。テストが成功すると、他のモジュールは参照されず、コマンドが実行されます。テストが失敗すると、次のモジュールに移ります。
  • auth include system-auth — この行には /etc/pam.d/system-auth モジュールのコンテンツが含まれており、認証のためにこのコンテンツを処理します。
  • account required pam_permit.so — この行は pam_permit.so モジュールを使って、root ユーザーもしくはコンソールにログインしているユーザーがシステム再起動をできるようにします。
  • session required pam_permit.so — この行は、セッション設定に関するものです。pam_permit.so を使って setup ユーティリティーが失敗しないようにします。
PAM はいくつかのモジュール向けの認証中に 引数 を使って情報をプラグ可能なモジュールに渡します。
たとえば、pam_pwquality.so モジュールはパスワードの強度をチェックし、複数の引数を取ることができます。以下の例では、enforce_for_root で root ユーザーのパスワードでも強度チェックをパスする必要があることを指定し、retry でユーザーが強固なパスワードを 3 回入力できることを定義しています。 
password	requisite	pam_pwquality.so enforce_for_root retry=3
無効な引数は通常無視され、PAM モジュールの成功や失敗には影響しません。ただし、モジュールのなかには無効な引数で失敗するものもあります。ほとんどのモジュールはエラーを journald サービスに報告します。journald の使用方法と関連の journalctl ツールに関する情報は、『システム管理者のガイド』を参照してください。

注記

journald サービスは Red Hat Enterprise Linux 7.1 で導入されました。Red Hat Enterprise Linux の以前のバージョンでは、ほとんどのモジュールはエラーを /var/log/secure ファイルに報告します。

10.2.2. 注釈付きの PAM 設定例

例10.1「シンプルな PAM 設定」 は、PAM アプリケーション設定ファイルのサンプルです。

例10.1 シンプルな PAM 設定

#%PAM-1.0
auth		required	pam_securetty.so
auth		required	pam_unix.so nullok
auth		required	pam_nologin.so
account		required	pam_unix.so
password	required	pam_pwquality.so retry=3
password	required	pam_unix.so shadow nullok use_authtok
session		required	pam_unix.so
  • 最初の行は、行頭のハッシュ記号 (#) が示すように、コメントになります。
  • 2 行目から 4 行目は、ログイン認証用に 3 つのモジュールをスタックしています。
    auth required pam_securetty.so — このモジュールは、ユーザーが root としてログインしようとしており、/etc/securetty ファイルが存在している場合に、そのユーザーのログイン先の TTY が ファイルに記載されていることを確認します。
    TTY がファイルに記載されていない場合は、root としてログインしようとすると、Login incorrect メッセージが表示され、失敗します。
    auth required pam_unix.so nullok — このモジュールはユーザーにパスワードを要求し、/etc/passwd と、存在する場合は /etc/shadow に保存されている情報を使用して、パスワードを確認します。
    引数 nullok は pam_unix.so モジュールに空白のパスワードを許可するよう指示します。
  • auth required pam_nologin.so — これは認証の最終ステップです。/etc/nologin ファイルが存在するかどうかを確認します。このファイルが存在してユーザーが root でない場合は、認証に失敗します。

    注記

    この例では、最初の auth モジュールが失敗しても、3 つすべての auth モジュールが確認されます。これにより、どの段階で認証に失敗したかをユーザーに知らせずに済みます。この情報が攻撃者の手に渡ると、システムの攻撃方法がより簡単に推測されてしまいます。
  • account required pam_unix.so — このモジュールは、必要なアカウント確認を実行します。たとえば、シャドウパスワードが有効になっていると、pam_unix.so モジュールのアカウントインターフェースはアカウントの有効期間が切れているかどうか、またはユーザーが許可されている猶予期間内にパスワードを変更していないかを確認します。
  • password required pam_pwquality.so retry=3 — パスワードの有効期間が切れている場合は、pam_pwquality.so モジュールのパスワードコンポーネントが新たなパスワードを要求します。そして、新規に作成されたパスワードが辞書ベースのパスワード解読プログラムで容易に判断できるかどうかをテストします。
    引数 retry=3 は、テストに 1 回失敗しても、ユーザーは強固なパスワードを作成する機会があと 2 回あることを示しています。
  • password required pam_unix.so shadow nullok use_authtok — この行は、pam_unix.so モジュールの password インターフェースを使って、プログラムがユーザーのパスワードを変更するかどうかを指定します。
    • 引数 shadow は、ユーザーのパスワード更新の際にシャドウパスワードを作成するようモジュールに指示します。
    • 引数 nullok は、ユーザーが空白のパスワード から 変更できるようにし、それ以外の場合は null パスワードをアカウントロックとして扱うようモジュールに指示します。
    • この行の最後の引数 use_authtok は、PAM モジュールのスタック化の際における順序の重要性の例を提供します。この引数は、ユーザーに新規パスワードを要求しないようモジュールに指示します。代わりに、以前のパスワードモジュールが記録したパスワードを受け入れます。これにより、新規パスワードはすべて、受け入れ前にパスワードの安全テスト pam_pwquality.so をパスする必要があります。
  • session required pam_unix.so — 最後の行は、pam_unix.so モジュールのセッション引数にセッションを管理するよう指示します。このモジュールはユーザー名とサービスタイプを各セッションの最初と最後に /var/log/secure に記録します。このモジュールは他のセッションモジュールとスタック化した追加機能を補うことができます。

[2] 設定可能な制御フラグには複雑なものもあります。これらは、属性=値 のペアで設定します。属性の完全な一覧は、pam.d の man ページで確認できます。
このページには機械翻訳が使用されている場合があります (詳細はこちら)。