Solaris のシステム管理 (セキュリティサービス)

第 4 章 PAM の使用

この章では、Pluggable Authentication Module (PAM) フレームワークについて説明します。PAM は、認証サービスを「プラグイン」する方法を提供して、複数の認証サービスを使用できるようにします。

PAM (概要)

Pluggable Authentication Module (PAM) フレームワークを使用すると、login、ftp、telnet などのシステムエントリサービスを変更しなくても、新しい認証技術を「プラグイン」できるようになります。また、PAM を使用すると、 UNIX ログインを DCE や Kerberos のような他のセキュリティメカニズムと統合できます。また、アカウント、セッション、およびパスワードの管理メカニズムもプラグインできます。

PAM を使用する利点

PAM を使用すると、ユーザー認証用のシステムエントリサービス (ftp、login、telnet、rsh など) を任意に組み合わせて選択することができます。PAM には次の利点があります。

柔軟な構成ポリシー
- アプリケーションごとの認証ポリシー
- デフォルトの認証メカニズムを選択する機能
- 高度なセキュリティシステムにおける複数のパスワード

一般ユーザーにも使いやすい
- メカニズムが異なってもパスワードが同じであれば、パスワードを再入力する必要がない
- パスワードマッピング機能により、複数の認証方式に単一のパスワードを使用できる。この機能は、個々の認証方式に関連するパスワードが異なっている場合でも有効である
- ユーザーが複数のコマンドを入力しなくても、複数の認証方式のパスワードを求めるプロンプトを表示できる

オプションパラメータをユーザー認証サービスに渡す機能

PAM の構成要素

PAM ソフトウェアは、ライブラリ、いくつかのモジュール、および構成ファイルで構成されます。いくつかのコマンドまたはデーモンの新しいバージョンは、PAM インタフェースを利用できます。

次の図は、アプリケーション、PAM ライブラリ、pam.conf ファイル、および PAM モジュール間の関係を示します。

図 4–1 PAM の動作

PAM ライブラリが PAM モジュールとアプリケーションの間に位置しています。

アプリケーション (ftp、telnet、および login) は、PAM ライブラリを使用して、適切なモジュールにアクセスします。pam.conf ファイルは、使用するモジュールを定義して、各アプリケーションがモジュールを使用する順番を定義します。モジュールからの応答は、ライブラリ経由でアプリケーションに戻されます。

次の節では、PAM の構成要素とアプリケーションの関係について説明します。

PAM ライブラリ

PAM ライブラリ /usr/lib/libpam は、適切なモジュールをロードして、スタックプロセスを管理するためのフレームワークを提供します。また、すべてのモジュールがプラグインできる汎用構造になっています。

スタッキング機能

PAM フレームワークは、「スタッキング機能」を使用して、複数のサービスでユーザーを認証する方式を提供します。構成によって、認証方式ごとにパスワードを求めるプロンプトをユーザーに出すことも可能です。認証サービスが使用される順序は、PAM 構成ファイルで決定されます。

パスワードマッピング機能

スタッキング機能では、ユーザーが複数のパスワードを覚えておく必要があります。「パスワードマッピング機能」を使用すると、基本パスワードから他のパスワードを復号できるので、ユーザーが複数のパスワードを覚えたり入力したりする必要はありません。各認証メカニズム間でパスワードの同期を取るためのオプションもあります。ただし、スタック内で使用される最も安全性の低いパスワード方式によってメカニズムのセキュリティが制限されてしまうため、この方法ではセキュリティの危険性が増すおそれがあります。

Solaris 9 リリースにおける PAM への変更

Solaris 9 では、PAM サービスがいくつかの点で拡張されています。ここでは、最も重要な変更点について説明します。

スタッキングを適切に行うために、pam_unix モジュールが個々の単一サービスモジュールに分割されました。これらのモジュールの機能は、既存のモジュールと同等です。これらの機能は、次の各モジュールで提供されます。
- pam_authtok_get
- pam_authtok_check
- pam_authtok_store
- pam_unix_auth
- pam_dhkeys
- pam_passwd_auth
新しいモジュールについては、PAM モジュールを参照してください。
新しい PAM サービスとして、 cron、dtsession、ppp、および ssh が加わりました。新しいサービスについては、PAM で有効なサービス名を参照してください。
PAM 構成ファイルが、新しいモジュールと新しいサービスを含むよう更新されました。構成ファイルについては、一般的な pam.conf ファイルを参照してください。

Solaris 9 Update 2 リリースにおける PAM への変更

Update 2 には、新しいバインディング制御フラグが含まれています。このフラグの導入によって、追加の認証をスキップすることが可能になります。ただし、スキップするためには、そのサービスモジュールが正常に終わるだけでなく、その前に実行されたすべての必須モジュールが正常に終わっていなければなりません。この制御フラグについては、pam.conf(4) のマニュアルページと PAM 制御フラグを参照してください。

