2.2. PAM 設定ファイル
/etc/pam.d/ ディレクトリーには、PAM 対応各アプリケーションの PAM 設定ファイルが含まれます。
2.2.1. PAM サービスファイル
PAM 対応のアプリケーションまたは サービス にはそれぞれ、
/etc/pam.d/ ディレクトリーにファイルがあります。このディレクトリーの各ファイルは、アクセスを制御するサービスと同じ名前を持ちます。
PAM 対応プログラムは、サービス名を定義し、独自の PAM 設定ファイルを
/etc/pam.d/ ディレクトリーにインストールします。たとえば、login プログラムはサービス名を login として定義し、/etc/pam.d/login PAM 設定ファイルをインストールします。
2.2.2. PAM 設定ファイル形式
各 PAM 設定ファイルには、モジュールとその制御または引数を定義するディレクティブが含まれます。
ディレクティブの構文はすべて簡単なもので、モジュールの目的 (インターフェース) とモジュールの設定を特定します。
module_interface control_flag module_name module_arguments
2.2.2.1. PAM モジュールのインターフェース
4 種類の PAM モジュールインターフェースが利用できます。それぞれは、承認プロセスのさまざまな要素に対応します。
auth: このモジュールインターフェースは、使用を認証します。たとえば、パスワードの有効性を要求し、検証します。このインターフェースのあるモジュールは、グループメンバーシップや Kerberos チケットなどの認証情報を設定することもできます。account: このモジュールインターフェースは、アクセスが許可されることを確認します。たとえば、ユーザーアカウントの有効期限が切れたか、または特定の時間にユーザーがログインできるかどうかを確認します。password: このモジュールインターフェースは、ユーザーパスワードの変更に使用されます。session: このモジュールインターフェースは、ユーザーセッションを設定および管理します。このインターフェースのあるモジュールは、ユーザーのホームディレクトリーをマウントしたり、ユーザーのメールボックスを利用可能にするなど、アクセスを許可するために必要な追加のタスクも実行できます。
注記
個別のモジュールは、いずれかのインターフェースまたはすべてのモジュールインターフェースを提供できます。たとえば、
pam_unix.so は 4 つのモジュールインターフェースをすべて提供します。
PAM 設定ファイルでは、モジュールインターフェースは以下のように最初のフィールドで定義されます。以下に例を示します。
auth required pam_unix.so
これにより、PAM が
pam_unix.so モジュールの auth インターフェースを使用するように指示されます。
モジュールインターフェースのディレクティブは、重ねて配置することでスタック化 が可能なので、複数のモジュールをまとめて 1 つの目的に使用することができます。モジュールの制御フラグが
sufficient または requisite 値を使用している場合、モジュールの一覧表示順序は認証プロセスで重要になります。
スタック化により、管理者はユーザーが認証を行う前に、特定の条件を必須とすることが容易になります。たとえば、
reboot コマンドは通常、PAM 設定ファイルで説明されているように、いくつかのスタックされたモジュールを使用します。
[root@MyServer ~]# cat /etc/pam.d/reboot #%PAM-1.0 auth sufficient pam_rootok.so auth required pam_console.so #auth include system-auth account required pam_permit.so
- 最初の行はコメントで、処理されません。
auth sufficient pam_rootok.so: この行はpam_rootok.soモジュールを使用して、UID が 0 であることを確認し、現在のユーザーが root かどうかをチェックします。このテストに成功すると、他のモジュールは参照されず、コマンドが実行されます。このテストが失敗すると、次のモジュールが参照されます。auth required pam_console.so: この行は、pam_console.soモジュールを使用してユーザーの認証を試行します。このユーザーがコンソールにすでにログインしている場合は、pam_console.soがサービス名 (reboot) と同じ名前を持つ/etc/security/console.apps/ディレクトリーにファイルがあるかどうかを確認します。そのようなファイルが存在する場合は、認証が成功し、制御が次のモジュールに渡されます。#auth include system-auth: この行はコメント化され、処理されません。account required pam_permit.so- この行はpam_permit.soモジュールを使用して、root ユーザーまたはコンソールにログインしているすべてのユーザーによるシステムの再起動を許可します。
2.2.2.2. PAM 制御フラグ
すべての PAM モジュールは、呼び出されると成功または失敗の結果を生成します。コントロールフラグは結果に基づいて PAM に指示します。モジュールは特定の順序でスタックでき、制御フラグは特定モジュールの成功または失敗の重要性を判断し、ユーザーをサービスに対して認証する際の全体的な目標を決定します。
設定にはキーワードのみを使用する単純なフラグがいくつかあります。
required: 認証を継続するには、モジュール結果が成功する必要があります。この時点でテストが失敗すると、そのインターフェースを参照するすべてのモジュールテストの結果が完了するまでユーザーには通知されません。requisite: 認証を継続するには、モジュール結果が成功する必要があります。ただし、この時点でテストが失敗すると、初回失敗したrequiredまたはrequisiteモジュールテストを反映したメッセージとともに、すぐにユーザーに通知されます。sufficient: モジュール結果は、失敗すると無視されます。ただし、モジュールフラグ付きのsufficientの結果が成功で、かつ、以前のモジュールフラグ付きのrequiredが失敗していない場合は、その他の結果は不要で、ユーザーはサービスに認証されます。optional: モジュール結果は無視されます。その他のモジュールがインターフェイスをを参照しない場合に認証成功に必要となるのは、optionalとしてフラグが付いたモジュールです。include: 他のコントロールとは異なり、モジュールの結果の処理方法とは関係ありません。このフラグは、指定のパラメーターに一致する設定ファイルのすべての行でプルし、それらをモジュールに引数として追加します。
重要
呼び出される
required モジュールの順序は重要ではありません。sufficient および requisite 制御フラグのみにより、順番は重要になります。
設定可能な制御フラグは数多くあります。これらは attribute=value のペアで設定されます。属性の全リストは
pam.d man ページで確認できます。
2.2.2.3. PAM モジュール名
モジュール名は、指定されたモジュールインターフェースを含むプラグ可能なモジュールの名前で PAM を提供します。アプリケーションが適切なバージョンにリンクされているため、ディレクトリー名は省略されます。これは
libpam、モジュールの正しいバージョンを見つけることができます。
2.2.2.4. PAM モジュール引数
PAM はいくつかのモジュール向けの認証中に 引数 を使って情報をプラグ可能なモジュールに渡します。
たとえば、
pam_userdb.so モジュールは Berkeley DB ファイルに保存されている情報を使用してユーザーを認証します。Berkeley DB は、多くのアプリケーションに埋め込まれたオープンソースデータベースシステムです。モジュールは db 引数を取り、リクエストしたサービスに使用するデータベースを認識できるようにします。以下に例を示します。
auth required pam_userdb.so db=/path/to/BerkeleyDB_file
無効な引数は通常無視され、PAM モジュールの成功や失敗には影響を及ぼしません。ただし、一部のモジュールは無効な引数で失敗する可能性があります。多くのモジュールはエラーを
/var/log/secure ファイルに報告します。
2.2.3. PAM 設定ファイルのサンプルについて
例2.1「シンプルな PAM 設定」 は、PAM アプリケーション設定ファイルのサンプルです。
例2.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_cracklib.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_cracklib.so retry=3: パスワードの有効期限が切れた場合、pam_cracklib.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_cracklib.soテストを通過する必要があります。
session required pam_unix.so: 最後の行は、pam_unix.soモジュールのセッションインターフェースにセッションを管理するよう指示します。このモジュールは、各セッションの開始と最後で、ユーザー名とサービスタイプを/var/log/secureに記録します。このモジュールは、追加機能のために他のセッションモジュールとスタックすることで補足できます。
