10.2. PAM 設定ファイルについて
PAM 対応のアプリケーションまたは サービス ごとに、
/etc/pam.d/ ディレクトリーに ファイルがあります。このディレクトリーの各ファイルは、アクセスを制御するサービスと同じ名前を持ちます。たとえば、 login プログラムはログインとしてサービス名を定義し、/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: 認証を続行するには、モジュール結果が成功する 必要 があります。この時点でテストが失敗すると、そのインターフェイスを参照するすべてのモジュールテストの結果が完了するまでユーザーには通知されません。
- 必須 - 認証を続行するには、モジュールの結果が正常に実行される必要があります。ただし、この時点でテストが失敗すると、最初に失敗した required また は requisite モジュールテストを反映したメッセージとともに、すぐにユーザーに通知されます。
- sufficient - モジュールが失敗する場合、結果は無視されます。ただし、モジュールフラグ付きの sufficient の結果が成功し、以前のモジュールフラグ付きの required が失敗していない場合は、その他の結果は不要で、ユーザーはサービスに対して認証されます。
- オプション - モジュールの結果は無視されます。他のモジュールがインターフェイスを参照していない場合に、認証を成功させるには、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- この行は、UID が 0 であることを確認することで、pam_rootok.soモジュールを使用して現在のユーザーが 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 としてログインしようとしている 場合 に、そのファイルが存在する 場合 は、ユーザーがログインする TTY が
/etc/securettyファイルに一覧表示されます。TTY がファイルに記載されていない場合は、root でログインしようとすると、Login incorrectメッセージを表示して失敗します。auth required pam_unix.so nullok - このモジュールはユーザーにパスワードを要求し、/etc/passwdに保存されている情報を使用してパスワードをチェックし、存在する場合は/etc/shadow。引数は、pam_unix.soモジュールに空のパスワードを許可するように nullok に指示します。 - 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 は、テストが初めて失敗すると、強力なパスワードを作成する可能性が 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に記録します。このモジュールは、追加機能のために他のセッションモジュールとスタックすることで補足できます。