PAM (手順)

この節では、PAM のフレームワークを完全に機能させるために必要な作業について説明します。特に、PAM 構成ファイルに関連するセキュリティのいくつかの問題について注意する必要があります。

PAM (作業マップ)

作業	説明	参照先
PAM のインストールを計画する	ソフトウェア構成処理を開始する前に、構成を検討および決定する	PAM の計画
新しい PAM モジュールを追加する	必要に応じて、サイト固有のモジュールを作成およびインストールし、汎用ソフトウェアにない要件に対応する。この手順はインストール処理を含む	PAM モジュールを追加する方法
`~/.rhosts` によるアクセスを拒否する	`~/.rhosts` によるアクセスを拒否して、セキュリティを強化する手順	PAM を使用して、リモートシステムからの非承認アクセスを防ぐ方法
エラーレポートを開始する	`syslog` を使用して PAM エラーメッセージのレポートを開始する	PAM のエラーレポートを開始する方法

PAM の計画

ユーザーの環境に最適な PAM の使用方法を決定するために、次の問題から始めます。

何が必要か、特にどのモジュールを選択するかを決定する
特別な注意が必要なサービスを確認する。適宜、OTHER を使用する
モジュールを実行する順番を決定する
各モジュールに対する制御フラグを選択する
各モジュールに必要なオプションを選択する

ここで、PAM 構成ファイルを変更する前に次のことを考慮することをお勧めします。

すべてのアプリケーションを指定しなくてもいいように、モジュールタイプごとに OTHER エントリを使用する
sufficient 制御フラグと optional 制御フラグのセキュリティへの影響を確認する
モジュールに関連するマニュアルページを参照する。これらのマニュアルページには、各モジュールの機能、使用可能なオプション、スタック内のモジュール間の相互作用などの説明がある

注意 –
PAM 構成ファイルの構成を間違えたり壊したりすると、スーパーユーザーでもログインできなくなる可能性があります。この場合、sulogin コマンドは PAM を使用しないので、スーパーユーザーは、マシンをシングルユーザーモードでブートして問題を解決する必要があります。

/etc/pam.conf ファイルを変更したあと、スーパーユーザーとしてログインしている間にできる限り調査します。変更によって影響を受ける可能性があるコマンドは、すべてテストしてください。たとえば、新しいモジュールを telnet サービスに追加した場合、telnet コマンドを使用して、行なった変更が期待どおりに動作しているかどうかを検証します。

PAM モジュールを追加する方法

スーパーユーザーになるか、同等の役割を引き受けます。

使用する制御フラグとオプションを決定します。

モジュールについては、PAM モジュールを参照してください。

新しいモジュールを /usr/lib/security/sparcv9 にコピーします。

Solaris 8 の場合は、/usr/lib/security にコピーします。

モジュールファイルの所有者が root で、そのアクセス権が 555 になるように、アクセス権を設定します。

PAM 構成ファイル /etc/pam.conf を編集して、このモジュールを適切なサービスに追加します。

検証

構成ファイルが間違って構成されているおそれもあるので、システムをリブートする前にテストを行う必要があります。システムをリブートする前に、rlogin、su、および telnet を実行してください。サービスは、システムをブートしたときに 1 度だけ生成されるデーモンである場合があります。その場合には、システムをリブートしてから、モジュールが追加されていることを確認する必要があります。

PAM を使用して、リモートシステムからの非承認アクセスを防ぐ方法

PAM 構成ファイルから「rlogin auth rhosts_auth.so.1」エントリを削除します。この手順によって、rlogin セッション中、 ~/.rhosts ファイルは読み取られなくなり、ローカルシステムに認証されていないリモートシステムからのアクセスを防止できます。~/.rhosts ファイルまたは /etc/hosts.equiv ファイルの存在またはその内容にかかわらず、すべての rlogin アクセスにパスワードが必要になります。

注 –

~/.rhosts ファイルへのその他の非承認アクセスを防ぐには、rsh サービスも無効にする必要があります。サービスを無効にする最良の方法は、/etc/inetd.conf ファイルからサービスエントリを削除することです。PAM 構成ファイルを変更しても、サービスを無効にはできません。

PAM のエラーレポートを開始する方法

/etc/syslog.conf ファイルを編集して、PAM エラーレポートに次のエントリを必要に応じて追加します。
- auth.alert — すぐに修正する必要がある状態についてのメッセージ
- auth.crit – 致命的なメッセージ
- auth.err – エラーメッセージ
- auth.info – 情報提供用メッセージ
- auth.debug – デバッグメッセージ

syslog デーモンを再起動するか、SIGHUP シグナルを syslog デーモンに送信して、PAM のエラー報告を有効にします。

例 — PAM のエラーレポートを開始する

