この付録には,次の情報があります。
エンハンスト・セキュリティをインストールするには,オプションのエンハンスト・セキュリティ・サブセット (OSFC2SECnnn
および
OSFXC2SECnnn
) をインストールする必要があります。
エンハンスト・セキュリティ・サブセットをインストールする前に,万が一のために,ルート・ファイル・システムのバックアップ・コピーを作成してください。バックアップを実行するには,次のいずれかのコマンドを使用します (dump
は UFS ファイル・システムでのみ使用可能)。
# dump -0uf /dev/rmt0h /
または
# vdump -0Nuf /dev/rmt0h /
ご使用のシステム環境に合わせてテープ・デバイス名を変更してください。ファイル・システムのバックアップの詳細については,『システム管理ガイド』 を参照してください。
次の方法で,エンハンスト・セキュリティ・サブセットをインストールできます。
Tru64 UNIX (アドバンストまたはベーシック) オペレーティング・システム・ソフトウェアのフル・インストレーション時。フル・インストレーションでは,root アカウントでシステムが起動されます。アカウントを追加する前に
secconfig
スクリプトを実行してください。
Tru64 UNIX の旧バージョンからオペレーティング・システム・ソフトウェアからシステムをアップデートする場合は,アップデート・インストレーション時。アップデート・インストレーション時,すべてのユーザ・アカウントとデータベースが保持されます。secconfig
プログラムを実行すると,これらのデータがエンハンスト・セキュリティ形式に変換されます。
セキュリティ・サブセットをインストールすると,次のようなメッセージが表示されます。
Configuring "C2-Security " (OSFC2SECnnn) Configuring "C2-Security GUI " (OSFXC2SECnnn)
パスワードの平凡性チェックを有効にする場合は,OSFDCMTEXTnnn サブセットもインストールする必要があります。サブセットのインストールの詳細については,『インストレーション・ガイド』 を参照してください。
nnn
は,Tru64 UNIX のバージョン番号です。現在のバージョン番号は,『リリース・ノート』 を参照してください。
A.2 エンハンスト・セキュリティの有効化
secconfig
ユーティリティは対話型プログラムであり,システムのセキュリティ・レベル (「BASE」と「ENHANCED」) を有効にすることができます。システムがマルチユーザ・モードのときでも,このプログラムを実行することができます。ただし,選択したセキュリティ機能によっては,secconfig
が完了するときにセキュリティ機能を変更する必要があります。その場合はシステムをリブートする必要があります。
エンハンスト・セキュリティを有効にするには,次の手順を実行します。
エンハンスト・セキュリティ・サブセット (OSFC2SECnnn
および
OSFXC2SECnnn
) がインストールされていることを確認します。
# /usr/sbin/setld -i | grep SEC OSFC2SECnnn installed C2-Security (System Administration) OSFXC2SECnnn installed C2-Security GUI (System Administration)
nnn は,サブセットの現在のバージョン番号を表す数値です。現在のバージョン番号は,『リリース・ノート』 を参照してください。
secconfig
ユーティリティを使い,次の方法でエンハンスト・セキュリティを有効にします。
/usr/sbin/sysman secconfig
コマンドを入力し,セキュリティ・レベルの入力が求められたら,ENHANCED セキュリティを選択します。
CDE を使い,「アプリケーション・マネージャ」 --> 「システム管理」 --> 「システム設定」 --> 「セキュリティ設定」を選択します。「セキュリティ設定」を選択すると,エンハンスト・セキュリティが有効になります。
エンハンスト・セキュリティを有効にする際の留意点については,A.2.1 項 を参照してください。
システムをシングルユーザ・モードにしてリブートします (シャットダウン・メッセージにより,すぐにパスワードを変更する必要があることをユーザに伝える必要があります)。
保護パスワード・デーモン (/usr/bin/prpasswdd
) があるかどうかで,エンハンスト・セキュリティが有効になっているかどうかが分かります。
A.2.1 エンハンスト・セキュリティを有効にする際の留意点
以下の項では,エンハンスト・セキュリティを有効にする際の留意点について説明します。
A.2.1.1 NIS の使用
システムが NIS (Network Information Service) で提供されるパスワード・データベースを使用する場合,NIS サーバのパスワード・データベースに登録されているユーザごとに,ローカルのエンハンスト認証プロファイルを作成するよう求められます。その後に変更した NIS パスワードは,データベースに伝達されません。ローカル・システムにあるエンハンスト・パスワードは期限切れとなり,ユーザは次回のログイン時に新しいパスワードを入力する必要があります。
セキュリティ・レベルを基本セキュリティに戻すと,エンハンスト認証プロファイルのファイルはそのまま残されます。再度 ENHANCED セキュリティに戻すと,エンハンスト認証プロファイルのファイルがありそれにパスワードがある限り,エンハンスト・パスワードは更新されます。
エンハンスト・セキュリティと NIS の使用についての詳細は,A.6 節
を参照してください。
A.2.1.2 セグメントの共用
シェアード・ライブラリではページ・テーブル共用メカニズムが使用されるため,通常のファイル・システムのアクセス許可では,承認されていない読み込みから保護することはできません。たとえば,ユーザ
joe
が次のシェアード・ライブラリを所有しているとします。
-rw------- 2 joe staff 100000 Sep 18 1997 /usr/shlib/foo.so
このシェアード・ライブラリをプログラム内で使用している場合,foo.so
のテキスト部分は,ユーザ
joe
として実行していなくても,他の実行中のプロセスから見えてしまいます。ライブラリのテキスト部分のみこの方法で共用されます。データ・セグメントは共用されません。
すべてのセグメンテーションを無効にして承認されていない共用を回避するには,secconfig
でセグメントの共用を無効にするか尋ねられたときに "yes" と応えてください。セグメントの共用がすでに無効のときは,secconfig
スクリプトがそのことを報告します。
注意
セグメントの共用を無効にすると,メモリの使用量が大きく増加します。
A.2.1.3 Execute Bit Set Only By Root
execute bit set only by root
オプションを有効にすると,root ユーザのみがファイルの実行許可を設定できるようになります。
A.2.2 エンハンスト・セキュリティの構成
エンハンスト・セキュリティでは,ユーザ,端末,およびデバイスに適用するシステム省略時設定を指定できます。後述の項に,よく使用する省略時の設定とその構成方法について説明します。
システム省略時設定は,/etc/auth/system/default
の省略時設定データベースに保存されます。このデータベースには,4 種類のフィールドがあります。
省略時設定データベースのみに存在するシステム単位のフィールドこれらのフィールドには
d_
という接頭辞が付きます。
ユーザ省略時設定フィールド この値は,ユーザのプロファイルの対応するフィールドによって置き換えることができます。これらのフィールドには
u_
という接頭辞が付きます。
端末制御フィールド この値は,端末制御データベースの対応するフィールドによって置き換えることができます。これらのフィールドには
t_
という接頭辞が付きます。
デバイス割り当てフィールド この値は,デバイス割り当てデータベース・ファイルの対応するフィールドによって置き換えることができます。これらのフィールドには
v_
という接頭辞が付きます。
次のインタフェースを使い,エンハンスト・セキュリティ関連のユーザ,端末,デバイス設定の省略時の値を変更します。
dxaccounts
GUI では,「Local Templates」 --> 「Default」を選択して,ユーザ用の省略時設定フィールドを変更します。
dxdevices
の GUI では,デバイス用の省略時設定フィールドを変更します。
edauth
ユーティリティにより,省略時設定フィールドすべてに下位レベル・インタフェースが提供されます。
ファイル形式およびフィールド値については
authcap
(4)edauth
の使用については
edauth
(8)default
(4)prpasswd
(4)ttys
(4)devassign
(4)A.2.2.1 有効期間
システム上でパスワードの有効期間の設定を行わない場合,default
データベースで
u_exp
および
u_life
を 0 に設定します。パスワード長の制限を決定する省略時の方法はパスワードの有効期間に基づいているため,さらに
u_minchosen
および
u_maxchosen
をサイトにとって適切な値に設定します。
エントリの例を次に示します。
:u_exp#0:u_life#0:u_minchosen#5:u_maxchosen#32:\
u_minchg
フィールドを次のように 0 にすると,最短の変更時間間隔を削除できます。
:u_minchg#0:\
これにより,ユーザはパスワードを変更した後,すぐにまたパスワードを変更できるようになります。
A.2.2.3 変更制御
サイトのニーズに応じて,パスワード変更制御を構成することができます。default
データベースに次のフィールドを入力すると,ユーザにパスワードの変更方法を選択させることができます。
:u_pickpw:u_genpwd:u_genchars:u_genletters:u_restrict:\ :u_policy:u_nullpw:u_pwdepth#0:\
(上記フィールドのうち,u_pwdepth
は数値,それ以外は論理値となります。論理値フィールドは,指定されていれば真,その後に @ があれば偽となります。)
A.2.2.4 ログインの最大試行回数
侵入検出のために,連続的なログイン失敗の回数がカウントされ,ユーザ (u_maxtries
) や端末 (t_maxtries
) ごとに設定された最大回数と比較されます。最大回数を超えた場合,u_unlock
や
t_unlock
で指定した時間の間,そのユーザ・アカウントまたは端末でのログインが無効となります。ユーザ・アカウントに対する侵入保護を無効にするには,u_maxtries
を 0 にします。端末に対する侵入保護を無効にするには
t_maxtries
を 0 にします。ユーザに対する
default
データベースのエントリの例を次に示します。
:u_maxtries#0:\
省略時の侵入保護時間 (86400 秒つまり 24 時間) がサイトに適していない場合,u_unlock
フィールドをサイトに適した値 (u_maxtries
上限に達したときに,直前のログイン失敗後に正常ログインが認識されるまでの秒数) に変更します。u_unlock
フィールドを 0 (:u_unlock#0:
)に設定すると,ログイン試行間隔の時間は無限 (自動的に再度使用可能になることはない) に設定されます。t_maxtries
を使用すれば,端末に対しても同じような動作を制御できます。
A.2.2.6 ログインの時間間隔
default
データベースの
u_max_login_intvl
フィールドにより,システム全体のログイン間隔の最大許容時間を設定することができます。
端末に対するシステムの省略時設定のログイン・タイムアウトは,default
データベースの
t_login_timeout
フィールドで変更できます。ttys
データベースの * エントリでも設定することができます。X windows では,このフィールドを 0 (無限) にする必要があります。
A.2.2.7 端末ごとのログイン・レコード
端末ごとの正常ログインおよびログイン失敗を記録しない場合,default
データベースの
d_skip_ttys_updates
論理フィールドを次のとおり設定します。
:d_skip_ttys_updates:\
この場合,端末ごとの侵入保護が無効になる副作用があります。
A.2.2.8 正常ログインのロギング
厳密な C2 セキュリティでは,正常ログインのロギングが必要になります。このロギングを無効にするには,d_skip_success_login_log
論理フィールドを次のように設定します。
:d_skip_success_login_log:\
通常,ユーザ・アカウントへのログイン失敗は,記録されます。このロギングを無効にするには,d_skip_fail_login_log
論理フィールドを次のように設定します。これにより,システム全体での侵入検出および侵入保護も無効になります。
:d_skip_fail_login_log:\
d_auto_migrate_users
論理フィールドを設定すると,ログイン時にエンハンスト・プロファイルがなければ自動的に作成することが可能になります。これにより,従来のユーザ・プロファイルの追加方法をそのまま使用できます。
A.2.2.11 保証機能
d_accept_alternate_vouching
フィールドを設定すると,エンハンスト・セキュリティと DCE を一緒に使用することができます。
A.2.2.12 暗号化
crypt
() を使用してパスワード確認を行うプログラムをサポートするために,ユーザ・パスワードを
/etc/passwd
ファイルに残したまま,エンハンスト・プロファイルの他の機能を使用する場合,/usr/sbin/sysman secconfig
ユーティリティを実行する前に
default
データベースに次のエントリを入力します。
:u_newcrypt#3:\
これは,<prot.h>
ファイルの AUTH_CRYPT_C1CRYPT 値に対応しています。
A.3 エンハンスト・セキュリティ・データベース
表 A-1
にエンハンスト・セキュリティ・データベースを示します。
表 A-1: エンハンスト・セキュリティ・データベース
データベース | 保存場所 | 内容 |
保護パスワード | /tcb/files/auth.db
/var/tcb/files/auth.db |
ユーザ認証データベース |
システム省略時設定 | /etc/auth/system/default |
データベース・フィールドの省略時の値 |
端末制御 | /etc/auth/system/ttys.db |
各端末のセキュリティ情報 |
ファイル制御 | /etc/auth/system/files |
システム・ファイルごとの保護属性 |
デバイス割り当て |
/etc/auth/system/devassign |
デバイスに固有の制御 |
A.3.1 エンハンスト (保護) パスワード・データベース
保護パスワード・データベースには,システム上にアカウントを持つ各ユーザのエンハンスト認証プロファイルが格納されています。各プロファイルには,次のような情報が含まれます。
ユーザ名とユーザ ID
暗号化されたパスワード
ユーザの監査属性
パスワード生成パラメータ
正常ログインおよびログイン失敗の日時および端末
エンハンスト (保護) パスワード・データベースは
/tcb/files/auth.db
ファイルに格納されています。
エンハンスト・パスワード・データベースの内容の詳細については,
prpasswd
(4)A.3.2 システム省略時設定データベース
システム省略時設定データベースには,データベース・フィールドの省略時の値が格納されています。エンハンスト (保護) パスワード・データベース,端末制御データベース,またはデバイス割り当てデータベースに管理者が明示的に値を設定していない場合に,これらの省略時の値が使用されます。
システム省略時設定データベースには,以下の情報が含まれます。
省略時のパスワード生成パラメータ
ユーザごとに設定される,ログイン失敗の省略時の回数
直接接続されている端末ごとに設定される,許されるログイン失敗の省略時の回数
省略時のデバイス割り当てパラメータ
システム省略時設定データベースは
/etc/auth/system/default
に格納されています。詳細については,
default
(4)A.3.3 端末制御データベース
端末制御データベース には,システムに接続された各端末のログイン処理を制御するための情報が格納されています。システムは,端末からシステムへのアクセスを制御するための追加情報としてこのデータベースを使用します。管理者はサイトの物理的なニーズおよび管理上のニーズに合わせて,端末ごとに異なるログイン・ポリシを設定することができます。
端末制御データベースの各エントリには,次のような情報が含まれます。
端末のデバイス名
その端末から最後に正常ログインしたユーザ ID およびタイム・スタンプ
その端末で最後にログインに失敗したユーザ ID およびタイム・スタンプ
その端末からログインする際の,ログイン間の遅延
その端末をロックするまでに許されるログイン失敗の回数
システムのインストール完了時には,端末制御データベースにシステム・コンソールのエントリが格納されています。システム設定時にこれらの初期値を変更します。ログインするためには,これも最初にインストールされる対応するエントリがデバイス割り当てデータベースに必要になります。
端末制御データベースは
/etc/auth/system/ttys.db
に格納されています。詳細については,
ttys
(4)A.3.4 ファイル制御データベース
ファイル制御データベース には,システム・ファイル (つまりエンハンスト・セキュリティの動作に必要なファイル) の保護属性の情報が格納されています。このデータベースはシステムの完全性を維持するのに役立ちます。システム・ファイルごとに 1 つのエントリが含まれます。
ファイル制御データベースの各エントリには,次のような情報が含まれます。
ファイルの完全パス名
ファイルの所有者およびグループ
ファイルのモードおよびタイプ
承認可能な特権セットおよび承認された特権セット
アクセス制御リスト
システムのインストールが完了したときには,ファイル制御データベースにセキュリティ関連の全システム・ファイルのエントリが格納されています。システム設定時にはこのデータベースを変更する必要はありませんが,まれにシステム動作時にこのデータベースのアップデートを行う必要があります。
/etc/auth/system/files
ファイルの内容の詳細については,
files
(4)A.3.5 デバイス割り当てデータベース
デバイス割り当てデータベースには, ユーザとのデータ交換に使用するデバイスについての情報が格納されています。ログイン端末ごとに 1 つのエントリが,デバイス割り当てデータベース内に必要です。システムは,システム・デバイスで送受信されるデータのセキュリティ属性を制限するのにこのデータベースを使用します。
デバイス割り当てデータベースの各エントリには,デバイスを記述する情報と,デバイスのパス名を適切な物理デバイスに対応付けるための情報が含まれます。これは,いくつかの 異なるパス名が同じ物理デバイスを参照することがあるため必要となります。たとえば,2 つのパス名が同じシリアル・ポートに対応することがあります。一方のパス名ではモデム制御を有効にし,もう 一方のパス名ではモデム制御を無効にすることが考えられます。
デバイス割り当てデータベースの各エントリには,次のような情報が含まれます。
デバイスのパス名
同じ物理デバイスに対応する他のパス名
デバイスの種類
ログイン端末を参照するエントリには,対応するエントリが端末制御データベースに必要です。
デバイス割り当てデータベースは
/etc/auth/system/devassign
に格納されています。詳細については,
devassign
(4)A.4 エンハンスト・セキュリティ・データベースの管理ユーティリティ
Tru64 UNIX には,Berkeley データベース (Berkeley DB) の カスタム・バージョンが組み込まれており,重要なセキュリティ・ファイルに対する高性能なデータベース・サポートを提供します。DB 機能には,事前書き出しのロギングおよびチェックポイントを使用して変更内容を記録する,完全なトランザクション・サポートおよびデータベース・リカバリが含まれます。重大な障害が発生した場合,データベース・ファイルをリストアし,ログをロール・フォワードすることにより,セキュリティ・データベースは直前の一貫性のあるトランザクション状態に復元できます。
エンハンスト・セキュリティには,以下のデータベース管理ユーティリティが含まれており,/usr/tcb/bin
ディレクトリに格納されています。
db_archive
アクティブなトランザクションで使用されなくなったエンハンスト・セキュリティ・データベース・ログ・ファイルを表示します。/var
の領域を回復するために,このファイルを安全にバックアップして,削除できます。
db_checkpoint
メモリの内容を書き出し,ログにチェックポイント・レコードを書き込んで,ディスクにログを書き出す。
db_load
ファイルまたは標準入力から読み込み,データベースにロードします。
db_unload
データベースをファイルにアンロードします。
db_stat
セキュリティ・データベースの統計情報を表示します。
db_recover
予期しない障害が発生した後,データベースを矛盾しない状態に復元します。
通常,セキュリティ・データベースはインストレーション・ユーティリティでのみロードまたはアンロードされます。データベースは,データベース管理作業を軽減するように設計されていますが,セキュリティ・データベースのログ・ファイルを追加すると,ログ・ファイルが拡大して
/var
の空き領域がなくなる可能性があります。このため,セキュリティ構成ユーティリティには,cron
ジョブを作成して,アクティブなトランザクションで使用されなくなったログ・ファイルを定期的に削除するオプションがあります。
A.5 エンハンスト・セキュリティおよびユーザの認証
エンハンスト・セキュリティを稼働させているシステムは,/etc/passwd
ファイルとエンハンスト・セキュリティ・データベースを使ってユーザの認証を行います。エンハンスト・セキュリティ・データベースは以下のデータベースから構成されています。
保護パスワード・データベース (/tcb/files/auth.db
および
/var/tcb/files/auth.db
)
システム省略時設定データベース (/etc/auth/system/default
)
エンハンスト・セキュリティの認証データベースには,/etc/passwd
に定義されているユーザ・アカウントごとに 1 つのエントリがあります。エンハンスト・セキュリティでは,暗号化されたパスワードを除き
/etc/passwd
ファイルは変更されていません。暗号化されたパスワードは
/etc/passwd
ファイルから
auth.db
データベースに移動しています。/etc/passwd
ファイルの他のフィールド (シェルなど) はそのまま
/etc/passwd
ファイルにあり,通常の方法で使用されます。
エンハンスト・セキュリティの認証データベースでは,ユーザ名および UID によって各ユーザを一意に識別します。これらの情報は
/etc/passwd
ファイルのユーザのエントリと一致する必要があります。暗号化されたパスワード以外に,エントリにはエンハンスト・セキュリティでのみ使用する一連のフィールドおよび値が含まれます。これらのフィールドの説明については
prpasswd
(4)authcap
(4)
ユーザ・アカウントはテンプレート・アカウントと関連付けることができます。このテンプレート・アカウントを使用すると,ユーザのグループに省略時の値を設定することができます。アカウントは最終的に,/etc/auth/system/default
ファイルに保存されているシステム省略時設定テンプレートの値と関連付けられます。
エンハンスト・セキュリティを使用している場合,ユーザは
passwd
コマンドの使用を続行して自分のパスワードを変更します。
A.5.1 ユーザ・プロファイル
エンハンスト・セキュリティの認証データベースにあるユーザのエントリは,ユーザ・プロファイルと呼ばれます。セキュリティ対応プログラムは,プロファイル内のフィールドおよび値を解釈します。ユーザ・プロファイルにはすべてのフィールドを含める必要はありません。フィールドがユーザ・プロファイルに指定されていない場合,システムはそのユーザに対応付けられたテンプレート・アカウントを参照し,最終的にシステム省略時設定テンプレートを参照して,フィールドの値を見つけます。
値は次のように取得されます。
ユーザ・プロファイルにユーザ固有の値があれば,その値を使用します。
ユーザ・プロファイルにテンプレート・アカウントへの参照があり,ユーザ固有の値が定義されていない場合,テンプレート・アカウントの値が使用されます。
フィールドの値がユーザ・プロファイルとテンプレート・アカウントのいずれにも定義されず,システム省略時設定テンプレートにそのフィールド値が定義されている場合,システム省略時設定テンプレートの値が使用されます。
値がどこにも定義されていない場合,そのフィールドに対する静的なシステム省略時設定が使用されます。
システム省略時設定テンプレートの値は
/etc/auth/system/default
ファイルにあり,dxaccounts
の「View Local Template」オプションまたは
edauth
ユーティリティを使って変更することができます。他のテンプレート・アカウントは
auth.db
データベースに保存されます。テンプレート・アカウントには,/etc/passwd
に対応するエントリがないことに注意してください。
A.5.1.1 /etc/passwd 情報の回復
/etc/passwd
ファイルが失われたとしてもエンハンスト・プロファイルがあれば,次のコマンド・シーケンスを使用して,失われたデータの一部を回復することができます。
# bcheckrc # /tcb/bin/convuser -dn | /usr/bin/xargs /tcb/bin/edauth -g | \ sed '/:u_id#/!d;s/.*:u_name=//;s/:u_id#/:*:/;s/:u_.*$/:/' \ > psw.missing
これにより,次のようなエントリを含む
psw.missing
ファイルが作成されます。
root:*:0: jdoe:*:1000:
1 次グループ情報,finger 情報,ホーム・ディレクトリ,およびログイン・シェルはエンハンスト・プロファイルに記録されません。これらのフィールドのデータは,別の方法で回復する必要があります。
A.5.2 エンハンスト・セキュリティ認証データベースの完全性チェック
/usr/tcb/bin/authck
コマンドを使って,
エンハンスト・セキュリティ認証データベースの全体構成および内部の一貫性をチェックします。authck
コマンドは,各データベースのエントリの正当性をチェックし,他のデータベースの関連フィールドのチェックも行います。たとえば,ユーザの保護パスワード・データベース・エントリを
/etc/passwd
ファイルと照合します。
authck
コマンドは,データベース間の矛盾をリストしたレポートを生成します。プログラムの出力結果と実際のデータベースのエントリを比較し,矛盾点を直ちに修正してください。問題が発生するのは,通常,データベースの 1 つを手作業で更新し,関連するデータベースに必要な変更を行わなかった場合です。
authck
コマンド行では,次の引数を指定することができます。
-p
保護パスワード・データベースおよび
/etc/passwd
ファイルをチェックし,これらが完全で,矛盾していないことを確認します。また,保護パスワード・データベースに適切な値が設定されているかチェックします。
-t
端末制御データベースのフィールドに適切な値が設定されているかチェックします。
-f
ファイル制御データベースの構文および指定値の誤りをチェックします。このフラグを指定しない場合,エントリに不明な承認指定やユーザ名などが指定されていても無視されます。通常このような誤りは,"root" の代わりに "rooot" と入力したといった入力ミスが多いため,プログラムでは正しい値を推測しようとします。
-v
冗長モード。
-a
-f
,-p
,-t
,および
-v
の機能を実行します。実行中にプログラムの処理ステータスが表示されます。
詳細については,
authck
(8)A.5.3 ファイル制御データベースへのアプリケーションの追加
setld
プログラム以外の方法でシステムにアプリケーションを追加する場合,アプリケーションの制御ファイルとデータベース・ファイルおよびプログラムについて,ファイル制御データベースのエントリを追加する必要があります。アプリケーション供給元に相談し,ファイルおよびプログラムの一覧,そして全ファイルに推奨される保護属性を入手することをお勧めします。
アプリケーションのファイルをファイル制御データベースに追加すると,アプリケーションのリソースの完全性を定期的にチェックすることができます。
ファイルの完全性チェックについての詳細は,
fverify
(8)A.6 エンハンスト・セキュリティと NIS
NIS (Network Information Service) を使用すると,エンハンスト (保護) パスワード・データベースの一部または全部を配布できます。同様に,BSD ユーザ・アカウント・データベースやグループ・データベースを配布することもできます。Tru64 UNIX の NIS マスタは,エンハンスト・セキュリティが稼動している Tru64 UNIX システムである NIS クライアントのほか,他メーカのシステムを含め,BSD 認証を使う NIS クライアントにサービスを提供できます。
エンハンスト・セキュリティで NIS を使用すると,以下のユーザ・アカウント・データベースを持つことになります。
NIS マスタ・サーバ上:
/var/yp/src/passwd
および
/var/yp/src/group
ファイルから生成され,ndbm
または
btree
マップとして配布される NIS 配布型の基本ユーザ・アカウント・データベース。
/var/yp/src/prpasswd
ファイルから生成され,btree
マップとして配布される NIS 配布型のエンハンスト・セキュリティ・ユーザ・アカウント・データベース。
NIS クライアント上:
/etc/passwd
および
/etc/group
ファイルにあるローカルの基本ユーザ・アカウント・データベース
ローカルのエンハンスト・セキュリティ・ユーザ・アカウント・データベース
図 A-1
に,NIS マスタ・サーバおよびクライアント上のユーザ・アカウント・データベースを示します。
図 A-1: NIS およびエンハンスト・セキュリティ・ファイル
/etc/svc.conf
ファイルの
auth=
エントリにより,ローカルのユーザ・アカウント・データベースおよび NIS エンハンスト・セキュリティ・ユーザ・アカウント・データベースでユーザ・エントリを検索する順序を指定します。ローカルが先か,NIS (yp) が先かのいずれかになります。
/etc/passwd
エントリでの + 符号による置き換え機能も同じように動作します。
注意
NIS を使用した基本セキュリティ・システムをエンハンスト・セキュリティ・システムにアップグレードする際,Create Entries for NIS Users という質問に yes と答えると,
/usr/sbin/sysman secconfig
ユーティリティは NIS ユーザ (/etc/passwd
ファイルの+username
エントリ) に対してauth.db
エントリのみを作成します。
エンハンスト・セキュリティ・ユーザ・アカウント・データベースには置き換え機能がありません。ユーザのプロファイルは,ローカル・データベースと NIS 配布データベースのいずれかにすべて含まれます。NIS アカウント用のテンプレートを定義し,NIS エンハンスト・セキュリティ・マップの一部として配布することはできますが,NIS はシステム省略時設定のテンプレート (/etc/auth/system/default
) を配布しません。このテンプレートにより,ユーザのプロファイルに指定されていないフィールドに対して最終省略時設定が提供されます。したがって,エンハンスト・セキュリティでは,NIS クライアントはそれぞれの
/etc/auth/system/default
ファイルを使用して,ローカルのユーザ・プロファイルおよび NIS ユーザ・プロファイル両方の最終省略時設定を取得します。クライアントのシステム省略時設定ファイルに NIS マスタと異なる値が設定されている場合,予期しない動作をすることがあります。
passwd
コマンドは,ユーザのローカル・エントリまたは NIS エンハンスト・セキュリティ・エントリにあるパスワードを変更します。yppasswd
コマンドは,NIS 配布型の基本ユーザ・アカウント・データベースのフィールドを通常どおりに変更します。
NIS ユーザ・アカウントを変更するには,dxaccounts
の「View NIS User」オプションを使用するか,または
useradd
,usermod
および
userdel
ユーティリティに
-x distributed=1 local=0
オプションを指定して実行します。
NIS の詳細については,『ネットワーク管理ガイド:サービス編』 を参照してください。
A.6.1 NIS アカウント用テンプレート
/var/yp/src/prpasswd
ファイルは,NIS で配布されるエンハンスト・セキュリティ・ユーザ・アカウントのソースです。このファイルには,テンプレート・プロファイルと通常のユーザ・プロファイルを含めることができます。ローカルのユーザ・プロファイルと同様,NIS ユーザ・プロファイルにすべてのフィールドを含める必要はありません。NIS ユーザのプロファイルに指定されていないフィールドがある場合,システムはフィールドの値が見つかるまで,そのユーザに対応する NIS テンプレート・アカウントを参照し,最終的にローカルのシステム省略時設定テンプレートを参照します。
値は次のように取得されます。
ユーザ・プロファイルにユーザ固有の値があれば,その値を使用します。
ユーザ・プロファイルにテンプレート・アカウントへの参照があり,ユーザ固有の値が定義されていない場合,テンプレート・アカウントの値が使用されます。
フィールドの値がユーザ・プロファイルとテンプレート・アカウントのいずれにも定義されず,システム省略時設定テンプレートにそのフィールド値が定義されている場合,システム省略時設定テンプレートの値が使用されます。
値がどこにも定義されていない場合,そのフィールドに対する静的なシステム省略時設定が使用されます。
NIS テンプレート・アカウントを変更するには,dxaccounts
の「View NIS Template」オプションまたは
edauth
ユーティリティを使用します。
システム省略時設定テンプレートの値は,NIS クライアントの
/etc/auth/system/default
ファイルに格納されています。NIS では,システム省略時設定テンプレートは配布されないことに注意してください。NIS クライアントは自分の
/etc/auth/system/default
ファイルを使用して,ローカルのユーザ・プロファイルと NIS ユーザ・プロファイルの両方の最終省略時設定を取得します。クライアントのシステム省略時設定ファイルに NIS マスタと異なる値が含まれる場合,予期しない動作をすることがあります。
A.6.2 エンハンスト・セキュリティ環境での NIS マスタ・サーバの構成
エンハンスト・セキュリティ環境で NIS マスタを構成するには,次の手順を実行します。
マスタ・サーバ上で NIS が動作している場合は,次のように停止します。
# /sbin/init.d/nis stop
エンハンスト・セキュリティ・サブセットがインストールされているか確認します。
システム省略時設定テンプレートを,以下のように変更します。
# edauth -dd default
次のフィールドを設定します。
d_skip_success_login_log: d_skip_ttys_updates:
/var/yp/src/hosts
,/var/yp/src/passwd
,/var/yp/src/group
,および
/var/yp/src/prpasswd
ファイルを作成します。
sysman nis
プログラムを実行します。
sysman nis
プログラムによって最初にセキュリティ (ypbind
の
-s
オプション) の入力が求められたら,y
を選択して
ypbind -s
を実行し,セキュア・ソケットを指定します。
sysman nis
プログラムによって再度セキュリティ (ypbind
の
-S
オプション) の入力が求められたら,y
を選択し,ドメイン名 1 つと承認されたスレーブ・サーバを 4 つまで指定します。
/etc/svc.conf
ファイルに次のエントリがあることを確認します。
auth=local,yp
NIS を起動します。
# /sbin/init.d/nis start
A.6.2.1 手作業:小規模ユーザ・アカウント・データベースのマップ
エンハンスト・セキュリティを使ってクライアントをサポートする NIS マスタ・サーバでは,手作業での設定が最適です。dxaccounts
プログラム,または代わりに
adduser
,addgroup
,useradd
,userdel
および
usermod
コマンドを使用して,アカウント・マップを設定します。アカウントを設定する別の方法については,A.6.5 項
を参照してください。
A.6.2.2 自動処理:大規模ユーザ・アカウント・データベースのマップ
既存の NIS 配布型の基本ユーザ・アカウント・データベースが大規模な場合,次のコマンドを入力して,NIS 配布型のエンハンスト (保護) パスワード・データベースを自動で作成できます。
# convuser -Mc
別の方法として,/var/yp/src/prpasswd
ファイルを作成して次のコマンドを実行しても,マップを作成することができます。
# /usr/tcb/bin/edauth -Lg > /var/yp/src/prpasswd # cd /var/yp; make prpasswd
A.6.3 エンハンスト・セキュリティ環境での NIS スレーブ・サーバの設定
NIS がスレーブ・サーバ上で稼働している場合,/sbin/init.d/nis stop
コマンドを使って NIS を停止する必要があります。次の設定手順は,エンハンスト・セキュリティを使用するクライアントをサポートする NIS スレーブ・サーバに固有のものです。
エンハンスト・セキュリティ・サブセットがインストールされていることを確認します。
システム省略時設定テンプレートを,以下のように変更します。
# edauth -dd default
次のフィールドを設定します。
d_skip_success_login_log: d_skip_ttys_updates:
sysman nis
プログラムを実行します。
sysman nis
プログラムによって最初にセキュリティ (ypbind
の
-s
オプション) の入力が求められたら,y
を選択して
ypbind -s
を実行し,セキュア・ソケットを指定します。
sysman nis
プログラムによって再度セキュリティ (ypbind
の
-S
オプション) の入力が求められたら,y
を選択し,ドメイン名 1 つと承認されたスレーブ・サーバを 4 つまで指定します。
/etc/svc.conf
ファイルに次のエントリがあることを確認します。
auth=local,yp
/var/yp/ypxfr_1perday
,/var/yp/ypxfr_1perhour
,/var/yp/ypxfr_2perday
ファイルを編集し,それぞれに次の行を追加します。
ypxfr -a "$method" prpasswd ypxfr -a "$method" prpasswd_nonsecure
NIS を起動します。
# /sbin/init.d/nis start
A.6.4 エンハンスト・セキュリティ環境での NIS クライアントの設定
NIS がスレーブ・サーバ上で稼働している場合,/sbin/init.d/nis stop
コマンドを使って NIS を停止する必要があります。次の設定手順は,エンハンスト・パスワード・セキュリティを使用する NIS クライアントに固有のものです。
エンハンスト・セキュリティ・サブセットがインストールされていることを確認します。
次のコマンドを使用して,システム省略時設定テンプレートを変更します。
# edauth -dd default
次のフィールドを設定します。
d_skip_success_login_log: d_skip_ttys_updates:
sysman nis
プログラムを実行します。
sysman nis
プログラムによって最初にセキュリティ (ypbind
の
-s
オプション) の入力が求められたら,y
を選択して
ypbind -s
を実行し,セキュア・ソケットを指定します。
sysman nis
プログラムによって再度セキュリティ (ypbind
の
-S
オプション) の入力が求められたら,y
を選択し,ドメイン名 1 つと承認されたスレーブ・サーバを 4 つまで指定します。
/etc/svc.conf
ファイルを編集し,auth
用の
yp
エントリを含めます。エントリは、auth=local,yp
となります。
/sbin/init.d/nis start
コマンドを使って NIS を起動します。
既存のローカル・アカウントを NIS へ移行するには,次のコマンドを実行します。
# edauth -Lg | edauth -NsC
NIS を削除する必要がある場合,NIS アカウントをローカル・データベースにコピーし,クライアント上で次のコマンドを実行して NIS を削除します。
# edauth -gN | edauth -sLC # sysman nis <メニューから Remove オプションを選択する>
クライアント上のエンハンスト (保護) パスワード・データベースは,NIS データベースにあってローカル・データベースにないすべてのアカウントで更新されます。
A.6.7 導入時の注意点
以下の情報は,エンハンスト・セキュリティおよび NIS に固有です。
エンハンスト・セキュリティ環境で NIS を実行している場合にパスワードを変更するには,ローカルおよび NIS 配布型のエンハンスト (保護) パスワード・データベース両方のエントリに対して,passwd
コマンドを実行します。passwd
コマンドは,svc.conf
ファイル 内の検索リスト (auth=local,yp
エントリ) を使用し,エントリが NIS 配布型のエンハンスト・パスワード・データベースにあるかどうかにかかわらず,エンハンスト (保護) パスワード・データベースの中で最初に見つかった,指定されたユーザに対応するエントリにあるパスワードを更新します。
エンハンスト・パスワード・データベースの各エントリは,ローカルのエンハンスト・パスワード・データベースまたは NIS 配布型のエンハンスト・パスワード・データベースのいずれか 1 つのデータベースにのみ存在していなければなりません。エンハンスト・パスワード・データベース情報の確認ルーチンおよび操作ルーチンは,見つかった最初のコピーに対して処理を実行します (svc.conf
ファイルで定義)。NIS の
yp
ルーチンは,NIS 配布型のエンハンスト・パスワード・データベースのみを対象に動作します。同じエントリが両方のデータベースにある場合,混乱が生じることがあります。このような状況が発生した場合,一方のエントリを削除してください。
root
アカウント情報は配布しないでください。クライアント・システム上でローカルの
root
アカウントを管理することで,NIS サーバがダウンしていても,root
アカウントを使ってクライアント・システムにログインすることができます。
最後の正常ログインに関する情報を維持するには,ユーザがログインするたびにそのユーザのエンハンスト・プロファイルを更新するように設定します。このため,NIS マスタでは,マップを再構築しスレーブへ送信するが必要があります。Tru64 UNIX Version 5.1A では,この更新をオプションとしているため,d_skip_success_login_log
システム省略時設定フィールドの値を true に設定して,この更新を無効にできます。正常ログインのロギングを無効にした場合,NIS スレーブ・サーバを正しく構成すれば,NIS マスタ・サーバが常時使用可能でなくても正常にログインすることができます。
スケーラビリティの改善には次のものがあります。
単一のエントリを更新しても,prpasswd
マップ全体が再構築されないことがあります。可能ならば,マップ・エントリは直接更新されます。
手作業による再構築後に
prpasswd
ファイルに対して手作業で変更を行わないでください。rpc.yppasswdd
デーモンがエントリをキャッシュしているために,手作業による変更が置き換えられてしまう可能性があるからです。prpasswd
ファイルを変更する必要がある場合は,NIS サーバを停止してから変更を行い,その後 NIS サーバを再起動します。
正常ログインのロギングが有効の場合,正常ログインは NIS マップの配布が完了する前に完了します。NIS マスタが更新されたことを確認するまで待つだけです。ログイン失敗のロギングを有効にすると,失敗したログインは NIS マップからスレーブ・サーバへの配布が完了するまで待って完了します。これはセキュリティの問題およびタイミングの問題に対処するために必要です。
NIS マップのデータベース形式は構成可能です。ndbm
の他に,btree
または
hash
を選択することができます。NIS マップの保存に
ndbm
を使用する場合,保存できるアカウントのレコード数に制限があり,その数はアカウント名と UID の組合せに依存します。上限は通常約 30,000 エントリですが,アカウント名と UID の組合せによっては 10,000 エントリ以下となる場合もあります。ndbm
にはこのような制約があるため,特にエンハンスト・セキュリティを使用する場合,データベース形式に
btree
を使用します。
NIS サーバは,共通のデータベース形式で動作させるのが最適です。スレーブ・サーバにマスタとは別の形式を定義した場合 (btree
ではなく
ndbm
など),マップをスレーブ・サーバにプッシュする時間が大幅に増加します。これは,スレーブ・サーバが,マスタから単一の要素としてデータベースを受信するのではなく,データベースを一度に 1 要素ずつ再構築しなければならないためです。
NIS スレーブが NIS マスタ上の
ypservers
NIS マップにリストされていない場合,これらのスレーブに対応する NIS クライアントで性能上の問題が発生することがあります。この問題を解決するには,NIS マスタ上の
ypservers
NIS マップにすべての NIS スレーブを定義します。そして,スレーブ・サーバ上で次のコマンドを実行し,NIS マスタからユーザ・アカウント・データベースを取り込みます。
# /var/yp/ypxfr -d `domainname` -h NISMASTER -c prpasswd # /var/yp/ypxfr -d `domainname` -h NISMASTER -c prpasswd_nonsecure
この例では,NISMASTER を使用する NIS マスタ・サーバの名前に置き換えてください。このコマンドでは,これらのスレーブ・サーバに対するマップの最初のコピーが送信されます。
ログインに失敗したログイン・プロセスでは,prpasswd
マップで直前のログイン失敗の情報を確認する必要があります。これには,最新の
prpasswd
マップが必要です。このため,ログイン失敗が発生するたびにprpasswd
マップに対して
yppush
操作を実行する必要があります。このマップは (少なくとも)
rpc.yppasswdd
デーモンの通常運用時にプッシュする必要があります。このような構成では,/var/yp/Makefile
の変数
NOPUSH
を設定することはお勧めできません。
prpasswd
情報の共有に NIS を使用できないサイトでは,NFS を使用して
/tcb/files
および
/var/tcb/files
ディレクトリを共有することができます。この場合,必要に応じて
-root=client1:client2:client3
または
-root=0
を用いて,関連ノードに root
アクセス権付きでディレクトリをエクスポートする必要があります。
exports
(4)
表 A-2
では,一般的な NIS の問題および考えられる原因について説明します。
表 A-2: NIS のトラブルシューティング
問題 | 考えられる原因 |
ローカル・アカウントにはログインできるが,どの NIS アカウントにもログインできません。dxaccounts
ユーティリティでは,アカウントが存在しロックされていないと表示されます。 |
1.
2.
|
ブート時に,スレーブ NIS サーバが更新済みの
prpasswd
マップを取得できません。 |
|
dxaccounts
プログラムの [表示] ポップアップ・メニューに,NIS ユーザ・アカウント・データベースのオプション ([NIS Users],[NIS Groups],[NIS Templates] など) が表示されません。 |
NIS が稼働していないか,または構成されていません。 |
|
これは情報メッセージなので,対処は必要ありません。 |
|
ホスト・マップが存在しません。次のコマンドを実行します。
|
A.7 TruCluster でのエンハンスト・セキュリティ
TruCluster は,単一のセキュリティ・ドメインです。特に指定しなければ,各メンバに対して,識別と認証,アクセス制御リスト (ACL),および監査が全く同じに構成され,ユーザおよびシステム管理者に対して一貫したインタフェースが提供されます。
1 つの認証ファイルがクラスタの全メンバ間で共用されるため,各ユーザ・アカウントはすべてのクラスタ・メンバで有効です。このためユーザは,どのメンバが接続を受け入れたかを意識することなく,クラスタにログインすることができます。同一構成の ACL チェックにより,認証とファイル・アクセス制御の一貫性が確保されます。ユーザは,どのメンバでも同じアクセス権を持ちます。クラスタ単位の監査設定により,クラスタの動作を統一的に取得できるようになります。
A.7.1 TruCluster での基本セキュリティからエンハンスト・セキュリティへのアップグレード
既存の TruCluster を基本セキュリティからエンハンスト・セキュリティへアップグレードするときには,クラスタ全体をリブートする必要があります。このアップグレードにより,ユーザ・アカウントが/etc/passwd
ファイルから
auth.db
データベースへコピーされ,/etc/passwd
ファイルのパスワードが削除され,新しいセキュリティ・ライブラリに切り替わります。telnet
セッションのような,ユーザ名とパスワードを認証する新しいプロセスは,新しいライブラリを使って新しいデータベースにアクセスします。ただし,dtlogin
セッションや CDE ウィンドウのロックのような既存のプロセスは,元のライブラリを続けて使います。このライブラリは,パスワードが削除された
/etc/passwd
ファイルにアクセスすることを想定しているため,既存のプロセスでのパスワード確認は必ず失敗します。特に,コンソール・ログイン・ウィンドウでこの問題が発生すると,root アカウントが無効になっているものと誤って解釈されてしまうことがあります。クラスタのリブートにより,この状態を防ぐことができます。
A.7.2 TruCluster でのエンハンスト・セキュリティのインストールおよび構成
TruCluster にエンハンスト・セキュリティを構成する理想的なタイミングは,TruCluster Server ライセンスおよびサブセットをロードしてクラスタを作成する前です。インストールの際に,エンハンスト・セキュリティのサブセット (OSFC2SECnnn および OSFXC2SECnnn ) を選択する必要があります。
nnn は,Tru64 UNIX のバージョン番号です。現在のバージョン番号は,『リリース・ノート』 を参照してください。
エンハンスト・セキュリティ・ソフトウェアは,次のように TruCluster のメンバにインストールされます。
クラスタの最初のメンバに Tru64 UNIX をインストールする際には,TruCluster Server ソフトウェアをインストールする前にセキュリティ環境を完全に設定する必要があります。設定したセキュリティ構成は,他の構成データとともに他のクラスタ・メンバに,それぞれが起動するときに伝達されます。
最初のメンバ以外のクラスタ・メンバに Tru64 UNIX をインストールする場合,TruCluster ソフトウェアをインストールする際に,クラスタ内の既存のメンバからエンハンスト・セキュリティ環境が継承されます。
クラスタ環境で稼働しているメンバでエンハンスト・セキュリティを有効にする場合は,1 つのメンバからエンハンスト・セキュリティを設定した後,クラスタ内の各マシンをリブートする必要があります。
クラスタでは,基本とエンハンストの両方のセキュリティがサポートされています。基本セキュリティでは,標準 UNIX の
/etc/passwd
および
/etc/group
ファイルが使われます。基本セキュリティは,省略時の構成です。エンハンスト・セキュリティは,secconfig
ユーティリティの [Custom Setup] メニュー上の「Security Configuration」アイコンを使って構成されます。
A.7.3 アクセス制御リスト
/usr/sbin/sysman secconfig
ユーティリティの [Custom Setup] メニュー上の「Security Configuration」アイコンには,チェック・ボックスがあります。このチェック・ボックスを使うと,基本セキュリティまたはエンハンスト・セキュリティのもとで,すべてのクラスタ・メンバ上のアクセス制御リストのサポートを有効または無効にすることができます。ACL サポートにより,アクセス・チェックおよび ACL 継承の状態 (有効または無効) が決まります。ACL の作成,変更,削除,および調査は,ACL のサポート状況に関係なく行うことができます。
NFS ファイル・システムには,ACL をサポートするために
proplistd
デーモンが必要です。
A.7.4 分散ログインと NIS
クラスタでは,共通の認証環境が利用でき,保護された,分散型の,高可用性のログインが可能です。クラスタは,NIS のマスタ,スレーブ,またはクライアントとしても機能させることができます (NIS 環境では,すべてのクラスタ・メンバの役割が同じでなければなりません)。
NIS マスタの場合,クラスタは,/etc/passwd
の標準ユーザ・プロファイルと,エンハンスト・セキュリティ (保護パスワード・データベースで保守される) で提供されるエンハンスト・ユーザ・プロファイルの,両方の NIS 配布をサポートします。これらのエンハンスト・ユーザ・プロファイルは,/etc/passwd
を
passwd
マップとして配布するのと同じ方法で,prpasswd
マップとして NIS で配布することができます。
エンハンスト・セキュリティを稼動しているクラスタを NIS マスタとして設定するには,次の手順を実行します。
指定したアカウントを,passwd
を含め
/var/yp/src
にロードします。詳細については,『ネットワーク管理ガイド:サービス編』を参照してください。
convuser -Mc
を使って,1 行ごとのエントリで
prpasswd
マップを設定します。詳細については,
convuser
(8)
『ネットワーク管理ガイド:サービス編』 で説明しているように,NIS を設定します。nissetup
の実行中,メンバを NIS サーバの認証リストにバインドするために,ypbind
のセキュリティ・オプション
-S
を選択します。そして,これらのサーバの 1 つとしてクラスタ別名を指定します。
Tru64 UNIX の『ネットワーク管理ガイド:サービス編』で説明しているように,prpasswd
マップをサポートするようにマップ保守スクリプトを変更します。
注意
1 つ以上のノードがエンハンスト・セキュリティを実行していてるドメインで,Tru64 UNIX Version 5.1A 以上と DIGITAL UNIX バージョン 4.x システムが混在している場合は,Tru64 UNIX Version 5.1A 以上のシステムを NIS マスタにしなければなりません。エンハンスト・セキュリティを実行しているノードがない場合は,バージョン 4.x システムを NIS マスタにすることができます。
dxaccounts
ユーティリティでは,NIS アカウントの追加とユーザのセキュリティ・オプションの変更を同時に行うことはできません。最初にアカウントを作成してから,ユーザのセキュリティ・オプションを変更しなければなりません。ユーザの一次グループが
/var/yp/src/group
マップに定義されていないと,useradd
コマンドは失敗します。
エンハンスト・セキュリティを有効にすると,新しいデーモン
prpasswdd
が導入されます。そのデーモンの 2 つのインスタンス (親と子) が,各クラスタ・メンバ上で実行されます。親は主に,子の起動と再起動を担当します。子は,認証データベースへの変更の書き込みを担当します。クラスタでのロックの競合をなくすために,/var
マウント・ポイントを提供しているクラスタ・メンバ上のデーモンだけが,すべてのクライアントに代わって書き込みを実際に行います。その他の
prpasswdd
デーモンは,ホット・スタンバイ・モードになっています。マウント・ポイントを処理しているクラスタ・メンバのアクティブ・デーモンに障害が発生すると,別のメンバが両方の役割を引き受けます。
NIS マスタとしてエンハンスト・セキュリティで動作するクラスタでは,NIS
prpasswd
マップの
prpasswdd
と同じように
rpc.yppasswdd
デーモンが動作します。
A.8 デバイスの安全確保
ワークステーションは,コンピュータ・ルームのように保護の容易な環境ではなく,普通のオフィスで使われるため,セキュリティ上の問題があります。
ワークステーションに近づけた誰かが,そのシステムのスーパユーザになって,そこから別のシステムでのスーパユーザになれる可能性があります。たとえば,システムをシングルユーザ・モードでブートするのも 1 つの方法です。
オフィスのドアに鍵がある場合,システムから離れるときはドアに鍵をかけてください。
また,テープ・カートリッジやフロッピィ・ディスクのような取り外し可能メディアも, 使用していないときには鍵のかかる場所に保管して保護しなければなりません。
ワークステーションの中には,コンソール・パスワードを設定できるものもあります。コンソール・パスワードを有効にしているときは,パスワードなしでは省略時のブートしか実行できません。コンソール・パスワードについての詳細は,ハードウェアおよびファームウェアのマニュアルを参照してください。
A.8.1 デバイス・セキュリティの特性
セキュリティ特性の定義および設定にあたっては,次の点を考慮します。
デバイス固有の情報の作成,管理。個々のデバイスのシステム省略時設定を置き換えて,必要に応じて追加の権利を許可したり,制限を追加したりできます。端末をロックして使用を防止することもできます。
システムのセキュア構成に含まれるデバイスに対する省略時の制御パラメータの設定。端末のシステム省略時設定は次のとおりです。
ログイン失敗の最大回数は 10。
出荷時には,ログイン・タイムアウトは設定されていません。つまり,暗黙に 0 となり,タイムアウトは無制限です。
ログイン失敗時の遅延時間は 2 秒。
セキュア・デバイスを作成または変更する前に,システムのハードウェアおよびソフトウェアのインストレーション中に必要となる,
標準的なデバイス・インストレーション手順をすべて完了しておく必要があります。デバイス特殊ファイルが
/dev
ディレクトリに存在し,適切なアクセス許可が設定されている必要があります。端末の特殊ファイルは
root
が所有し,グループを
tty
にし,モードを
0620
にする必要があります。
ls
コマンドを使用すると,インストレーションが完了していることを検証できます。一般的な例を次に示します。
# ls -lg /dev/tty* crw---------- 1 root tty 0, 2 Aug 15 09:29 /dev/tty00 crw---------- 1 root tty 0, 3 Aug 15 09:29 /dev/tty01
dxdevices
プログラムを使用して,システムを構成する全デバイスのセキュリティ特性を定義します。dxdevices
プログラムは,デバイス割り当てデータベースおよび端末制御データベースを管理する手段を提供します。dxdevices
プログラムを使って,端末や X ディスプレイにセキュリティ属性を割り当てることができます。
A.8.1.1 dxdevices プログラムを使ったデバイスの変更,追加および削除
「Devices」ダイアログ・ボックスを使用して,「Modify/Create」ダイアログ・ボックス,「Select devices」ダイアログ・ボックスの順に選択します。デバイスを追加または削除するには,まずデバイスを選択するか入力してから,[File] をクリックして必要な変更を行います。デバイスを変更するには,まずデバイスを選択してから,[Modify] をクリックして必要な変更を行います。詳細については,dxdevices
のオンライン・ヘルプを参照してください。
A.8.1.2 dxdevices プログラムを使った省略時の値の設定
「Devices」ダイアログ・ボックスを使用して,「Defaults」ダイアログ・ボックスを選択します。必要に応じて,全端末のシステム省略時設定を設定します。「Modify Terminal」ダイアログ・ボックスで設定して,値を個別に置き換えない限り,端末ではこれらの省略時の値が使用されます。詳細については,dxdevices
のオンライン・ヘルプを参照してください。
A.8.2 セキュリティ・データベースの更新
デバイスの省略時設定またはデバイス固有のパラメータを割り当てると,システムは以下のセキュリティ・データベースを更新します。
システム省略時設定データベース
/etc/auth/system/default
。すべてのシステム・デバイスに対する省略時の値 (
省略時の制御パラメータなど) が含まれます。
デバイス割り当てデータベース
/etc/auth/system/devassign
。システム・デバイスに対するデバイス固有の値が含まれます。
端末制御データベース
/etc/auth/system/ttys.db
。認証用のデバイス固有の値 (ログイン失敗の試行回数など) が含まれます。
セキュア構成の各デバイスに対応するエントリが,デバイス割り当てデータベースに必要です。このデータベースには,すべてのシステム・デバイスのセキュリティ特性に関する情報が集約されています。これにはデバイスのパス名や種類なども含まれます。省略時の設定では,/etc/auth/system/ttys.db
および
/etc/auth/system/devassign
データベースに,端末 (但し X ディスプレイは対象外) に対するワイルドカードのエントリがあります。
出荷時の X ディスプレイ・エントリには,サイトでシステム省略時設定のログイン・タイムアウトを変更する場合に備え,:t_login_timeout#0:
エントリがあります。ワイルドカードを使った X ディスプレイ・エントリが必要な場合,次のように作成します。
# echo \ \'*\:*:t_devname=*\:*:t_login_timeout#0:t_xdisplay:chkent:\' \ | /tcb/bin/edauth -s -dt # echo \'*\:*:v_type=xdisplay:chkent:\' | /tcb/bin/edauth -s -dv
この項では,システムで発生する問題と,問題の回避方法や修正方法について説明します。システムを正常に動作させるために必要な重要なファイルおよびプログラムを調査できるように,システムの起動にかかわる事柄について説明します。 システムをシングルユーザ・モードにすると,安全にバックアップを行うことができます。システムでの重大なデータ損失を防ぐ方法は, これ以外にはありません。
以下の節で説明する問題が発生すると,システムがブートできなくなります。
A.9.1 ロック・ファイル
システムのセキュリティ・データベースは,システムの正常動作に欠かせません。これらのデータベースではロック・ファイルを使用して,同期を取りながらセキュリティ関連データベースを書き換えます。プロセスは,データベース・エントリを書き換える前に,ロック・ファイルを自動的に作成します。ロック・ファイルがすでにある場合,プログラムでは,現在別のプロセスがデータベースを使用していると想定し,ロック・ファイルが削除されるまで待機します。ロック・ファイルが存在し続け,適正時間 (現在は 50 秒) 内に変更されない場合,ロック・ファイルを待っているプログラムはシステム・クラッシュまたはソフトウェア・エラーが発生したと見なし,ロック・ファイルを削除して新しいロック・ファイルを作成します。
システムでは,通常のファイル名に
:t
拡張子を追加して,ロック・ファイルの名前とします。
システムのスタートアップ・スクリプトには,システムの起動時にすべてのロック・ファイルを削除する処理が含まれています。次のファイルには,関連するロック・ファイルがあり,そのファイルがあるためにシステムが正しく動作しないことがあります。
/dev/console
/etc/auth/system/default
/etc/auth/system/devassign
/tcb/files/auth.db
/etc/auth/system/ttys.db
/etc/auth/system/default
/etc/auth/system/devassign
/etc/passwd
/etc/group
/sbin/rc[023]s
/dev/console
/dev/tty*
/dev/pts/*
/sbin/sulogin
/sbin/sh
/vmunix
A.9.2.1 /tcb/files/auth.db データベース
システムが動作を開始すると,セキュリティ・データベースでさまざまなパラメータが調査されます。いずれかのデータベースが壊れると,システムは正常にブートされません。可能であれば,スタートアップ・プログラムによってデータベースに問題があることが報告され,システムを修復できるように,システム・コンソールでシングルユーザ・シェルが起動されます。ただし,場合によっては,システムが起動しなくなり,『システム管理ガイド』 に記載されているスタンドアロン手順でシステムを修復しなければならなくなることがあります。
root 用のエンハンスト (保護) パスワード・データベースのエントリは,/tcb/files/auth.db
データベースに保存されます。root に対応するエントリが矛盾する場合,
システムはシングルユーザ・モードになりますが,起動するシェルのセキュリティ・パラメータはすべて省略時の属性になります。
システムがシングルユーザ・モードの場合,次のコマンドを入力して,root に対するエンハンスト (保護) パスワード・データベースのエントリを作成できます。
# edauth root
次の例に,root に対する一般的なエンハンスト (保護) パスワード・データベースのエントリを示します。
root:u_name=root:u_id#0:\ :u_pwd=encrypted_password:\ :u_minchg#0:u_pickpw:u_nullpw:u_restrict@:\ :u_maxtries#100:u_lock@:chkent:
各フィールドの詳細については,
prpasswd
(4)
root を含む必要があります。
root である必要があります。
値は 0 とする必要があります。
暗号化されたパスワード。認証時,システムは 入力されたパスワードを暗号化されたパスワードと照合します。データベースのエントリを作成する際には,このフィールドを空にしても構いません。
すべてのデータベースと同様,エントリは chkent という単語で終わる必要があります。
このエントリにある他のフィールドは,情報用であるか,または予定外のアカウント・ロックから保護するために使用します。システムでは,シングルユーザ・モードに切り替わる際に,root アカウントをロックする可能性がある条件をすべて無効にします。
A.9.2.2 /etc/auth/system/ttys.db ファイル
端末制御データベースには,システム・コンソールに対する有効なエントリがある必要があります。システム・コンソールのエントリは,
console
という単語で始め,その後にコロンを付ける必要があります。そして,chkent
という単語で終らなければなりません。唯一必須のフィールドは
t_devname
で,console
という値を設定する必要があります。たとえば次のとおりです。
console:t_devname=console:chkent:
A.9.2.3 /etc/auth/system/default ファイル
システム省略時設定データベースは,最初のフィールドを
default
とし,chkent
で終わる必要があります。このデータベースに関連する
:t
ロック・ファイルがあってはなりません。
一般的な例を次に示します。
default:\ :d_name=default:\ :d_boot_authenticate@:\ :d_audit_enable@:\ :d_pw_expire_warning#3456000:\ :u_pwd=*:\ :u_minchg#0:u_maxlen#20:u_exp#15724800:u_life#31449600:\ :u_pickpw:u_genpwd:u_restrict@:u_nullpw@:\ :u_genchars:u_genletters:u_maxtries#5:u_lock@:\ :t_logdelay#1:t_maxtries#5:t_lock@:t_login_timeout#60:\ :chkent:
A.9.2.4 /etc/auth/system/devassign ファイル
コンソールに対するエントリが矛盾している場合,アプリケーションは起動できません。最初のフィールドは
console
という単語にし,最後のフィールドは
chkent
という単語にする必要があります。v_type
フィールドには,terminal
を設定しなければなりません。
一般的な例を次に示します。
console:v_devs=/dev/console:v_type=terminal:\ :chkent:
/etc/passwd
ファイルはパスワード・データベースです。このファイルが存在し,正しい形式でなければなりません。このファイルの暗号化されたパスワードは更新されません。
A.9.2.6 /etc/group ファイル
/etc/group
ファイルはグループ・データベースです。このファイルが存在し,正しい形式でなければなりません。
A.9.2.7 /sbin/rc[023] ファイル
/sbin/rc[023]
ファイルは,init
で実行レベルを切り替えるために使用されます。インストール後に,これらのファイルのコピーを保存しておいてください。
A.9.2.8 /dev/console ファイル
/dev/console
ファイルは,システム・コンソールに対応するキャラクタ型デバイスです。このファイルは,システムのブートに必須です。
A.9.2.9 /dev/pts/* および /dev/tty* ファイル
/dev/pts/*
および
/dev/tty*
ファイルは,プロセス間通信に使用する疑似端末デバイスです。
A.9.2.10 /sbin/sulogin ファイル
/sbin/sulogin
実行可能ファイルにより,シングルユーザ・モードでのアクセスを,root のパスワードを知っているユーザに限定できます。
A.9.2.11 /sbin/sh ファイル
/sbin/sh
実行可能ファイルは,システムでシェルを起動し,シングルユーザ・モードへ移行するのに必要です。
A.9.2.12 /vmunix ファイル
/vmunix
ファイルは,オペレーティング・システムの実行可能イメージです。ブート・ロード・ソフトウェアは,
ブート時にオペレーティング・システムをメモリにロードし,制御をそれに移します。
A.9.3 ログインまたはパスワード変更での問題
システムへのログインまたはパスワード変更に問題が発生した場合,fverify
コマンドを使用して,セキュリティ・サブセットのファイルの属性をチェックしてください。たとえば,OSFC2SEC510 サブセットのファイルのファイル属性を確認するには,次のコマンドを入力します。
# cd / # /usr/lbin/fverify < /usr/.smdb./OSFC2SEC510.inv
ローカル・ユーザのプロファイル・ファイルのファイル属性は,ls -l
および
authck -pf
コマンドを使用してチェックします。
ユーザから報告されたログイン上の問題が,保護プロファイルを更新できない,またはロックを取得できないといったもので,またアカウント管理を集中化している場合は,A.6 節 を参照してください。
dxaccounts
および
usermod
などのユーティリティでは,/etc/.AM_is_running
というロック・ファイルを共用しています。このファイルが存在する場合,ユーティリティは警告を表示します。