test

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

第 17 章 PAM の使用

この章では、プラグイン可能認証モジュール (PAM) フレームワークについて説明します。PAM は、認証サービスを Solaris オペレーティングシステム (Solaris OS) に「プラグイン」する方法を提供します。PAM によって、システムへのアクセス時に複数の認証サービスを使用できるようになります。

PAM (概要)

プラグイン可能認証モジュール (PAM) フレームワークを使用すると、login、ftp、telnet などのシステムに入るためのサービスを変更しなくても、新しい認証サービスを「プラグイン」できるようになります。また、PAM を使用すると、UNIX ログインを Kerberos などほかのセキュリティーメカニズムと統合できます。また、アカウント、資格、セッション、およびパスワードの管理メカニズムも「プラグイン」できます。

PAM を使用する利点

PAM フレームワークを使用すると、システムに入るためのサービス (ftp、login、telnet、rsh など) のユーザー認証を構成できます。PAM には次の利点があります。

PAM フレームワークの概要

PAM フレームワークは次の 4 つの部分から成ります。

このフレームワークは、認証関連アクティビティーの統一的な実施手段を提供します。このアプローチを使えば、アプリケーション開発者は、PAM サービスのポリシーの意味を知らなくてもサービスを使用できるようになります。アルゴリズムは一元的に提供されます。アルゴリズムの変更は、個々のアプリケーションとは無関係に行えます。PAM を使えば、管理者は、アプリケーションを変更しないで、特定システムのニーズに合わせて認証プロセスを調整できるようになります。この調整は、PAM 構成ファイル pam.conf を通じて行われます。

次の図は、PAM のアーキテクチャーを示したものです。アプリケーションは、PAM アプリケーションプログラミングインタフェース (API) 経由で PAM ライブラリと通信します。PAM モジュールは、PAM サービスプロバイダインタフェース (SPI) 経由で PAM ライブラリと通信します。したがって、PAM ライブラリを使えば、アプリケーションとモジュールとの相互通信を実現できます。

図 17–1 PAM のアーキテクチャー

この図は、アプリケーションと PAM サービスモジュールが PAM ライブラリにアクセスする方法を示しています。

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

Solaris 10 リリースには、プラグイン可能認証モジュール (PAM) フレームワークに対する、次のような変更が含まれています。

PAM (手順)

この節では、PAM のフレームワークが特定のセキュリティーポリシーを使用するために必要な作業について説明します。PAM 構成ファイルに関連するセキュリティーのいくつかの問題について注意する必要があります。セキュリティーの問題については、「PAM の実装計画」を参照してください。

PAM (作業マップ)

作業 

説明 

参照先 

PAM のインストールを計画します。 

ソフトウェア構成処理を開始する前に、構成を検討および決定します。 

「PAM の実装計画」

新しい PAM モジュールを追加します。 

必要に応じて、サイト固有のモジュールを作成およびインストールし、汎用ソフトウェアにない要件に対応します。この手順ではこれらの新しい PAM モジュールのインストール方法について説明します。 

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

~/.rhosts によるアクセスを拒否します。

~/.rhosts によるアクセスを拒否して、セキュリティーを強化します。

「PAM を使用して、遠隔システムからの rhost 式アクセスを防ぐ方法」

エラー記録を開始します。 

syslog を使用して PAM エラーメッセージの記録を開始します。

「PAM のエラーレポートを記録する方法」

PAM の実装計画

配布時に、pam.conf 構成ファイルは Solaris の標準的なセキュリティーポリシーを実装します。このポリシーは、多くの状況で機能します。別のセキュリティーポリシーを実装する必要がある場合に注意すべき問題は、次のとおりです。

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

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

この手順では、新しい PAM モジュールを追加する方法を示します。新しいモジュールは、サイト固有のセキュリティーポリシーを網羅するためや、Sun 以外のアプリケーションをサポートするために作成します。

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

    役割には、認証と特権コマンドが含まれます。役割の詳細については、「RBAC の構成 (作業マップ)」を参照してください。

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

    制御フラグについては、「PAM スタックのしくみ」を参照してください。

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

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

  5. モジュールが適切に追加されたことを検証します。

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

ProcedurePAM を使用して、遠隔システムからの rhost 式アクセスを防ぐ方法

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

    役割には、認証と特権コマンドが含まれます。役割の詳細については、「RBAC の構成 (作業マップ)」を参照してください。

  2. rhosts_auth.so.1 を含む行をすべて PAM 構成ファイルから削除します。

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

  3. rsh サービスを無効にします。

    ~/.rhosts ファイルへのその他の非承認アクセスを防ぐには、rsh サービスも無効にする必要があります。 


    # svcadm disable network/shell

ProcedurePAM のエラーレポートを記録する方法

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

    役割には、認証と特権コマンドが含まれます。役割の詳細については、「RBAC の構成 (作業マップ)」を参照してください。

  2. 必要な記録のレベルに /etc/syslog.conf ファイルを構成します。

    記録レベルの詳細については、syslog.conf(4) を参照してください。

  3. syslog デーモンの構成情報を再表示します。


    # svcadm refresh system/system-log

PAM の構成 (参照)

login、rlogin、su、cron などのシステムサービスに対する PAM サービスモジュールを構成するには、PAM 構成ファイル pam.conf(4) を使用します。システム管理者がこのファイルを管理します。pam.conf 内のエントリの順番が間違っていると、予期しない副作用が生じる可能性があります。たとえば、pam.conf の設定が不適切であると、ユーザーがロックアウトされ、修復のためにシングルユーザーモードが必要になる可能性があります。順番の設定方法については、「PAM スタックのしくみ」を参照してください。

PAM 構成ファイルの構文

