PAM設定ファイル

PAMサービス名

　PAMを使用できるアプリケーションのサービス名は、/etc/pam.dにある設定ファイルの名前になります。PAMを使用するプログラムは、独自のサービス名を定義します。

　たとえば、login プログラムのサービス名は login 、 ftpd プログラムのサービス名は ftp 、となります。

　一般に、サービス名は、サービスにアクセスするプログラムの名前であり、サービスを提供するプログラムの名前ではありません。

PAMモジュール

　PAMには次の4つのタイプのモジュールがあり、特定のサービスへのアクセスを制御します。

• auth ──実際の認証を提供（パスワードの要求およびチェック）し、グループの所属件またはKerberosの「チケット」などの「証明書」を設定します。

• account ──認証が許可されることをチェックします（アカウントが期限切れでないか、ユーザーがその時刻のログインを認められているか、など）。

• password ──パスワードの設定に使用されます。

• session ──ユーザーが認証された後で使用されます。sessionモジュールによって、ユーザーが自分のアカウントを使用できるようになります（たとえば、ユーザーのホームディレクトリをマウントしたり、メールボックスを利用できるようになります）。

　これらのモジュールは スタック される、つまり次々に置き換えられるので、複数のモジュールが使用できます。認証プロセスにおいて、モジュールスタックの順番は非常に重要です。なぜなら、ユーザー認証が発生する前に、いくつかの条件を管理者が要求することが容易になるからです。

　たとえば、 rloginは通常、少なくとも4つのスタックされた認証方法を使用します。PAM設定ファイルでは次のように示されます。

auth       required     /lib/security/pam_nologin.so
auth       required     /lib/security/pam_securetty.so
auth       required     /lib/security/pam_env.so
auth       sufficient   /lib/security/pam_rhosts_auth.so
auth       required     /lib/security/pam_stack.so service=system-auth
account    required     /lib/security/pam_stack.so service=system-auth
password   required     /lib/security/pam_stack.so service=system-auth
session    required     /lib/security/pam_stack.so service=system-auth

　rloginが承認される際、PAMは/etc/nologinが存在しないこと、rootとしてリモートからログインするのでないこと、環境変数がロードされないことを確認します。その後、rhosts認証が成功すると、接続が認められます。rhosts認証が失敗した場合、標準パスワード認証が実行されます。

　新しいPAMモジュールはいつでも追加できます。また、PAM対応アプリケーションにそれらのモジュールを使用させることができます。たとえば、一時パスワード作成方法を作成し、それをサポートするようなモジュールを作成できる場合、再コンパイルや修正を実行しなくても、PAMを認識するプログラムは、新しいモジュールと新しい一時パスワード作成方法を使用することができます。これは非常に重要です。プログラムを再コンパイルすることなく、テストと同じように認証方法をうまく組み合わせることができるからです。

　モジュール作成に関するマニュアルは、 /usr/share/doc/pam— <バージョン番号>にあります。

PAM制御フラグ

　PAMモジュールは、チェックの結果が成功であることも失敗であることもあります。制御フラグは、その結果に対する処理方法をPAMに提供します。モジュールは特定の順序でスタックされるので、制御フラグは、ユーザーが後に続くモジュールの重要度を設定することができるようにします。

　もう一度、 rlogin PAM設定ファイルを確認します。

auth       required     /lib/security/pam_nologin.so
auth       required     /lib/security/pam_securetty.so
auth       required     /lib/security/pam_env.so
auth       sufficient   /lib/security/pam_rhosts_auth.so
auth       required     /lib/security/pam_stack.so service=system-auth
account    required     /lib/security/pam_stack.so service=system-auth
password   required     /lib/security/pam_stack.so service=system-auth
session    required     /lib/security/pam_stack.so service=system-auth

　モジュールのタイプが指定されると、制御フラグは、プログラム全体に対するユーザーのアクセス権を考慮するにあたって、特定のモジュールの重要度を決定します。

　PAM標準によって、4つのタイプの制御フラグが定義されています。