次の例では、すべての警告メッセージを画面に表示します。致命的なメッセージはスーパーユーザーに電子メールで送信されます。情報メッセージとデバッグ用メッセージは、/var/log/pamlog ファイルに追加されます。

auth.alert	/dev/console
auth.crit	'root'
auth.info;auth.debug	/var/log/pamlog

ログ内の各行は、タイムスタンプ、メッセージを生成したシステム名、およびメッセージ本体で構成されます。pamlog ファイルには、大量の情報が記録される可能性があります。

PAM (参照)

PAM は、実行時に取り外しが可能なモジュールを使用して、システムエントリサービスの認証を提供します。スタッキング機能を利用すると、複数のサービスを使用してユーザーを認証できます。また、パスワードマッピング機能を利用すると、ユーザーは複数のパスワードを覚える必要がなくなります。

PAM モジュール

各 PAM モジュールは、特定のメカニズムを実装します。PAM 認証を設定するときは、モジュールとモジュールタイプの両方を指定する必要があります。モジュールタイプは、モジュールが実行する処理を定義します。複数のモジュールタイプ (認証、アカウント管理、セッション管理、またはパスワード管理) を各モジュールに関連付けることができます。

次の表では、各 PAM モジュールについて、モジュール名、モジュールファイル名、および説明を示します。各モジュールのパスは、インストールされている Solaris で使用できる命令によって異なります。モジュールのデフォルトのパスは、/usr/lib/security/ $ISA です。$ISA の値は、sparc または i386 です。詳細は、isalist(5) のマニュアルページを参照してください。

表 4–1 PAM モジュール


モジュール名とモジュールファイル名	説明
`authtok_check` `pam_authtok_check.so.1`	パスワード管理をサポートする。このモジュールは、パスワードのさまざまなチェックを行う。たとえば、パスワードの長さをチェックしたり、ログイン名を循環的にシフトしたものとパスワードを比較してその複雑さを検証したり、あるいは新しいパスワードと古いパスワードを比較して変更された文字数をチェックしたりして、ユーザーが単純なパスワードを使用しないように支援する。詳細は、`pam_authtok_check(5)` のマニュアルページを参照
`authtok_get` `pam_authtok_get.so.1`	認証およびパスワード用にパスワードプロンプト機能を提供する。詳細は、`pam_authtok_get(5)` のマニュアルページを参照
`authtok_store` `pam_authtok_store.so.1`	認証だけをサポートする。このモジュールは、ユーザーの認証トークンを更新する。正常に更新したトークンは、指定されたレポジトリまたはデフォルトのレポジトリに格納する。詳細は、`pam_authtok_store(5)` のマニュアルページを参照
`dhkeys` `pam_dhkeys.so.1`	認証で使用する Diffie-Hellman 鍵の管理をサポートする。このモジュールは、Secure RPC 認証と Secure RPC 認証トークンの管理をサポートする。詳細は、`pam_dhkeys(5)` のマニュアルページを参照
`dial_auth` `pam_dial_auth.so.1`	認証だけで使用する。このモジュールは、`/etc/dialups` ファイルと `/etc/d_passwd` ファイルに格納されたデータを、認証用として使用する。主に `login` コマンドで使用される。詳細は、`pam_dial_auth(5)` のマニュアルページを参照
`krb5` `pam_krb5_auth.so.1`	認証、アカウント管理、セッション管理、およびパスワード管理をサポートする。認証には Kerberos 資格が使用される。詳細は、`pam_krb5(5)` のマニュアルページを参照
`ldap` `pam_ldap.so.1`	認証とパスワード管理をサポートする。LDAP サーバーのデータの認証に使用される。詳細は、`pam_ldap(5)` のマニュアルページを参照
`projects` `pam_projects.so.1`	アカウント管理をサポートする。詳細は、`pam_projects(5)` のマニュアルページを参照
`rhosts_auth` `pam_rhosts_auth.so.1`	認証だけで使用する。このモジュールは、`ruserok()` ルーチンによって `~/.rhosts` および `/etc/host.equiv` ファイルに格納されたデータを使用する。主に `rlogin` と `rsh` コマンドで使用する。詳細は、`pam_rhosts_auth(5)` のマニュアルページを参照
`roles` `pam_roles.so.1`	アカウント管理だけをサポートする。RBAC の `user_attr` データベースが、ユーザーが引き受けることができる役割を決定する。詳細は、`pam_roles(5)` のマニュアルページを参照
`sample` `pam_sample.so.1`	認証、アカウント管理、セッション管理、およびパスワード管理をサポートする。テストに使用する。詳細は、`pam_sample(5)` のマニュアルページを参照
`smartcard` `pam_smartcard.so.1`	認証だけをサポートする。詳細は、`pam_smartcard(5)` のマニュアルページを参照
`unix` `pam_unix.so.1`	認証、アカウント管理、セッション管理、およびパスワード管理をサポートする。このモジュールでは、4 種類すべてのモジュールタイプを定義できる。UNIX パスワードを認証に使用する。 Solaris 環境では、パスワードを取得するための適切なネームサービスの選択は、`/etc/nsswitch.conf` ファイルで制御する。詳細は、`pam_unix(5)` のマニュアルページを参照
`unix_account` `pam_unix_account.so.1`	アカウント管理をサポートする。このモジュールは、`nsswitch.conf` ファイルに指定されたレジストリのパスワード有効期限情報を取得して、パスワードおよびユーザーアカウントの期限が切れていないことを確認する。詳細は、`pam_unix_account(5)` のマニュアルページを参照
`unix_auth` `pam_unix_auth.so.1`	認証をサポートする。このモジュールは、PAM ハンドルに含まれているパスワードを検証する。このモジュールはまた、ユーザーのパスワードが、指定されたレポジトリまたはデフォルトのレポジトリに格納されているパスワードと一致しているか確認する。詳細は、`pam_unix_auth(5)` のマニュアルページを参照
`unix_session` `pam_unix_session.so.1`	セッション管理をサポートする。このモジュールは、セッション管理を開始するために、`/var/adm/lastlog` ファイルを更新する。詳細は、`pam_unix_session(5)` のマニュアルページを参照

