PAM は、実行時に取り外しが可能なモジュールを使用して、システムエントリサービスの認証を提供します。スタッキング機能を利用すると、複数のサービスを使用してユーザーを認証できます。また、パスワードマッピング機能を利用すると、ユーザーは複数のパスワードを覚える必要がなくなります。
各 PAM モジュールは、特定のメカニズムを実装します。PAM 認証を設定するときは、モジュールとモジュールタイプの両方を指定する必要があります。モジュールタイプは、モジュールが実行する処理を定義します。複数のモジュールタイプ (認証、アカウント管理、セッション管理、またはパスワード管理) を各モジュールに関連付けることができます。
次の表では、各 PAM モジュールについて、モジュール名、モジュールファイル名、および説明を示します。各モジュールのパスは、インストールされている Solaris で使用できる命令によって異なります。モジュールのデフォルトのパスは、/usr/lib/security/ $ISA です。$ISA の値は、sparc または i386 です。詳細は、isalist(5) のマニュアルページを参照してください。
表 4–1 PAM モジュール
セキュリティ上の理由から、これらのモジュールファイルの所有者は root である必要があり、また、group と other に書き込み権があってはなりません。ファイルの所有者が root でない場合、PAM はモジュールをロードしません。
モジュールタイプはモジュールのインタフェースを定義するため、PAM モジュールのタイプを理解する必要があります。実行時 PAM モジュールには、次の 4 つのタイプがあります。
「認証モジュール」はユーザーの認証を行う。さらに、このモジュールでは、資格を設定、更新、または削除できる。そのほか、認証モジュールは、ユーザーを識別するための管理ツールを提供する
「アカウントモジュール」は、パスワードの有効期限、アカウントの有効期限、およびアクセス時間制限を確認する。アカウントモジュールは、認証モジュールでユーザーを識別したあと、そのユーザーにアクセス権を与えるべきかどうかを決定する。
「セッションモジュール」は、認証セッションの開閉を管理する。セッションモジュールは、動作を記録したり、セッション終了後のクリーンアップを実行したりできる。
「パスワードモジュール」によって、実際のパスワードを変更する。
PAM 構成ファイル /etc/pam.conf は、使用する認証サービスとその使用順序を決定します。このファイルを編集すると、システムエントリアプリケーションごとに認証メカニズムを選択できます。
PAM 構成ファイルは、次の構文のエントリで構成されます。
service_name module_type control_flag module_path module_options |
service_name |
サービス名 (ftp、login、telnet など) |
module_type |
サービスのモジュールタイプ。詳細は、PAM モジュールのタイプを参照 |
control_flag |
モジュールの継続または失敗の動作を決定する |
module_path |
サービスを実装するライブラリオブジェクトへのパスを指定する |
module_options |
サービスモジュールに渡すオプションを指定する |
pam.conf ファイルにコメントを追加するには、コメント行の最初に # (ポンド記号) を入力します。フィールドを区切るには、空白またはタブを使用します。
行のフィールド数が 4 つ未満の場合、module_type または control_flag に無効な値が指定されている場合、または指定したモジュールが存在しない場合は、PAM 構成ファイル内のエントリは無視されます。
有効なサービス名
そのサービスで使用できるモジュールタイプ
そのサービス名に関連するデーモンまたはコマンド
サービスによっては適用できないモジュールタイプがあります。たとえば、password モジュールタイプは、passwd コマンドだけに適用できます。また、passwd コマンドは認証と関連がないため、このサービスに関連付けられた auth モジュールタイプはありません。
表 4–2 /etc/pam.conf ファイルの有効なサービス名
サービス名 |
デーモンまたはコマンド |
適用可能なモジュールタイプ |
---|---|---|
/usr/sbin/cron |
auth、account |
|
/usr/dt/bin/dtlogin |
auth、account、session |
|
/usr/dt/bin/dtsession |
auth |
|
/usr/sbin/in.ftpd |
auth、account、session |
|
/usr/sbin/init |
session |
|
/usr/bin/login |
auth、account、session |
|
/usr/bin/passwd |
password |
|
/usr/bin/ppp |
auth、account、session |
|
/usr/sbin/rpc.rexd |
account、session |
|
/usr/sbin/in.rlogind |
auth、account、session |
|
/usr/sbin/in.rshd |
auth、account、session |
|
/usr/lib/saf/sac |
session |
|
/usr/bin/ssh |
auth、account、session |
|
/usr/bin/su |
auth、account |
|
/usr/sbin/in.telnetd |
auth、account、session |
|
/usr/lib/saf/ttymon |
session |
|
/usr/sbin/in.uucpd |
auth、account、session |
モジュールの続行動作または失敗動作を決定するには、PAM 構成ファイル /etc/pam.conf のエントリごとに「制御フラグ」を選択する必要があります。スタック内の各モジュールは、要求の成功や失敗を決定できます。
続行動作では、後続のモジュールをチェックするかどうかを定義します。特定のモジュールの応答によっては、追加モジュールをスキップできます。
失敗動作では、エラーメッセージのログや報告をどのように行うかを定義します。失敗には任意 (optional) と必須 (required) があります。必須の場合は、他のモジュールが正常であっても要求は必ず失敗に終わります。任意の場合は、要求が必ず失敗に終わるとは限りません。
これらのフラグはすべてのモジュールタイプに適用されますが、次の説明では、これらのフラグは認証モジュールで使用されていると仮定します。制御フラグは、次のとおりです。
binding – この制御フラグが適用されたモジュールが成功し、かつそれ以前の必須モジュールの中に失敗したものがない場合は、残りのモジュールをスキップします。失敗が返された場合は、必須の失敗を記録し、スタックの処理を続けます。
binding 制御フラグは、そのモジュールが成功した場合にそれ以後のモジュールのチェックを行わないことを除けば、 required 制御フラグに似ています。このフラグが適用されたモジュールで失敗が 1 つでもあると、ほかのモジュールからの応答がどうであれ、要求は成功とはみなされません。このフラグが適用されたモジュールが成功すると、それ以前の必須モジュールの中に失敗したものがなければ、要求は成功とみなされます。
required – この制御フラグが適用されたモジュールが成功した場合は、必須の成功を記録し、後続モジュールのチェックを続けます。モジュールが失敗した場合は、これが最初の必須の失敗であれば、エラーメッセージを保存してからスタックのチェックを続けます。これが最初の失敗でなければ、スタックのチェックを続けます。
要求が成功するために特定のモジュールの成功が欠かせない場合は、required 制御フラグを使用すべきです。このフラグが適用されたモジュールで失敗が 1 つでもあると、ほかのモジュールからの応答がどうであれ、要求は成功とはみなされません。このフラグが適用されたモジュールの 1 つが成功しても、要求の成功を意味するわけではありません。要求が成功するためには、スタックのすべての必須モジュールからの応答が成功でなければなりません。
requisite – この制御フラグが適用されたモジュールが成功した場合は、必須の成功を記録し、後続のモジュールのチェックを続けます。モジュールが失敗した場合は、必須の失敗を記録し、最初の必須の失敗であるというエラーメッセージを返し、それ以後のチェックをスキップします。
requisite 制御フラグは、モジュールが失敗した場合にそれ以後のモジュールのチェックを行わないことを除けば、 required 制御フラグに似ています。このフラグが適用されたモジュールで失敗が 1 つでもあると、ほかのモジュールからの応答がどうであれ、要求は成功とはみなされません。このフラグが適用されたモジュールの 1 つが成功しても、要求の成功を意味するわけではありません。要求が成功するためには、スタックのすべての必須モジュールからの応答が成功でなければなりません。
optional – この制御フラグが適用されたモジュールが成功した場合は、任意の成功を記録し、スタックのチェックを続けます。モジュールが失敗した場合は、任意の失敗を記録し、スタックのチェックを続けます。
optional 制御フラグは、ユーザーを認証するにはスタック内の他のモジュールのどれかが成功すれば十分であるという場合に使用します。このフラグは特定のモジュールが成功するということがそれほど重要でない場合に使用します。要求の成功または失敗は、ほかの必須の失敗または成功によって決まります。
ユーザーが作業を行ううえでアクセス権を持つ必要があるモジュールには、optional フラグを付けないでください。
sufficient – この制御フラグが適用されたモジュールが成功し、かつそれ以前の必須モジュールの中に失敗したものがない場合は、残りのモジュールをスキップします。モジュールが失敗した場合は、任意の失敗を記録し、スタックのチェックを続けます。
sufficient 制御フラグは、モジュールが成功した場合にそれ以後のモジュールのチェックを行わないことを除けば、 optional 制御フラグに似ています。このフラグが適用されたモジュールが成功すると、それ以前の必須モジュールの中に失敗したものがなければ、要求は成功とみなされます。このフラグが適用されたモジュールが失敗すると、成功したモジュールが以前になければ、要求は失敗とみなされます。
これらの制御フラグの詳細については、次の節を参照してください。次の節では、デフォルトの /etc/pam.conf ファイルについて説明します。
一般的な /etc/pam.conf ファイルには、次の動作が指定されています。
login コマンドを実行したときは、pam_authtok_get、pam_dhkeys、pam_auth_unix、および pam_dial_auth モジュールの認証が成功する必要があります。
rlogin コマンドを実行したときは、pam_rhost_auth の認証に失敗した場合、pam_authtok_get、pam_dhkeys、および pam_auth_unix モジュールの認証が成功する必要があります。
sufficient 制御フラグは、 rlogin コマンドを実行したとき、pam_rhost_auth モジュールによる認証が成功すれば十分であることを意味します。次のエントリは無視されます。
認証を必要とするその他のコマンドが実行されたときは、ほとんどの場合、pam_authtok_get、 pam_dhkeys、および pam_auth_unix モジュールの認証が成功する必要があります。
rsh コマンドが実行されたときは、pam_rhost_auth モジュールの認証には sufficient フラグが適用されます。pam_rhost_auth モジュールの認証が成功した場合は、それ以外の認証は必要ありません。
OTHER サービス名を使用すると、認証を必要とするがこのファイルには含まれていない他のコマンドに対するデフォルトとして設定できます。OTHER オプションを使用すると、同じモジュールを使用する多数のコマンドを 1 つのエントリだけでカバーできるため、ファイルの管理が簡単になります。また、OTHER サービス名を「すべてを捕捉する」と言う意味で使用すると、1 つのモジュールですべてのアクセスをカバーできます。通常、OTHER エントリは、各モジュールタイプのセクションの最後に指定します。
通常、module_path のエントリには「ルートからのパス名」を指定します。module_path に入力したファイル名がスラッシュ (/) で始まらない場合、そのファイル名の前にパス /usr/lib/security/$ISA が付きます。モジュールが他のディレクトリにある場合は、フルパスを使用する必要があります。module_options の値は、そのモジュールのマニュアルページに記載されています。たとえば、UNIX モジュールは、pam_unix(5) のマニュアルページに記載されています。
login auth required pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_auth.so.1 login auth required pam_dial_auth.so.1 |
この例の login サービスでは、4 つの認証モジュールの認証がすべて必須になっています。login コマンドは、いずれかのモジュールからエラーが返されると失敗します。