• required フラグモジュール──許可される認証の順序で完全にチェックされなければなりません。requiredモジュールのチェックが失敗すると、同じタイプのほかのモジュールがチェックされるまでユーザーには何も通知されません。

• requisite フラグモジュール──これも、許可される認証の順序で完全にチェックされなければなりません。ただし、 requisite モジュールのチェックが失敗した場合は、RequiredまたはRequisitモジュールが最初に失敗したことを知らせるメッセージがユーザーに直ちに通知されます。

• sufficient フラグモジュール──このチェックが失敗した場合、無視されます。ただし、 sufficient フラグモジュールのチェックが成功し、その上のrequired フラグモジュールがすべて成功した場合、このタイプのほかのモジュールはチェックされず、このモジュールタイプ全体のチェックが成功したと見なされます。

• optional フラグモジュール──このモジュールタイプの認証が成功または失敗しても、あまり重要ではありません。このモジュールが役立つのは、このタイプのモジュール以外がすべて成功または失敗したときだけです。この場合、成功または失敗した optional フラグモジュールによって、そのモジュールタイプ全体のPAM認証が決定されます。

　さらに制御機能を増した新しい制御フラグ構文が、PAMで利用できるようになりました。この新しい構文についての詳細は、 /usr/share/doc/pam— <バージョン番号> にあるPAMのマニュアルを参照してください。

PAMモジュールパス

　モジュールパスによって、指定されたモジュールタイプとともに使用するプラグ可能なモジュールの場所がPAMに知らされます。通常、 /lib/security/pam_stack.so のようにモジュールへのフルパスが示されます。ただし、フルパスが提示されない場合（つまり、パスが / で始まっていない場合）、モジュールの表示はPAMのデフォルトの位置、 /lib/security になります。

PAMの引数

　特定のモジュールタイプを認証するとき、PAMはプラグ可能なモジュールへ情報を渡すために引数を使用します。この引数によって、特定のプログラムのPAM設定ファイルが、共通のPAMモジュールを別の方法で使用できるようになります。

　たとえば、 pam_userdb.so モジュールは、Berkeley DBファイルに保存された秘密鍵を使ってユーザーを認証します（Berkeley DBは、特殊な情報を追跡するためのオープンソースデータベースシステムで、多くのアプリケーションに内蔵されるよう設計されています）。このモジュールは、使用するBerkeley DBファイル名を指定する引数 db を取ります。引数はサービスによって異なります。

　したがって、PAM設定ファイルの行 pam_userdb.so は、次のようになります。

auth      required  /lib/security/pam_userdb.so db=
path
/
to
/
file

　無効な引数は無視され、PAMモジュールの成功または失敗のどちらにも影響しません。無効な引数が渡されると、通常、エラーが /var/log/messages に表示されます。ただし、レポート方法がPAMモジュールによって制御されている場合は、モジュールの指示どおりにエラーがログされます。

PAM設定ファイルのサンプル

　PAMアプリケーションの設定ファイルのサンプルを示します。

#%PAM-1.0
auth      required  /lib/security/pam_securetty.so
auth      required  /lib/security/pam_unix.so shadow nullok
auth      required  /lib/security/pam_nologin.so
account   required  /lib/security/pam_unix.so
password  required  /lib/security/pam_cracklib.so
password  required  /lib/security/pam_unix.so shadow nullok use_authtok
session   required  /lib/security/pam_unix.so

　先頭行はコメントです（ # で始まる行は、すべてコメントです）。2行目から4行目ではログイン認証で使用するモジュールを列挙しています。

auth      required  /lib/security/pam_securetty.so

　2行目は、ユーザーがrootとしてログインを試行し、かつ/etc/securettyファイルが存在するならば、ログイン試行時に使用されたttyがこのファイルにリストされていることを確認します。

auth      required  /lib/security/pam_unix.so shadow nullok

　3行目で、ユーザーはパスワードを要求され、そのパスワードがチェックされます。

auth      required  /lib/security/pam_nologin.so

　4行目は、/etc/nologinファイルが存在するかをチェックし、存在する場合にはそのファイルの内容を表示し、ユーザーがrootでない場合には、そのユーザーのログインを許可しません。