セキュリティ上の理由から、これらのモジュールファイルの所有者は root である必要があり、また、group と other に書き込み権があってはなりません。ファイルの所有者が root でない場合、PAM はモジュールをロードしません。

PAM モジュールのタイプ

モジュールタイプはモジュールのインタフェースを定義するため、PAM モジュールのタイプを理解する必要があります。実行時 PAM モジュールには、次の 4 つのタイプがあります。

「認証モジュール」はユーザーの認証を行う。さらに、このモジュールでは、資格を設定、更新、または削除できる。そのほか、認証モジュールは、ユーザーを識別するための管理ツールを提供する
「アカウントモジュール」は、パスワードの有効期限、アカウントの有効期限、およびアクセス時間制限を確認する。アカウントモジュールは、認証モジュールでユーザーを識別したあと、そのユーザーにアクセス権を与えるべきかどうかを決定する。
「セッションモジュール」は、認証セッションの開閉を管理する。セッションモジュールは、動作を記録したり、セッション終了後のクリーンアップを実行したりできる。
「パスワードモジュール」によって、実際のパスワードを変更する。

PAM 構成ファイル

PAM 構成ファイル /etc/pam.conf は、使用する認証サービスとその使用順序を決定します。このファイルを編集すると、システムエントリアプリケーションごとに認証メカニズムを選択できます。

PAM 構成ファイルの構文

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 構成ファイル内のエントリは無視されます。

PAM で有効なサービス名

下記の表に、次の項目を示します。

有効なサービス名
そのサービスで使用できるモジュールタイプ
そのサービス名に関連するデーモンまたはコマンド

サービスによっては適用できないモジュールタイプがあります。たとえば、password モジュールタイプは、passwd コマンドだけに適用できます。また、passwd コマンドは認証と関連がないため、このサービスに関連付けられた auth モジュールタイプはありません。

表 4–2 /etc/pam.conf ファイルの有効なサービス名


サービス名	デーモンまたはコマンド	適用可能なモジュールタイプ
`cron`	`/usr/sbin/cron`	`auth、account`
`dtlogin`	`/usr/dt/bin/dtlogin`	`auth、account、session`
`dtsession`	`/usr/dt/bin/dtsession`	`auth`
`ftp`	`/usr/sbin/in.ftpd`	`auth、account、session`
`init`	`/usr/sbin/init`	`session`
`login`	`/usr/bin/login`	`auth、account、session`
`passwd`	`/usr/bin/passwd`	`password`
`ppp`	`/usr/bin/ppp`	`auth、account、session`
`rexd`	`/usr/sbin/rpc.rexd`	`account、session`
`rlogin`	`/usr/sbin/in.rlogind`	`auth、account、session`
`rsh`	`/usr/sbin/in.rshd`	`auth、account、session`
`sac`	`/usr/lib/saf/sac`	`session`
`ssh`	`/usr/bin/ssh`	`auth、account、session`
`su`	`/usr/bin/su`	`auth、account`
`telnet`	`/usr/sbin/in.telnetd`	`auth、account、session`
`ttymon`	`/usr/lib/saf/ttymon`	`session`
`uucp`	`/usr/sbin/in.uucpd`	`auth、account、session`

PAM 制御フラグ

モジュールの続行動作または失敗動作を決定するには、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 ファイルについて説明します。

一般的な `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 コマンドは、いずれかのモジュールからエラーが返されると失敗します。