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 に記録します。このモジュールは他のセッションモ ジュールとスタック化した追加機能を補うことができます。