Show Table of Contents
このページには機械翻訳が使用されている場合があります (詳細はこちら)。
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
に記録します。このモジュールは他のセッションモジュールとスタック化した追加機能を補うことができます。
このページには機械翻訳が使用されている場合があります (詳細はこちら)。