構成ファイル内のエントリの形式は、次のとおりです。

service-name module-type control-flag module-path module-options
service-name

サービスの名前。たとえば、ftp、login、または passwd などです。アプリケーションは、自身が提供するサービスごとに異なるサービス名を使用できます。たとえば、Solaris Secure Shell デーモンが使用するサービス名は次のとおりです。 sshd-none、sshd-password、sshd-kbdint、sshd-pubkey、sshd-hostbased。サービス名 other は事前に定義された名前であり、ワイルドカードのサービス名として使用されます。構成ファイル内で特定のサービス名が見つからない場合には、other の構成が使用されます。

module-type

サービスのタイプ。具体的には auth、account、session、password のいずれかです。

control-flag

サービスの統合された成功または失敗の値を決定するうえで、そのモジュールの果たす役割を示します。有効な制御フラグは、binding、include、optional、required、requisite、および sufficient です。制御フラグの使用方法については、「PAM スタックのしくみ」を参照してください。

module-path

サービスを実装しているライブラリオブジェクトへのパス。パス名が絶対パスでない場合、そのパス名は /usr/lib/security/$ISA/ に対する相対パスとみなされます。libpam による検索が、アプリケーションの特定のアーキテクチャーに対するディレクトリ内で行われるように、アーキテクチャーに依存するマクロ $ISA を使用します。

module-options

サービスモジュールに渡されるオプション。各モジュールのマニュアルページには、そのモジュールで使用できるオプションの説明があります。典型的なモジュールオプションとしては、nowarn や debug などがあります。

PAM スタックのしくみ

あるアプリケーションが次の関数を呼び出すと、libpam は構成ファイル /etc/pam.conf を読み取り、そのサービスの操作に関与するモジュールを決定します。

認証管理やアカウント管理など、このサービスのある操作に対するモジュールが /etc/pam.conf に 1 つしか含まれていない場合、そのモジュールの結果によって、その操作の結果が決まります。たとえば、passwd アプリケーションのデフォルトの認証操作には、1 つのモジュール pam_passwd_auth.so.1 が含まれています。


passwd  auth required           pam_passwd_auth.so.1

これに対し、サービスのある操作に対して複数のモジュールが定義されている場合、それらのモジュールは「スタック」を形成しており、そのサービスに対する「PAM スタック」が存在している、と言います。たとえば、pam.conf に次のエントリが含まれる場合を考えます。


login   auth requisite          pam_authtok_get.so.1
login   auth required           pam_dhkeys.so.1
login   auth required           pam_unix_cred.so.1
login   auth required           pam_unix_auth.so.1
login   auth required           pam_dial_auth.so.1

これらのエントリは、login サービスに対するサンプルの auth スタックを表現したものです。このスタックの結果を決定するには、個々のモジュールの結果コードに対して「統合プロセス」を実行する必要があります。統合プロセスでは、各モジュールが、/etc/pam.conf 内で指定された順番で実行されます。個々の成功コードまたは失敗コードが、モジュールの制御フラグに基づいて総合結果へと統合されます。制御フラグによっては、スタックの早期終了が発生する可能性があります。たとえば、requisite モジュールが失敗したり、sufficient モジュールや binding モジュールが成功したりする可能性があります。スタックの処理が完了すると、個々の結果が組み合わされて単一の総合結果が算出され、それがアプリケーションに渡されます。

制御フラグは、サービスへのアクセスを決定するうえで、ある PAM モジュールが果たす役割を示します。制御フラグとその効果は、次のとおりです。

次の 2 つの図は、統合プロセスでアクセスがどのように決定されるかを示したものです。最初の図は、制御フラグのタイプごとに成功または失敗がどのように記録されるのかを示しています。2 番目の図は、統合された値の決定方法を示しています。

図 17–2 PAM スタック: 制御フラグの効果

このフロー図は、制御フラグが PAM スタックにどのような影響を与えるのかを示しています。

図 17–3 PAM スタック: 統合された値の決定方法

このフロー図は、PAM スタックにおける統合された値の決定方法を示しています。

PAM スタックの例

次のような、認証を要求する rlogin サービスの例を考えます。

例 17–1 典型的な PAM 構成ファイルの内容の一部

この例の pam.conf ファイルには、rlogin サービスに対して次のような内容が含まれています。


     # Authentication management
     ...     
     # rlogin service 
     rlogin  auth sufficient         pam_rhosts_auth.so.1
     rlogin  auth requisite          pam_authtok_get.so.1
     rlogin  auth required           pam_dhkeys.so.1
     rlogin  auth required           pam_unix_auth.so.1
     ...

rlogin サービスが認証を要求すると、libpam はまず、pam_rhosts_auth(5) モジュールを実行します。pam_rhosts_auth モジュールの制御フラグは、sufficient に設定されています。pam_rhosts_auth モジュールがユーザーの認証に成功すると、処理が中止され、アプリケーションに成功が返されます。

pam_rhosts_auth モジュールがユーザーの認証に失敗すると、次の PAM モジュールである pam_authtok_get(5) が実行されます。このモジュールの制御フラグは、requisite に設定されています。pam_authtok_get が失敗すると、認証処理が終了し、失敗が rlogin に返されます。

pam_authtok_get が成功すると、次の 2 つのモジュール pam_dhkeys(5) と pam_unix_auth(5) が実行されます。どちらのモジュールにも、required に設定された制御フラグが関連付けられているため、各モジュールが失敗を返すかどうかにかかわらず、処理が継続されます。pam_unix_auth の実行が終了すると、rlogin 認証用のモジュールはもう残っていません。この時点で、pam_dhkeys、pam_unix_auth のいずれかが失敗を返していた場合、ユーザーは rlogin 経由でのアクセスを拒否されます。