Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

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

PAM 対応アプリケーションまたはサービスにはそれぞれ 、/etc/pam.d/ ディレクトリーにファイルがあります。このディレクトリーの各ファイルは、アクセスを制御するサービスと同じ名前を持ちます。たとえば、ログインプログラムはサービス名を ログインとして定義し 、/etc/pam.d/login PAM 設定ファイルをインストールします。
警告
PAM 設定ファイルを手動で編集するのではなく、authconfig ツールを使用して PAM を設定する方法は強く推奨されます。

10.2.1. PAM 設定ファイル形式

各 PAM 設定ファイルには、モジュール (認証設定エリア) を定義するディレクティブとその制御もしくは属性が含まれています。
ディレクティブはすべて簡単な構文で、モジュールの目的（インターフェース）とモジュールの設定を特定します。 
module_interface	control_flag	module_name module_arguments
PAM 設定ファイルでは、モジュールインターフェースは定義されている最初のフィールドです。以下に例を示します。 
auth	required	pam_unix.so
PAM インターフェースは、基本的に特定のモジュールを実行できる認証アクションのタイプです。4 種類の PAM モジュールインターフェースが利用できます。それぞれは、認証および承認プロセスのさまざまな要素に対応します。
  • auth: このモジュールインターフェースはユーザーを認証します。たとえば、パスワードの有効性を要求し、検証します。このインターフェースのあるモジュールは、グループメンバーシップなどの認証情報を設定することもできます。
  • account: このモジュールインターフェースは、アクセスが許可されることを確認します。たとえば、ユーザーアカウントの有効期限が切れたか、または特定の時間にユーザーがログインできるかどうかを確認します。
  • Password: このモジュールインターフェースは、ユーザーパスワードの変更に使用されます。
  • Session: このモジュールインターフェースは、ユーザーセッションを設定および管理します。このインターフェースのあるモジュールは、ユーザーのホームディレクトリーをマウントしたり、ユーザーのメールボックスを利用可能にするなど、アクセスを許可するために必要な追加のタスクも実行できます。
個別のモジュールは、いずれかのインターフェースまたはすべてのモジュールインターフェースを提供できます。たとえば、pam_unix.so は、4 つのモジュールインターフェースを提供します。
pam_unix.so などのモジュール名は、PAM を、指定されたモジュールインターフェースを含むライブラリーの名前を指定します。アプリケーションが適切なバージョンの libpam にリンクされているため、ディレクトリー名は省略されます。
すべての PAM モジュールは、呼び出されると成功または失敗の結果を生成します。コントロールフラグは結果に基づいて PAM に指示します。モジュールは特定の順序で一覧表示（スタック）でき、制御フラグは特定モジュールの成功または失敗の重要性を判断し、ユーザーをサービスに対して認証する際の全体的な目標を決定します。
単純なフラグがいくつかあります。[2]: キーワードを使用して設定を設定します。
  • required - 認証を継続するには、モジュール結果が成功する必要があります。この時点でテストが失敗すると、そのインターフェースを参照するすべてのモジュールテストの結果が完了するまでユーザーには通知されません。
  • requisite - 認証を継続するには、モジュール結果が成功する必要があります。ただし、この時点でテストが失敗すると、最初の失敗したモジュールまたは 必須の モジュールテストを反映したメッセージとともに、すぐにユーザーに通知されます。
  • sufficient - モジュール結果は、失敗すると無視されます。ただし、モジュールフラグを設定したモジュールの結果が正常で 、それにフラグを設定した以前の モジュールに必要ない場合には、他の結果は不要で、ユーザーはサービスに認証されます。
  • オプション: モジュール結果は無視されます。その他のモジュールがインターフェイスをを参照しない場合に認証成功に必要となるのは、オプションとしてフラグが付いたモジュールです。
  • include: 他のコントロールとは異なり、モジュールの結果の処理方法とは関係ありません。このフラグは、指定のパラメーターに一致する設定ファイルのすべての行でプルし、それらをモジュールに引数として追加します。