　最初のauthモジュールが失敗しても、3つのモジュールすべてがチェックされることに注意してください。これはセキュリティ上の処理であり、認証が拒否された理由をユーザーに悟られないように設計されています。なぜなら、拒否された理由を知ることによって認証を突破することが容易になる可能性があるからです。この動作を変更するには、requiredをrequisiteに変更します。requisite モジュールから失敗という結果が返された場合、その他のモジュールを呼び出すことなく、PAM認証は即座に失敗します。

account   required  /lib/security/pam_unix.so

　5行目で必要なアカウント処理が実行されます。たとえば、シャドウパスワードが有効な場合、 pam_unix.so モジュールは、アカウントの期限が切れていないか、またはユーザーがパスワードを変更していないか、パスワード変更に関する猶予期間が切れていないか、をチェックします。

password  required  /lib/security/pam_cracklib.so

　6行目は、新規に変更されたパスワードに対して一連のテストを実行することにより、そのパスワードがパスワードに対する辞書型攻撃プログラムによって簡単に判明するものでないことなどを確認します。

password  required  /lib/security/pam_unix.so shadow nullok use_authtok

　7行目（複数行になることもあります）で、loginプログラムがユーザーのパスワードを変更する際には、pam_unix.soモジュールを使用させることを指定しています（これが行われるのは、authモジュールがパスワードを変更する必要があると判断した—シャドウパスワードの期限が切れた、などの場合に限られます）。

session   required  /lib/security/pam_unix.so

　最後の8行目は、 pam_unix.so モジュールを使用してセッションを管理することを指定しています。現在のところ、このモジュールは何も行いません。したがって、必要なモジュールと置き換える（またはスタックすることで補足する）ことができます。

　各ファイル内の行の順序が重要であることに注意してください。required 　モジュールの呼び出し順序はさして重要ではないのですが、その他の制御フラグを利用することができます。optional が使用されることはめったにありません。sufficient と requisite では、順序が重要になります。

　login用のauth設定を確認します。

#%PAM-1.0
auth      required    /lib/security/pam_nologin.so
auth      required    /lib/security/pam_securetty.so
auth      required    /lib/security/pam_env.so
auth      sufficient  /lib/security/pam_rhosts_auth.so
auth      required    /lib/security/pam_stack.so service=system-auth

　1行目で pam_nologin.so は、 /etc/nologin が存在するかどうかをチェックします。存在する場合、root以外はログインできません。

auth      required    /lib/security/pam_securetty.so

　2行目で pam_securetty.so は、安全ではない端末からrootのログインが行われないようにします。これで、rootによる rlogin 試行のすべてが効果的に拒否されます。許可したい場合（その場合には、インターネットに接続しないか、または優れたファイアウォールを設置することをお勧めします）は、the section called PAMとrlogin、rsh、rexecの使用を参照してください。

auth      required    /lib/security/pam_env.so

　3行目で pam_env.so モジュールは、 /etc/security/pam_env.conf に指定された環境変数をロードします。

auth      sufficient  /lib/security/pam_rhosts_auth.so

　4行目でpam_rhosts_auth.soが、ユーザーのホームディレクトリにある.rhostsを使用してユーザーを認証すると、PAMはpam_stack.soによる通常のパスワード認証を行わず、即座にrloginを認証します。pam_rhosts_auth.so によるユーザーの認証が失敗した場合、その失敗した認証は無視されます。

auth      required    /lib/security/pam_stack.so service=system-auth

　5行目で pam_rhosts_auth.so がユーザー認証に失敗した場合、 pam_stack.so モジュールは通常のパスワード認証を実行し、引数 service=system-auth を渡します。

	注意
	securetty チェックが失敗し、ユーザーがrootとしてリモートからログインしようとしていることが判明したときに、パスワードの入力を要求したくない場合は、 pam_securetty.so モジュールを required から requisite に変更してください。その反対に、リモートからのrootログインを許可する場合（極力避けて下さい）、この行をコメントアウトしてください。