この章の最初の節では、Secure RPC で使用できる Diffie-Hellman 認証機構について説明します。 2 番目の節では、Pluggable Authentication Module (PAM) フレームワークについて説明します。PAM は、認証サービスを「プラグイン」する方法を提供して、複数の認証サービスを使用できるようにします。
この章で説明する手順は次のとおりです。
Secure RPC は、ホストと、要求を依頼したユーザーの両方を認証する認証方法です。Secure RPC は、Diffie-Hellman 認証を使用します。この認証機構は DES 暗号化を使用します。Secure RPC を使用するアプリケーションには、NFS と NIS+ ネームサービスがあります。
NFS ソフトウェアを使用すると、複数のホストがネットワーク上でファイルを共有できます。NFS システムでは、サーバーは、複数のクライアントから利用できるデータと資源を格納します。クライアントは、サーバーがクライアントと共有するファイルシステムにアクセスできます。クライアントマシンにログインしたユーザーは、ファイルシステムをサーバーからマウントすることによって、そのファイルシステムにアクセスできます。このとき、クライアントマシン上のユーザーには、ファイルはクライアントのローカルファイルシステム上にあるように見えます。NFS 環境の最も一般的な使用形態として、システムを各オフィスにインストールして、すべてのユーザーファイルを 1 箇所で集中管理する方法が挙げられます。 mount -nosuid オプションなどのいくつかの NFS 機能を使用すると、権限のないユーザーがデバイスやファイルシステムにアクセスすることを禁止できます。
NFS 環境では Secure RPC を使用して、要求を出したユーザーをネットワーク上で認証します。これを Secure NFS と呼びます。認証機構 AUTH_DH
は、Diffie-Hellman 認証で DES 暗号化を使用し、許可されたアクセスを確認します。AUTH_DH
機構は、AUTH_DES
とも呼びます。
『Solaris のシステム管理 (第 3 巻)』では、Secure NFS を設定および管理する方法を説明しています。NIS+ テーブルの設定と cred テーブルへの名前の入力は、『Solaris ネーミングの管理』で説明しています。RPC 認証に含まれる手順の概要については、「Diffie-Hellman 認証の実装」を参照してください。
Data Encryption Standard (DES) 暗号化機能は 56 ビットの鍵を使用して、データ鍵を暗号化します。資格を持つ 2 人のユーザー (プリンシパル) が同じ DES 鍵を知っている場合、彼らはその鍵を使用してテキストを暗号化または復号化することによって、プライベートに通信できます。DES は比較的高速な暗号化機構です。DES チップは暗号化をより高速にします。しかし、チップがなくても、ソフトウェアが実行します。
DES 鍵だけを使用する危険性とは、同じ鍵を使用して暗号化した暗号テキストメッセージを十分に収集すれば、鍵を発見し、メッセージを復号化できることです。この理由のため、Secure NFS などのセキュリティシステムは鍵を頻繁に変更します。
Kerberos は、マサチューセッツ工科大学 (MIT) で開発された認証システムです。Kerberos は DES 暗号を使用します。Kerberos Version 4 は Secure RPC ではサポートされませんが、RPCSEC_GSS を使用する Kerberos Version 5 のクライアント側実装は、Solaris 8 リリースに含まれます。詳細は、第 21 章「SEAM の概要」を参照してください。
Diffie-Hellman のユーザー認証方法は簡単には破られません。クライアントとサーバーは、それぞれ独自の非公開鍵 (秘密鍵とも呼ぶ) を持っていて、共通鍵が利用できるように公開鍵と組み合わせて使用します。クライアントとサーバーはお互いにこの共通鍵を使用し、両者で合意された暗号化復号化機能 (DES など) を使用して通信します。この方法は、以前の Solaris リリースの DES 認証と同じです。
認証は、送信側のシステムの共通鍵を使用して現在の時刻を暗号化する機能を利用します。受信側のシステムは、その現在の時刻を復号し、自分の時刻と照合します。クライアントとサーバーで時刻が同期していることを確認してください。
公開鍵と非公開鍵は、NIS または NIS+ のデータベースに格納されます。NIS では、publickey マップに鍵を格納します。NIS+ では、cred テーブルに鍵を格納します。これらのファイルには、すべてのユーザーの公開鍵と非公開鍵が入っています。
システム管理者は、NIS または NIS+ のテーブルを設定して、ユーザーごとに公開鍵と非公開鍵を生成する義務があります。公開鍵は、ユーザーのパスワードで暗号化されて格納されます。これによって、その公開鍵はそのユーザーだけが知っていることになります。
この節では、DH 認証 (AUTH_DH
) を使用するクライアントサーバーセッションにおける一連のトランザクションを説明します。
トランザクションの前に、管理者は newkey コマンドか nisaddcred コマンドを使用して、公開鍵と秘密鍵を生成します (各ユーザーは一意の公開鍵と秘密鍵を持ちます)。公開鍵は公開データベースに格納されます。秘密鍵は、暗号化された形式で、同じデータベースに格納されます。鍵のペアを変更するには、chkey コマンドを使用します。
通常、ログインパスワードは Secure RPC パスワードと同じです。この場合、keylogin は必要ありません。パスワードが異なる場合、ユーザーはログインしてから明示的に keylogin を実行しなければなりません。
keylogin プログラムは、Secure RPC パスワードを求めるプロンプトをユーザーに出して、そのパスワードを使用して秘密鍵を復号します。keylogin プログラムは、復号した秘密鍵をキーサーバーというプログラムに渡します (キーサーバーは、すべてのコンピュータ上にローカルインスタンスを持つ RPC サービスです)。キーサーバーは、復号された秘密鍵を保存して、ユーザーがサーバーで Secure RPC トランザクションを発行するのを待ちます。
パスワードが同じ場合は、ログインプロセスが秘密鍵をキーサーバーに渡します。パスワードが異なる必要があり、ユーザーが常に keylogin を実行しなければならない場合は、keylogin プログラムをユーザーの環境の構成ファイル (‾/.login、‾/.cshrc、‾/.profile など) に入れておいて、ユーザーがログインするたびに自動的に実行されるようにします。
ユーザーがサーバーとのトランザクションを開始すると、次の動作が行われます。
キーサーバーはランダムに対話鍵を生成します。
カーネルはこの対話鍵を使用して、クライアントのタイムスタンプを暗号化します (他の動作も行います)。
キーサーバーは公開鍵データベースでサーバーの公開鍵を検索します (publickey(4) のマニュアルページを参照してください)。
キーサーバーはクライアントの秘密鍵とサーバーの公開鍵を使用して、共通鍵を作成します。
キーサーバーは共通鍵を使用して対話鍵を暗号化します。
次に、暗号化したタイムスタンプと暗号化した対話鍵を含む伝送データがサーバーに送信されます。伝送データには資格とベリファイアが含まれます。資格は、次の 3 つの構成要素を持ちます。
クライアントのネット名
共通鍵で暗号化された対話鍵
対話鍵で暗号化された「ウィンドウ」
この場合の「ウィンドウ」とは、クライアントが主張する、サーバーの時刻とクライアントのタイムスタンプとの許容されるべき差のことです。サーバーの時刻とクライアントのタイムスタンプとの間の差がウィンドウより大きい場合、サーバーはクライアントの要求を拒否します。クライアントは RPC セッションを開始する前にサーバーと同期を取るため、通常の状態では、このような事態は発生しません。
暗号化されたタイムスタンプ
指定したウィンドウの暗号化されたベリファイアから 1 を引いた値
ウィンドウベリファイアが必要な理由は次の場合です。誰かが別のユーザーになりすまそうとして、資格とベリファイアの暗号化されたフィールドに書き込む代わりに、ランダムなビットだけを埋め込むプログラムを書いたと仮定します。サーバーはこの対話鍵をなんらかのランダム鍵に復号化し、それを使用してウィンドウとタイムスタンプを復号化しようと試みます。その結果、乱数が生成されるだけです。しかし、数千回の試行を重ねるうちには、このランダムなウィンドウタイムスタンプのペアが認証システムを通過することが十分ありえます。ウィンドウベリファイアは、正しい資格の解読をより困難にします。
サーバーがクライアントから伝送データを受信すると、次の動作が行われます。
サーバーのローカルなキーサーバーが、公開鍵データベースでクライアントの公開鍵を検索します。
キーサーバーは、クライアントの公開鍵とサーバーの秘密鍵を使用して、共通鍵を計算します。この共通鍵はクライアントが計算したものと同じです。共通鍵を計算するためには、どちらか一方の秘密鍵を知っている必要があるため、これを行えるのはサーバーとクライアントだけです。
カーネルは共通鍵を使用して、対話鍵を復号します。
カーネルはキーサーバーを呼び出して、復号された対話鍵によりクライアントのタイムスタンプを復号します。
サーバーは、クライアントのタイムスタンプを復号した後、次の 4 種類の情報を資格テーブルに格納します。
クライアントのコンピュータ名
対話鍵
ウィンドウ
クライアントのタイムスタンプ
サーバーは、最初の 3 つの情報を将来の使用のために格納します。サーバーはタイムスタンプを格納して、同じタイムスタンプが再度使用できないようにします。サーバーは、最後に参照したタイムスタンプよりも時間的に後のタイムスタンプだけを受け付けるため、同じタイムスタンプのトランザクションはすべて拒否されることが保証されます。
この手順において暗黙的に仮定されているのは呼び出し側の名前であり、何らかの方法でこの名前を認証しなければなりません。キーサーバーは、この目的には DES 認証を使用できません。DES 認証を使用すれば、デッドロックが発生するからです。キーサーバーは、 UID ごとに秘密鍵を格納し、ローカルの root プロセスへの要求だけを許可することによってこの問題を解決します。
サーバーは、ベリファイアをクライアントに返します。ベリファイアは、次の構成要素を持ちます。
サーバーが自分の資格キャッシュに記録するインデックス ID
対話鍵によって暗号化された、クライアントのタイムスタンプから 1 を引いたもの
タイムスタンプから 1 を引く理由は、これを無効化して、クライアントのベリファイアとして再利用できないようにするためです。
クライアントがベリファイアを受信し、そのサーバーを認証します。クライアントは、このベリファイアを送信できるのはサーバーだけであることを知っています。その理由は、クライアントが送信したタイムスタンプの内容を知っているのはサーバーだけだからです。
一番目以降のすべてのトランザクションごとに、クライアントは 2 番目のトランザクションでインデックス ID をサーバーに返し、もう 1 つの暗号化されたタイムスタンプを送信します。サーバーは、クライアントのタイムスタンプから 1 を引いたものを対話鍵で暗号化して、返送します。
システム管理者は、ネットワークを安全にするためのポリシーをネットワーク上に実装できます。必要なセキュリティのレベルはサイトによって異なります。この節では、ネットワークセキュリティに関連するいくつかの作業手順を説明します。
スーパーユーザーになります。
keyserv デーモン (キーサーバー) が動作していることを確認します。
# ps -ef | grep keyserv root 100 1 16 Apr 11 ? 0:00 /usr/sbin/keyserv root 2215 2211 5 09:57:28 pts/0 0:00 grep keyserv |
キーサーバーが動作していない場合は、キーサーバーを起動します。
# /usr/sbin/keyserv |
NIS+ セキュリティの詳細は、『Solaris ネーミングの管理』を参照してください。
スーパーユーザーになります。
/etc/nsswitch.conf ファイルを編集して、次の行を追加します。
publickey: nisplus |
NIS+ クライアントを起動します。
# nisinit -cH hostname |
hostname は、そのテーブルにクライアントマシン用のエントリを持つ、信頼されている NIS+ サーバー名です。
次のコマンドを入力して、クライアントを cred テーブルに追加します。
# nisaddcred local # nisaddcred des |
keylogin コマンドを使用して、設定を確認します。
パスワードを求めるプロンプトが出たら、この手順は成功です。
次の例は、ホスト pluto を使用して、earth を NIS+ クライアントとして設定しています。警告は無視できます。keylogin コマンドが受け付けられて、earth が Secure NIS+ クライアントとして正しく設定されていることを確認しています。
# nisinit -cH pluto NIS Server/Client setup utility. This machine is in the North.Abc.COM. directory. Setting up NIS+ client ... All done. # nisaddcred local # nisaddcred des DES principal name : unix.earth@North.Abc.COM Adding new key for unix.earth@North.Abc.Com (earth.North.Abc.COM.) Network password: xxx <Press Return> Warning, password differs from login password. Retype password: xxx <Press Return> # keylogin Password: # |
次のコマンドを入力して、ユーザーを root マスターサーバー上の cred テーブルに追加します。
# nisaddcred -p unix.UID@domainname -P username.domainname. des |
この場合、「username-domainname」はドット (.) で終了しなければなりません。
次の例は、DES セキュリティ認証をユーザー george に与えています。
# nisaddcred -p unix.1234@North.Abc.com -P george.North.Abc.COM. des DES principal name : unix.1234@North.Abc.COM Adding new key for unix.1234@North.Abc.COM (george.North.Abc.COM.) Password: Retype password: # rlogin rootmaster -l george # keylogin Password: # |
クライアント上でスーパーユーザーになります。
/etc/nsswitch.conf ファイルを編集して、次の行を追加します。
publickey: nis |
newkey コマンドを使用して、新しい鍵ペアを作成します。
# newkey -h hostname |
hostname は、クライアント名です。
次の例は、earth を Secure NIS クライアントとして設定しています。
# newkey -h earth Adding new key for unix.earth@North.Abc.COM New Password: Retype password: Please wait for the database to get updated... Your new key has been successfully stored away. # |
サーバーにスーパーユーザーとしてログインします。
ユーザー用の新しい鍵を作成できるのは、NIS+ サーバーにログインしたシステム管理者だけです。
ユーザー用の新しい鍵を作成します。
# newkey -u username |
username はユーザー名です。システムはパスワードを求めるプロンプトを出します。システム管理者は汎用パスワードも入力できます。非公開鍵は汎用パスワードで暗号化されて格納されます。
# newkey -u george Adding new key for unix.12345@Abc.North.Acme.COM New Password: Retype password: Please wait for the database to get updated... Your new key has been successfully stored away. # |
ログインして chkey -p コマンドを入力するように、ユーザーに伝えます。
これによって、そのユーザーは自分だけが知っているパスワードを使用して、自分の非公開鍵を再び暗号化できます。
earth% chkey -p Updating nis publickey database. Reencrypting key for unix.12345@Abc.North.Acme.COM Please enter the Secure-RPC password for george: Please enter the login password for george: Sending key change request to pluto... # |
chkey コマンドを使用すると、新しい鍵ペアをユーザーに作成できます。
Diffie-Hellman の publickey 認証がネットワークで有効にされていなければなりません。「Diffie-Hellman 認証で NIS+ 資格を設定する方法」と 「Diffie-Hellman 認証で NIS 資格を設定する方法」を参照してください。
スーパーユーザーになります。
Diffie-Hellman 認証でファイルシステムをマウントします。
# mount -F nfs -o sec=dh server:resource mountpoint |
Pluggable Authentication Module (PAM) フレームワークを使用すると、login、ftp、telnet などのシステムに入るためサービスを変更しなくても、新しい認証技術を「プラグイン」できるようになります。また、PAM を使用すれば、 UNIX ログインを DCE や Kerberos のような他のセキュリティ機構と統合できます。また、アカウント、セッション、およびパスワードの管理機構もプラグインできます。
PAM フレームワークを使用すると、システム管理者は任意のシステムに入るため、サービス (ftp、login、telnet、rsh など) とユーザー認証用を組み合わせることができます。次に PAM の利点をいくつか挙げます。
エンドユーザーにも使いやすい
機構が異なってもパスワードが同じであれば、パスワードを再入力する必要がない
各認証方法に関連するパスワードが異なっている場合でも、パスワードマッピング機能により、複数の認証方法で 1 つのパスワードを使用する機能
ユーザーが複数のコマンドを入力しなくても、複数の認証方法のパスワードを求めるプロンプトを出す機能
オプションパラメタをユーザー認証サービスに渡す機能
PAM は、実行時に取り外しが可能なモジュールを使用して、システムに入るためのサービスに認証を提供します。これらのモジュールは、その機能に基づき、4 つの異なるタイプに分かれます。認証、アカウント管理、セッション管理、およびパスワード管理です。スタッキング機能によって、複数のサービス経由でユーザーを認証できます。また、パスワードマッピング機能によって、ユーザーは複数のパスワードを覚えておく必要がありません。
モジュールタイプはモジュールのインターフェースを定義するため、PAM モジュールのタイプを理解することは重要です。実行時 PAM モジュールには、次の 4 つのタイプがあります。
「認証モジュール」は、ユーザーの認証を提供して、資格を設定、更新、または削除できます。認証モジュールは、ユーザーの識別に役立つ管理ツールを提供します。
「アカウントモジュール」は、パスワードの有効期限、アカウントの有効期限、およびアクセス時間制限をチェックします。アカウントモジュールは、認証モジュールでユーザーを識別した後に、そのユーザーにアクセス権を与えるべきかどうかを決定します。
「セッションモジュール」は、認証セッションの開閉を管理します。セッションモジュールは、動作を記録したり、セッション終了後のクリーンアップを実行したりできます。
「パスワードモジュール」によって、実際のパスワードを変更できます。
PAM フレームワークは、「スタッキング機能」を使用して、複数のサービスでユーザーを認証する方法を提供します。構成によって、認証方法ごとにパスワードを求めるプロンプトをユーザーに出すことも可能です。認証サービスが使用される順序は、PAM 構成ファイルで決定されます。
スタッキング機能を使用する方法では、ユーザーが複数のパスワードを覚えておかなければなりません。「パスワードマッピング機能」を使用すれば、主要パスワードから他のパスワードを復号できるので、ユーザーは複数のパスワードを覚えたり入力したりする必要はありません。各認証機構間でパスワードの同期を取るためのオプションもあります。スタック内で使用される最も安全性の低いパスワードによって各機構のセキュリティが制限されてしまうので、この方法はセキュリティの危険性を増大してしまうことに注意してください。
PAM ソフトウェアは、ライブラリ、いくつかのモジュール、および構成ファイルからなります。いくつかのシステムに入るためのコマンドまたはデーモンの新しいバージョンは、PAM インタフェースを利用できます。
図 20-1 は、アプリケーション、PAM ライブラリ、pam.conf ファイル、および PAM モジュール間の関係を示しています。
アプリケーション (ftp、telnet、および login) は、PAM ライブラリを使用して、適切なモジュールにアクセスします。pam.conf ファイルは、使用するモジュールを定義して、各アプリケーションがモジュールを使用する順番を定義します。モジュールからの応答は、ライブラリ経由でアプリケーションに戻されます。
次の節では、この関係について説明します。
PAM ライブラリ /usr/lib/libpam は、適切なモジュールをロードして、スタッキング手順を管理するためのフレームワークを提供します。また、すべてのモジュールを取り外すことができる汎用構造も提供します。
各 PAM モジュールは、特定の機構を実装します。PAM 認証を設定するときは、モジュールとモジュールタイプの両方を指定する必要があります。モジュールタイプは、モジュールが実行する処理を定義します。複数のモジュールタイプ (auth、account、session、または password) を各モジュールに関連付けることができます。
次のリストで各 PAM モジュールについて説明します。
pam_unix モジュール /usr/lib/security/pam_unix.so.1 は、認証、アカウント管理、セッション管理、およびパスワード管理に使用できます。このモジュールでは、4 種類すべてのモジュールタイプの定義が使用できます 。このモジュールは、UNIX パスワードを認証に使用します。Solaris 環境では、パスワードを取得するための適切なネームサービスの選択は、/etc/nsswitch.conf ファイルで制御されます。詳細は、pam_unix(5) のマニュアルページを参照してください。
dial_auth モジュール /usr/lib/security/pam_dial_auth.so.1 は、認証だけに使用できます。このモジュールは、/etc/dialups ファイルと /etc/d_passwd ファイルに格納されたデータを認証するのに使用します。このモジュールは主に login で使用されます。詳細については、pam_dial_auth(5) のマニュアルページを参照してください。
rhosts_auth モジュール /usr/lib/security/pam_rhosts_auth.so.1 も、認証だけに使用できます。このモジュールは、‾/.rhosts ファイルと /etc/hosts.equiv ファイルに格納されたデータを ruserok 経由で使用します。このモジュールは、主に rlogin コマンドと rsh コマンドで使用されます 。詳細については、pam_rhosts_auth(5) のマニュアルページを参照してください。
セキュリティ上の理由から、これらのモジュールファイルの所有者は root でなければならず、また、その書き込み権を group と other に与えてはなりません。ファイルの所有者が root でない場合、PAM はモジュールをロードしません。
krb5 モジュール /usr/lib/security/pam_krb5_auth.so.1 は、認証、アカウント管理、セッション管理、およびパスワード管理のサポートを提供します。認証には Kerberos 資格が使用されます。
セキュリティ上の理由から、これらのモジュールファイルの所有者は root でなければならず、また、その書き込み権を group と other に与えてはなりません。ファイルの所有者が root でない場合、PAM はモジュールをロードしません。
PAM 構成ファイル /etc/pam.conf は、使用する認証サービスとそれらを使用する順序を決定します。このファイルを編集すれば、システムに入るためのアプリケーションごとに認証機構を選択できます。
PAM 構成ファイルは、次の構文のエントリからなります。
service_name module_type control_flag module_path module_options |
service_name |
サービス名 (たとえば、ftp、login、telnet など) |
module_type |
サービスのモジュールタイプ |
control_flag |
モジュールの継続または失敗の意味を決定する |
module_path |
サービス機能を実装するライブラリオブジェクトのパス |
module_options |
サービスモジュールに渡される特定のオプション |
pam.conf ファイルにコメントを追加するには、その行を # (ポンド記号) で始めます。フィールドを区切るには、空白を使用します。
次の 3 つの状態のいずれかが存在する場合、PAM 構成ファイル内のエントリは無視されます。(1) 行のフィールド数が 4 つより少ない。(2) module_type または control_flag に無効な値が指定されている。(3) 指定したモジュールが見つからない。
表 20-1 は、有効なサービス名、そのサービスで使用できるモジュールタイプ、およびサービス名に関連するデーモンまたはコマンドを示しています。
サービスごとに適切でないモジュールタイプもいくつかあります。たとえば、password モジュールタイプは、passwd コマンドだけに指定できます。このコマンドは認証には関連しないので、このコマンドに関連する auth モジュールタイプはありません。
表 20-1 /etc/pam.conf での有効なサービス名
サービス名 |
デーモンまたはコマンド |
モジュールタイプ |
---|---|---|
dtlogin |
/usr/dt/bin/dtlogin |
auth、account、session |
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 |
rexd |
/usr/sbin/rpc.rexd |
auth |
rlogin |
/usr/sbin/in.rlogind |
auth、account、session |
rsh |
/usr/sbin/in.rshd |
auth、account、session |
sac |
/usr/lib/saf/sac |
session |
su |
/usr/bin/su |
auth、account、session |
telnet |
/usr/sbin/in.telnetd |
auth、account、session |
ttymon |
/usr/lib/saf/ttymon |
session |
uucp |
/usr/sbin/in.uucpd |
auth、account、session |
認証プロセス中にモジュールの処理を継続するか失敗するかを決定するには、エントリごとに 4 つの制御フラグの 1 つを選択しなければなりません。制御フラグは、各モジュールで正常終了と異常終了がどのように処理されるかを示します。これらのフラグはすべてのモジュールに適用されますが、次の説明では、これらのフラグは認証モジュールで使用されていると仮定します。制御フラグは、次のとおりです。
required - 最終的に成功を返すためには、このモジュールが正常終了を返さなければなりません。
すべてのモジュールに required フラグを付けた場合、ユーザーの認証が成功するには、すべてのモジュールの認証が成功しなければなりません。
一部のモジュールが失敗した場合、最初に失敗したモジュールのエラー値が報告されます。
required フラグを付けたモジュールが失敗しても、スタック中のすべてのモジュールは継続して処理されますが、異常終了が返されます。
どのモジュールにも required フラグを付けなかった場合、ユーザーの認証が成功するには、そのサービスの少なくとも 1 つのエントリが成功しなければなりません。
requisite - 後続の認証が行われるには、このモジュールが正常終了を返さなければなりません。
requisite フラグの付いたモジュールが失敗した場合、すぐにエラーがアプリケーションに返され、それ以上認証は行われません。スタック中で、このモジュールより前に required というラベルの付いたモジュールが失敗していなければ、このモジュールからのエラーが返されます。このモジュールより前に、required というラベルの付いたモジュールが失敗している場合は、required モジュールからのエラーメッセージが返されます。
optional - このモジュールが失敗した場合、このスタック内の他のモジュールが正常終了を戻せば、最終的に成功が返される可能性があります。
optional フラグは、スタック内の 1 つのモジュールが成功すればユーザーの認証が成功するときに使用します。このフラグは、この認証機構が成功することが重要でない場合だけに使用します。
ユーザーが作業をするためには、特定の機構に関連する許可を取得する必要がある場合、そのモジュールに optional フラグを付けてはなりません。
sufficient - このモジュールが成功すると、スタック内の残りのモジュールは required フラグが付いていてもスキップされます。
sufficient フラグは、1 つの認証が成功すれば、ユーザーにアクセス権を与えてもかまわないことを示します。
これらのフラグの詳細は、デフォルトの /etc/pam.conf ファイルについて説明している 「PAM の構成」を参照してください。
次の例は、汎用 pam.conf ファイルを示しています。
# PAM configuration # Authentication management # login auth required /usr/lib/security/pam_unix.so.1 login auth required /usr/lib/security/pam_dial_auth.so.1 rlogin auth sufficient /usr/lib/security/pam_rhost_auth.so.1 rlogin auth required /usr/lib/security/pam_unix.so.1 dtlogin auth required /usr/lib/security/pam_unix.so.1 telnet auth required /usr/lib/security/pam_unix.so.1 su auth required /usr/lib/security/pam_unix.so.1 ftp auth required /usr/lib/security/pam_unix.so.1 uucp auth required /usr/lib/security/pam_unix.so.1 rsh auth required /usr/lib/security/pam_rhost_auth.so.1 OTHER auth required /usr/lib/security/pam_unix.so.1 # # Account management # login account required /usr/lib/security/pam_unix.so.1 rlogin account required /usr/lib/security/pam_unix.so.1 dtlogin account required /usr/lib/security/pam_unix.so.1 telnet account required /usr/lib/security/pam_unix.so.1 ftp account required /usr/lib/security/pam_unix.so.1 OTHER account required /usr/lib/security/pam_unix.so.1 # # Session management # login session required /usr/lib/security/pam_unix.so.1 rlogin session required /usr/lib/security/pam_unix.so.1 dtlogin session required /usr/lib/security/pam_unix.so.1 telnet session required /usr/lib/security/pam_unix.so.1 uucp session required /usr/lib/security/pam_unix.so.1 OTHER session required /usr/lib/security/pam_unix.so.1 # # Password management # passwd password required /usr/lib/security/pam_unix.so.1 OTHER password required /usr/lib/security/pam_unix.so.1 |
この汎用 pam.conf ファイルは、次の内容を指定しています。
login を実行するとき、pam_unix モジュールと pam_dial_auth モジュールの両方による認証が成功しなければなりません。
rlogin を実行するとき、pam_unix モジュールによる認証が失敗した場合は、pam_rhost_auth モジュールによる認証が成功しなければなりません。
sufficient 制御フラグは、rlogin の場合は、pam_rhost_auth モジュールによる認証が成功すれば十分であり、次のエントリが無視されることを示しています。
認証を必要とする他のほとんどのコマンドの場合、pam_unix モジュールによる認証が成功しなければなりません。
rsh の場合、pam_rhost_auth モジュールによる認証が成功しなければなりません。
OTHER サービス名を使用すれば、認証を必要とするがこのファイルには含まれていない他のコマンドに対するデフォルトとして設定できます。OTHER オプションを使用すると、同じモジュールを使用する多数のコマンドを 1 つのエントリだけでカバーできるので、ファイルの管理が簡単になります。また、OTHER サービス名を「すべてを捕捉する」と言う意味で使用すると、1 つのモジュールですべてのアクセスをカバーできます。通常、OTHER エントリは、各モジュールタイプのセクションの最後に指定します。
ファイル内の残りのエントリは、アカウント、セッション、およびパスワードの管理を制御します。
デフォルトサービス名 OTHER を使用すると、汎用 PAM 構成ファイルは、次のように簡単になります。
# PAM configuration # # Authentication management # login auth required /usr/lib/security/pam_unix.so.1 login auth required /usr/lib/scurty/pam_dial_auth.so.1 rlogin auth sufficient /usr/lib/security/pam_unix.so.1 rlogin auth required /usr/lib/security/pam_rhost_auth.so.1 rsh auth required /usr/lib/security/pam_rhost_auth.so.1 OTHER auth required /usr/lib/security/pam_unix.so.1 # # Account management # OTHER account required /usr/lib/security/pam_unix.so.1 # # Session management # OTHER session required /usr/lib/security/pam_unix.so.1 # # Password management # OTHER password required /usr/lib/security/pam_unix.so.1 |
通常、module_path のエントリには「ルートからのパス名」を指定します。module_path に入力したファイル名がスラッシュ (/) で始まらない場合、そのファイル名の前にパス /usr/lib/security/ が付きます。モジュールが他のディレクトリにある場合は、フルパスを使用しなければなりません。
module_options の値については、そのモジュールのマニュアルページ (たとえば、pam_unix(5)) を参照してください。
pam_unix モジュールでサポートされている use_first_pass オプションと try_first_pass オプションを使用すると、ユーザーは認証用の同じパスワードを再入力しなくても再利用できます。
login が pam_local と pam_unix の両方による認証を指定した場合、ユーザーは、モジュールごとにパスワードを入力するようにプロンプトが表示されます。パスワードが同じ場合、use_first_pass モジュールオプションを使用すれば、パスワードの入力を求めるプロンプトは 1 度だけ表示されます。そのパスワードを両方のモジュールで使用して、ユーザーを認証します。パスワードが異なる場合、認証は失敗します。通常、このオプションは、次に示すように、optional 制御フラグといっしょに使用して、依然としてユーザーのログインが可能なようにします。
# Authentication management # login auth required /usr/lib/security/pam_unix.so.1 login auth optional /usr/lib/security/pam_local.so.1 use_first_pass |
try_first_pass モジュールオプションを代わりに使用すると、パスワードが一致しなかった場合またはエラーが発生した場合、ローカルモジュールは、2 番目のパスワードを求めるプロンプトを表示します。必要なすべてのツールにアクセスするために、ユーザーが両方の認証方法を必要とする場合、このオプションを使用すると 1 つのタイプの認証だけでアクセスできるので、ユーザーが混乱する場合があります。
この節では、PAM のフレームワークを完全に機能させるために必要な作業について説明します。特に、PAM 構成ファイルに関連するセキュリティのいくつかの問題について注意する必要があります。
どのように PAM を使用すればユーザーのサイトに最適であるかを決定するために、次の問題から始めます。
何が必要か、特にどのモジュールを選択するかを決定します。
特別な注意が必要なサービスを確認します。適宜、OTHER を使用します。
モジュールを実行する順番を決定します。
そのモジュールに対する制御フラグを選択します。
モジュールに必要な任意のオプションを選択します。
ここで、構成ファイルを変更する前に考慮すべき問題を示します。
すべてのアプリケーションを指定しなくてもいいように、モジュールタイプごとに OTHER エントリを使用します。
sufficient 制御フラグと optional 制御フラグのセキュリティの意味を考慮します。
モジュールに関連するマニュアルページを参照して、各モジュールがどのように機能するか、どのオプションが使用できるか、およびスタック中のモジュール間の相互作用を理解します。
PAM 構成ファイルの構成を間違えたり壊したりすると、スーパーユーザーでもログインできなくなる可能性があります。sulogin は PAM を使用しないので、スーパーユーザーは、マシンをシングルユーザーモードでブートして問題を解決しなければなりません。
/etc/pam.conf ファイルの変更後、スーパーユーザーとしてログインしている間にできるだけ調査します。変更によって影響を受けるコマンドは、すべてテストします。たとえば、新しいモジュールを telnet サービスに追加した場合、telnet コマンドを使用して、行なった変更が期待どおりに動作しているかどうかを確認します。
スーパーユーザーになります。
使用される制御フラグやオプションを決定します。
モジュールについては、「PAM モジュール」を参照してください。
新しいモジュールを /usr/lib/security にコピーします。
モジュールファイルの所有者が root で、そのアクセス権が 555 になるように、アクセス権を設定します。
PAM 構成ファイル /etc/pam.conf を編集して、このモジュールを適切なサービスに追加します。
構成ファイルが間違って構成されていた場合などのために、システムをリブートする前にテストすることは非常に重要です。システムをリブートする前に、rlogin、su、および telnet を実行します。サービスが、システムがブートするときだけに生成されるデーモンの場合は、システムをリブートしなければ、モジュールが正しく追加されていることを確認できません。
PAM 構成ファイルから「rlogin auth rhosts_auth.so.1」エントリを削除します。これによって、rlogin セッション中、‾/.rhosts ファイルは読み込まれなくなります。したがって、リモートシステムからローカルシステムへの認証されていないアクセスを防ぐことができます。‾/.rhosts ファイルまたは /etc/hosts.equiv ファイルの存在またはその内容にかかわらず、すべての rlogin アクセスにはパスワードが必要になります。
‾/.rhosts ファイルへの承認されていない他のアクセスを防ぐには、rsh サービスも無効にする必要があります。サービスを無効にする最良の方法は、/etc/inetd.conf からサービスエントリを削除することです。PAM 構成ファイルを変更しても、サービスを無効にはできません。
/etc/syslog.conf を編集して、次の PAM のエラー報告に関するエントリを追加します。
syslog デーモンを再起動するか、SIGHUP シグナルをこのデーモンに送信して、PAM のエラー報告を有効にします。
次の例では、警戒メッセージはすべてコンソールに表示されます。致命的なメッセージは root に電子メールで送信されます。情報メッセージとデバッグ用メッセージは、/var/log/pamlog ファイルに追加されます。
auth.alert /dev/console auth.crit 'root' auth.info;auth.debug /var/log/pamlog |
ログ内の各行は、タイムスタンプ、メッセージを生成したシステム名とメッセージ自身からなります。pamlog ファイルには、大量の情報が記録される可能性があります。