モジュールインターフェースのディレクティブは、スタック化するか、または別の場所に配置することができます。したがって、複数のモジュールをまとめて 1 つの目的に使用することができます。
注記
モジュールの制御フラグで十分の値または 必須の値が使用される場合、モジュールの一覧表示順序は認証プロセスで重要になります。
スタッキングを使用すると、ユーザーの認証を許可する前に、特定の条件が存在する必要があります。たとえば、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 enough 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 ユーザーのパスワードも強度チェックをパスして、再試行で強固なパスワードを入力するためにユーザーが 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 としてログインしようとしている TTY で、ユーザーがログインしている TTY が /etc/securetty ファイル （このファイルが存在する場合に ）に一覧表示されます。
    TTY がファイルに一覧表示されていない場合、root でログインしようとすると、Login incorrect メッセージが表示されます。
    auth required pam_unix.so nullok - このモジュールはユーザーにパスワードを要求し、/etc/passwd に保存された情報を使用してパスワードを確認します（存在する場合は /etc/shadow ）。
    引数は、pam_unix.so モジュールに、空のパスワードを許可するように指示します。
  • auth required pam_nologin.so: これは最終認証手順です。これは、/etc/nologin ファイルが存在するかどうかを確認します。ユーザーが存在して root でない場合は、認証に失敗します。
    注記
    この例では、最初の認証モジュールが失敗しても、3 つの認証モジュールがすべてチェックされます。これにより、ユーザーは認証に失敗したステージを把握できません。攻撃者のこのような知識により、システムのクラッキング方法がより簡単に推測される可能性があります。
  • 必要な pam_unix.so: このモジュールは、必要なアカウントの検証を実行します。たとえば、シャドウパスワードが有効になっていると、pam_unix.so モジュールのアカウントインターフェースが、アカウントの有効期限が切れたか、許可される猶予期間内にユーザーがパスワードを変更していないかどうかを確認します。
  • Password required pam_pwquality.so retry=3: パスワードの期限が切れている場合、pam_pwquality.so モジュールのパスワードコンポーネントは新しいパスワードを要求します。次に、新たに作成されたパスワードをテストして、辞書ベースのパスワードクラッキングプログラムで簡単に判別できるかどうかを確認します。
    引数 retry=3 は、テストに初めて失敗した場合、ユーザーは強固なパスワードを作成する機会が 2 つあります。
  • Password required pam_unix.so shadow nullok use_authtok: この行は、プログラムが pam_unix.so モジュールのパスワードインターフェースを使用して、プログラムがユーザーのパスワードを変更するかどうかを指定します。
    • 引数シャドウは、ユーザーのパスワード更新の際にシャドウパスワードを作成するようモジュールに指示します。
    • 引数は nullok で、ユーザーがパスワードを空のパスワードから変更できるようにするようモジュールに指示します。それ以外の場合は、null パスワードはアカウントロックとして処理されます。
    • この行の最後の引数 use_authtok は、PAM モジュールをスタックする際に順序の重要性を示す優れた例を提供します。この引数は、ユーザーに新しいパスワードを要求しないようにモジュールに指示します。代わりに、以前のパスワードモジュールで記録されたパスワードを受け入れます。これにより、新しいパスワードはすべて、受け入れられる前に安全なパスワードの pam_pwquality.so テストを通過する必要があります。
  • session required pam_unix.so - 最後の行は、pam_unix.so モジュールのセッションインターフェースにセッションを管理するよう指示します。このモジュールは、各セッションの開始と終了時に、ユーザー名とサービスタイプを /var/log/secure に記録します。このモジュールは、追加機能のために他のセッションモジュールとスタックすることで補足できます。

[2] 設定可能な制御フラグは数多くあります。これらは attribute=value のペアで設定されます。属性の完全なリストは pam.d man ページで確認できます。
このページには機械翻訳が使用されている場合があります (詳細はこちら)。