Trusted Solaris 管理の手順

パート III ホストおよびネットワーク管理

Trusted Solaris を実行しているホストの大半はネットワークに接続されます。『Trusted Solaris 管理の手順』マニュアルのパート III では、ホストとネットワークの構成、ファイルの共有、ローカルネットワークとリモートネットワークに接続されたホスト間の通信管理について、必要な背景と手順を説明します。

注 -

ネットワークに接続されないスタンドアロン型ホストのインストール方法については、マニュアル『Trusted Solaris のインストールと構成』に書かれています。

第 9 章「Trusted Solaris におけるホスト管理およびネットワーク管理の概念」では、必要な概念を紹介します

第 10 章「トラステッドネットワークデータベースにおけるセキュリティ属性の指定とルーティング設定」では、主に次の項目について説明します。

第 11 章「ファイルおよびファイルシステムの管理」では、主に次の項目について説明します。

第 12 章「NIS+ 管理」では、主に次の項目について説明します。

第 13 章「Trusted Solaris カーネルスイッチ設定の変更」では、主に次の項目について説明します。

「設定可能な Trusted Solaris カーネルスイッチ」

第 14 章「印刷管理」では、主に次の項目について説明します。

第 15 章「デバイスの管理」では、主に次の項目について説明します。

「デバイス割り当ての管理とデバイスラベル範囲の設定」

第 16 章「ソフトウェアの追加」では、主に次の項目について説明します。

第 9 章 Trusted Solaris におけるホスト管理およびネットワーク管理の概念

この章では、ネットワーク上のホストの管理に関する必要な概念と背景について、次の項目について説明します。

「トラステッドネットワークデータベース」の更新手順、ならびに他の関連操作の手順については、第 10 章「トラステッドネットワークデータベースにおけるセキュリティ属性の指定とルーティング設定」を参照してください。トラステッドネットワークの概要に関しては『Trusted Solaris 管理の概要』の「トラステッドネットワークの管理」を参照してください。

トラステッドネットワーク通信の確認

Trusted Solaris オペレーティング環境は、Trusted Solaris 7 ホストと次の 4 種類のホスト間におけるネットワーク通信をサポートします。

Trusted Solaris 2.x オペレーティング環境またはそれ以降のバージョンを実効するホスト
TCP/IP をサポートするが、セキュリティ属性を認識しないオペレーティングシステムまたはオペレーティング環境を実行するホスト (Solaris、他の UNIX システム、Windows、および MacOS など)
一部の Trusted Solaris 7 および 2.x セキュリティ属性を認識する他のトラステッドオペレーティングシステムを実行するホスト (Trusted Solaris 1.x ホストなど)

ネットワーク通信およびネットワークサービスは、次に挙げるさまざまな Trusted Solaris サブシステムによって管理されます。

マウントされたファイルシステムの管理に使用されるトラステッド NFS

Trusted Solaris 7 ホスト間のマウントならびに、Trusted Solaris 7 ホストと NFS を認識する他のホスト間のマウントをサポートします。マウントの設定方法については、第 11 章「ファイルおよびファイルシステムの管理」を参照してください。
ホスト、ネットワーク、ユーザーが定義された構成ファイルの集中管理に使用される NIS+

Trusted Solaris 環境における NIS+ の違いについては、第 12 章「NIS+ 管理」を参照してください。

ユーザーおよびホストの集中管理に使用される Solstice AdminSuite ツール

NIS+ マスターサーバーの NIS+ テーブルに保持される管理データの大半は、Solstice ツールによって管理されます。NIS+ に依存せずホストごとのローカルファイルを更新することも可能です。

新しいワークステーション (ディスクレスワークステーションも含む) やサーバーを構成済みの分散システムに追加する場合は、マニュアル『Trusted Solaris のインストールと構成』を参照してください。Solstice ツールを使用してユーザーを管理したり、ホストのセキュリティ属性を設定する方法については、このマニュアルの別の章で説明しています。

注 -
データベースマネージャは資格を設定しません。ホストテーブルやローカルファイルにホスト用のエントリを作成するだけです。ホストマネージャはホストの資格も確立するため、新しいホストを追加するときに使います。
トラステッドネットワーク通信をサポートするトラステッドネットワークと拡張ルーティングソフトウェア

セキュリティ管理者役割は、ネットワーク上のホスト間の通信をそのサイトが要求する程度にあわせ、開放または制御します。方法については、「トラステッドネットワークの目的」を参照してください。

トラステッドネットワークの目的

トラステッドネットワークソフトウェアでは、次の機能が保証されています。

ネットワーク通信におけるデータの正確なラベル付け
ローカルネットワーク経由でデータを送受信する際およびファイルシステムがマウントされる際の必須アクセス制御 (MAC) 規則の実行
データを遠隔ネットワークに配信する際の必須アクセス制御 (MAC) 規則の実行

tnrhdb(4)、tnrhtp(4)、tnidb(4) の各トラステッドネットワークデータベースには、ホスト、ネットワーク、ネットワークインタフェースに適用されるラベルや他のセキュリティ属性が格納されます。トラステッドネットワークデータベースについては、「トラステッドネットワークデータベース」で詳しく説明します。また、操作手順については、第 10 章「トラステッドネットワークデータベースにおけるセキュリティ属性の指定とルーティング設定」で説明します。

セキュリティ管理者は、トラステッドネットワークデータベースの特定のフィールドを使用して、Trusted Solaris マシンからの通信が、転送データの機密レベルと同じセキュリティレベルのゲートウェイを介してのみ配信されるように指定できます。このようなルーティングは、「トラステッドルーティング」と呼ばれています。

ルーティングの仕組みおよび Trusted Solaris 環境で使用されるデータベースについては、「ルーティング」の項で説明します。

Trusted Solaris ネットワークの例

最も単純で保護しやすいネットワーク構成は、単一スタンドアロン型の同機種分散システムです。この構成はまた、ネットワーク通信の保護に関する評価基準を完全に満たした、唯一の構成といえます。分散システムは、次の条件下で稼動する 1台から複数台のホストによって構成されます。

Trusted Solaris 2.5、2.5.1 または 7 オペレーティング環境を実行する
同一 NIS+ マスターサーバーによって管理され、すべてのマシンに関する同一セットのセキュリティ属性を持ち、ユーザーは、ネットワーク上で一意に識別される
同一ワイヤに接続されている (あるいは、仮想的に同一ワイヤになるよう構成されている)

この方法で管理されるホストはみな、同じセキュリティドメインに属すものと考えられます。単一セキュリティドメイン内では、ワイヤ上に送出されるパケットが同じネットワークに接続された他のすべてのホストによって拾い上げられるため、ルーティングテーブルを必要としません。

この種のネットワークでは、顧客側で傍受に対する物理的な保護対策が施されていると想定されます。これは、Trusted Solaris ソフトウェアが暗号化機能をサポートしていないためです。

すでにおわかりのように、Trusted Solaris オペレーティング環境を単独で実行している単一ホストは、スタンドアロン型セキュリティドメインとみなされます。

同機種セキュリティドメインの例

図 9-1 は、NIS+ マスターとして動作するホスト F が接続された単一のセキュリティドメインを示しています。それぞれのホストは、単一のネットワークインタフェースによってネットワークに接続されます。「ネットワークインタフェース」とは、ホストをネットワークケーブルに接続するホスト上の物理コネクタを指します。大抵の場合、インタフェースには Ethernet コネクタが使用され、ローカルネットワークのすべてのホストが接続されている Ethernet ケーブルに接続されます。ホストまたはネットワークインタフェースの「ネットワーク認可範囲」 (インタフェースを介す通信すべてに適用されます) は、最下位機密ラベルと最上位機密ラベルで定義されます。この認可範囲はセキュリティ管理者によって決定され、トラステッドネットワークデータベースに指定されます。

図 9-1 単一のセキュリティドメイン

異機種システム混在ネットワーク

Trusted Solaris ホストは、他のオペレーティングシステムを実行するホストとも通信可能です。それらのホストが同じワイヤに接続されているか、あるいは別のネットワークに接続されているかは問いません。

ネットワークに追加しようとしているホストが、さまざまな信頼レベルで他のオペレーティングシステムを実行するローカルネットワークに接続されている場合は、セキュリティ管理者は、ワイヤを保護するための何らかの手段を検討しなければなりません。Trusted Solaris は暗号化を提供しません。

他のホストタイプに用意されたトラステッドネットワークデータベースのエントリに、それらのホストタイプから転送されないセキュリティ属性を指定したり、それらのホストと通信可能なラベルを指定する必要があります。次の図は、異機種システム混在ネットワークと、Trusted Solaris ホストが通信可能なホストタイプの例をいくつか示しています。

図 9-2 異機種システム混在ネットワーク

上の図で、Solaris ホストが NIS+ 対応の Solaris バージョンを実行している場合は、このホストを NIS+ マスターホスト F の NIS+ クライアントとして構成できます。CIPSO、RIPSO、TSIX ホストは、それぞれの構成情報がローカルファイルに保持されるスタンドアロンシステムとして、ネットワークに構成されます。(cipso、ripso、tsix ホストタイプは、表 9-1 に示します。)

ホストタイプ、テンプレート、プロトコル

tnrhdb と tnrhtp データベースのエントリの組み合わせにより、複数のホストとネットワークを特定のホストタイプに対応付けることができます。このホストタイプによって、カーネルがメッセージの解読に使用するプロトコルが識別され、そのプロトコルによって、カーネルはパケットのヘッダーから検出されるべきセキュリティ属性を知ることができます。次の表は、ホストタイプと、それに対して作成されるトラステッドネットワークデータベースのエントリを示しています。

表 9-1 ホストタイプ名


ホストタイプ	トラステッドネットワークデータベースで使用される名称	プロトコルと注釈
Trusted Solaris 2.x またはそれ以降	`sun_tsol`	TSOL プロトコル。このプロトコルは、Trusted Solaris 2.x またはそれ以降で実行するホスト間のセキュリティ属性の転送を簡易化する。TSOL は TSIX(RE) 1.1 - SAMP プロトコルから派生したプロトコルで、ネットワークプロトコルスタックの同様の場所にセキュリティ属性を渡し、同様のヘッダー構造を使用する。TSOL プロトコルはバイナリ形式でセキュリティ属性を渡すため、トークンマッピングを必要としない。Trusted Solaris 2.x またはそれ以降で実行するホスト間に限り使用される。
TSIX/RE	`tsix`	制限付環境用トラステッドセキュリティ情報交換 (Trusted Security Information Exchange for Restricted Environments (TSIX/RE) ) プロトコル (セキュリティ属性の受け渡しにはトークンマッピングを使用)。
MAXSIX	`msix`	Trusted Solaris 1.x、MAXSIX が使用するネットワークプロトコル。このプロトコルの使用により、Trusted Solaris 1.2 マシンとのネットワーク接続が可能になる。このプロトコルはもともと MaxSix 1.0 で使用されたもので、トークン形式でセキュリティ属性を IP オプションフィールドに渡す。ラベルは CIPSO のタグタイプ 3 として渡される。
TSIX(RE) 1.1 - CIPSO	`cipso`	Common IP Security Option プロトコルの TSIX(RE) 1.1。IP オプションフィールドに渡されるセキュリティラベルの指定に使用される。CIPSO ラベルはデータの機密ラベルから自動的に取得される。セキュリティラベルの受け渡しにはタグタイプ 1 が使用される (CIPSO)。その後このラベルは、IP レベルでのセキュリティ検査に使用される。また、ネットワークパケット内のデータのラベル設定に使用される場合もある。
RIPSO	`ripso`	IETF REC 1108 に記述される Revised IP Security Option (RIPSO)。ラベルを IP パケットに組み込むための DoD IP ラベル付け方式を定義する。また、ネットワーク MAC の検査にも使用される。管理目的で設定された固定式の RIPSO ラベルは、特定のホストと交換されたネットワークパケットに適用される。この機能は REC 規格を完全に満たすものではないが、RIPSO ラベルを必要とする場合に十分な機能を与えるものとされている。
ラベルなし	`ラベルなし`	Solaris またはラベルのないオペレーティングシステムを実行するホストに割り当てられる。ラベルなしホストへのパケット転送は、`ADMIN_LOW` からそのホストのテンプレートのデフォルトのラベルエントリで指定された機密ラベルまでの、すべての有効な機密ラベルで行われる。パケットを単一機密ラベルに制限するには、最下位機密ラベルと最上位機密ラベルが同等でなければならない。受信パケットには、デフォルトの機密ラベルが割り当てられる。

上の表の 2 列目のホストタイプ名称は、トラステッドネットワークデータベースで使用されている名称です。

デフォルトの tnrhtp データベースには、各ホストタイプに１つずつサンプルのテンプレートが含まれています。セキュリティ管理者役割は、これらのテンプレートをそのまま使用することも、コピー、リネーム、変更して使用することもできます。tnrhtp データベースに含まれるすべてのテンプレート名は、データーベースマネージャで tnrhdb データベースを使用してホストの IP アドレスにテンプレートを指定しようとすると、画面に一覧表示されます。図 9-3 を参照してください。

たとえば、Trusted Solaris をトラステッドホスト (ホストタイプに sun_tsol を指定したホスト) として構成するとします。この場合、セキュリティ管理者役割は、tnrhdb データベースにそのホストのエントリを追加し、tnrhtp データベースから sun_tsol ホストタイプを持つ適切なテンプレートを割り当てます。

図 9-3 tnrhtb データベースのテンプレート名一覧 : 「追加 (Add)」メニュー

ホストタイプ別の構成可能なセキュリティ属性は、第 10 章「トラステッドネットワークデータベースにおけるセキュリティ属性の指定とルーティング設定」の表 10-1 を参照してください。

複数のセキュリティドメイン例

複数の NIS+ ドメインから成る複数のセキュリティドメインは、ゲートウェイで接続される場合があります。次の図は、2 つのセキュリティドメイン構成を示しています。ホスト F はセキュリティドメイン #1 の NIS+ マスターで、ホスト K はセキュリティドメイン #2 の NIS+ マスターです。2 つのセキュリティドメインは、ゲートウェイホスト G によって接続されています。

図 9-4 2 つのセキュリティドメイン

Trusted Solaris 管理用語でいう「ゲートウェイ」とは通常、複数のネットワークインタフェースを持つホストを指します。したがって、複数のネットワークは Trusted Solaris ゲートウェイで接続される場合があり、これは推奨される構成でもあります。Trusted Solaris ゲートウェイを使用すると、トラステッドネットワークソフトウェアにトラステッドネットワークデータベースに定義された属性を使用させることでネットワークを行き来するパケットのセキュリティポリシーを実施したり、CIPSO や RIPSO ラベルのパケットのトラステッドルーティングをサポートしたりすることが可能になります。

ネットワーク認可範囲の条件

ゲートウェイのトラステッドネットワークインタフェースである tnidb(4) データベースのネットワーク認可範囲を制限することは、セキュリティ管理者役割にとって、他のネットワークとの通信を実現する上で、開放や制御の適切なレベルを構成する 1 つの手段となります。

ほとんどの Trusted Solaris ホストでは、認可範囲を ADMIN_LOW から ADMIN_HIGH に指定します。この認可範囲にしておくと、同機種 Trusted Solaris 分散システム内のすべてのホストが、同じシステムの他のホストからパケットをさまざまな機密ラベルで受信することができます。ゲートウェイの認可範囲は、ローカル分散システム外のホストとあらゆる機密ラベルで通信できるように設定したり、あるいは限定されたラベルに通信を制限するように設定したりできます。

注 -

ネットワークインタフェースの認可範囲を制限する際には注意が必要です。ネットワークサービスは、ネットワークインタフェースの認可範囲に、それらのサービスに適した機密ラベルが含まれていないと機能しません。たとえば、NIS+ マスターとの通信には、ADMIN_LOW から ADMIN_HIGH までのネットワーク認可範囲が要求されます。監査サーバーに書き込まれる ADMIN_HIGH の監査トレールファイルの場合は、ネットワークインタフェースの認可範囲に ADMIN_HIGH が含まれている必要があります。

図 9-5 認可範囲の異なる 2 つのセキュリティドメイン

通信を制限するには、上の図に示すゲートウェイ G の tnidb エントリを、次の表のように指定します。

表 9-2 ネットワークの認可範囲を制限する場合の tnidb エントリの例


インタフェース名	ネットワーク認可範囲
le0 (セキュリティドメイン #1 に対するインタフェース)	`PUBLIC` から `INTERNAL USE ONLY`
le1 (セキュリティドメイン #2 に対するインタフェース)	`ADMIN_LOW` から `ADMIN_HIGH`

ネットワークにおけるセキュリティ属性の搬送方法

セキュリティ属性がパケットにどのように追加されるのかを理解しておくことは、さまざまな種類のホストを定義したり、トラステッドネットワークデータベースにおいて、セキュリティ属性を指定したりする方法を理解するための必要条件となります。また、ここに説明する内容は、トラステッドルーティングを設定する上でも重要になります。

最上位レベルのネットワークパケットは、次の図に示すような形式になります。

表 9-3 パケットの形式


Ethernet ヘッダー	IP ヘッダー [IP オプション]	TCP または UDP ヘッダー	データ	Ethernet トレーラ

ネットワーク通信には、TCP/IP と UDP/IP のどちらも使用できます。トラステッドネットワークデータベースのエントリで、ホストタイプとして sun_tsol または tsix を指定すると、トラステッドネットワークソフトウェアによって、TCP または UDP ヘッダーの後、すなわちデータの前に「security attribute modulation protocol (SAMP)」ヘッダーが挿入されます。ホストタイプが sun_tsol または tsix に指定された場合のパケットは、次の図のような形式になります。

表 9-4 TSIX および Trusted Solaris のパケット形式


Ethernet ヘッダー	IP ヘッダー [IP オプション]	TCP または UDP ヘッダー	SAMP ヘッダー	データ	Ethernet トレーラ

SAMP ヘッダーには、属性がバイナリ形式かトークン形式かを指定する属性ヘッダーなどの、パケットのセキュリティ属性が入ります。SAMP ヘッダーがルーティングに使用されることはありません。

IP オプション

IP ヘッダーの IP オプションフィールド (表 9-4 の [IP オプション] 部) には、RIPSO または CIPSO のどちらかのラベルとオプションが入り、トラステッドルーティングに使用されます。Trusted Solaris ホストでは、宛先ホストの tnrhdb と tnrhtp エントリを構成して、送信パケットの IP オプションフィールドに CIPSO または RIPSO のどちらかのラベル情報をセットできるようになっています。サポートされている CIPSO オプションには、CIPSO ホスト用のタグタイプ 1 と、MSIX ホスト用のタグタイプ 3 の 2 種類があります。「パケットの CIPSO ラベル」、「パケットの RIPSO ラベル」、「トラステッドネットワークデータベースにおけるエントリの作成」を参照してください。

パケットの CIPSO ラベル

そのホストに割り当てられたトラステッドネットワークテンプレートのエントリが、次の条件のいずれかを満たしている場合、トラステッドネットワークソフトウェアは、送信パケットの IP オプションに、CIPSO ラベルと CIPSO DOI (domain of interpretation) 番号をセットします。一方、着信パケットでは、IP オプションにセットされた CIPSO ラベルと DOI を調べます。

cipso ホストタイプとして割り当てていること
msix ホストタイプとして割り当てていること
sun_tsol ホストタイプとして割り当て、IP ラベル型を CIPSO に設定していること
tsix ホストタイプとして割り当て、IP ラベル型を CIPSO に設定していること

テンプレートの IP ラベルフィールドが CIPSO に設定されていたり、リモートホストタイプが cipso に設定されている場合は、タグタイプ 1 が使用されます。リモートホストタイプが msix の場合は、CIPSO タグタイプの 3 が使用されます。

送信パケットで搬送される CIPSO ラベルは、トラステッドネットワークソフトウェアによって、データに対応する実際の機密ラベルから取得されます。場合によっては、Trusted Solaris の機密ラベルが CIPSO ラベルと直接一致することもあります。たとえば、機密ラベル CONFIDENTIAL が、CIPSO ラベル CONFIDENTIAL と一致します。しかし、大半の Trusted Solaris の機密ラベルは、CIPSO ラベルに直接対応しません。

注 -

トラステッドルーティングを設定するために CIPSO ラベルを使用したり、ホストタイプが cipso のホストとの通信を希望するサイトでは、CIPSO ラベルにうまく割り当てることができるよう、セキュリティ管理者が前もってサイトのラベルの構成案を立てておくことをお勧めします。

CIPSO DOI (domain of interpretation) も指定する必要があります。このとき、次のホストがみな同じ CIPSO DOI を共有するようにします。

送信側ホスト
メッセージが経由するすべてのゲートウェイ
宛先ホスト

機密ラベルと CIPSO ラベル間でマッピングを行うには、格付け値は 255 以下である必要があります。すべてのコンパートメントビット番号は 239 以下である必要があります。

デフォルトでは、CIPSO ラベルに割り当てられないほど大きな機密ラベルで送られてきたメッセージは、破棄するようになっています。

表 9-5 CIPSO ラベルにマッピングされるラベルの構成要素の制限


構成要素	値 (この値以下)
格付け値	255
コンパートメント番号	239

ADMIN_HIGH ラベルは上記表に示された制限を超えるため、デフォルトでは、ADMIN_HIGH ラベル付きのパケットは破棄されます。ADMIN_HIGH ラベルをネットワークインタフェース経由で送信する必要がある場合、関連するすべてのマシン上で tsol_admin_high_to_cipso カーネルフラグを 1 に設定します。このフラグは、セキュリティ管理者役割が /etc/system ファイルで設定できます。したがって、パケットが ADMIN_HIGH 機密ラベルを持つとき、そのラベルは、格付け値が 255 で、0 から 239 までのすべてのコンパートメントビットがオンの状態で CIPSO ラベルにマッピングされます。

注 -

ADMIN_HIGH ラベルがマッピングされるようにフラグが設定されている場合、格付け値が 255 で、0 から 239 までのすべてのコンパートメントビットがオンであるラベルがユーザー認可範囲内に存在しないことを確認してください。そうしなければ、マッピング後、このようなユーザーラベルは ADMIN_HIGH と区別が付かなくなります。すべてのラベルがマッピング可能であることを保証するために、コンパートメント番号が 239 を超えるユーザーラベルが存在しないことを確認します。

パケットの RIPSO ラベル

そのホストに割り当てられたトラステッドネットワークテンプレートのエントリが、次の条件のいずれかを満たしている場合、トラステッドネットワークソフトウェアは、送信パケットの IP オプションに RIPSO ラベルをセットします。一方、ホストからの着信パケットでは、IP オプションにセットされた RIPSO ラベルを調べます。

ripso 型ホストとして割り当てていること
sun_tsol 型ホストとして割り当て、IP 型ラベルを RIPSO に指定していること
tsix 型ホストとして割り当て、IP 型ラベルを RIPSO に指定していること

送信パケットの RIPSO ラベルは、管理上の目的で定義されます。セキュリティ管理者役割は、tnrhtp データベース内で格付けを「RIPSO 送信クラス (RIPSO Send Class)」フィールドに、コンパートメントまたは保護許可フラグ (PAF) を「RIPSO 送信 PAF (RIPSO Send PAF)」フィールドに指定します。

次の表はRIPSOA ラベルでサポートされている送信用の格付けを示しています。

表 9-6 RIPSO ラベルでサポートされている格付け


RIPSO ラベルでサポートされている格付け
`Top_Secret`
`Secret`
`Confidential`
`Unclassified`

「RIPSO 送信 PAF (RIPSO Send PAF)」と「RIPSO 戻り PAF (RIPSO Return PAF)」フィールドは、表 9-7 に示す保護許可フラグ (PAF) を参照します。「RIPSO 送信 PAF (RIPSO Send PAF)」フィールドに設定された PAF は、コンパートメント名と同様に、RIPSO ラベル内で格付けと共に使用されます (例 : Top_Secret SCI)。「RIPSO 戻り PAF (RIPSO Return PAF)」フィールドに指定された PAF は、ICMP メッセージのラベル付けで使用されます。このメッセージは、RIPSO ラベルの着信パケットに対するエラー応答として作成されるものです。ICMP メッセージで返送される格付けは、パケットの RIPSO の格付けと同じものが使用されます。

表 9-7 「RIPSO 送信 PAF (RIPSO Send PAF)」または「RIPSO 戻り PAF (RIPSO Return PAF)」フィールドに設定される保護許可フラグ


保護許可フラグ(RIPSO ラベルでサポートされている格付けで設定されるか、RIPSO エラーとして設定される)
`GENSER`
`SIOP-ESI`
`SCI`
`NSA`
`DOE`

ルーティング

ローカルネットワークから外への通信を単一のラベル (PUBLIC など) に制限したいサイトもあります。このようなサイトでは、ネットワーク認可範囲 PUBLIC を外部ネットワークに接続されているインタフェースに割り当てます。Trusted Solaris 環境には、ネットワーク間通信のルーティング手段が何種類かサポートされているため、セキュリティ管理者役割は、サイトのセキュリティポリシーで要求されるセキュリティレベルを実施できるような経路 (ルート) を設定できます。TCP/IP とルーティングの詳細については、『TCP/IP とデータ通信』を参照してください。

背景

同じネットワーク上でのホストからホストへの通信の場合は、ルートやルーターは必要ありません。 (この項では、ゲートウェイと「ルーター」という用語をそれぞれ置き換えて使用することがあります。なぜなら、ゲートウェイがパケットのルーティングを行うからです)。認可範囲チェックは発信元で実行されます。ただし、受信側ホストが Trusted Solaris を実行している場合は、受信先で実行されます。

発信元ホストと宛先ホストが物理的に異なるネットワークに接続されている場合は、パケットは発信元ホストからゲートウェイに送信されます。宛先ホストと最初のホップのゲートウェイの認可範囲は、ルート選択時に発信元ホストでチェックされます。ゲートウェイは、宛先ホストが接続されているネットワークにパケットを転送します。宛先に到達するまでに、複数のゲートウェイを経由するパケットもあります。Trusted Solaris ゲートウェイでは認可範囲の検査が実行されまることがありますが、中間ゲートウェイでは実行されず、単にパケットを受け渡すだけとなります。

ゲートウェイにはそれぞれ、すべての宛先に対するルートリストが保持されます。標準 Solaris のルーティングメトリックでは、宛先までの最短経路に基づくルート選択が可能ですが、Trusted Solaris 2.5.1 および 7 の拡張版は、それに加え、セキュリティ条件を満たしたトラステッドルーティングを実現しています。パケットに IP セキュリティオプションを付加することによって、中間ルーターでも認可範囲チェックに IP ラベルを使用できるようになるからです。トラステッドルーティングは、すべてのゲートウェイが RIP (拡張経路制御情報プロトコル、extended Routing Information Protocol) を認識するかどうかに依存します。したがって、トラステッドルーティングはルーティングに他のプロトコルを使用するインターネットでは使用できません。すべてのゲートウェイが拡張 RIP (経路制御情報プロトコル、Routing Information Protocol) を使用するイントラネット上でのみトラステッドルーティングは使用できます。

トラステッドルーティングを採用しているサイトでは、ラベルなしホストのクラスタの反対側に接続された Trusted Solaris ホストとの通信や、ラベルを認識しないルーターを 1 つ以上経由する通信のセキュリティを確保しなければなりません。このようなサイトでは、セキュリティ管理者役割がトンネリングを設定する必要があります。なお、「クラスタ」および「トンネリング」という用語については、「用語と概念」で定義しています。

修正版 TCP/IP ルーティング機能

トラステッドネットワークの構成とルートの設定を始める前に、セキュリティ管理者役割は次のことを理解しておく必要があります。

Trusted Solaris ルーティングの基本となる TCP/IP ルーティング (TCP/IP はこのマニュアルの範囲外です)

セキュリティ管理者役割はまた、次のことも理解しておかなければなりません。これらの項目については、残りの項で説明します。

Trusted Solaris の新しいルーティング用語
Trusted Solaris のルーティング拡張機能
サイトのルーティング条件
サイトの条件を満たすことのできる Trusted Solaris の機能

次の TCP/IP ルーティング機能は、Trusted Solaris の拡張セキュリティ情報をサポートするよう修正されています。

カーネルに保持されるルーティングテーブル
routed(1M) ルーティングデーモン
経路制御情報プロトコル (Routing Information Protocol、RIP)
route(1M) コマンド
netstat(1M) コマンド

用語と概念

この項では、知っておかなければならない用語から順に定義していきます。各用語は、先に出てきた用語の定義に基づいて定義されます。

ルーター

厳密にいえば、ルーターは 2 個以上のネットワークインタフェースを持ち、あるネットワークから別のネットワークにパケットを転送するマシンのことをいいます。「ルーター」の代わりに「ゲートウェイ」という用語が使用されることもあります。セキュリティ管理者は通常、Trusted Solaris 環境のルートを慎重に選択しなければならないため、機密情報に使用するすべてのルーターのセキュリティ特性を理解しておく必要があります。

信頼度の最も高いルーティングを確保するには、ルーターに Trusted Solaris ホストを使用してルートを設定します。他の種類のルーター上では、必ずしもすべての Trusted Solaris セキュリティ機能が使えるわけではなく、さらに、パケットはラベル付き (MAC) セキュリティ保護なしでルーターを通過できることを念頭に置いておくことが必要です。

Solaris ルーターは、IP オプションセクションに認識不能なラベルが検出されても、パケットを破棄せず、そのまま転送します。しかし、CIPSO、RIPSO、MSIX ルーターの場合は、対応するラベル型がパケットの IP オプションセクションに検出されないと、パケットを破棄してしまいます。たとえば、CIPSO ルーターでは、パケットの IP オプションセクションに CIPSO ラベルが検出されなければ、そのパケットは破棄されます。ホスト間の通信を設定する際は、このような注意事項を理解したうえで、パケットが適切なルーターに経由されるようにしなければなりません。

ルーティングテーブル

各ホストのカーネルに保持されるルーティングテーブルには、ルートが定義されます。このルーティングテーブルの各エントリによって、特定の宛先に対するルートが確定します。

宛先 (特定のホストまたはネットワーク)

最初のホップゲートウェイ (ルート内の最初のゲートウェイ)

ゲートウェイに対応するインタフェース

ルーティングソフトウェアはルートテーブルを参照し、宛先ホストに対するルートを見つけようとします。ルートテーブルに宛先ホストが明確に定義されていない場合は、そのホストが接続された (サブ) ネットワークのエントリを探します。宛先ホストも、そのホストが接続されたネットワークも定義されていない場合は、デフォルトゲートウェイにパケットを送信します (デフォルトゲートウェイが定義されている場合)。デフォルトゲートウェイは複数定義でき、それぞれ平等に扱われます。ポインタによって最後に使用されたデフォルトゲートウェイが記録され、次のルーティングにはリストの次のゲートウェイが使用されます。

注 -

場合によっては、複数のデフォルトゲートウェイによってループが生じることもあります。

トラステッドルーティングをサポートできるよう、Trusted Solaris ルーティングテーブルは、宛先までのホップ数を指定するメトリック (計測データ) に加え、セキュリティ情報も保持するよう拡張されています。「SRI」と「拡張メトリック」については、この後で定義します。

ルーティングテーブルのエントリは、次のどちらかの方法で作成されます。

動的方法

routed(1M) ルーティングデーモンによって、拡張メトリックを含むルートエントリが動的に作成される。
静的方法

管理者役割が 2 種類のルーティングファイルのどちらかに手動で静的ルートを作成する。ルートエントリと共に拡張メトリックを提供するかどうかは、管理者役割が選択する。

小規模なネットワークでは、管理者役割が手動でルートを設定し、状況の変化に応じて手動でルーティングテーブルを変更することも可能です。たとえば、外部との通信を、すべて 1 台のゲートウェイで行っているサイトも多数あります。このようなケースでは、その 1 台のゲートウェイが、ネットワーク上の各ホストのデフォルトとして静的に定義されます。

注 -

静的ルーティングを使用するルーターは使用可能であることを公示しないためほとんどの場合、動的ルーティングを使用している他の大半のシステムには認識されません。

大規模なネットワークでは、静的ルートを手動で構成したり管理することは不可能です。大規模なネットワークでは、たいていの場合、動的ルーティングが使用されます。

SRI

トラステッドルーティングに必要なセキュリティ属性のセットを SRI (security routing information) と呼びます。SRI には、ルートの認可範囲を確定するために、常に次の情報が含まれます。

最下位機密ラベル
最上位機密ラベル

route(1M) のマニュアルページに書かれているように、次のセキュリティ属性を SRI に含めることもできます。

CIPSO DOI
RIPSO ラベル
RIPSO エラー
CIPSO のみ
RIPSO のみ
MSIX のみ

SRI は次のどちらかの方法で取得されます。

SRI が動的ルーティングソフトウェアによって取得される場合、最初に、ルーター上のゲートウェイの tnrhdb および tnrhtp エントリから取得される
SRI が静的ルーティングテーブルに手動入力される場合は、セキュリティ管理者役割によって定義される

拡張 RIP

Xerox Routing Information Protocol (RIP) バージョンは、Trusted Solaris 環境用に拡張されており、ルーターからルートが伝達される際に、ルートのメトリックと共にセキュリティ属性がサポートされるようになっています。インターネットでは別のプロトコルを使用してルーティングが行われるため、拡張 RIP の互換性が保持されるのは、すべてのゲートウェイが RIP を認識できるイントラネット内だけになります。

拡張メトリック

拡張メトリック (Extended Metric) は、標準のルーティングメトリックと SRI の両方から成り、ルーティングテーブルにルートのエントリ単位で保存されます。ルーティングソフトウェアは、これらの拡張メトリックを比較することによって、セキュリティ条件を満たす最短の経路を選択します。拡張メトリックは、route(1M) を使用して、静的ルート用に手動で入力することもできます。ルートを手動で定義する方法については、「認可チェック」を参照してください。

動的ルーティングが使用される場合は、ルーティングデーモンの in.routed がセキュリティ強化された特殊な応答パケットを送信し、検出されたルートを伝達します。

送信側と受信側ホストの間には、複数のゲートウェイを経由する数種類のルートが存在する場合があり、ルートごとに拡張メトリックが異なることもあります。このような場合は、ルーティングソフトウェアによって、SRI がパケットのセキュリティ属性と一致するルートが選択されます。

sec_response パケット

基本的な Solaris システムでは、in.routed(1M) が各インタフェースのリクエストパケットを転送し、他のホストから送られてくるリクエストパケットや応答パケットを待ちます。一方、Trusted Solaris システムの in.routed は、応答パケットを送信する際に必ず sec_response パケットも送信します。このパケットには、ルートのメトリック以外に SRI も含まれています。応答パケットと同様に、sec_response パケットも、1 ホップずつメトリックと SRI を調整しながらルートを伝達していきます。

sec_response パケットは、Trusted Solaris ゲートウェイからは伝送されても、Trusted Solaris 以外の (以下、非 Trusted Solaris と呼びます) ゲートウェイからは伝送されません。2 台の Trusted Solaris ホスト間で、Trusted Solaris ルーターから非 Trusted Solaris ゲートウェイにルートのセキュリティ情報を送信するには、クラスタのエッジにある Trusted Solaris ルーターにトンネリングを設定する必要があります。こうすることによって、Trusted Solaris ホストとその他のオペレーティングシステムまたは環境で実行されるホストが混在するイントラネットでも、経路制御が可能になります。次の「クラスタ / 雲」および「トンネリング」を参照してください。

クラスタ / 雲

このマニュアルでいうクラスタとは、0 台以上のホストと1台以上のゲートウェイの集合 (または雲) を指します。

Trusted Solaris クラスタでは、すべてのホストが Trusted Solaris 2.5、2.5.1 または 7 オペレーティング環境のいずれかを実行し、すべてのゲートウェイがTrusted Solaris 7 または 2.5.1 オペレーティング環境を実行しています。
Trusted Solaris 以外のクラスタでは、ホストは Trusted Solaris 2.5、2.5.1、および 7 以外のオペレーティングシステム (または、オペレーティング環境) を実行しており、ゲートウェイは Trusted Solaris 2.5.1 と 7 以外のオペレーティングシステム (または、オペレーティング環境) を実行しています。
単一のイントラネットの中で 2 台の Trusted Solaris 2.5.1 または 7 ホスト間に非 Trusted Solaris クラスタが存在し、その間の通信を実現したい場合は、トンネリングを使用して、非 Trusted Solaris 2.5.1 クラスタの反対側までのルートに関する拡張メトリックを送信する必要があります。

以下に示す 2 つの図では、イントラネットとその中のクラスタが雲の形で示されています。Trusted Solaris クラスタは白抜きの雲で、同ゲートウェイは白抜きの円で囲まれています。また、非 Trusted Solaris クラスタは影のついた雲で、同ゲートウェイは正方形で囲まれています。

次の図は、3 つのクラスタで構成されたイントラネットを示しています。Trusted Solaris ホストの H1 は、Trusted Solaris 7 または 2.5.1 ゲートウェイで非 Trusted Solaris の雲に接続されています。ホスト H2 は、応答および sec_response パケットを自分のネットワークに伝送します。応答パケットはホスト H1 が接続されたネットワークに伝達されますが、sec_response パケットは伝達されません。sec_response パケットがないと、ホスト H1 はホスト H2 までのルートのセキュリティ情報が入った拡張メトリックを取得できません。なぜなら、中間クラスタの非 Trusted Solaris ゲートウェイで実行されている標準の RIP は、拡張 RIP のパケットを H2 のネットワークから H1 のネットワークに転送できないからです。

図 9-6 イントラネット内のクラスタの例

トンネリング

2 つの Trusted Solaris クラスタの間に、トラステッドルーティングを使用する非 Trusted Solaris クラスタが存在するときは、セキュリティ管理者役割はトンネリングを設定して、2 つの Trusted Solaris クラスタ内のゲートウェイが各ルートの拡張メトリックを交換できるようにしなければなりません。クラスタはすべて同一イントラネット内に構成する必要があります。また、以前の Trusted Solaris リリースでは、動的ルーティングと、拡張メトリックを制御する拡張 RIP がサポートされていないため、Trusted Solaris ゲートウェイでは Trusted Solaris 7 または 2.5.1 を実行しなければなりません。図 9-7 は、トンネリングの設定方法を示しています。

1台以上の非 Trusted Solaris ゲートウェイを介してトンネルに設定される Trusted Solaris ルーターは、すべて転送ホストとして機能し、反対側に接続された Trusted Solaris ホストまでのルートの拡張メトリックを伝達します。図 9-7 では、転送ホストゲートウェイ G1 の tunnel ファイルに、ホスト H2 が接続されたネットワークの IP アドレスが保持されます。G1 の Trusted Solaris ルーティングソフトウェアは、H1 までのルートの拡張メトリックを、H2 が接続されたネットワークに直接ブロードキャストします。G2 は H1 までのルートの拡張メトリックを取得し、それを自分のルーティングテーブルに追加します (双方向通信を行う場合は、ゲートウェイ G3 と G4 にも、ホスト H1 のネットワークの IP アドレスが入った tunnel ファイルを作成する必要があります)。

図 9-7 イントラネット内の非 Trusted Solaris クラスタを通過するトンネリング

有効なエントリで tunnel ファイルが作成されている場合は、拡張 in.routed デーモンによって、sec_t_response という特殊なラベルなし応答パケットが送信されます。ルートの拡張メトリック情報を含む sec_t_response パケットは、tunnel ファイルにリストされたネットワークに直接送信されます。

図 9-7 では、転送ホストゲートウェイ G1 の tunnel ファイルに、ホスト H2 が接続されたネットワークの IP アドレスが保持されます。G1 の Trusted Solaris ルーティングソフトウェアは、H1 までのルートの拡張メトリックが入った sec_t_response パケットを、H2 が接続されたネットワークに直接ブロードキャストします。このようにして、G2 は H1 までのルートの拡張メトリックを取得し、それを自分のルーティングテーブルに追加します (双方向通信を行う場合は、ゲートウェイ G3 と G4 にも、ホスト H1 のネットワークの IP アドレスが入った tunnel ファイルを作成する必要があります)。

sec_response パケットと同様に sec_t_response パケットも、in.routed が Trusted Solaris ルーターから応答パケットを送信するときに必ず送信されます。sec_t_response パケットは、直接宛先ネットワークに送信される必要があります。これは、宛先ネットワークとの間にある非 Trusted Solaris 2.5.1 または 7 ルーターでは sec_response パケットを転送できないからです。

非 Trusted Solaris クラスタを通る非 Trusted Solaris ルートはすべて、同じ SRI を持っていなければなりません。すなわち、これらのルートは、同じデフォルトラベルと IP ラベルオプション (ある場合) を使用して Trusted Solaris システムで定義される必要があります。

詳細については、in.routed(1M) のマニュアルページを参照してください。また、「トンネリングの設定」および第 10 章「トラステッドネットワークデータベースにおけるセキュリティ属性の指定とルーティング設定」「トンネリングを設定するには」を参照してください。

静的ルーティング

静的ルーティングは、同じく静的ルーティングを使用している他の Trusted Solaris ホストとネットワークとの通信にしか使用できません。静的ルーティングを使用するルーターは使用可能であることを公示しないため、動的ルーティングを使用しているシステムに認識されないからです。起動時には、次のファイルのどちらかが route(1M) コマンドによって使用され、カーネルテーブルにルーティングエントリが作成されます。

defaultrouter(4) - デフォルトゲートウェイの確立に使用される
tsolgateways(4) - 特定のネットワークのゲートウェイとデフォルトゲートウェイの確立に使用される

動的ルーティング

Trusted Solaris 2.5.1 またはそれ以降のバージョンは、Solaris 2.5 またはそれ以降のリリースで使用されている次の 2 つの動的ルーティングプロトコルを使用します。

in.routed(1M) に実装された Routing Information Protocol (RIP) バージョン 1
in.rdisc(1M) に実装された ICMP Router Discovery Message

なお、RIP プロトコルは拡張されています。

`in.rdisc`

ホストに /usr/sbin/in.rdisc プログラムはあっても、/etc/defaultrouter と /etc/tsolgateways ファイルが存在しない場合は、ICMP Router Discovery (RDISC) が動的ルーティングに使用されます。また、このプロトコルは、デフォルトゲートウェイをルーティングテーブルにインストールします。

デフォルトでは、in.rdisc がホストで実行されるようになっています。ホストで in.routed を実行するには、/usr/sbin/in.rdisc を削除するか、リネームする必要があります。in.rdisc によって設定されたデフォルトゲートウェイには、対応する拡張メトリックはありません。

`in.routed`

/usr/sbin/in.rdisc が存在しない場合、ホストは in.routed を実行します。『TCP/IP とデータ通信』に書かれているように、ルーターとして構成されたマシンは、自動的に Routing Information Protocol (RIP) バージョン 1 と RDISC プロトコルを実行します。in.routed は、完全なルーティングテーブルをインストールします。

動的ルーティングまたは静的ルーティングの決定

次の図に、ゲートウェイ以外の Trusted Solaris ホスト上に特定のファイルおよびプログラムが存在するかどうかによって、静的ルーティングまたは動的ルーティングのどちらを行うかを決定する方法を示します。

図 9-8 ホストが使用するルーティングの種類の確定方法

認可チェック

トラステッドネットワークソフトウェアは、認可検査を実行して、発信元ホスト、宛先ホスト、そこに設定されるルートの各セキュリティ属性を比較します。セキュリティ属性 (認可範囲と指定された CIPSO または RIPSO ラベル情報) は、ホストの tnrhdb または tnrhtp ファイルのエントリから取得されます。ルートのセキュリティ属性 (SRI) は、ルーティングテーブル内のそのルートの拡張メトリックから取得されます。ルートの拡張メトリックが指定されていない場合は、最初のホップのゲートウェイホストのエントリのセキュリティ属性が検査されます。

ルータ上では、転送されるべきパケットに RIPSO または CIPSO ラベルがあり、パケットの IP オプション部のラベルが使用されているときにのみ認可チェックが行われます。パケットに CIPSO ラベルがあれば、その機密ラベルは、入出力インタフェースのラベル範囲と比較されます。その機密ラベルは、次のホップのゲートウェイのラベル範囲とも比較されます。

送信メッセージにおける MAC の実施

送信側ホストでは、次の認可検査が行われます。

送信されるパケットの機密ラベルが、次の条件を満たしていること
- 宛先ホストの認可範囲内である
- 発信元ホストのネットワークインタフェースの認可範囲内である
パケットに CIPSO ラベルが含まれる場合は、その DOI が宛先ホストの DOI とルートの拡張メトリックの DOI と一致すること。ルートの拡張メトリックが指定されていない場合は、DOI が最初のホップのゲートウェイの DOI と一致すること
パケットに RIPSO ラベルが含まれる場合は、その RIPSO ラベルと PAF フラグが、宛先ホストおよびルートの拡張メトリックの RIPSO ラベル、PAF フラグと一致すること。ルートの拡張メトリックが指定されていない場合は、RIPSO ラベルと PAF フラグが、最初のホップのゲートウェイのものと一致すること
宛先ホストが MSIX ホストとして指定されている場合は、送信されるパケットの機密ラベルが宛先ホストの認可範囲内であり、ルートの拡張メトリックに MSIX 属性が含まれていること。ルートの拡張メトリックが指定されていない場合は、最初のホップのゲートウェイのホストタイプが MSIX として指定されており、パケットのラベルが最初のホップのゲートウェイ用に指定された認可範囲内であること

注 -

最初のホップの検査は、あるネットワークのホストから別のネットワークのホストにゲートウェイを介してメッセージが送信される場合に行われます。

転送メッセージにおける MAC 検査

Trusted Solaris ゲートウェイでは、次のホップとネットワークインタフェースの認可検査が実行されます。

パケットに CIPSO ラベル情報が含まれる場合は、転送されるパケットで以下の条件が満たされなければなりません。

ルートの拡張メトリックに CIPSO オプションが含まれていること。ルートの拡張メトリックが指定されていない場合は、次のホップのゲートウェイのエントリが、次のいずれかで定義されていること
- CIPSO 型ホスト
- CIPSO IP ラベルの sun_tsol 型ホスト
- CIPSO IP ラベルの tsix 型ホスト
パケットの CIPSO ラベルが、ルートの拡張メトリックから取得した認可範囲内であること。または、ルートの拡張メトリックが指定されていない場合は、パケットの CIPSO ラベルが、次のホップのゲートウェイのエントリに指定された認可範囲内であること
送信インタフェースのネットワークデータベースエントリに指定された CIPSO DOI が、パケットの DOI と一致すること

パケットに RIPSO ラベル情報が含まれる場合は、転送されるパケットで以下の条件が満たされなければなりません。

ルートの拡張メトリックに RIPSO オプションが含まれていること。ルートの拡張メトリックが指定されていない場合は、次のホップのゲートウェイのエントリが、次のいずれかで定義されていること
- RIPSO 型ホスト
- RIPSO IP ラベルの tsol 型ホスト
- RIPSO IP ラベルの tsix 型ホスト
パケットの RIPSO ラベルと PAF が、ルートの拡張メトリックに定義された RIPSO ラベルと RIPSO PAF と一致すること。または、ルートの拡張メトリックが指定されていない場合は、パケットの RIPSO ラベルと RIPSO PAF が、次のホップのゲートウェイのエントリに指定された RIPSO ラベルと RIPSO PAF と一致すること

メッセージの機密ラベルがどの宛先ホスト、ゲートウェイ、またはネットワークインタフェースについても、それらの認可範囲として指定された最下位および最上位ラベルの中に含まれない場合、そのメッセージはドロップされます。

着信メッセージにおける MAC の実施

受信側ホストでは、次の検査が行われます。

受信するパケットの機密ラベルが、次の条件を満たしていること
- 発信元ホストのトラステッドネットワークデータベースのエントリに指定された認可範囲内である
- データを受信するネットワークインタフェースのトラステッドネットワークデータベースに指定された認可範囲内であること
パケットに CIPSO ラベルが含まれる場合は、その DOI が、受信側ホストのトラステッドネットワークデータベースのエントリに指定された DOI と一致すること
パケットに RIPSO ラベルが含まれる場合は、その RIPSO ラベルと PAF フラグが、受信側ホストのトラステッドネットワークデータベースのエントリに指定された RIPSO ラベルと PAF フラグと一致すること

受信の場合、Trusted Solaris ネットワークソフトウェアは、可能な限り機密ラベルと他のセキュリティ属性をパケット自体から取得します。ただし、これが問題なく行えるのは、メッセージが Trusted Solaris システムで認識可能な形式のラベルと必要な属性をサポートしているシステムから送信される場合だけです。多くの場合、パケットはラベルを認識しないホストや、認識可能なラベルを送信しないホストから送られてきます。そしてまた、パケットに必要な属性が完全に含まれていない場合もあります。

すべての必要なセキュリティ属性をパケットから取得できない場合は、不足している属性がトラステッドネットワークデータベースからメッセージに割り当てられます。ホストのエントリから取得不能な属性は、メッセージが経由してきたインタフェースに適用される、トラステッドネットワークインタフェースのデータベースのエントリに指定された属性によって補われます。

静的ルーティングの設定

LAN の外側で行われる通信の静的ルーティングを設定するには、Trusted Solaris セキュリティ管理者役割が、各ホストの /etc ディレクトリにある 2 つの静的ルーティングテーブルの 1 つにゲートウェイを指定する必要があります。tsolgateways(4) ファイルには、次の 2 種類のゲートウェイを指定できます。

ネットワークゲートウェイ

このネットワークエントリを指定すると、すべての通信が、指定されたゲートウェイだけを介して指定されたネットワークに経路指定される。ネットワークゲートウェイには拡張メトリックの指定が可能。
デフォルトゲートウェイ

デフォルトゲートウェイのルーティングテーブルのエントリを使用すると、指定されたゲートウェイを介して、リストに指定されていないすべてのネットワークとの通信が可能。

ルーティングテーブルにネットワークエントリだけのエントリを指定すると、指定されたネットワークだけに通信が制限されます。ルーティングテーブルに 1 個以上ネットワークエントリを指定した場合でも、デフォルトエントリを指定することができます。

単純なネットワークでは、デフォルトゲートウェイを /etc/defaultrouter ファイルに指定できます (詳細は、route(1M) のマニュアルページを参照してください)。

「静的ルーティング」で説明したように、トラステッドネットワークソフトウェアは、最初に tsolgateways を検索し、このファイルが見つかった場合は defaultrouter ファイルを検索しません。どちらのファイルも見つからない場合は、動的ルーティングが使用されます。

tsolgateways ファイルのメトリックフィールドに入力される数値は、発信元ホストと宛先ホスト間にあるゲートウェイの数になります。同じネットワークのホストに対する伝送では、ホップは使用されません。図 9-9 は、ホップ数 0 の同一ネットワークに接続された 4 台のホスト (H1、H2、H3、H4) を示しています。

図 9-9 単一セキュリティドメインの 4 台のホスト間で行われるホップ数 0 の通信例

発信元ネットワークのゲートウェイに直接接続されたネットワークへの伝送では、ホップ数が 1 となります。図 9-10 は、ゲートウェイ G1によってネットワーク 129.150.102.0 に直接接続されたネットワーク 129.150.101.0 を示しています。ゲートウェイ G1には、インタフェースごとに 1 つずつホスト名が付いています。gateway-101 は 101 ネットワークに接続されたインタフェースの名前であり、gateway-102 は 102 ネットワークに接続されたインタフェース用の名前です。ゲートウェイが 1 つしかない単純なネットワークには /etc/defaultrouter を使用できます。したがって、129.150.101.0 ネットワーク上のホスト H1、H2、H3、H4 に、gateway-101 だけを指定する defaultrouter ファイルを作成することができます。tsolgateways ファイルを使用する場合は、ネットワークアドレスを 129.150.102.0 に、メトリックをホップ数 1 に指定します。

図 9-10 単一ゲートウェイで構成された 2 つのセキュリティドメインのデフォルトルートとネットワークルートの例

2 台のゲートウェイを経由するネットワークの伝送では、図 9-11 に示すようにホップ数が 2 となります。この図では、IP アドレス 129.150.101.0 のネットワーク上のホスト H1、H2、H3、H4 に作成される tsolgateways ファイルの例を示しています。図に示されるように、ゲートウェイ G1 はネットワーク 129.150.101.0 とネットワーク 129.150.102.0 を接続し、ゲートウェイ G2 はネットワーク 129.150.102.0 とネットワーク 129.150.103.0 を接続しています。tsolgateways ファイルの最初のエントリには、ゲートウェイ 1 - 101 を介す 129.150.102.0 へのネットワークルートが設定されており、メトリック欄の 1 は、宛先ネットワークまでのホップ数が 1 個であることを示しています。2 番目のエントリには、ゲートウェイ 1 - 101 を介す 129.150.103.0 へのネットワークルートが設定されており、メトリック欄の 2 は、宛先ネットワークまでのホップ数が 2 個であることを示します。

図 9-11 3 つのネットワーク間通信に設定された `tsolgateways` ファイルの例

次の図は、ゲートウェイ G1、G2、G3 を使用した、さらに複雑なネットワークトポロジを示しています。

手順については、「単一ゲートウェイで構成されたネットワークの簡易デフォルトルートを設定するには」を参照してください。

図 9-12 複雑なゲートウェイ構成とルーティングテーブルの例

トラステッドルーティングの設定

この節では、送信データの機密レベルと同じセキュリティレベルで構成されたゲートウェイだけを経由する通信ルートが必ず使用されるために、知っておかなければならないことが書かれています。この節は、「ルーティング」の節をすでに読んで理解していることを前提にしています。ルーティングの設定手順については、第 10 章「トラステッドネットワークデータベースにおけるセキュリティ属性の指定とルーティング設定」の「ルーティングの IP ラベルを設定するには」を参照してください。

トラステッドルーティングを設定するには、セキュリティ管理者が、すべてのホストとゲートウェイにあるトラステッドネットワークデータベースのエントリを設定できなければなりません。

送信側ホストで、テンプレートに CIPSO IP ラベルと CIPSO DOI が定義されている宛先にパケットを送信する場合は、宛先に割り当てられた DOI と送信側ホストに割り当てられた DOI が一致しなければなりません。さらに、最初のホップのゲートウェイのテンプレートには、宛先のものと一致する CIPSO DOI が定義され、パケットの CIPSO ラベルを含む認可範囲が設定される必要があります。テンプレートに RIPSO IP ラベル (格付け) と RIPSO PAF (コンパートメント) が定義されている宛先にパケットを送信する場合は、宛先に割り当てられた RIPSO の格付けとコンパートメントの組み合わせが、送信側ホストに割り当てられた組み合わせと一致しなければなりません。また、最初のホップのゲートウェイのテンプレートには、宛先と同じ RIPSO ラベルと PAF が定義される必要があります。セキュリティ管理者役割によって宛先ホストのテンプレートに IP ラベルが指定されると、トラステッドネットワークソフトウェアは、指定されたラベルを送信パケットの IP 部に挿入します。IP ラベル型を CIPSO にする場合は、パケットの機密ラベルから CIPSO ラベルを取得します。IP ラベル型を RIPSO にする場合は、宛先ホストのテンプレートに管理目的で定義された RIPSO ラベルを使用します。

受信側ホストでパケットを受信する場合は、発信元ホストのテンプレートに指定された CIPSO ラベルと CIPSO DOI が、受信側ホストに指定された CIPSO ラベルと CIPSO DOI に一致しなければなりません。

トラステッドルーティングの考慮事項

ここでは、前の節に記述した規則を簡単な例と図で説明していきます。ホスト H1 と H2 は Trusted Solaris ホストであり、これらのホストは、CIPSO IP ラベルに基づくトラステッドルーティングを使用して通信します。H1 は、G1 までのデフォルトルートを設定する in.rdisc を実行しています。G1 と H2 の間には、他の Trusted Solaris ゲートウェイが存在する可能性もあります。

次の図は、発信元ホスト H1 がパケットを G1 経由で H2 に送信できるようにするために、H1 の tnrhdb、tnrhtp、tnidb ファイルに設定しなければならない定義内容を示しています。パケットの機密ラベルは CONFIDENTIAL になっており、この例では、この機密ラベルによって直接 CIPSO ラベルの CONFIDENTIAL に割り当てられているとします。

図 9-13 送信側ホストのトラステッドネットワークファイルの定義

送信側ホストでは、パケットの送信前に、トラステッドネットワークソフトウェアが次の手順で検査を行います。

H2 のテンプレートを検査し、IP ラベルタイプが CIPSO に、CIPSO DOI が 1 に指定されていることを確認する。ソフトウェアによって取得されたパケットの CIPSO ラベルは C であり、H2 の認可範囲 (confidential から confidential) であるため、次の検査を行う。
H1 のテンプレートを検査し、H2 の CIPSO DOI と同じ CIPSO DOI が定義されていることを確認する。また、パケットのラベルが、H1 に割り当てられたテンプレートに構成されている送信インタフェースの認可範囲内であることもチェックする。ここでは、どちらの検査にも合格するので、次に G1 のテンプレートに対する検査を行う。
G1 のテンプレートを検査し、パケットと同じ CIPSO DOI が定義されていること、および認可範囲にパケットと同じ CIPSO ラベルが含まれていることを確認する。

すべての検査に合格すると、トラステッドネットワークソフトウェアは CIPSO ラベル C と CIPSO DOI 1 をパケットに挿入し、G1 に送信します。図 9-13 は前の図の続きで、パケットの転送前にゲートウェイで実行される検査を示しています。

図 9-14 パケット転送前にゲートウェイで実行される検査

ゲートウェイでは、パケットの転送前に、トラステッドネットワークソフトウェアが次の手順で検査を行います。

パケットの IP オプション部をチェックし、IP ラベルが CIPSO に、CIPSO DOI が 1 に設定されていることを確認する。
受信ネットワークインタフェースに割り当てられたテンプレートに、CIPSO IP ラベルと CIPSO DOI 1 が定義されていることを確認する。
受信インタフェースの tnidb エントリを検査し、認可範囲に C が含まれていることを確認する。
パケットを別のゲートウェイに転送する場合は、G2 のテンプレートの IP ラベルに CIPSO と CIPSO DOI 1 が定義され、認可範囲に C が含まれていることを確認する。

次の図は図 9-14の続きで、パケット受信時に宛先ホストで実行される検査を示しています。

図 9-15 受信側ホストで実行される検査

宛先ホスト H2 では、パケットを受信する前に、トラステッドネットワークソフトウェアが次の手順で検査を行います。

パケットの IP オプション部を検査し、IP ラベルが CIPSO に、CIPSO DOI が 1 に指定されていることを確認する。
H1 のテンプレートを検査し、IP ラベルが CIPSO に、CIPSO DOI が 1 に指定されていることを確認する。ソフトウェアによって取得されたパケットの CIPSO ラベルは C であり、H1 の認可範囲の confidential から confidential 内であるため、次の検査を行う。
H2 の受信インタフェースの tnrhtp エントリに CIPSO DOI 1 が定義され、受信インタフェースの tnidb エントリの認可範囲に C が含まれていることを確認する。

セキュリティ管理者役割は、最初のホップのゲートウェイおよび宛先ホストに対し、同じホストタイプと IP ラベル型を指定します。

IP ラベルを指定するには、ホストタイプとして次のどれかを指定します。

sun_tsol
tsix
cipso
ripso

また、IP ラベル型を次のどちらかで統一する必要があります。

RIPSO または
CIPSO

例:

RIPSO をサポートする非 Trusted Solaris システムを実行しているゲートウェイ、または商用 RIPSO ルーターのための IP ラベルを指定する場合は、次のホストタイプを入力します。

ripso

CIPSO をサポートする非 Trusted Solaris システムを実行しているゲートウェイ、または商用 CIPSO ルーターのための IP ラベルを指定する場合は、次のホストタイプを入力します。

cipso

CIPSO タイプ 3 を使用して Trusted Solaris 1.x ホストを経由させる場合は、IP ラベルとして次のホストタイプを入力します。

msix

Trusted Solaris ゲートウェイはまず、設定されたテンプレートによって sun_tsol、tsix、ciposo、ripso のいずれかのホストタイプとして識別されます。その後で RIPSO または CIPSO の IP ラベル型が IP ラベルフィールドに割り当てられます。RIPSO または CIPSO ラベルをサポートする非 Trusted Solaris ホストや商用ルーターも、ripso または cipso ホストタイプを使用して構成できます。Trusted Solaris 1.x ホストの場合は、パケットにタイプ 3 の CIPSO ラベルが挿入されるため、トラステッドルーティングには使用できません。

CIPSO ラベルは、トラステッドネットワークソフトウェアによってパケットの機密ラベルから取得されます。一方、RIPSO ラベルは、セキュリティ管理者役割によってテンプレートの「RIPSO Send Class」と「RIPSO -Send PAF」フィールドに指定されます。

パケットがゲートウェイで転送されるときは、トラステッドネットワークソフトウェアによってパケットの CIPSO または RIPSO ラベルが参照され、ルーティングテーブルにルートの拡張メトリック情報がある場合は、それと比較されます。ルートの拡張メトリック情報がない場合は、最初のホップのゲートウェイのトラステッドネットワークデータベースのエントリのセキュリティ情報と比較されます。このようにして、メッセージが適切な信頼レベルのゲートウェイだけを経由することが保証されます。

トラステッドネットワークソフトウェアは、次の図に示すパケットの部分しか参照しません。Trusted Solaris と TSIX ラベル、その他のセキュリティ属性は、パケットの TCP/UDP ヘッダーとEthernet トレーラ間にあるアクセス不能な部分に保存されます。一方、CIPSO ラベルと RIPSO ラベルは、パケットのアクセス可能な IP ヘッダー部に保存されます。

表 9-8 トラステッドネットワークソフトウェアがアクセス可能なパケット部


Ethernet ヘッダー	IP ヘッダー [IP オプションの RIPSO ラベル]	TCP または UDP ヘッダー	. . .	Ethernet トレーラ

CIPSO または RIPSO IP ラベルで指定された sun_tsol と tsix ホストタイプとの組み合わせを使用すると、パケットに Trusted Solaris または TSIX のセキュリティ属性を付加して、それらの属性を認識する宛先ホストに送信できるようになります。また、宛先との間にある Trusted Solaris ルーターでは、トラステッドネットワークソフトウェアがパケットのアクセス可能な IP 部の CIPSO または RIPSO ラベルを参照し、パケットの搬送ルートを制御されます。IP ラベルが指定されていないと、ゲートウェイのトラステッドネットワークソフトウェアは、パケットのラベルを確認したり、次のホップで必要な認可チェックを実行することができません。なぜなら、トラステッドネットワークソフトウェアは、パケット内に保持されているラベルと他のセキュリティ属性を確認しないからです。

注 -

CIPSO ラベルは、送信データの実際の機密ラベルから取得されるため、セキュリティ管理者役割が CIPSO ラベルを指定することはありません。ただし、IP ラベル型が CIPSO の場合は、このラベル型の通信がルートされる各セキュリティドメインのセキュリティ管理者の間で、通信に使用される Trusted Solaris の機密ラベルが合意されていなければなりません。これは、トラステッドネットワークソフトウェアによって、機密ラベルが同等の CIPSO ラベルに変換されるためです。また、セキュリティ管理者たちは、先に掲げたすべてのホストタイプに対し、同じ CIPSO DOI を指定することも承諾している必要があります。

注 -

RIPSO ラベルと RIPSO エラーは管理上の目的で定義されるため、リストにあげたホストには、それぞれ同じ RIPSO ラベルと RIPSO エラーを指定しなければなりません。IP ラベル型が RIPSO の場合は、この IP ラベルの通信がルートされる各セキュリティドメインのセキュリティ管理者の間で、先に掲げたすべてのホストタイプに対し、指定すべき RIPSO ラベル、保護許可フラグ、RIPSO エラーが合意されている必要があります。

単一ラベルのゲートウェイで複数のラベルのパケットを転送可能にするには

単一ラベルのホスト (ラベルなしあるいは ripso のホストの種類として指定されたもの) には、テンプレートにデフォルトの機密ラベルを割り当てる必要があります。ラベルなしホストのテンプレートにおける最下位および最上位機密ラベルは、ルーティングに使用する認可範囲を確定します。それぞれのラベルなしのホストに割り当てられた認可範囲は、単一ラベルゲートウェイによるパケットの転送に使われます。これは、デフォルトの機密ラベルだけでは受信が許可されないためです。

単一ラベルゲートウェイの認可範囲は、トラステッドネットワークソフトウェアがどのパケットをそのゲートウェイで送信するかを決めるのに使われています。ラベルのないゲートウェイで転送されるパケットは、認可範囲内になければなりません。

ADMIN_LOW から ADMIN_HIGH までのデフォルトのラベル範囲は、デフォルトの unlabel テンプレートで設定されます。必要に応じて、セキュリティ管理者役割は、そのデフォルトのラベル範囲の変更を行うことができます。

第 10 章トラステッドネットワークデータベースにおけるセキュリティ属性の指定とルーティング設定

この章では、セキュリティ管理者役割が Trusted Solaris システムとの通信を許可するホストやネットワークを指定したり、その通信に適用するセキュリティ属性を指定したりする際の手順について説明します。これらの情報は、次の観点から説明されています。

トラステッドネットワークデータベースのさまざまなセキュリティ属性に設定すべき値
トラステッドネットワークデータベースに設定された値の使用方法
ルーティングおよびトラステッドルーティングの設定方法

第 9 章「Trusted Solaris におけるホスト管理およびネットワーク管理の概念」および次の項目では、必要な背景知識について説明します。

この章で説明している手順は次のとおりです。

トラステッドネットワークデータベース

セキュリティ管理者役割は、次の図に示すようなデータベースマネージャを使用して、トラステッドネットワークデータベースである tnrhdb(4)、tnrhtp(4)、tnidb(4) にエントリを作成します。各データベースの役割は以下のとおりです。

図 10-1 データベースマネージャの「読み込み (Load)」リストで選択された Tnidb

tnrhtp ファイルは、さまざまなホストタイプに適用するセキュリティ属性のセットが定義されたテンプレートを保持する
tnrhdb ファイルは、tnrhtp ファイルからホストとネットワークにテンプレートを割り当てる
tnidb ファイルは、ネットワークインタフェースに適用するセキュリティ属性を割り当てる

tnidb ファイルに指定された値は、個々のホストやネットワークの tnrhtp および tnrhdb に指定された属性とともに参照され、インタフェースを経由する通信に適用されるセキュリティ属性が確定します (これらの詳細については「着信メッセージにおける MAC の実施」、および「トラステッドネットワークデータベースの属性に関する優先規則」を参照してください)。

データベースマネージャを使用できるようにするには、その前にネームサービスを選択しなければなりません。これには次の 2 つの選択肢があります。

NIS+
なし (None)

データベースマネージャの起動方法とネームサービスの選択方法については、必要に応じて、「「Solstice アプリケーション (Solstice_Apps)」アプリケーションフォルダ内の管理ツールの使用」を参照してください。

tnidb ファイルの値はローカルホストのネットワークインタフェースに適用されるため、tnidb ファイルは常に /etc/security/tsol のローカルファイルとして保持されます。

tnrhdb および tnrhtp ファイルは通常、NIS+ テーブルとして管理されます。ただし、スタンドアロン型 Trusted Solaris ホストの場合は、ネームサービスを使用しないように構成されることもあり、このようなホストでは、両ファイルは /etc/security/tsol に保持されます。

trusted network データベースからの情報は /var/tsol の下にあるカーネルキャッシュファイルに書き込まれます。データベースマネージャを使用して変更を行い、ネーミングサービスを選択しない場合、ローカルホスト上のカーネルキャッシュは自動的に更新されます。NIS+ ネーミングサービスを選択している場合、NIS+ クライアントが NIS+ マスターから trusted network データベースの変更を引き出すまでに最大 30 分かかる可能性があります。

注 -

キャッシュファイルのエントリは変更できますが、削除できません。エントリを削除する唯一の方法は、カーネルキャッシュファイルを削除してリブートすることです。この手順については、「キャッシュされている Trusted Network データベース内のエントリを削除するには」を参照してください。リブート後、tnd(1M) によって新しいキャッシュファイルが作成されます。

Trusted Solaris 版のネームサービススイッチファイル nsswitch.conf(4) には tnrhtp と tnrhdb 用のエントリが含まれています。これらのエントリはサイトの構成に合わせて変更する必要があります。次に、デフォルトの設定を示します。

# TSOL
tnrhtp: nisplus files
tnrhdb: nisplus files

これらのエントリを変更するには、管理役割になり「ネーム・サービス・スイッチ (Name Service Switch)」アクションを実行します (「ネーム・サービス・スイッチ (Name Service Switch)」アクションのアクセス方法に関しては必要に応じて「管理アクションを起動するには」を参照してください)。なお、正しいファイル属性 (所有者、グループ、モード、ラベル) を維持するために、このファイルは直接編集しないようにしてください。

各ホストタイプに設定可能なセキュリティ属性

各ホストタイプごとに設定可能なセキュリティ属性を次の表に示します。詳細については、tnrhtp(4) のマニュアルページを参照してください。

表 10-1 ホストタイプごとのセキュリティ属性


ホストタイプ	セキュリティ属性	デフォルトのテンプレート名
`unlabeled`	機密ラベル、認可上限、UID、GID、強制された特権、監査 UID、監査マスク、監査端末 ID、監査セッション ID、(省略可能な、ゲートウェイホスト用の最下位 SL および最上位 SL)	`unlab` 注意: デフォルトの `unlab` テンプレートは `ADMIN_LOW` 機密ラベルを持っているため、必ず、サイトのユーザー認可範囲内に収まる適切なラベルに変更すること。
`sun_tsol`	許容された特権、最下位 SL と最上位 SL、IP 機密ラベル、RIPSO ラベル、RIPSO エラー、CIPSO DOI、監査 `UID`、監査マスク、監査端末 ID、監査セッション ID	`tsol` (IP ラベルなしで定義) `tsol_1` (IP ラベル型を RIPSO に設定して定義する) `tsol_2` (IP ラベル型を CIPSO と CIPSO Domain 1 に設定して定義する)
`ripso`	機密ラベル、認可上限、UID、GID、強制された特権、RIPSO ラベル、RIPSO エラー、監査 UID、監査マスク、監査端末 ID、監査セッション ID、(ゲートウェイホスト用の最下位 SL および最上位 SL)	`ripso`
`cipso`	認可上限、UID、GID、強制された特権、最下位 SL と最上位 SL、CIPSO DOI、監査 UID、監査マスク、監査端末 ID、監査セッション ID	`cipso`
`tsix`	機密ラベル、認可上限、UID、GID、許容された特権、強制された特権、最下位 SL と最上位 SL、IP ラベル、RIPSO ラベル、RIPSO エラー、CIPSO DOI、監査 UID、監査マスク、監査端末 ID、監査セッション ID	`tsix`
`msix`	機密ラベル、認可上限、UID、GID、最下位 SL と最上位 SL、監査 UID、監査マスク、監査端末 ID、監査セッション ID	`msix`

上記の表の 3 番目の欄は、システムに同梱されているデフォルトのテンプレート名をすべて示したものです。デフォルトのテンプレートセットはコピー、リネーム、または再定義できます。

テンプレートマネージャで各ホストタイプに割り当てられるテンプレート

注 -

テンプレートマネージャ画面でホストタイプを一度選択すると、そのホストタイプに適用されないフィールドは、使用できないようにグレー表示になります。

以下の項では、サポートされているホストタイプ別に、図を参照しながら、サポートされているテンプレートおよびフィールドについて説明しています。

TRUSTED SOLARIS 7、2.5.1、2.5 (sun_tsol) ホストタイプ

Ethernet ヘッダー

IP ヘッダー [IP オプション]

TCP または UDP ヘッダー

SAMP ヘッダー [バイナリ属性]

データ

Ethernet トレーラ

sun_tsol ホストタイプを指定した場合 (つまり、テンプレートマネージャで「Trusted Solaris 7, 2.5.1, 2.5」オプションを選択した場合)、トラステッドネットワークソフトウェアは SAMP (Security Attribute Modulation Protocol) を使ってセキュリティ属性を送信します。セキュリティ属性はトークンマッピング形式でなく、バイナリ形式で表現されます。

注 -

Trusted Solaris 7、2.5.1、2.5 サーバーのディスクレスクライアントは、sun_tsol ホストタイプとして指定されなければなりません。

sun_tsol ホストタイプのエントリで、「I.P. ラベルの型 (IP. Label Type)」フィールドを「CIPSO」または「RIPSO」に設定すると、IP ヘッダーの IP オプションに CIPSO または RIPSO ラベルが挿入され、Trusted Solaris 7、2.5.1、および 2.5 ホストからの通信のトラステッドルーティングに使用されます。「トラステッドネットワークデータベースにおけるエントリの作成」、および「パケットの CIPSO ラベル」を参照してください。

Trusted Solaris 7、2.5.1、および 2.5 ホストに設定できるセキュリティ属性は、図 10-2 のとおりです。このホストタイプに適用されないフィールドは、使用できないようにグレー表示されます。

図 10-2 Tnrhtp で Trusted Solaris 7、2.5.1、2.5 ホストタイプに設定できるフィールド

次の表に、sun_tsol ホストタイプの設定可能なセキュリティ属性の詳細を示します。

表 10-2 sun_tsol ホストタイプのセキュリティ属性の詳細


設定可能な属性	説明
最下位機密ラベル (`min_sl=`)	`ADMIN_LOW` または他の有効な機密ラベルを指定し、`sun_tsol` ホストとの通信を制限する。
最上位機密ラベル (`max_sl=`)	`ADMIN_HIGH` または他の有効な機密ラベルを指定し、`sun_tsol` ホストとの通信を制限する。
許容された特権 (`allowed_privs=`)	当該ホストによりネットワーク (受信と送信の両方) で伝達される有効な特権セットを制限するために指定する。指定した特権だけが許可される。`all` はすべての特権が解釈されることを意味する。`none` は特権が解釈されないことを意味する。ホストに適用される `tnrhtp` テンプレートでは、`allowed_privs=empty` は、このフィールドの `tnidb` に指定したものが適用されることを意味する。`tnidb` ファイルでは、`empty` は特権が適用されないことを意味する。
IP ラベル (`ip_label=`)	有効なタイプ (`none`、`ripso`、`cipso`) を 1 つだけ指定する。
RIPSO ラベル (`ripso_label=`)	`ip_label=empty` の場合、`ripso_label=emplty` を指定する。IP ラベルタイプが `ripso` の場合、サポートされる格付けレベルエンコーディング (`Top_Secret`、`Secret`、`Confidential`、`Unclassified`) を 1 つだけ指定する。
RIPSO エラー (`ripso_error=`)	`ip_label=empty` の場合、`ripso_error=empty` を指定する。IP ラベルタイプが `ripso` の場合、サポートされる保護権限フラグ (`GENSER`、`SIOP-ESI`、`SCI`、`NSA`、`DOE`) を 1 つだけ指定する。格付けレベルには `ripso_label` フィールドの値が使われる。
CIPSO DOI (`cipso_doi=`)	`ip_label=empty` の場合、`cipso_doi=empty` を指定する。IP ラベルタイプが `cipso` の場合、ホストの CIPSO ラベル付きパケット用ドメイン解釈に対応する番号を指定する。
監査マスク、監査端末 ID、監査セッション ID

TSIX (tsix) ホストタイプ

Ethernet ヘッダー IP ヘッダー [IP オプション] TCP または UDP ヘッダー SAMP ヘッダーデータ Ethernet トレーラ

tsix ホストタイプを指定した場合 (つまり、テンプレートマネージャの「ホストタイプ (Host Type)」メニューで「TSIX」を選択した場合)、トラステッドネットワークソフトウェアは TSIG (Trusted System Interoperability Group) で制定された TSIX 規格に準拠するホストと通信します (Sun Microsystems Federal, Inc. は TSIG のメンバーです)。tsix ホストタイプの場合、トラステッドネットワークソフトウェアは SATMP (Security Attribute Token Mapping Protocol) を使います。属性がトークン形式であることは、SAMP ヘッダーの属性ヘッダーで識別されます。属性がバイナリ形式の代わりにトークン形式で伝送されることを除けば、パケットは sun_tsol ホストタイプと同じ形式になります。

「I.P. ラベルの型 (IP Label Type)」フィールドは「なし (None)」、「CIPSO」、「RIPSO」のいずれかに設定できます。このフィールドを設定すると、IP ヘッダーの IP オプションに、トラステッドルーティングに使用される CIPSO または RIPSO ラベルが挿入されます。「トラステッドネットワークデータベースにおけるエントリの作成」を参照してください。

TSIX ホストタイプを使用して通信を行うには、送信側と受信側のホストを両方とも同じ TSIX DOT (domain of translation) 内に設定する必要があります。

注 -

サンの TSIX トークンマップの定義は、最初に定義された TSIX DOT であるため、Trusted Solaris システムとの通信を希望する他の組織では、少なくとも 1 つ以上の TSIX DOT が定義されるまでは、このサン定義の DOT を使用する必要があります。将来的には、トークンの意味を定義する TSIX DOT レジストリが設定される予定です。

「I.P. ラベルの型 (IP Label Type)」フィールドに CIPSO が指定された tsix タイプのホストでは、system(4) ファイルの tsol_admin_high_to_cipso スイッチを 1 に設定しなければなりません。そうしないと、Trusted Solaris ホストとの通信が不能になります。/etc/system ファイルにスイッチを追加する方法については、第 13 章「Trusted Solaris カーネルスイッチ設定の変更」を参照してください。

tsix ホストに設定できるセキュリティ属性は、次の図のとおりです。このホストタイプに適用されないフィールドは、使用できないようにグレー表示されます。

図 10-3 Tnrhtp で TSIX ホストタイプに設定できるフィールド

次の表に、tsix ホストタイプの必須セキュリティ属性の詳細を示します。

表 10-3 tsix ホストタイプの必須セキュリティ属性


設定可能な属性	説明
最下位機密ラベル (`min_sl=`)	16 進数形式の `ADMIN_LOW`または他の有効な機密ラベルを指定し、tsix ホストとの通信を制限する。
最上位機密ラベル (`max_sl=`)	16 進数形式の `ADMIN_HIGH` または他の有効な機密ラベルを指定し、tsix ホストとの通信を制限する。
許容された特権 (`allowed_privs=`)	当該ホストによりネットワーク (受信と送信の両方) で伝達される有効な特権セットを制限するために指定する。指定した特権だけが許可される。`all` はすべての特権が解釈されることを意味する。`none` は特権が解釈されないことを意味する。ホストに適用される `tnrhtp` テンプレートでは、`allowed_privs=empty` は、このフィールドの `tnidb` に指定したものが適用されることを意味する。`tnidb` ファイルでは、`empty` は特権が適用されないことを意味する。
強制された特権 (`forced_privs=`)	当該ホストは特権を提供しないため、定義しているホストからの着信パケットに適用される特権を指定する。`all` はすべての特権が解釈されることを意味する。`none` は特権が解釈されないことを意味する。ホストに適用される `tnrhtp` テンプレートでは、`forced_privs=empty` は、このフィールドの `tnidb` に指定したものが適用されることを意味する。`tnidb` ファイルでは、`empty` は特権が適用されないことを意味する。
デフォルトのラベル (`def_label=`)	当該ホストは機密ラベルを提供しないため、定義しているホストからの着信パケットに適用される機密ラベルを指定する。
デフォルトの認可上限 (`def_cl=`)	当該ホストは認可上限を提供しないため、定義しているホストからの着信パケットに適用される認可上限ラベルを指定する。プロセスは、その認可上限に対応する機密ラベルに書き換えることができる。
デフォルトの `UID`(`def_uid=`)	当該ホストは `UID` を提供しないため、定義しているホストからの着信パケットに適用される `UID` を指定する。
IP ラベル (ip_label=)	有効なタイプ (`NONE`、RIPSO、CIPSO) を 1 つだけ指定する。
RIPSO ラベル (`ripso_label=`	`ip_label=empty` の場合、`ripso_label=emplty` を指定する。IP ラベルタイプが `ripso` の場合、サポートされる格付けレベルエンコーディング (`Top_Secret`、`Secret`、`Confidential`、`Unclassified`) を 1 つだけ指定する。
RIPSO エラー (`ripso_error=`)	`ip_label=empty` の場合、`ripso_error=empty` を指定する。IP ラベルタイプが `ripso` の場合、サポートされる保護権限フラグ (`GENSER`、`SIOP-ESI`、`SCI`、`NSA`、DOE) を 1 つだけ指定する。格付けレベルには `ripso_label` フィールドの値が使われる。
CIPSO DOI (cipso_doi=)	`ip_label=empty` の場合、`cipso_doi=empty` を指定する。IP ラベルタイプが `cipso` の場合、ホストの CIPSO ドメイン解釈に対応する番号を指定する。

TRUSTED SOLARIS 1.2、1.1 (msix) ホストタイプ

Trusted Solaris 1.2、1.1 (msix) ホストからの通信にサポートされるセキュリティ属性ではラベルだけが使用され、IP ヘッダーによって搬送されます。

Trusted Solaris 1.2 または 1.1 オペレーティング環境では MSIX 1.0 の完全な機能と MSIX 2.0 の一部の機能が含まれているため、これらの環境が動作しているホストのテンプレートでは Trusted Solaris 1.2 or 1.1 ホストタイプを指定する必要があります。Trusted Solaris 1.2 と 1.1 の MSIX のバージョンは MSIX 2.0 の一部の機能だけしかサポートしていないため、MSIX 2.0 プロトコルを使うホストのテンプレートでは msix ホストタイプを指定してはなりません。

Trusted Solaris 1.2、1.1 ホストに指定できるセキュリティ属性は、次の図のとおりです。このホストタイプに適用されないフィールドは、使用できないようにグレー表示されます。

図 10-4 Tnrhtp で TRUSTED SOLARIS 1.2、1.1 ホストタイプに設定できるフィールド

CIPSO (cipso) ホストタイプ

Ethernet ヘッダー

IP ヘッダー [CIPSO ラベルが入ったIP オプション]

TCP または UDP ヘッダー

データ

Ethernet トレーラ

CIPSO ホストタイプは、CIPSO 規格に準拠するホストとの通信をサポートします。CIPSO ホストでサポートされるセキュリティ属性は CIPSO ラベルだけです。このラベルはデータの機密ラベルから取得され、cipso ホストタイプのホストに送信されるパケットの IP ヘッダーに挿入されます。ホストのエントリには、宛先ホスト、および送信したパケットがルートされるすべてのゲートウェイと同じ CIPSO DOI (domain of interpretation) を指定しなければなりません。送信側ホストが CIPSO ホストタイプとして指定されると、トラステッドネットワークソフトウェアは、着信パケットの IP ヘッダーに挿入された CIPSO ラベルを検索します。

CIPSO ホストに指定できるセキュリティ属性は、次の図のとおりです。このホストタイプに適用されないフィールドは、使用できないようにグレー表示されます。

図 10-5 Tnrhtp で CIPSO ホストタイプに設定できるフィールド

RIPSO (ripso) ホストタイプ

Ethernet ヘッダー

IP ヘッダー [RIPSO ラベルが入ったIP オプション]

TCP または UDP ヘッダー

データ

Ethernet トレーラ

RIPSO 規格に準拠するホストをサポートします。ripso タイプのホストとの通信に使用される RIPSO ラベルは、tnrhtp(4) のマニュアルページに書かれているように、そのホストのテンプレートに管理上の目的で定義されます。ripso ホストタイプのテンプレートでは、「RIPSO 送信クラス RIPSO Send Class)」フィールドを Top Secret、Secret、Confidential、Unclassified または 16 進数の値のいずれかに設定しなければなりません。また、テンプレートの「RIPSO 送信 PF (RIPSO Send PAF)」フィールドと「RIPSO 戻り PAF (RIPSO Return PAF)」フィールドは、どちらも「GENSER」、「SIOP-ESI」、「SCI」、「NSA」、「DOE」または 16 進数の値のいずれかに設定する必要があります。

ripso ホストに指定できるセキュリティ属性は、次の図のとおりです。このホストタイプに適用されないフィールドは、使用できないようにグレー表示されます。

図 10-6 Tnrhtp で RIPSO ホストタイプに設定できるフィールド

送信は、最下位機密ラベル (「最下位 SL (Minimum SL)」フィールドで指定する) とデフォルトの機密ラベル (「ラベル (Label)」フィールドで指定する) の間のどの機密ラベルでも行えます。一方、受信はデフォルトの機密ラベルでのみ行えます。

注 -

自サイトの送信を 1 つの機密ラベルに制限する必要がある場合だけ、「ラベル (Label)」フィールドで指定したデフォルトの機密ラベルと同じ最下位 SL を設定する必要があります。

ラベルなし (unlabeled) ホストタイプ

Ethernet ヘッダー

IP ヘッダー [IP オプション]

TCP または UDP ヘッダー

データ

Ethernet トレーラ

ラベルなしホストに指定できるセキュリティ属性は、図 10-7 のとおりです。このホストタイプに適用されないフィールドは、使用できないようにグレー表示されます。

最下位および最上位機密ラベルフィールドは、トラステッドルーティングに使用され、ラベルなしゲートウェイを介したパケットのルーティングを行います。セキュリティ管理者役割は、最下位機密ラベルと最上位機密ラベルを使用してパケットの範囲を定義し、ラベルなしゲートウェイを介した転送を実現することができます。

ラベルなしホスト、あるいは RIPSO ホストでは、送信は、最下位機密ラベル (「最下位 SL (Minimum SL)」フィールドで指定) とデフォルトの機密ラベル (「ラベル (Label)」フィールドで指定) 間のどの機密ラベルでも行われるのに対して、受信は、デフォルトの機密ラベルでのみ行われます。

注 -

自分のサイトの送信を 1 つの機密ラベルに限定する必要がある場合は、「ラベル (Label)」フィールドで指定したデフォルトの機密ラベルと同じ最下位 SL を設定する必要があります。

認可範囲は、ラベルなしホストでユーザーが実行できる書き込み操作の上限を設定します。たとえば、あるサイトで、Solaris オペレーティング環境を実行するラベルなしホストに対し、デフォルトの機密ラベルとして CONFIDENTIAL (C) を、認可上限として SECRET (S) を設定したとします。その結果、Trusted Solaris ホストからマウントされたファイルシステムで作業する Solaris ホストのユーザーは、機密ラベル S を持つ昇格されたファイルを開いて、そのファイルに書き込み操作を行うことができます (ただしこれは、ユーザーに対し、そのファイル名が表示される場合に限ります)。

図 10-7 Tnrhtp でラベルなしホストタイプに設定できるフィールド

トラステッドネットワークデータベースにおけるエントリの作成

tnrhdb ファイルでホストやネットワークにテンプレートを割り当てる前に、セキュリティ管理者は次のことを行っておく必要があります。

tnrhtp(4) ファイルの既存のテンプレートを確認する

データベースマネージャから Tnrhtp データベースを起動し、順番にそれぞれのテンプレートを選択して、その内容をテンプレートマネージャの「変更 (Modify)」ダイアログボックスに表示します。
サイトの必要性に応じて、既存のテンプレートを変更するか、新しいテンプレートを作成する
各ホストとネットワークに使用するテンプレートを決定する

tnrhdb オプションを使用して、閉鎖型または開放型ネットワーク構成を実現する

トラステッドネットワークは、次の 2 種類のネットワーク構成をサポートします。

あらゆるホストとの通信を許可する開放型ネットワーク構成
指定されたホストとネットワークに限り通信を許可する閉鎖的制御型ネットワーク構成

他のホストおよびネットワークとの通信を、開放型または閉鎖型のどちらにするかは、それぞれのサイトで決定します。

階層型代替機構

階層型代替アルゴリズムは、マニュアルページにも書かれているように、トラステッドネットワークソフトウェアが tnrhdb(4) データベースのホストのエントリを検索する際に使用します。トラステッドネットワークソフトウェアは、そのホスト固有のエントリが見つからなかった場合は、代わりにクラス C と一致するネットワークエントリを検索し、次にクラス B のエントリ、その次にクラス A のエントリと検索していきます。どのエントリも見つからない場合は、最後にワイルドカードエントリ (IP アドレス 0.0.0.0) を検索します。tnrhdb データベースに、そのホストの IP アドレスと一致するエントリがなければ、そのホストとの通信は許可されません。この代替メカニズムは、開放型ネットワーク構成でも制御型ネットワーク構成でも、注意して使用することができます。

ワイルドカードを使用した開放型ネットワーク構成

セキュリティ管理者役割は、「ワイルドカードエントリ」を作成してデフォルトの属性セットを指定し、それをネットワークデータベースにエントリが検出されなかったホストに割り当てます。ワイルドカードエントリに割り当てられたテンプレートは、「テンプレートの設定」の項で説明しているように、セキュリティ管理者が他のテンプレートとともに tnrhtp(4) データベースに構成します。

閉鎖的制御型のネットワーク構成

ホストとの通信は、トラステッドネットワークソフトウェアが、tnrhdb データベースのエントリにそのホストの IP アドレスを検出できない限り許可されません。通信を厳格に制限するには、セキュリティ管理者役割はネットワークエントリを指定する際に、ワイルドカードを使わずに個々のエントリを指定します。

テンプレートの設定

セキュリティ管理者役割がホストにテンプレートを対応付ける方法には何種類かあります。これらの方法については、次の手順を参照してください。

注 -

以下の例では、tsol_1、tsol、および wildcard (ワイルドカード) のテンプレートが tnrhtp ファイルに設定されているものと仮定します。

トラステッドネットワークデータベースの属性に関する優先規則

セキュリティ管理者役割によってホストの tnrhtp テンプレートに値が設定されている場合は、次の図に示すように、その tnrhtp ファイルの値が、tnidb のネットワークインタフェースに指定された値よりも優先されます。次の図を見てもわかるように、tnidb の値は、パケットを送信するホストの tnrhdb エントリに値が設定されていない場合しか適用されません。

図 10-8 属性の優先規則

デフォルト値が必要なフィールドは、少なくともどちらかのファイルで値が指定されていなければなりません。tnrhtp に empty という値が指定されたデフォルトのフィールドがある場合、セキュリティ管理者役割は、tnidb ファイル内の対応するデフォルトのフィールドにその値が指定されていることを確認する必要があります。

新たなインタフェースを追加するときは、セキュリティ管理者役割は、データベースマネージャのインターフェースマネージャの「追加 (Add)」ダイアログボックス内のフィールドをすべて指定する必要があります。セキュリティ管理者役割がインタフェースのデフォルトセットとして tnidb のデフォルト定義に変更を加えない場合は、データベースマネージャのインタフェースマネージャに表示されている値が適用されます。次の図に le0 に対する tnidb エントリを示します。ここでは、最下位 SL が ADMIN_LOW、最上位 SL が ADMIN_HIGH、ラベルが ADMIN_LOW[ADMIN_LOW]、認可上限が ADMIN_HIGH、ユーザー ID およびグループ ID が nobody です。

図 10-9 Tnidb データベースの le0 インタフェースへのデフォルトエントリ

優先例

次の図は、wildcard という名前のテンプレートが未知のホストに定義されています。ラベルは [INTERNAL] に、認可上限は INTERNAL に、ユーザー ID は 12022 に、グループ ID は 10 に定義されています。

図 10-10 デフォルト属性の未知のホストからの通信への割り当て

この例では、インタフェースの定義は、図 10-9 で指定されたデフォルト値で、ラベルは ADMIN_LOW、認可上限は ADMIN_HIGH、ユーザー ID とグループ ID はどちらも nobody です。

ラベル、認可上限、UID および GID は、テンプレート wildcard からとられるので、テンプレート内の値はインタフェースの tnidb の値よりも優先します。le0 インタフェースを介して未知のホストから送られるパケットに割り当てられるラベルは INTERNAL、認可上限は INTERNAL、ユーザー ID は 120022、グループ ID は 10 です。

ネットワーク認可範囲

ホストとネットワークには、それぞれ認可範囲が指定されます。ホストの認可範囲は、tnrhtp ファイルの min_sl および max_sl エントリで設定され、ネットワークインタフェースの認可範囲は、tnidb ファイルの min_sl、max_sl エントリで設定されます。

図 10-11 の例は、le0、le1 という 2 つのネットワークインタフェースを持つホスト G を示しています。le0 の認可範囲は ADMIN_LOW から ADMIN_HIGH に定義されており、le1 の認可範囲は INTERNAL_USE_ONLY から NEED_TO_KNOW ENG に定義されています。

図 10-11 2 つのネットワークインタフェースとそのネットワーク認可範囲

注 -

Trusted Solaris 分散システム内の通信では、認可範囲を ADMIN_LOW から ADMIN_HIGH に設定する必要があります。

「ネットワークインタフェースを構成するには」を参照してください。

ブート時トラステッドネットワークデータベース

ブート時専用ローカルバージョンの tnrhdb および tnrhtp ファイルは、常に /etc/security/tsol/boot ディレクトリに保持されています。ブート時のファイルの形式は、通常の tnrhdb(4) ファイルと tnrhtp(4) ファイルと同じです (それぞれのマニュアルページを参照)。

NIS+ クライアントは、それらの IP アドレスとトラステッドネットワーク構成情報が利用できない間は、ブート時に NIS+ マスターに到達可能でなければならないため、ブート時ファイルを必要とします。他のホストはルーターと通信する必要があります。

ブート時に通信すべきホストの IP アドレスを構成前に知る方法はないため、デフォルトのブート時 tnrhdb ファイルにはワイルドカードアドレスを指定します。すべてのホストは Trusted Solaris を稼働しているものと想定されるため、sun_tsol ホストタイプが割り当てられます。

ブート後、トラステッドネットワークに指定されたエントリは、/var/tsol 下のトラステッドネットワークキャッシュファイルのブート時ファイルにある同じ名前のエントリを無効にします。

注意 -

通常の tnrhdb データベース内に対応するエントリが存在しない場合、キャッシュされているワイルドカードエントリは無効にされることはありません。キャッシュされているエントリを削除するには、カーネルキャッシュファイルを削除してリブートする以外に方法はありません。この手順については、「キャッシュされている Trusted Network データベース内のエントリを削除するには」を参照してください。

デフォルトのブート時エントリ

次の例に示すように、/etc/security/tsol/boot/tnrhdb 内にあるデフォルトのエントリは、IP アドレス 0.0.0.0 で指定されるワイルドカードエントリに tsol というテンプレートを割り当てます。

# Loaded at initial boot time only.
# Should be replaced by regular entries after boot.
# 0.0.0.0:tsol

次の例に示すように、デフォルトの /etc/security/tsol/boot/tnrhtp ファイルには、tsol というテンプレートが 1 つだけ存在します。tsol テンプレートは sun_tsol ホストタイプに割り当てられます。

# Loaded at initial boot time only.
# Should be replaced by regular entry after boot.
#tsol:host_type=sun_tsol;min_sl=0x00000000000000000000000000000000000000
000000000000000000000000000000;
max_sl=0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff;
allowed_privs=all;ip_label=none;ripso_label=empty;
ripso_error=empty;cipso_doi=empty;def_audit_auid=3;def_audit_mask=0x0000000000;
def000000_audit_termid=0x0000000000000000;def_audit_asid=0;

デフォルトのエントリの変更

各 NIS+ クライアントの最初のブート後、インストールチームは、必要なセキュリティのレベルに応じて、次のうちの 1 つを行うことをお勧めします。

ワイルドカードエントリを削除し、ブート時に通信するすべてのホスト用のエントリを作成し、必要に応じて、テンプレートを追加します。

「ワイルドカードエントリの変更」を参照してください。

注意 -
通信が許可されているホストおよびネットワークを個々に定義しているサイトでは、デフォルトのワイルドカードエントリを変更する必要があります。
ワイルドカードを割り当てられているテンプレートを、ラベルなしホストタイプで定義されているテンプレートに変更します。

次の例では、ラベルなしホストタイプで定義されている、デフォルトの unlab テンプレートを割り当てています。
0.0.0.0:unlab

ワイルドカードエントリの変更

以降のブート時に通信するホストを制御するには、/etc/security/boot/tnrhdb 内のワイルドカードエントリを、ブート時に通信するすべてのホスト用のエントリに変更し、必要なテンプレートを /etc/security/boot/tnrhtp に追加します。「ブート時ファイル tnrhdb および tnrhtp のデフォルトエントリを変更するには」を参照してください。

次のエントリが必要です。

NIS+ マスター用のエントリ
ローカルホストのすべての IP アドレス用のエントリ

たとえば、2 つのインタフェースを持つゲートウェイホストは、hosts(4) ファイルに次のようなエントリを持っています。
137.150.113.111 trusted 137.150.113.112 trusted-112
次に、ブート時 tnrhdb における、トラステッドな 2 つの IP アドレス用のエントリを示します。
137.150.113.111:tsol 137.150.113:112:tsol
ローカルホストのループバックアドレス用のエントリ
127.0.0.1:tsol
1 つまたは複数のルーター用のエントリ

NIS+ クライアントがルーターでない場合、次のうちの 1 つを行います。
- ローカルネットワーク上のルーターの IP アドレスを入力します (例: 137.150.113.120)。
- フォールバックネットワーク用のエントリを作成します (例: 137.150.113.0)。
NIS+ クライアントがルーターである場合、ブート時に通信する必要があるすべてのルーターの一覧を作成します。
キャッシュファイルを削除して、ワイルドカードエントリを削除します。

この手順については、「キャッシュされている Trusted Network データベース内のエントリを削除するには」を参照してください。

トンネリングの設定

「トンネリング」の項で説明したように、トンネリングを設定すると、2 台の Trusted Solaris ゲートウェイの間に Trusted Solaris 以外のホストとゲートウェイのクラスタ (雲) が存在している場合でも、イントラネット上のルートの拡張メトリックを共有できるようになります。この場合、ホストはすべて、Trusted Solaris 拡張 RIP を実行するゲートウェイとともに、同一イントラネット内に構成されなければなりません。トンネリングを設定しないと、ゲートウェイの拡張 RIP によって生成される特殊なセキュリティ応答パケットが、リモート Trusted Solaris ゲートウェイに到達できないため、認識されたルートの拡張メトリックも転送不能なります。

トンネリングを設定するには、セキュリティ管理者が Trusted Solaris ゲートウェイに tunnel ファイルを作成します。tunnel ファイルには、Trusted Solaris ゲートウェイに接続されたリモートネットワークの IP アドレスが保持されます。セキュリティ情報が含まれるラベルなしブロードキャストパケットは、この tunnel ファイルに指定されているネットワークに直接送信され、Trusted Solaris ゲートウェイによって受信されます。「トンネリングを設定するには」を参照してください。

手順

ブート時ファイル tnrhdb および tnrhtp のデフォルトエントリを変更するには

セキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動します。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

「管理用エディタ (Admin Editor)」アクションを実行して /etc/security/tsol/boot/tnrhdb ファイルを開き、編集します。

必要に応じて、「管理用エディタアクションを使用してファイルを編集するには」を参照してください。

デフォルトエントリの例を次に示します。
0.0.0.0:tsol

ワイルドカードエントリを削除するか、定義し直します。

次に、ラベルなしホストタイプが割り当てられている、デフォルトの unlab テンプレートを使用して、定義し直したワイルドカードエントリを示します。
0.0.0.0:unlab
ワイルドカードエントリを削除した場合、次の手順に進みます。ワイルドカードエントリを定義し直した場合、手順 7 に進みます。

ワイルドカードエントリを変更するには、現在のホストがブート時に通信する必要があるすべてのホストのエントリを作成します。
1. NIS+ クライアントの場合、NIS+ マスター用のエントリを作成します。
2. 構成中のホストの IP アドレスごとにエントリを作成します。
  
  次に、2 つのインタフェースを持つルーターであるホスト用のエントリを示します。
  127.150.113.111:tsol 127.150.113.112:tsol
3. 構成中のホストのループバックアドレス用のエントリを作成します。
  127.0.0.1:tsol
4. 構成中のホストがルーターでない場合、ホストがルーターを見つけるための 1 つまたは複数のエントリを作成します。
  
  次のいずれかを行います。
  1. ローカルネットワーク上にあるルータ用のエントリを作成します。
  2. NIS+ クライアントがローカルルーターを見つけるための、ネットワーク用のフォールバックエントリを作成します。
次の例に、NIS+ クライアント用のエントリを示します。ホストの IP アドレスは 129.96.22.29、NIS+ マスターの IP アドレスは 129.96.22.40、ループバック IP アドレスは 127.0.0.1、そして、ネットワークの IP アドレスは 129.96.22.0 です (ルーターを見つけるために使われる)。
129.96.22.29:tsol 129.96.22.40:tsol 127.0.0.1:tsol 129.96.22.0:tsol

ファイルを上書き保存し、閉じます。
:wq

必要に応じて、tnrhdb ファイルのエントリのために必要なテンプレートがあれば追加します。

「管理用エディタ (Admin Editor)」アクションを実行して /etc/security/tsol/boot/tnrhtp ファイルを開き、編集します。

たとえば、tnrhdb(4) 内に指定されているいずれかのホストのホストタイプがラベルなしの場合、次に示すように、host_type=unlabeled を含むテンプレートを追加します。

unlab:unlabeled; def_label=0x000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000[0x1000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000];
def_cl=0x00000000000000000000000000000000000000000000000000000000000000000000; 
def_uid=empty; def_gid=empty; forced_privs=empty;
min_sl=0x00000000000000000000000000000000000000000000000000000000000000000000; 
max_sl=0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff; 
def_audit_auid=3; def_audit_mask=0x00 00000000000000; 
def_audit_termid=0x0000000000000000; def_audit_asid=0;

注意 -

デフォルトの unlab テンプレートを使う場合は、def_label フィールドの機密ラベル部分を、必ずユーザー認可範囲内に収まるようなラベルに変更してください。デフォルトのテンプレートの機密ラベルは ADMIN_LOW であり、通常のユーザーはこのラベルでは作業できません。情報ラベル部分は ADMIN_LOW に固定されています。

ファイルを上書き保存し、閉じます。
:wq

データベースマネージャからトラステッドネットワークデータベースにアクセスするには

セキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動します。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

アプリケーションマネージャの「Soltice アプリケーション (Solstice_Apps)」フォルダを開きます。

必要に応じて、「管理アプリケーションを起動するには」を参照してください。

データベースマネージャ (Database_Manager) アイコンをダブルクリックし、データベースマネージャの「読み込み (Load)」リストを開きます。

次の例は、「Soltice アプリケーション (Solstice_Apps)」フォルダで選択されたデータベースマネージャを示しています。

データベースマネージャの「読み込み (Load)」リストの「ネームサービス (Naming Service)」メニューから、ネームサービスを選択します。

デフォルトでは、次の例に示すように NIS+ ネームサービスが選択されており、NIS+ のドメイン名が「ドメイン名 (Domain)」テキストエントリフィールドに表示されるようになっています。

注 -
NIS+ を使っている場合でも、tnidb は常に、「ネーミングサービス (Naming Service)」を「なし (None)」に設定して変更したローカルファイルであることを念頭に置いてください。これに対して、tnrhdb と tnrhtp は、「ネーミングサービス (Naming Service)」を「NIS+」または「なし (None)」に設定して変更できます。スタンドアロンの Trusted Solaris システムを NIS+ なしで構成する場合、上記 3 つのファイルはすべて「ネーミングサービス」を「なし (None)」に設定して変更します。これらのファイルのための nsswitch.conf(4) エントリが、ローカルファイルと NIS+ ファイルの両方に加えられた変更を反映する検索シーケンスになっていることを確認してください。
1. tnidb にアクセスする場合は、「なし (None)」を選択します。
  
  「なし (None)」を選択すると、次の例に示すように、現在のホスト名が「ホスト名 (Host)」テキストエントリフィールドに表示されます。
2. tnrhdb および tnrhtp ファイルにアクセスする場合は、システム構成に合わせ、「NIS+」または「なし (None)」のどちらかのネームサービスを選択します。

ネームサービスを「なし (None)」にした場合で、リモートホストのデータベースを構成する場合は、「ホスト名 (Host)」テキストエントリフィールドにそのホスト名を入力します。

編集するトラステッドネットワークデータベースの名前をダブルクリックします。または強調表示してから「了解 (OK)」をクリックします。

必要に応じて、「tnrhtp に新規テンプレートを作成するには」、「tnrhdb で単一のホストにテンプレートを割り当てるには」、「tnrhdb でホストのグループにテンプレートを割り当てるには」、「ワイルドカードを使用して、別に指定されていないすべてのホストの tnrhdb エントリを作成するには」、「ホストテンプレートまたはネットワークインタフェースエントリに認可範囲を設定するには」、「ネットワークインタフェースを構成するには」、「tnidb で新規エントリを追加する、または既存エントリを変更するには」、または「ルーティングの IP ラベルを設定するには」に進んでください。

tnrhtp に新規テンプレートを作成するには

セキュリティ管理者役割になって、ADMIN_LOW ワークスペースに移動し、データベースマネージャを起動します。

必要に応じて、「データベースマネージャからトラステッドネットワークデータベースにアクセスするには」を参照してください。フィールドの定義に関しては、tnrhtp(4) のマニュアルページも参照してください。「各ホストタイプに設定可能なセキュリティ属性」に述べたように、すべてのフィールドが各テンプレートにあるわけではありません。

「ネームサービス (Naming Service)」オプションメニューをクリックし、さらに「なし (None)」または「NIS+」をクリックします。

データベースマネージャの「読み込み (Load)」リストの Tnrhtp を強調表示し、「編集 (Edit)」メニューから「追加 (Add)」を選択します。

テンプレートマネージャの「追加 (Add)」ダイアログが次の図のように表示されます。

「テンプレート名 (Template Name)」に入力します。

「ホストタイプ (Host Type)」オプションメニューのボタンをクリックし、メニューの中から希望するホストタイプをクリックして選択します。

注 -
以降の手順を進めていくときに、必ずしもすべてのホストタイプですべてのフィールドが使用できるわけではないことに注意してください。

「最下位 SL (Minimum SL)」ボタンをクリックし、ラベルビルダーを使用して、希望する最下位機密ラベルを指定します。

ラベルを認識するホストでは、このフィールドは、ホストの認可範囲の下限を設定するのに使われます。ラベルなしおよび RIPSO ホストタイプの場合は、このフィールドは、ホストがゲートウェイのときのトラステッドルーティングに使われます。

「最上位 SL (Maximum SL)」ボタンをクリックし、ラベルビルダーを使用して、希望する最上位機密ラベルを指定します。

ラベルを認識するホストでは、このフィールドは、ホストの認可範囲の上限を設定するのに使われます。ラベルなしおよび RIPSO ホストタイプの場合は、このフィールドは、ホストがゲートウェイのときのトラステッドルーティングに使われます。

希望するユーザー ID を入力するか、「Def!」をクリックして、空のデフォルト値を設定します。

ラベルなしのホストの場合、ここでユーザー ID を指定しないときは、各ローカルホストの Tnidb にユーザー ID を指定してください。

希望するグループ ID を入力するか、「Def!」をクリックして、空のデフォルト値を設定します。

ラベルなしのホストの場合、ここでグループ ID を指定しないときは、各ローカルホストの Tnidb にグループ ID を指定してください。

「ラベル (Label)」ボタンをクリックし、ラベルビルダーを使用して、希望するデフォルトの機密ラベルを指定します。
1. 「更新後のラベル (Update With)」フィールドに機密ラベルを入力します。
2. 「更新 (Updata)」ボタンをクリックします。
3. 「了解 (OK)」をクリックして、変更を保存し、ダイアログを終了します。

「認可上限 (Clearance)」ボタンをクリックし、認可上限ビルダーを使って、希望するデフォルトの認可上限ラベルを指定します。
1. 「更新後のラベル (Update With)」フィールドに認可上限を入力します。
2. 「更新 (Updata)」ボタンをクリックします。
3. 「了解 (OK)」をクリックして、変更を保存し、ダイアログを終了します。

希望する強制された特権を選択します。
1. 「強制された特権 (Forced Privileges)」ボタンをクリックして、「強制された特権 (Forced Privileges)」ダイアログボックスを起動し、次のどれかを行います。
  1. 希望する強制された特権を「含む (Included:)」一覧に移動します。
  2. 「Def!」ボタンをクリックして、デフォルトの強制された特権セット (空) を指定します。
  3. 「All!」ボタンをクリックして、すべての特権を指定します。
2. 「了解 (OK)」をクリックして、変更を保存し、ダイアログを終了します。

希望する許可された特権を選択します。
1. 「許可された特権 (Allowed Privileges)」ボタンをクリックして、「許可された特権 (Allowed Privileges)」ダイアログボックスを起動し、次のどれかを行います。
  1. 希望する許可された特権を「含む (Included:)」一覧に移動します。
  2. 「Def!」ボタンをクリックして、デフォルトの許可された特権セット (空) を指定します。
  3. 「All!」ボタンをクリックして、すべての特権を指定します。
2. 「了解 (OK)」をクリックして、変更を保存し、ダイアログを終了します。

希望する監査特性を選択します。
1. 「監査特性 (Audit Characteristics)」ボタンをクリックして、「監査特性 (Audit Characteristics)」ダイアログボックスを起動します (任意)。
  1. 「監査ユーザー ID (Audit User ID)」を入力します。
  2. 「監査端末 ID (Audit Terminal ID)」を入力します。
  3. 「監査セッション ID (Audit Session ID)」を入力します。
  4. 「All!」ボタンをクリックして、すべての特権を指定します。
2. 「了解 (OK)」をクリックして、変更を保存し、ダイアログを終了します。

(省略可能) トラステッドルーティングの IP ラベルフィールドを指定します。

どのラベルを入力したらよいのかわらない場合は、「トラステッドルーティングの設定」を参照してください。

「了解 (OK)」をクリックして、変更を保存し、テンプレートマネージャを閉じます。

tnrhdb で単一のホストにテンプレートを割り当てるには

セキュリティ管理者役割になり ADMIN_LOW ワークスペースに移動して、データベースマネージャを起動します。

必要に応じて、「データベースマネージャからトラステッドネットワークデータベースにアクセスするには」を参照してください。フィールドの定義については、tnrhdb(4) のマニュアルページも参照してください。

「ネームサービス (Naming Service)」オプションメニューをクリックし、さらに「なし (None)」または「NIS+」を指定します。

データベースマネージャの「読み込み (Load)」リストで Tnrhdb を強調表示し、「編集 (Edit)」メニューから「追加 (Add)」を選択します。

ホストの IP アドレスを、「IP アドレス (IP Address)」フィールドに入力します。

「テンプレート名 (Template Name)」オプションメニューボタンをクリックし、次の図に示すように希望のテンプレート名を選択します。

「了解 (OK)」をクリックして、変更を保存し、「データベースマネージャ: 追加 (Database Manager: Add)」ダイアログボックスを閉じます。

次の例は、IP アドレス (192.110.120.6) で識別されるホストで、テンプレート tsol_1 が割り当てられています。

tnrhdb データベースに新たに追加されたエントリの様子を次の図に示します。

tnrhdb でホストのグループにテンプレートを割り当てるには

セキュリティ管理者役割になり ADMIN_LOW ワークスペースに移動して、データベースマネージャを起動します。

必要に応じて、「データベースマネージャからトラステッドネットワークデータベースにアクセスするには」を参照してください。

Tnrhtp データベースで割り当てるテンプレートを決定します。

データベースマネージャの「読み込み (Load)」リストで Tnrhdb を強調表示し、「編集 (Edit)」メニューから「追加 (Add)」を選択します。

ネットワークの IP アドレスを入力します。

「テンプレート名 (Template Name)」オプションメニューボタンをクリックして、次の図に示すように、希望するテンプレート名をクリックして選択します。

「了解 (OK)」をクリックして、変更を保存し、ダイアログボックスを閉じます。

次の図に、ネットワークエントリを示します。

次の例に、tnrhdb(4) ファイル内にある、デフォルトの tsol テンプレートを持つネットワーク 192.168.254.0 用の新しいエントリと、IP アドレスが 192.168.254.1 であり、tsol_1 テンプレートを持ったホスト用のエントリを示します。結果として、IP アドレスが 192.168.254.1 のホストは、tsol_1 テンプレートを使い、このネットワーク中の他のホストはすべて tsol テンプレートを使います。

注 -
ホストが接続されているネットワークのエントリを作成して、明示的または暗黙的にすべてのホストを一覧表示し、ワイルドカードを使用しなければ、そこに表示されたホストだけがシステムと通信を行えるような、制御された設定が可能になります。

変更が終わったら、「ファイル (File)」をクリックしてメニューを表示し、「終了 (Exit)」オプションをクリックしてデータベースマネージャの「Tnrhdb データベース (Tnrhdb Database)」ダイアログボックスを閉じます。

ワイルドカードを使用して、別に指定されていないすべてのホストの tnrhdb エントリを作成するには

セキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動して、データベースマネージャを起動します。

必要に応じて、「データベースマネージャからトラステッドネットワークデータベースにアクセスするには」を参照してください。

必要に応じて新しいテンプレートを作成します。

これには、「tnrhtp に新規テンプレートを作成するには」を参照してください。次の図はラベルなしホストタイプを指定するワイルドカードテンプレートを示します。

図 10-12 Tmrhtp データベースマネージャの新規ワイルドカードテンプレート

データベースマネージャの「読み込み (Load)」リストで Tnrhdb を強調表示し、「編集 (Edit)」メニューから「追加 (Add)」を選択します。

必要に応じて、「データベースマネージャからトラステッドネットワークデータベースにアクセスするには」を参照してください。

ワイルドカードの IP アドレス 0.0.0.0 とテンプレート名を、表示されたダイアログボックスに入力します。

「テンプレート名 (Template Name)」メニューをクリックして表示し、一覧からテンプレート名を選択します。

次の図では、ワイルドカードテンプレートを 0.0.0.0 のワイルドカードエントリに割り当てています。

修正が終わったら、「了解 (OK)」ボタンをクリックします。

次の図は、ワイルドカード IP アドレスの新しいエントリを示したもので、wildcard というテンプレートに対応しています。この新しいワイルドカードエントリは、未指定のホストをすべてデフォルトエントリに割り当てます。

注意 -
ワイルドカードエントリを使用すると、どのホストでもシステムとの通信が許可されます。

変更が終わったら、「ファイル (File)」をクリックして、メニューを表示し、「終了 (Exit)」を選択してデータベースマネージャの「Tnrhdb データベース (Tnrhdb Database)」ダイアログボックスを閉じます。

キャッシュされている Trusted Network データベース内のエントリを削除するには

セキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動します。

/var/tsol ディレクトリに移動します。

キャッシュファイル tnrhtp_c と tnrhdb_c を削除します。

リブートします。

ホストテンプレートまたはネットワークインタフェースエントリに認可範囲を設定するには

セキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動して、データベースマネージャを起動します。

必要に応じて、「データベースマネージャからトラステッドネットワークデータベースにアクセスするには」を参照してください。

注 -
各ホストには、そのホスト固有のネットワークインタフェースの属性を指定する個別の tnidb ファイルが存在します。データベースマネージャの tnidb 用の読み込み一覧において、「ネーミングサービス (Naming Service)」メニューにある唯一のオプションは「なし (None)」です。

1 台以上のホストに割り当てられたテンプレートのホスト認可範囲を設定するには、Tnrhtp を変更し、「最下位 SL (Minimum SL)」と「最上位 SL (Maximum SL)」を指定します。
1. データベースマネージャの「読み込み (Load)」リストの Tnrhtp を強調表示します。
2. 既存のテンプレートを変更するには、そのテンプレート名を強調表示し、「変更 (Modify)」を選択します。
3. 「最下位 SL (Minimum SL)」および「最上位 SL (Maximum SL)」フィールドに、ボタンをクリックしたときに表示されるラベルビルダーダイアログボックスを使用して、必要な機密ラベルを指定します。

現在のホスト上の複数のインタフェースのネットワーク認可範囲を設定するには、次の手順を実行します。
1. データベースマネージャの「読み込み (Load)」リストの Tnidb を強調表示します。
2. 最下位および最上位機密ラベルのフィールドに、必要な機密ラベルを入力します。
  
  注 -
  デフォルトのネットワーク認可範囲は、ADMIN_LOW から ADMIN_HIGH までです。

ネットワークインタフェースを構成するには

新しいインタフェースを追加する場合、インタフェースに付属するマニュアルのハードウェアおよびソフトウェアのインストール手順に従い、ネットワークインタフェースカードを挿入します。

インタフェースインストールプログラムは、hostname.device_abbreviation という新しいデバイスファイルを /etc にインストールします。

ホストに複数のネットワークインタフェースがある場合は、Solaris の『TCP/IP とデータ通信』の説明に従って、ルーターまたはマルチホームホストとして構成します。

新しいネットワークインタフェースの名前がまだ Tnidb データベースに設定されていない場合は、「tnidb で新規エントリを追加する、または既存エントリを変更するには」の手順説明に従って、名前を追加します。

次の図は、デフォルトのネットワークインタフェース名を示しています。

サイトのセキュリティポリシーによって、ホストのインタフェースのデフォルト設定を変更しなければならない場合は、「tnidb で新規エントリを追加する、または既存エントリを変更するには」の手順説明に従ってエントリを変更します。

各フィールドのデフォルト設定は、次の表のとおりです。デフォルトのままでよい場合は、tnidb(4) ファイルを変更する必要はありません。

表 10-4 tnidb のデフォルト設定


`最下位 SL (Minimum SL)`	`最上位 SL (Maximum SL)`	`ラベル (デフォルト) (Label)`	`認可上限 (Clearance)`	`ユーザー ID (User ID)`	`グループ ID (Group ID)`	`強制された特権 (Forced Privileges)`
`ADMIN_LOW`	`ADMIN_HIGH`	`ADMIN_LOW`	`ADMIN_HIGH`	`nobody`	`nobody`	`empty`

tnidb で新規エントリを追加する、または既存エントリを変更するには

セキュリティ管理者役割になり ADMIN_LOW ワークスペースに移動して、データベースマネージャを起動します。

必要に応じて、「データベースマネージャからトラステッドネットワークデータベースにアクセスするには」を参照してください。

必要に応じて、インタフェースを設定します。

必要に応じて、「ネットワークインタフェースを構成するには」を参照してください。

インタフェース名がデフォルトのリストになければ、それを追加し、希望する属性を指定します。
1. 「編集 (Edit)」メニューから「追加 (Add)」を選択します。
  
  次の図は、le0 インタフェースを示したもので、「編集 (Edit)」メニューの「追加 (Add)」オプションが強調表示されています。
2. 追加されたインタフェースと希望する属性を指定します。
  
  インタフェースマネージャの「追加 (Add)」ダイアログボックスを次の図に示します。

インタフェース名がデフォルトリストにあれば、そのデフォルトの設定を変更します。
1. インタフェース名を強調表示し、「編集 (Edit)」メニューから「変更 (Modify)」を選択します。
  
  次の図は、le0 インタフェース名を示したもので、「編集 (Edit)」メニューの「変更 (Modify)」オプションが強調表示されています。
2. 必要に応じて、設定に変更を加えます。
  
  次の図は、hme0 のデフォルトの設定値を示したものです。

インタフェース名のリストにデフォルトのリストがない場合は、それを追加し、希望の属性を指定します。
1. 「編集 (Edit)」メニューの「追加 (Add)」を選択します。
  
  次の図に、le0 インタフェース名と強調表示されている「編集 (Edit)」メニューの「追加 (Add)」オプションを示します。
2. 追加インタフェース名と希望する属性を指定します。
  
  次の図にインタフェースマネージャの「追加 (Add)」ダイアログボックスを示します。

機密ラベル ADMIN_HIGH を有効な CIPSO ラベルで置き換えるには

転送ホストでセキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動します。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

「管理用エディタ (Admin Editor)」アクションを実行して /etc/system ファイルを開き、編集します。

必要に応じて、「管理用エディタアクションを使用してファイルを編集するには」を参照してください。

tsol_admin_high_to_cipso= フラグを 1 に設定するコマンド行を追加します。
set tsolsys:tsol_admin_high_to_cipso=1
カーネルのデフォルト設定は、system ファイルには表示されませんが、0 に設定されています。

ファイルを上書き保存し、閉じます。
:wq

単一ゲートウェイで構成されたネットワークの簡易デフォルトルートを設定するには

システム管理者役割になり、ADMIN_LOW ワークスペースに移動します。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

「デフォルトの経路の設定 (Set Default Routes)」アクションを実行して、ルーターのホスト名が入った /etc/defaultrouter エントリを作成します。

必要に応じて、「管理アクションを起動するには」を参照してください。また、構文および /etc/defaultrouter ファイルの使用方法については、 route(1M) のマニュアルページを参照してください。次の例は、merlot というデフォルトルーターのエントリを示しています。
merlot

ローカルファイルの /etc/hosts に、このゲートウェイのエントリがあることを確認します。
129.150.113.36 merlot

ローカルファイルの /etc/security/tsol/tnrhdb に、このゲートウェイのエントリがあることを確認します。
129.150.113.36:tsol

ファイルを上書き保存し、閉じます。
:wq

tnrhdb ファイルに追加したホストがあれば、tnctl(1M) コマンドを実行し、トラステッドネットワーキングキャッシュを更新します。
$ tnctl -h merlot

任意の拡張メトリックを使用して、特定のホストまたはネットワークの静的ルートを設定するには

システム管理者役割になり、ADMIN_LOW ワークスペースに移動します。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

「Tsol ゲートウェイの設定 (Set Tsol Gateways)」アクションを実行して /etc/tsolgateways ファイルを開き、編集します。

必要に応じて、「管理アクションを起動するには」を参照してください。また、構文および /etc/tsolgateways ファイルの使用方法については、tsolgateways(4) および route(1M) のマニュアルページを参照してください。なお、tsolgateways コマンドの拡張メトリックには、route コマンドと同じ構文が使用されます。

必要に応じて、1 つまたは複数のデフォルトエントリを設定します。

ここでは、129.150.113.36 という特定のゲートウェイアドレスを使用して、最初のエントリにデフォルトルートを設定しています。このエントリは、ホストにもパケットの送信先にも特定のルートが定義されていない場合に使用されます。
default 129.150.113.36 1

必要に応じて、1 つまたは複数のネットワークエントリを設定します。

下の例の 2 行目には、標準メトリックを使用してネットワークエントリを設定しています。3 行目では、拡張メトリックを使用しており、ラベル範囲を PUBLIC から INTERNAL に指定しています。
default 129.150.113.36 1 net 129.150.102.0 gateway-101 1 net 129.150.101.0 gateway-102 -m metric=2,min_sl="PUBLIC",max_sl="INTERNAL"

必要に応じて、1 つまたは複数のホストエントリを設定します。

下の例の4 行目では、trusted というゲートウェイホスト用に拡張メトリックを使用してホストエントリを設定し、ラベル範囲を「PUBLIC」から「PUBLIC」に指定しています。

default 129.150.113.36  1
net 129.150.102.0 gateway-101 1
net 129.150.101.0 gateway-102 -m metric=2,min_sl="PUBLIC",max_sl="INTERNAL"
host 129.150.101.3 trusted -m metric=2,min_sl="PUBLIC",max_sl="PUBLIC"

ローカルファイルの /etc/hosts または NIS+ の hosts.org_dir テーブルに、宛先ホストおよびゲートウェイのエントリが設定されていることを確認します。
129.150.113.36 merlot

ローカルファイルの /etc/security/tsol/tnrhdb に、宛先ホスト、ネットワークおよびゲートウェイのエントリが設定されていることを確認します。
29.150.113.36:tsol1

ファイルを上書き保存し、閉じます。
:wq

ルーティングの IP ラベルを設定するには

注 -

Tnrhtp テンプレートを設定し、それを送信側ホスト、メッセージが経由する各トラステッドゲートウェイ、宛先ホストにそれぞれ割り当てるには、以下の手順を実行します。

セキュリティ管理者役割になり、データベースマネージャを起動します。

必要に応じて、「データベースマネージャからトラステッドネットワークデータベースにアクセスするには」を参照してください。

データベース名 Tnrhtp をダブルクリックし (次の図を参照)、その後の図に示すようなデータベースマネージャを開きます。

テンプレート名をダブルクリックし、テンプレートマネージャを開きます。

次の図では、tsol_2 テンプレートが選択されています。

任意のフィールドを変更します。

ゲートウェイのテンプレートでは、ホストタイプとして RIPSO、CIPSO、Trusted Solaris 、TSIX のいずれかを使用できます。

CIPSO ラベルを使用する場合は次の手順に、RIPSO ラベルを使用する場合は手順 6 に進みます。

データの実際の機密ラベルから取得される CIPSO ラベルを使用するには、CIPSO DOI を指定します。

現在定義されている CIPSO DOI は 1 だけです。送信側ホスト、各ゲートウェイ、宛先ホストに、みな同じ CIPSO DOI が指定されていることを確認します。

RIPSO ラベルを使用するには、「RIPSO 送信クラス (RIPSO Send Class)」メニューから格付けを 1 つ選択し、次に「RIPSO 送信 PAF (RIPSO Send PAF)」メニューからサポートされている保護許可フラグを必要なだけ (選択しなくても構いません) 選択します。最後に「RIPSO 戻り PAF (RIPSO Return PAF)」メニューからサポートされている RIPSO エラーを 1 つ選択します。

注 -
送信側ホスト、各ゲートウェイ、宛先ホストには、同じ RIPSO ラベルと RIPSO エラーが指定されていることを確認します。

「了解 (OK)」をクリックして変更内容を適用させ、テンプレートマネージャを終了します。

アプリケーションマネージャの「システム管理 (System_Admin)」フォルダから「デフォルトの経路の設定 (Set Default Routes)」アクションを実行し、/etc/defaultrouter ファイルを開きます。

/etc/defaultrouter ファイルに、1 エントリにつき 1 行ずつ、名前または IP アドレスを使用してゲートウェイを一覧入力します。これにはホストの IP アドレスまたは名前を使用します。

注 -
ホスト名を使用する場合は、ローカルファイルの /etc/inet/hosts に、そのホストを IP アドレスと共に指定したエントリもなければなりません。

次の例は、ホスト名を使用して、/etc/defaultrouter ファイルにゲートウェイを入力したものです。
routeman
次の例では、routeman という名の同じゲートウェイを、IP アドレスを使用して /etc/defaultrouter ファイルに入力しています。
127.13.104.10

ファイルを上書き保存し、閉じます。
:wq

トンネリングを設定するには

転送ホストとは、1 台以上の非 Trusted Solaris 7 または 2.5.1 ゲートウェイをトンネリングさせることにより、相手側の Trusted Solaris 7 または 2.5.1 ホストにルートの拡張メトリックを伝達できるように設定された Trusted Solaris 7 または 2.5.1 ルーターをいいます。

転送ホストでセキュリティ管理役割になり、ADMIN_LOW ワークスペースに移動します。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

「管理用エディタ (Admin Editor)」アクションを実行して /etc/security/tsol/tunnel ファイルを開き、編集します。

必要に応じて「管理用エディタアクションを使用してファイルを編集するには」を参照してください。

1 行に 1 つずつ、宛先 (サブ) ネットワークの IP アドレスを入力します。

必要に応じて次の例を参照してください。
129.299.36.0

ファイルを上書き保存し、閉じます。
:wq

拡張メトリックを使用した双方向ルーティングを設定するには、リモートゲートウェイで前の手順を繰り返し、ローカルネットワークの IP アドレスを指定します。

第 11 章ファイルおよびファイルシステムの管理

この章では、Trusted Solaris システムでファイル、ディレクトリ、ファイルシステムを管理およびマウントする方法を理解するのに必要について説明します。また、ここでは、次の項目についても説明します。

この章では、次の手続きについても説明します。

Trusted Solaris のファイル、ディレクトリ、ファイルシステムに関する概要

Trusted Solaris システムでは、標準 Solaris システムでサポートするのとまったく同じファイル、ディレクトリ、ファイルシステム管理コマンドを、また、ほぼ同じ種類のファイルシステムをサポートしています。

ファイルまたはディレクトリにアクセスするときは、常に、さまざまなソースから取得したセキュリティ属性を使用してアクセス制御に関する決定が行われます。Trusted Solaris の拡張されたセキュリティ属性を操作するために、新たなコマンドが用意され、既存のコマンドが変更されました。

この章では、セキュリティ管理者役割が知っていなければならない次の事項について説明します。

セキュリティ属性の取得方法
セキュリティ属性の設定方法と設定値の変更方法
セキュリティ属性がまだないファイルシステムのマウント時にセキュリティ属性を指定する方法

ファイル、ディレクトリ、ファイルシステムへのアクセスに関する用語の確認

この節では、ファイル、ディレクトリ、ファイルシステムの管理方法を説明するためにこの章で使用する用語を定義します。これらの用語とその概念は、『Trusted Solaris ユーザーズガイド』と『Trusted Solaris 管理の概要』で紹介していますが、便宜上ここでも取り上げます。これらの定義にざっと目を通してから、この章の残りの部分に進んでもいいですし、この節を飛ばして、「ファイルおよびファイルシステムのセキュリティ属性」に進み、用語が理解できない場合にここに戻るようにしてもかまいません。

定義では、初出の特殊用語または強調する必要のある用語は、「」内に示します。

アクセス制御リスト

アクセス制御リスト (ACL) は、ファイルまたはディレクトリの所有者が指定できるエントリの一覧に基づいて、一種の任意アクセス制御を行います。アクセス制御リストは、個人またはグループに対しアクセスを許可または制限し、UNIX 標準のアクセス権ビットよりさらにきめ細かなアクセス制御を行うことができます。

アクセス権

ファイル、ディレクトリ、ファイルシステムに関するアクセスポリシーで説明するように、必須アクセス制御の条件を満たした場合、次に示すテストのいずれかが真の場合に、ファイルまたはディレクトリの読み取り、書き込み、実行または検索のアクセス権がプロセスに対し与えられます。

ファイルまたはディレクトリに関する ACL が存在する場合は、次に示す条件が順番にテストされ、いずれかの条件が真であれば、希望するアクセスが許可される。いずれの条件も真でなければ、アクセスは拒否される
- プロセスの実効 UID が、ファイルまたはディレクトリの所有者の UID と同じで、かつ ACL が希望するアクセスタイプを所有者に認めている
- プロセスの実効 UID が ACL のユーザーリストに明示的に記載され、かつ指定のユーザーに割り当てられている ACL と ACL マスクの両方で、希望するアクセスが指定のユーザーに認められている
- プロセス所有者の実効 GID または補足 GID がファイルまたはディレクトリの GID と同じであり、かつ所有者のグループに割り当てられている ACL 上のエントリおよび ACL マスクの両方で、希望するアクセスが所有者のグループに認められている
- プロセス所有者の実効 GID または補足 GID が ACL グループリストに指定されており、かつ指定のグループに割り当てられている ACL 上のエントリおよび ACL マスクの両方で、希望するアクセスが指定のグループに認められている
- ACL 上の「他の」項目で、希望するアクセスがプロセス所有者に認められている
アクセス対象のファイルまたはディレクトリに関する ACL が存在しない場合は、次に示す条件が順番にテストされ、いずれかの条件が真であれば、希望するアクセスが許可される。いずれの条件も真でなければ、アクセスは拒否される
- プロセスの実効 UID が、ファイルまたはディレクトリの所有者の UID と同じであり、かつ所有者によるファイルへのアクセス権を示す部分 (0700) が、希望するアクセスを許可する設定になっている
- 実効 GID がファイルまたはディレクトリの GID と同じで、かつグループによるファイルへのアクセス権を示す部分 (0070) が、希望するアクセスタイプを許可する設定になっている。プロセスの補足グループリスト上に記載されているグループの 1 つがファイルまたはディレクトリの GID と同じで、かつグループによるファイルへのアクセス権を示す部分 (0070) が、希望するアクセスを許可する設定になっている
- ファイルのアクセス権ビットの他の部分 (0007) が、希望するアクセスを他のすべてのユーザーまたはグループに許可する設定になっている

上記以外の場合、アクセスは拒否されます。ただし、プロセスが適切な 1 つ以上の DAC 無効化特権を表明している場合は別です。この特権については、「ファイル、ディレクトリ、ファイルシステムへのアクセスに関するポリシー」と「実行プロファイル機構」を参照してください。

ファイル、ディレクトリ、ファイルシステムへのアクセスに関するポリシー

UNIX システムでは、スプレッドシート、プリンタ、レター、本の章、メールボックスなど、ほとんどすべてのものがディレクトリに格納されるファイルとして扱われるため、何かを実行する場合にはユーザーファイルとディレクトリにアクセスする必要があります。この節では、アクセスの条件について説明します。UNIX システムではデバイスもファイルとして扱われますが、デバイスに適用される必須アクセス制御に関する規則は、ファイルまたはディレクトリに適用される規則とは若干異なります。デバイスに適用される必須アクセス制御に関する規則については、この節で別途説明します。

ファイル、ディレクトリ、デバイスは、次の方法でアクセスする場合があります。

「名前」を「表示する」(読み取る)
「内容」を「表示する」(読み取る)
「内容」または「属性」を「修正する」(書き込む)

Trusted Solaris システムでは、次の条件に基づいてこれらのアクセスが許可または拒否されます。

UNIX の基本的な任意アクセス制御の条件を満たしたかどうか
必須アクセス制御の条件を満たしたかどうか

あらゆる種類のアクセスで、プロセスの機密ラベルがパス名に含まれるすべてのディレクトリの機密ラベルより優位であり、かつプロセス所有者 (コマンドを実行した人) がパス名に含まれる各ディレクトリに対し任意の検索アクセス権を持っていることが必要です。この条件を満たしていればファイル、ディレクトリ、デバイスの名前を表示できます。

ファイルまたはディレクトリの内容や属性を表示する (読み取りアクセスを行う) 場合は、プロセスの機密ラベルが、ファイルまたはディレクトリの機密ラベルより優位でなければなりません。また、デバイスの内容を表示する (たとえば、テープドライブに装填されたテープの情報を読み込む) 場合は、プロセスの機密ラベルが、デバイスの機密ラベルと同等である必要があります。プロセス所有者は、ファイル、ディレクトリ、デバイスに対して任意の読み取りアクセスができなければなりません。

ファイルに書き込みを行なったり、ファイルの属性を修正したりするプロセスの場合は、ファイルの機密ラベルが、プロセスの機密ラベルより優位であり、かつプロセスの認可上限の範囲に収まっていなければなりません。プロセスの認可上限には、セッションの認可上限が設定されます。ディレクトリへの書き込みを行う (ファイルを作成する) プロセスの場合は、プロセスの機密ラベルが、ディレクトリの機密ラベルと同等でなければなりません。一方、デバイスへの書き込みを行う (たとえば、テープドライブに装填されているテープに情報を格納する) 場合、プロセスの機密ラベルが、デバイスの機密ラベルと同等でなければなりません。プロセス所有者は、ファイル、ディレクトリ、デバイスに対し任意の書き込みアクセス権を持っている必要があります。

デバイスファイルに関するセキュリティポリシーは、device_policy(4) ファイルにどのように定義されているかによって、通常のファイルに適用されるポリシーとは異なる場合があります。なお、このファイルは、セキュリティ管理者役割によって変更できます。

MAC 検査または DAC 検査で不合格になった各原因について、拒否されたアクセスの種類に基づいて固有の無効化特権をコマンドに対して指定することができます。コマンドに対し無効化特権を設定できるのはセキュリティ管理者役割だけです。なぜなら、セキュリティ管理者役割は、特権が信頼のある方法で行使されるよう、コマンドを実行するユーザーが認可されていること、またはコマンドの使用が信頼できることを確認しておかなければならないからです。

次に示す条件と無効化特権は、どの種類のアクセスにも適用されます。

プロセスの機密ラベルが、パス名に含まれるすべてのディレクトリの機密ラベルより優位であるか、またはプロセスが上位検索 (プロセスの機密ラベルより優位の機密ラベルを持つディレクトリを検索すること) 特権 (file_mac_search) を持っている
コマンドを実行するユーザーが、パス名に含まれるすべてのディレクトリについて任意の検索特権を持っているか、またはプロセスがディレクトリにアクセスする際に検索制約を無効にする特権 (file_dac_search) を持っている

次に示す条件と無効化特権は、表示 (読み取り) アクセスに適用されます。

プロセスの機密ラベルがファイルの機密ラベルより優位であるか、またはディレクトリやデバイスの機密ラベルと同等であるか、またはプロセスが MAC 読み取り制約を無効にする特権 (file_mac_read) を持っている
コマンドを実行するユーザーは、ファイルまたはディレクトリに対して任意の読み取りアクセス権を持っているか、またはプロセスが DAC 読み取り制約を無効にする特権 (file_dac_read) を持っている

次に示す条件と無効化特権は、変更 (書き込み) アクセスに適用されます。

ファイルの機密ラベルがプロセスの機密ラベルより優位であるか、ディレクトリまたはデバイスの機密ラベルがプロセスの機密ラベルと同等であるか、またはプロセスが MAC 書き込み制約を無効にする特権 (file_mac_write) を持っていて、上位書き込みや、ユーザーの認可上限より上位のファイル、ディレクトリまたはデバイスに対する書き込みが行える
コマンドを実行するユーザーは、ファイルまたはディレクトリに対して任意の書き込みアクセス権を持っているか、またはプロセスが DAC 書き込み制約を無効にする特権 (file_dac_write) を持っている

認可範囲

認可範囲は、実際には範囲ではなく、管理者が定義した上限と下限の間にあるすべてのラベルのセットから構成されています。Trusted Solaris システムにおけるラベルの種類と認可範囲の詳細については、「ラベル範囲」、「ユーザー認可範囲」、および「システム認可範囲」を参照してください。

装飾名

.MLD. というテキスト文字列は、デフォルトの MLD 接頭辞です。修飾名は、MLD 接頭辞を含む MLD のパス名です。修飾名は、MLD 自身にアクセスするときに使われます。

CMW ラベル

情報ラベルと、それに続く機密ラベルを [ ] で囲ったものから構成されます。形式は、情報ラベル [機密ラベル] です。

注 -

Trusted Solaris 7 以降のリリースでは、情報ラベルは使われません。CMW ラベルの情報ラベル部分は存在しますが、ADMIN_LOW に固定されています。

格付け

格付けは、機密ラベル、認可上限の階層を表す部分です。これらのラベルは、それぞれ 1 つの格付けを持ちます。ファイルまたはディレクトリに割り当てられた機密ラベルの格付けは、ファイルまたはディレクトリに含まれる情報の機密性に基づく相対的な保護のレベルを表します。ユーザーと、ユーザーに代わってアプリケーションとコマンドを実行するプロセスに割り当てられる認可上限の格付けは、信頼性のレベルを表します。

認可上限

認可上限は、ユーザーが操作する一連のラベルの上限です。下限とは、セキュリティ管理者が初期ラベルとして割り当てた最下位のラベルです。認可上限には、ユーザー認可上限とセッションの認可上限の 2 種類があります。

コンパートメント

コンパートメントは、サイトのセキュリティ管理者役割が指定できるオプションの一連の語句で、機密ラベル、認可上限に表示されます。コンパートメントは、興味のある領域、またはそのコンパートメントを含むラベル、それらのラベルが割り当てられたファイル、それらのファイルを使用して作業する個人に関連付けられた作業グループです。

任意アクセス制御

任意アクセス制御 (DAC) は、ファイルまたはディレクトリの所有者の「判断で」許可または拒否されるアクセスです。Trusted Solaris システムには、任意アクセス制御 (DAC) として、アクセス権ビットとアクセス制御リストの 2 種類が用意されています。

優位

任意の種類のラベル (機密ラベル、認可上限) のセキュリティレベルが比較対照のラベルのセキュリティレベルと同等かそれ以上の場合、そのラベルは、比較対照のラベルより優位であるといいます。優位なラベルの格付けは、もう一方のラベルの格付けと同位かまたは上位でなければなりません。また、優位なラベルには、もう一方のラベルに含まれるすべての語句 (コンパートメント) が含まれていなければなりません。2 つの対等のラベルは互いに対して優位です。 MAC に関する判断を行うとき、機密ラベルの優位性が比較されます。「完全な優位」を参照してください。

実行プロファイル機構

実行プロファイル機構を使用すると、コマンド、CDE アクション、(これらのコマンドとアクションに関連した) セキュリティ属性、およびユーザー認可を、実行プロファイルにまとめることができます。次に、この実行プロファイルを、ユーザーが実施する必要のある作業に基づいて、複数のユーザーに割り当てることができます。実行プロファイルで指定するセキュリティ属性には、コマンドおよび操作に関する継承可能な特権が含まれます。これらの特権は、ファイル、ディレクトリ、ファイルシステムに関する任意アクセスポリシーおよび必須アクセスポリシーを無効にするために使用することもできます。「Trusted Solaris のファイル、ディレクトリ、ファイルシステムに関する概要」を参照してください。

ラベル

ラベルは、ファイルまたはディレクトリに格納される情報を保護するレベルに基づいて、ファイルまたはディレクトリに割り当てられる機密保護識別子です。

ラベル範囲

ラベル範囲は、実際、機密ラベルの「集まり」であり、最上位のラベルと最下位のラベルで指定します。実行プロファイルのコマンドまたはアクションにおけるラベル範囲とは、コマンドまたはアクションが実行される機密ラベルを制限するラベルの範囲を指します。ファイルシステムにおけるラベル範囲とは、情報がファイルシステムに格納される機密ラベルを制限するものです。トラステッドネットワークデータベースのホストやネットワークにおけるラベル範囲とは、リモートホストまたはネットワークのラベル範囲に基づいて、ローカルホストとリモートホストあるいはネットワークとの間で行われる通信を制限するものです。ラベルを認識しないリモートホストは、単一の機密ラベルに割り当てられます。なお、ホストを単一の機密ラベルに割り当てるには、ホストの最上位の機密ラベルを最下位の機密ラベルと同じに設定します。リモートホストからマウントされるファイルシステムに指定するラベル範囲は、リモートホストのラベル範囲に収まっていなければなりません。割り当て可能なデバイスにおけるラベル範囲とは、デバイスが割り当てられる機密ラベルを制限するものです。したがって、デバイスを使用して情報が格納または処理される機密ラベルも制限されます。ホストのフレームバッファまたは音声装置など、割り当て不可能なデバイスでのラベル範囲とは、アクセスアカウントの認可上限に基づくホストまたは音声装置へのアクセスを指します。ネットワーク認可範囲も参照してください。

必須アクセス制御

必須アクセス制御 (MAC) は、ファイル、ディレクトリ、デバイス、その他アクセス対象となるものの機密ラベルを、それらにアクセスしようとしているプロセスの機密ラベルと比較することに基づいて、アクセスを制御することです。プロセスの機密ラベルは、一般的に、コマンドを起動するワークスペースの機密ラベルと同じです。ディレクトリとデバイスは、UNIX システムにおいてはファイルと同様に管理されますが、ディレクトリおよびデバイスに適用される必須アクセス制御 (MAC) の規則は、ファイルに適用される MAC ルールとは異なります。書き込みのためにファイルがアクセスされる前に、ファイルの機密ラベルがプロセスの機密ラベルより優位であることが MAC により検査され、「上位書き込み」と呼ばれるポリシーが適用されます。プロセスの認可上限より上位の機密ラベルを持つファイルに対してプロセスは書き込みを行うことができません。なお、プロセスの認可上限はセッションの認可上限に設定されます。(上位書き込みポリシーでは、プロセスと書き込み対象のファイルの機密ラベルが同等であることが認められます。) 書き込みのためにディレクトリまたはデバイスがアクセスされる前にディレクトリまたはデバイスの機密ラベルがプロセスの機密ラベルと同等であることが MAC により検査され、「同位書き込み」と呼ばれるポリシーが適用されます。表示 (読み取りまたは検索) のためにファイルまたはディレクトリがアクセスされる前に、プロセスの機密ラベルがファイルまたはディレクトリの機密ラベルより優位であることが MAC により検査され「下位読み取り」と呼ばれるポリシーが適用されます。表示のためにデバイスがアクセスされる前に、プロセスの機密ラベルがデバイスの機密ラベルと同等であることが MAC により検査され、「同位読み取り」と呼ばれるポリシーが適用されます。なお、下位読み取りポリシーには同位読み取りも含まれます。

ある機密ラベルを持つプロセスが、別の機密ラベルを持つ「ファイル」に読み取りまたは書き込みを行う際には、上位書き込み、下位読み取り (WURD) という規則が適用されます。ある機密ラベルを持つプロセスが、別の機密ラベルを持つ「ディレクトリ」に書き込みを行う際には、同位書き込み、下位読み取りという規則が適用されます。ある機密ラベルを持つプロセスが、別の機密ラベルを持つ「デバイス」に書き込みを行う際には、同位読み取り、同位書き込みという規則が適用されます。

最下位のラベル

ユーザーにとっての最下位のラベルとは、特定のユーザーが作業を実行できる機密ラベルの下限であり、ユーザーアカウントを設定する際にセキュリティ管理者役割がこれを指定します。一方、システムにとっての最下位のラベルとは、セキュリティ管理者が label-encodings ファイルの最下位ラベルフィールドに指定する機密ラベルのことで、すべてのユーザーの下限を設定するものです。

マルチレベルディレクトリ

マルチレベルディレクトリ (MLD) とは、異なる機密ラベルを持つ情報が、シングルレベルディレクトリ (SLD) と呼ばれるサブディレクトリで別々に管理されるディレクトリを指します。ほとんどのインタフェースにおいて MLD は、単一の名前をもつ単一ディレクトリとして認識されます。

Trusted Solaris システムでは、/tmp、/var/mail、ユーザーのホームディレクトリといった特定のディレクトリは、MLD として作成されます。さまざまなラベルの元で実行され、このような特定の標準的ディレクトリにファイルを書き込むことが必要となる標準的アプリケーションがここに格納されます。

MLD で作業をするユーザーは、現在のプロセスの機密ラベルでのみファイルを表示したり操作したりできます。ユーザーがファイルを昇格または降格する権限を持っている場合は、MLD 内に作成したファイルまたはディレクトリの機密ラベルを昇格または降格できます。昇格したファイルまたはディレクトリの名前は表示できます。また、セキュリティ管理者が system(4) ファイルにある tsol_hide_upgraded_names をデフォルト設定値の 0 から 1 に変更して、昇格されたファイルの名前を非表示にする場合もあります。

SLD にファイルを作成したときに、機密ラベルを持つ SLD がまだ存在していない場合は、Trusted Solaris が SLD を作成し、それにプロセスの機密ラベルを割り当てます。

ユーザーが MLD にアクセスする方法は、装飾名を使用する方法と「しない」方法の 2 通りがあります。ディレクトリにアクセスするためのインタフェース (cd(1)、mkdir(1)、ls(1)) ではどちらの方法も使用できます。装飾名を使用せずに MLD を参照すると、Trusted Solaris システムは、ユーザーが作業している機密ラベル (プロセスの機密ラベル) に対応するシングルレベルのディレクトリ (SLD) を透過的に参照するようになります。たとえば、PUBLIC ラベルで cd /tmp と入力すると、ユーザーは、機密ラベルに対応する SLD (/.MLD.tmp/.SLD.1) に移動します。装飾名を使用すると、プログラムは、プロセスと同じ機密ラベルを持つ SLD ではなく、MLD を直接参照できます。したがって、cd /.MLD.tmp と入力すると、ユーザーは最上位レベルの MLD に入り、現在の作業の機密ラベルより優位でない SLD をすべて一覧にすることができます。

アクセス権ビット

アクセス権ビットは、任意アクセス制御の一種です。所有者が指定するアクセス権は、誰がファイルまたはディレクトリの読み取り、書き込み、実行が行えるかを示す一連のビットとして格納されます。各ファイルまたはディレクトリには、3 つの異なるアクセス権セットが割り当てられます。すなわち、所有者に割り当てられるアクセス権セット、ファイルまたはディレクトリが指定されたグループの全メンバに割り当てられるアクセス権セット、およびその他全員に割り当てられるアクセス権セットがあります。アクセス制御リストも参照してください。

特権

特権とは、コマンドを実行するプロセスに対し認められる権利であり、コマンドやいくつかのオプションがセキュリティポリシーの一部を無効にできるものです。特権は、コマンド自体またはコマンドを使用する人が信頼のおける方法で特権を行使できると、サイトのセキュリティ管理者役割が判断した場合にのみ認める必要があります。実行するコマンドには、実行形式ファイルに割り当てらる強制特権セットや許可特権セットあるいは特権の継承によって特権を与えることができます。特権の継承は、実行プロファイル機構によって管理されます。「実行プロファイル機構」を参照してください。

プロセス

プロセスとは、コマンドを起動するユーザーに代わってコマンドを実行するものです。各プロセスは、ユーザー ID (UID)、グループ ID (GID)、追加グループリスト、ユーザーの監査 ID (AUID) など、いくつかのセキュリティ属性をユーザーから受け継ぎます。プロセスが受け継いだセキュリティ属性には、実行対象のコマンドで行使できる特権、プロセスの認可上限 (セッションの認可上限と同じ)、現在のワークスペースの機密ラベルが含まれます。

セキュリティ管理者役割

機密情報が保護されなければならない組織では、セキュリティ管理者は、サイトのセキュリティポリシーを定義し施行する人でサイトで処理されるすべての情報にアクセスできる人に割り当てられます (複数も可)。Trusted Solaris ソフトウェア環境でのセキュリティ管理者とは、適切な認可上限を持ち、かつサイトのセキュリティポリシーをソフトウェアで実現できるように、すべてのユーザーとホストのセキュリティ属性を定義する責任者 (複数も可) に割り当てられる管理役割です。デフォルトでは、この役割の名前はセキュリティ管理者役割です。

セキュリティ属性

セキュリティ属性は、Trusted Solaris のセキュリティポリシーを実現するために使用されます。Trusted Solaris 固有のセキュリティ属性は、「拡張」属性と呼ばれることがあります。これらの属性は、標準 Solaris の動作環境で使用されるセキュリティ属性を拡張したものだからです。プロセス、ユーザー、ファイル、ディレクトリ、ファイルシステム、トラステッドネットワーク上のホスト、割り当て可能なデバイスや他のエンティティには、基本 Solaris および Trusted Solaris の両環境のさまざまなセキュリティ属性のセットが割り当てられます。ユーザーが使用するセキュリティ属性のうち、標準 Solaris 環境から存在するものには、ユーザー ID (UID)、監査 ID (AUID)、グループ ID (GID)、追加グループ ID (SGID)、アクセス制御リスト (ACL) が含まれます。ユーザーが使用するセキュリティ属性のうち、Trusted Solaris 環境で拡張されたものには、認可上限、最下位ラベル (初期ラベル)、承認が含まれます。

ファイルおよびプロセスに重要な Trusted Solaris のセキュリティ属性は、CMW ラベルです。CMW ラベルの機密ラベル部分は、アクセスの判断に使用されます。Trusted Solaris 7 では情報ラベルは使われず、CMW ラベルでは ADMIN_LOW に固定されます。

機密ラベルの範囲を表すセキュリティ属性は、ファイルシステム、割り当て可能なデバイス、プリンタに割り当てられます。セキュリティ管理者役割は、UID、GID、ラベル範囲、いくつかの特権を、実行プロファイル内のコマンドと CDE アクションとに関連付けることができます。

機密ラベル範囲とともに、ネットワーク認可範囲と呼ばれるその他のセキュリティ属性が、トラステッドネットワークデータベース内のホストに割り当てられます。このデータベースを使用して、ホストとネットワーク間の通信に MAC を適用します。

NFS マウントが実行される機密ラベルは、トラステッドネットワークデータベースで NFS サーバーに割り当てられている機密ラベルによって制限されます。「ファイルシステムの属性」を参照してください。

セキュリティポリシー

Trusted Solaris 環境におけるセキュリティポリシーとは、DAC、MAC、情報へのアクセス方法を定義した情報ラベルのルールを指します。ユーザーにとってのセキュリティポリシーとは、サイトで処理される情報の機密性を定義した一連のルールであり、かつ無認可のアクセスから情報を保護するための手段でもあります。

機密ラベル

機密ラベルは、ファイル、ディレクトリ、プロセスに割り当てられる機密保護のためのラベルであり、それらに含まれている情報のセキュリティレベルに基づいてアクセスを制御するのに使用されます。

セッションの認可上限

セッションの認可上限は、特定のログインセッションでだけ有効な認可上限であり、セッションを開始したユーザーによって設定されます。セッション中に開始した各プロセスには、セッションの認可上限と同等のプロセスの認可上限が与えられます。セッションの認可上限には、ユーザーの認可上限と同等か、またはそれより低いものを設定できます。

シングルレベルディレクトリ

シングルレベルディレクトリ (SLD) とは、単一の機密ラベルを持つファイルが格納される MLD 内のディレクトリを指します。特定の機密ラベルで作業をしているユーザーが /tmp などの MLD があるディレクトリに入ると、このユーザーの作業ディレクトリは、MLD 内の単一ラベルディレクトリ (/.MLD.tmp/.SLD.1) に変更されます。この機密ラベルは、ユーザーが作業している機密ラベルと同じです。SLD 名は、.SLD. 接頭辞の後に SLD 名の作成順序を表す番号を付けたものです。

完全な優位

任意のラベル (機密ラベル、認可上限のいずれか) のセキュリティレベルが、比較対象となる別のラベルのセキュリティレベルより高い場合、そのラベルは、比較対象のラベルより完全に優位であると言います。完全な優位とは、同等でない優位を意味します。このような状態が発生するのは、一方のラベルの格付けが他方のラベルの格付けより上位にあり、かつ一方のラベルに他方のラベルのコンパートメントがすべて含まれている場合、または両方のラベルの格付けが同じで、かつ一方のラベルに、他方のラベルに含まれている全コンパートメントに加え、別のいくつかのコンパートメントが含まれている場合です。

システム認可範囲

システム認可範囲には、各サイトのセキュリティ管理者役割が label_encodings(4) ファイルに定義した規則に従って作成した有効な (正しい形式の) あらゆるラベルの集合と、あらゆる Trusted Solaris システムで使用される 2 つの管理ラベル、すなわち、ADMIN_LOW と ADMIN_HIGH が含まれます。

ユーザー認可範囲

ユーザー認可範囲は、一般ユーザーがシステム上で作業できるあらゆるラベルの集合であり、各サイトのセキュリティ管理者が定義します。システム認可範囲を定義する正しい形式のラベルに関する規則では、サイトの label_encodings(4) ファイルの ACCREDITATION RANGE セクションに指定された各種の値 (上限、下限、組み合わせ制約、その他の制約) によってさらに制約が課されます。

ユーザー認可上限

ユーザー認可上限とは、セキュリティ管理者によって割り当てられ、特定のユーザーが随時作業を行うラベルの集合の上限に相当します。セッションの認可上限を設定する特定のログインセッション中に、その認可上限を受け入れるか、それともさらに制約を課すかを決定できます。

ファイルおよびファイルシステムのセキュリティ属性

属性は、次のように指定できます。

ファイルシステム内にある個々のファイルまたはディレクトリのレベル (「ファイルおよびディレクトリのセキュリティ属性」を参照してください。)
ファイルシステムのレベル (「ファイルシステムの属性」を参照してください。)
マウント時 (「マウント時にセキュリティ属性を指定する」を参照してください。)

すべての ufs タイプのファイルシステムは可変属性ファイルシステムです。可変属性システムでは、各ファイルシステムオブジェクトの機密ラベルは作成時に設定され、変更できます。固定属性ファイルシステムでは、機密ラベルは、ファイルシステムがマウントされているリモートホストの tnrhdb(4) または tnrhtp(4) ファイルの def_SL 設定により、あるいはマウント時に決定されます。

必要な属性をどこからも取得できない場合は、一連のデフォルト値が使用されます。属性の取得方法に関するルールについては、「Trusted Solaris 属性の取得手順に関するルール」を参照してください。

ファイルおよびディレクトリのセキュリティ属性

次の表に示したセキュリティ属性は、標準 Solaris のオペレーティングシステムのものです。

表 11-1 標準 Solaris のセキュリティ属性


標準 Solaris のセキュリティ属性
ユーザー ID
グループ ID
アクセス権モード
アクセス ACL (オプション)
デフォルト ACL (オプション)

Trusted Solaris のファイルとディレクトリには、標準 Solaris ファイルシステムの属性に加えて、拡張セキュリティ属性が用意されています。Trusted Solaris セキュリティポリシーに必要な拡張セキュリティ属性を次の表に示します。

表 11-2 Trusted Solaris オペレーティングシステムにおけるファイルとディレクトリの属性


拡張セキュリティ属性	Trusted Solaris の拡張セキュリティ属性の説明
機密ラベル	ファイルまたはディレクトリの機密ラベル
強制された特権	オプション。実行可能ファイルが実行時にその使用を保証されている特権セット。許容された特権のサブセットでなければならない。
許容された特権	オプション。この実行可能ファイルが実行時に許容されている特権の最大セット。(実行可能ファイルを編集すると、それらの特権がすべて失われてしまうため、実行可能ファイルが使用することのできる特権を許容されたセットに制限することによってトロイの木馬の侵入を防ぐ。プログラムが編集されてしまうと、プログラムは継承可能な特権を使用することができないためである)。強制された特権のスーパーセットでなければならない。
ファイル属性フラグ	オプション。公開ファイル属性フラグのみをサポート。このフラグが設定されているファイルシステム内の任意のオブジェクトに対して、ある読み取り操作を行うと、その操作があらかじめ選択された監査クラスのものであっても、監査記録が生成されない。ただし、次のような例外がある。特権の使用のための監査疑似イベントの特権 (AUE_UPRIV) をあらかじめ選択した監査クラスに入れておき、特権の使用が必要になる操作を行うと、監査記録が常に生成される。このような例外はあるが、公開フラグが設定されていると監査記録が生成されない読み取り操作には次のようなものがある。`access(2)`、`fgetcmwlabel(2)`、`fgetsldname(2)`、`fstatvfs(2)`、 `getcmwfsrange(2)`、`getcmwlabel(2)`、`getfpriv(2)`、 `getmldadorn(2)`、 `getsldname(2)`、`lgetcmwlabel(2)`、 `lstat(2)`、`mldlstat(2)`、 `mldstat(2)`、`open(2)`、読み取りのみ、`patchconf(2)`、 `preadl(2)`、`readl(2)`、`readlink(2)`、 `stat(2)`、`statvfs(2)`
ディレクトリ属性フラグ	オプション。ディレクトリが MLD であることを示すフラグ。

Trusted Solaris オペレーティング環境では、パス名に含まれるディレクトリの機密ラベルに順序を付けません。

ファイルとディレクトリは、それらを含むディレクトリと同じ機密ラベルでだけ作成できます。ただし、特権を持つサブジェクトは、ファイルとディレクトリを作成し、有効な任意の機密ラベルで既存のファイルとディレクトリに再度ラベル付けを行なって、昇格したオブジェクトを作成することができます。「ファイルおよびディレクトリのラベルと特権を変更するには」を参照してください。

昇格されたファイルとディレクトリの名前が表示されないようにシステムを構成することができます。デフォルトでは、これらの名前を表示します。セキュリティ管理者役割は、system ファイルの tsol_hide_upgraded_names というスイッチの設定を変更します。詳細は、第 13 章「Trusted Solaris カーネルスイッチ設定の変更」を参照してください。設定の変更後、リブートしてください。

ディレクトリ名は、ディレクトリが削除されるときにクリアされます。これは、削除されたディレクトリの名前にアクセスできてはならないというオブジェクトの再利用条件に準拠したものです。

Trusted Solaris のシンボリックリンクは、ラベルを持ちます。

MLD は、ファイルシステム内で通常のディレクトリとして表示されますが、MLD であることを示すフラグを持っています。MLD は、それを作成、削除、使用するための特権を必要としません。MLD 内の SLD に下位読み取りアクセスを行うとき、非特権プロセスが読み取れるのはプロセス自身と同等の機密ラベルをもつ SLD とプロセス自身より下位の機密ラベルをもつ SLD に含まれる情報を合わせたものです。mldpwd(1) と mldrealpath(1) の各コマンドを使用して、現在の作業ディレクトリ名または他の MLD の装飾名を取得します。MLD のマウントは装飾名を必要としません。

vi(1) などのコマンドでディレクトリ内に新規のファイルを作成しよう (書き込もう) とすると、コマンドを実行しているプロセスのセキュリティ属性が、ファイルの作成先ディレクトリの対応するセキュリティ属性と比較されます。この例では、UID と機密ラベルが比較されます。ファイルの作成が成功するかどうかは、必要な MAC 検査と DAC 検査に合格するかどうかで決まります。ユーザー ID は、ディレクトリのアクセス権ビットと、ACL (存在する場合) とに指定された DAC 条件を満たしていなければなりません。また、MAC 条件を満たすには、ディレクトリの機密ラベルは、プロセスの機密ラベルより優位でなければなりません。

MLD であるディレクトリが単一ラベルを持つホストによってマウントされる場合は、そのホストの機密ラベルに対応する SLD がマウントされ、MLD はマウントされません。なお、この機密ラベルは、管理者の権限によりトラステッドネットワークデータベース内でそのホストに割り当てられたものです。たとえば、ユーザーのホームディレクトリが、ラベルなしのホスト上に自動的にマウントされる場合は、tnrhdb(4)/tnrhtp(4) 内でホストに割り当てられている、機密ラベルを持つ SLD だけがマウントされます。

ファイルとディレクトリのセキュリティ属性を変更する

ユーザーと管理者は、Trusted Solaris のファイルマネージャの使用により、ファイルとディレクトリのアクセス権の変更ができます。また承認されたユーザーと管理者は、ファイルとディレクトリの特権やラベルの設定ができます。行おうとしているアクセスが MAC ポリシーまたは DAC ポリシーに違反する場合は、承認が必要です。

ラベルと特権の変更

ファイルマネージャの「選択 (Selected)」メニューの「ラベル (Label)」オプションを使用すると、機密ラベルおよび情報ラベルを設定することができます。また、機密ラベルおよび情報ラベルの設定は、プロファイルに setlabel(1) コマンドが設定されている任意のアカウントによってコマンド行から実行することもできます。また、ファイルマネージャの「選択 (Selected)」メニューの「特権 (Privileges)」オプションを使用すると、実行可能ファイルに強制された特権と許容された特権を設定することができます。強制された特権と許容された特権の変更は、プロファイルの 1 つに setfpriv(1) コマンドが設定されている任意のアカウントによってコマンド行から実行することもできます。

「選択 (Selected)」メニューのオプションのどちらかで特権およびラベルを設定するためには、次の承認が必要です。

特権の設定には「ファイルの特権を設定」承認が必要である
ファイルおよびディレクトリの各ラベルの昇格には、「ファイルの機密ラベルを昇格」承認が必要である
ファイルおよびディレクトリの各ラベルの降格には、「ファイルの機密ラベルを降格」承認が必要である

次に、ファイルマネージャの「選択 (Selected)」メニューを示します。アクセス権の変更方法については、「ファイルおよびディレクトリのラベルと特権を変更するには」を参照してください。

図 11-1 ファイルマネージャの「選択 (Selected)」メニュー

ファイルとディレクトリの属性フラグの変更

getfattrflag(1) コマンドを使用して、ファイルまたはディレクトリの属性フラグを取得し、setfattrflag(1) コマンドを使用して、ファイルに公開オブジェクトフラグを、ディレクトリに MLD フラグをそれぞれ設定します。

ファイルシステムの属性

Trusted Solaris システムでサポートされるファイルシステムの特徴は、属性を変更できるファイルシステムと変更できないファイルシステムがあることです。属性が変更可能な場合、それらのファイルシステムは、可変属性ファイルシステム、または可変ファイルシステムと呼ばれます。たとえば、マウントされた可変ファイルシステムにおける機密ラベルは、承認されたユーザーによって変更することができます。

Trusted Solaris 拡張セキュリティ属性をサポートしていないファイルシステムは、(マウント時、あるいはデフォルトで) 割り当てられた属性の変更ができないため、固定ファイルシステムと呼ばれます。たとえば、マウントされている固定属性のファイルシステムに指定された機密ラベルは、オブジェクトが固定ファイルシステムから移動される場合にのみ変更が可能です。

すべての ufs タイプのファイルシステムは可変です。したがって、Trusted Solaris システムでインストールされるすべてのファイルシステムは可変です。Trusted Solaris または TSIX NFS サーバーからマウントされる nfs タイプのファイルシステムは可変です。他のオペレーティング環境が動作している NFS サーバーからマウントされる nfs タイプのファイルシステムは固定です。tmpfs ファイルシステムは可変です。fdfs、hsfs、および pcfs タイプのファイルシステムは常に固定です。lofs タイプのファイルシステムの属性は実際のファイルシステムの属性と同じです。詳細は、「Trusted Solaris システムにマウントできるファイルシステムの種類」を参照してください。

次の表には、可変属性ファイルシステムのセキュリティ属性を示します。また、可変属性を指定しない場合に使用されるデフォルト値も示します。

表 11-3 Trusted Solaris ファイルシステムのセキュリティ属性と定義済みの設定値


属性	説明	デフォルト値
ファイルシステムの MLD 接頭辞	ファイルシステムの MLD を示す MLD 接頭辞に使用される文字	.MLD
ファイルシステムの機密ラベル範囲	このファイルシステム上に作成されたファイルとディレクトリの最下位の機密ラベルと最上位の機密ラベル	ADMIN_LOW 〜 ADMIN_HIGH
ファイルシステムの機密ラベル	このファイルシステム上にあるすべてのファイルとディレクトリのうち、明示的な機密ラベルを持たないものについて仮定される機密ラベル	なし
ファイルシステムのアクセス ACL	このファイルシステム上にあるすべてのファイルとディレクトリのうち、明示的なアクセス ACL を持たないものについて仮定されるアクセス ACL (形式については `setfacl(1)` を参照のこと)	なし
ファイルシステムの強制された特権のセット	このファイルシステム上にあるすべての実行可能ファイルのうち、明示的な強制された特権を持たないものについて仮定される強制された特権のセット	なし
ファイルシステムの許容された特権のセット	このファイルシステム上にあるすべての実行可能ファイルのうち、明示的な許容された特権を持たないものについて仮定される許容された特権のセット	なし

ファイルシステムに可変属性を設定する

サイトのセキュリティポリシーに基づいて新たなセキュリティ属性が必要になった場合には、セキュリティ管理者役割を行うことができます。

getfsattr(1M) コマンドを使用してファイルシステムのセキュリティ属性を取得する
setfsattr(1M) を使用して、既存のファイルシステム上の属性セットを調整する (「ファイルシステム上でセキュリティ属性を設定するには」を参照してください。)

注意 -
Trusted Solaris ホスト上の /、/usr 、/var というファイルシステムのセキュリティ属性は、変更したり明示的に設定したりしないでください。予想外の結果になることがあります。

固定属性ファイルシステム

固定属性ファイルシステムをマウントするとき、セキュリティ管理者役割は mount -S コマンドをコマンド行から入力するか、 vfstab(4) ファイルを使用して、セキュリティ属性を指定できます。マウント時に指定された属性は、ファイルまたはディレクトリが属性を持っていなければ、マウントされたファイルシステム内のすべてのファイルおよびディレクトリに適用されます。ファイルまたはディレクトリ上のすべての属性が使用されます。たとえば、UNIX ファイルシステム内のファイルおよびディレクトリはユーザー ID (UID) とグループ ID (GID) を持っているため、ファイルシステムオブジェクトがすでに持っている UID と GID が使われます。ファイルまたはディレクトリが属性を持っておらず、マウント時に何も指定されない場合、デフォルト (表 11-4 を参照) が適用されます。

固定属性ファイルシステムでは、オブジェクトがファイルシステム上に存在するかぎり、セキュリティ属性はオブジェクト上で変更できません。

固定属性ファイルシステムは、Trusted Solaris ホストにマウントされるとき、単一の機密ラベルを持つよう構成されるので、「単一ラベルファイルシステム」と呼ばれます。

次の例は、Solaris 動作環境で動作する NFS サーバーから /spare と呼ばれる固定属性ファイルシステムを NFS マウントするコマンド行を示したものです。このサービスは、outside サービスと呼ばれます。/spare には、[INTERNAL_USE_ONLY] という機密ラベルが付けられており、次のコマンド行に示すように、-S オプション付きの mount が使われています。

$ mount -F nfs -S "slabel=INTERNAL_USE_ONLY; outside:/spare /spare

例えば、マウントされたファイルシステム /spare に、test と呼ばれるファイルがある場合、 /spare/test の機密ラベルは誰も変更できません。また、その情報ラベルを浮上させることもできません。ただし、/spare/test を /tmp または /export/home/secadmin などの別のディレクトリにコピーすると、そのラベルを変更することができます。

固定属性ファイルシステム (Solaris システムのファイルシステムなど) がマウントされていると、マウント時に指定されていないセキュリティ属性には、デフォルト値が割り当てられます。マウント時の属性値が mount コマンド行にもファイルシステムの vfstab_adjunct エントリにも指定されていないとき、属性をサポートしていない固定属性ファイルシステムに使用される値を表 11-4 に示します。

表 11-4 固定ファイルシステムに割り当て可能な属性


属性	デフォルト値
UID	UID がファイルシステムのオブジェクトとして定義されていないときは、割り当てが必要。フロッピーから DOS ファイルシステムをマウントするときなど。
GID	GID がファイルシステムのオブジェクトとして定義されていないときは、割り当てが必要。フロッピーから DOS ファイルシステムをマウントするときなど。
モード	UID がファイルシステムのオブジェクトとして定義されていないときは、割り当てが必要。フロッピーから DOS ファイルシステムをマウントするときなど。
属性フラグ	なし
MLD 接頭辞	空の文字列
機密ラベル範囲	ADMIN_LOW から ADMIN_HIGH
機密ラベル	固定ファイルシステムが CD-ROM またはフロッピーディスクからマウントされている場合: マウントポイントの機密ラベル (マウント処理を実行しているプロセスの機密ラベルに変更される) 固定ファイルシステムが NFS サーバーからマウントされている場合: デフォルトの機密ラベル (管理者役割がトラステッドネットワークエントリ内でサーバーに割り当てる)
アクセス ACL	なし
強制された特権セット	なし
許容された特権セット	なし

Trusted Solaris システムにマウントできるファイルシステムの種類

Trusted Solaris の mount(1M) を使用すると、次の種類のファイルシステムをマウントすることができます。

FDFS
HSFS
LOFS
NFS
PCFS
PROCFS
TMPFS
UFS

CACHEFS という種類のファイルシステムは、サポートされていません。自動マウント (automount(1M) のマニュアルページを参照) はファイルシステムを AUTOFS タイプでマウントします。

mount_nfs(1M)、mount_ufs(1M) など、mount_* と表現されるマニュアルページが複数用意されていますが、mount(1M) というコマンドは 1 つしかありません。mount というマニュアルページには、マウント時に設定できるセキュリティ属性と、マウントが正常終了するのに必要な特権、UID および GID について説明しています。セキュリティ属性の詳細については、「ファイルシステムの属性」とそれに続く説明を参照してください。

各種のファイルシステムをマウントするためのオプションについては、該当する mount_* マニュアルぺージを参照してください。vfstab_adjunct(4) というマニュアルページでは、/etc/security/tsol/vfstab_adjunct ファイルについて説明しています。このファイルには、vfstab(4) ファイル、 /etc/auto_direct ファイル、または autofs マップで指定されたファイルシステムをマウントする際に使用されるマウント時セキュリティオプションを入力することができます。

表 11-5 では、各種のマウントについて説明し、例も示します。

表 11-5 マウントの種類、例および説明


マウントの種類	使用する目的	説明
FDFS	仮想タイプのファイルシステムであり、ファイル名スペースを通して、プログラムが独自のファイル記述子にアクセスできるようにする	各プロセスはそれ自身のファイル記述子にしか、アクセスすることができないため、MAC および DAC による分離を確実に行うことができる。モード (0666)、グループ (スーパーユーザー) および所有者 (スーパーユーザー) はカーネルによって作成されるが、DAC の判断には使用されない。機密ラベルおよび情報ラベルは、そのファイル記述子に関連付けられているファイルまたはディレクトリの機密ラベルである。これは固定属性ファイルシステムである。
HSFS	ファイルシステムを CD デバイスからマウントする	`mount_hsfs(1M)` を参照のこと。Trusted Solaris 環境では、マウント時にファイルシステムの固定属性を指定できる。
LOFS	仮想ファイルシステムの作成を可能にする、仮想タイプのファイルシステムであり、代替パス名を使用して既存のファイルにアクセスできる	lofs(7FS) を参照のこと。Trusted Solaris システムのセキュリティ属性は、基本ファイルシステムのセキュリティ属性と同じである。
NFS	リモート NFS サーバーからファイルシステムをマウントする	`mount_nfs(1M)` を参照のこと。また、「Trusted Solarisの NFS マウント」も参照のこと。NFS マウントは、固定属性および可変属性の各ファイルシステム上で使用できる。
PCFS	ディスケットから DOS ファイルシステムをマウントする	`pcfs(7FS)` を参照のこと。このファイルシステムには、拡張属性は設定できない。
PROCFS	仮想タイプのファイルシステムであり、システム上の各プロセスのイメージにアクセスできる。/proc ディレクトリの各エントリの名前は、プロセス ID に対応する 10 進数の数字である。各ファイルの所有者は、プロセスの実ユーザー ID によって決まる。	Trusted Solaris システムの PROCFS は、全 Trusted Solaris 属性がサポートされる可変属性ファイルシステムである。プロセスからのアクセスは、`/proc` ファイルに設定された DAC 属性と MAC 属性に基づいて判断される。これらの属性は、プロセスの DAC 属性と MAC 属性から取り込まれる。proc_owner 特権を持っている呼び出し元プロセスは、呼び出し元が所有していないプロセスに関する情報を同じ機密ラベルで取得することができる。proc_mac_read 特権を持っている呼び出し元プロセスは、プロセスの機密ラベルが呼び出し元の機密ラベルより優位であるか、または無関係の場合に、呼び出し元が所有するプロセスに関する情報を取得できる。変更に関する制約は、読み取りに関する制約よりきめ細かく設定されている。`proc(4)` マニュアルページを参照のこと
TMPFS	スワップページを使用する一時的なファイルシステムをメモリ (一次メモリまたはスワップ記憶領域) にマウントする。マウントされた内容はリブート時に消滅する	`/tmp` はしばしば tmpfs としてマウントされる。この利点は、一時的なファイルシステムの内容に関係なく、アクセス速度が格段速くなるということである。これは、情報がディスクからでなく、メモリから取り込まれるからである。 `mount_tmpfs(1M)` を参照のこと
UFS	ファイルシステムをローカルディスクからマウントする	`mount_ufs(1M)` を参照のこと。UFS ファイルシステムには、マウント時に固定属性を割り当てたり、作成時または後に可変属性を割り当てたりすることができる。「ファイルシステムに可変属性を設定する」を参照のこと。注: ラベルなしの (固定属性) ファイルシステムでは、通常、MLD 接頭辞は有効ではない。ただし、例外として、別の可変ファイルシステムがラベルなしのファイルシステムにマウントされる場合に、そのファイルシステムのルートが MLD である場合は、MLD 接頭辞を指定する必要がある。接頭辞を指定しないと、デフォルトとして空の文字列が使用される

UFS マウントと NFS マウントは、もっとも一般的に使用されるマウントの種類です。

MLD は、次のファイルシステムのみで使用できます。

ufs (always variable)
nfs-variable

(Trusted Solaris サーバーからマウントされる NFS ファイルシステム)
lofs
tmpfs

保護用のマウントオプション

mount コマンドを使用するには、コマンド行または vfstab(4) ファイルに -o オプションを指定し、それに続けて 4 つの保護オプションのいずれかを指定します。これらの保護オプションには、マウントされるファイルシステム上にあるデータを保護するために使用するものもあれば、マウントされたファイルシステムからトロイの木馬のような侵入を防ぐものもあります。次の表に示す mount 制約はすべてのファイルシステムに適用されます。デフォルト値の欄には、admin がオプションを指定しない場合に使用される値を示します。

表 11-6 マウント時の制約とデフォルト値


説明	デフォルト値	代替値
書き込み操作を禁止する	`rw`	`ro`
実行可能ファイル上のユーザー ID 設定ビットを無視する	`suid`	`nosuid`
実行可能ファイル上の強制された特権セットを無視する	`priv`	`nopriv`
デバイス特殊ファイルのオープンを禁止し、標準以外のディレクトリからデバイスが使用されるのを防ぐ	`devices`	`nodevices`

注 -

書き込みを禁止する ro オプションと、ユーザー ID 設定ビットを無視する suid オプションは、標準 Solaris バージョンのマウントのものです。

各種ファイルシステムにおける属性のまとめ

ファイルシステムによっては、属性が個々のオブジェクト (ファイルやディレクトリ) に結びつくこともあれば、ファイルシステムのレベルだけにしか存在しないこともあります。ファイルシステムレベルの属性は、ファイルシステムそのものによって提供されるか、マウント時に指定されます。マウント時に指定した属性は、ファイルシステム上の同じ属性を無効にします。

ファイルシステムのセキュリティ属性のマウント時の指定は、コマンド行で -S オプション付きの mount を使って行われるか、vfstab_adjunct ファイルまたは、auto_master および autofs マップのエントリで -S オプションを付けて指定します。セキュリティ属性が auto_master でも autofs マップのエントリでも指定されておらず、マウントポイントのエントリが vfstab_adjunct ファイル内にあれば、vfstab_adjunct のセキュリティ属性が使われます。詳細は、mount(1M)、vfstab_adjunct(4)、および automounat(1M) のマニュアルページを参照してください。

次の表に、各種ファイルシステムがどのようなファイルシステム属性をサポートしているかを示します。表 11-8 の追加情報も参照してください。

表 11-7 各種ファイルシステムでサポートされている属性


属性	UFS/TNFS	TMPFS/SLNFS	PCFS/HSFS
許容された特権	FS	MT	MT
強制された特権	FS	MT	MT
CMW ラベル	FS	MT	MT
MLD 接頭辞	FS	MT	MT
ラベル範囲	FS	MT	MT
監査事前選択マスク	FS	MT	MT
ファイルシステム属性フラグ	FS	none	none
オブジェクト属性フラグ	FS	MT	MT
マウントフラグ	MT	MT	MT
アクセス ACL	OBJ	OBJ	MT
ファイルモード	OBJ	OBJ	MT*
ファイル所有者	OBJ	OBJ	MT*
ファイルグループ	OBJ	OBJ	MT*

次の表に、表 11-7 で説明したファイルシステムの属性がどこから取得されるのかを理解するための追加情報を示します。

表 11-8 各ファイルシステムの属性がどこから取得されるのか


ファイルシステムの種類	属性の入手先	種類	属性の入手先
UFS	Trusted Solaris ホストの ufs ファイルシステム	FS	ファイルシステムで指定された属性
TNFS	Trusted Solaris または TSIX サーバーの tnfs ファイルシステム	MT	マウント時指定の属性
TMPFS	tmpfs ファイルシステム	OBJ	ファイルシステムの全オブジェクトに付けられた属性
SLNFS	単一ラベル/ラベルなしサーバーの NFSv2 ファイルシステムまたはNFSv3 ファイルシステム	MT	Rock Ridge 拡張機能付き hsfs 用。 OBJ と同じ
PCFS	pcfs ファイルシステム
HSFS	hsfs ファイルシステム

マウント時にセキュリティ属性を指定する

固定ファイルシステムと可変ファイルシステムの両方において、セキュリティ属性はマウント時に指定できます。

次に、マウント時にセキュリティ属性を指定できるファイルシステムのタイプを示します。

属性がサポートされていないファイルシステム (DOS ファイルシステムなど)
UID、GID、モードをサポートしているが、Trusted Solaris 拡張セキュリティ属性をサポートしていないファイルシステム (ファイルシステムオブジェクトにおける機密ラベルなど)

属性が指定されていない場合は、デフォルト値が使用されます。

mount コマンドは、固定属性ファイルシステムをマウントするときに、特権セット、ACL、機密ラベルにデフォルト値を設定するように拡張されています。UFS およびトラステッド NFS (可変) ファイルシステムでは、マウントプロトコルは、ローカルマシン上またはリモートマシン上にあるファイルシステムから拡張属性を取り込むよう、機能拡張されています。

セキュリティ管理者は、マウント時にセキュリティ属性を指定するために、mount -S オプション、または vfstab_adjunct(4) ファイル内のファイルシステムのエントリを使用します。詳細は、mount(1M) のマニュアルページを参照してください。

マウント時にセキュリティ管理者役割が一連の属性を指定できるようにすることで、ファイルシステム、またはファイルとディレクトリのいずれかのレベルで、埋め込みセキュリティ属性をサポートしていない固定属性ファイルシステムをマウントできるようになります。また、セキュリティ管理者は属性を指定することによって、それらのファイルシステム上の定義済み属性を無効にできます。

ファイルシステムがマウントされる場合、ファイルシステムの種類でサポートされている属性のリストに照合して、指定のマウント属性が検査されます。マウント属性が、ファイルシステムでサポートされていない場合、マウントは失敗し、マウントコマンドの呼び出し元にエラーが返されます。たとえば、ufs というファイルシステムでは、ユーザー ID がサポートされ、マウントユーザー ID はサポートされていません。ファイルのマウント時に行われる 2 番目の検査は、属性値の妥当性に関するものです。属性値が有効でない場合、ファイルシステムはマウントされず、エラーが呼び出し元に返されます。たとえば、強制された特権セットは、許容される特権セットに含まれていなければなりません。

単一ラベルの固定属性ファイルシステムでは、ファイルシステムのマウント時に指定した単一機密ラベルでのみ、ファイルとディレクトリにアクセスすることができます。単一ラベルのファイルシステムでは、個々のファイルとディレクトリの機密ラベルと情報ラベルを変更できません。指定したラベル範囲と機密ラベルが全データのラベルを正確に表現するよう保証するのは、管理者の責任です。

ラベルなしのホストとして構成されたホストからマウントされたファイルシステムは、ホスト内にあるファイルとディレクトリの UID、GID、オプションの ACL とデフォルトの ACL をサポートしますが、セキュリティ属性は持ちません。セキュリティ管理者役割は、機密ラベル範囲 (事実上、ファイルシステムの単一ラベルになる) と、他のデフォルトのセキュリティ属性を指定します。

Trusted Solaris 属性の取得手順に関するルール

ファイルまたはディレクトリの属性は、ファイルシステムの属性より優先します。マウント時に指定された属性は、ファイルシステム内ですでに有効になっているファイルシステム属性より優先します。マウント時またはファイルシステムから取得できない属性には、デフォルト値が与えられます。

次の図に、属性の取得ルールを示します。

図 11-2 Trusted Solaris 属性の取得手順に関するルール

ラベルなしホストからマウントされた固定ファイルシステムについて、セキュリティ属性を指定する例

この例では、Solaris ホストからマウントされる /public というファイルシステムについて、セキュリティ管理者がファイルシステムの vfstab_adjunct のエントリに、次のセキュリティ属性を指定しています。

最下位の機密ラベルと最上位の機密ラベル (PUBLIC)
デフォルトの機密ラベル (PUBLIC)
許容された特権セット (なし)
強制された特権セット (なし)

このファイルシステム内のファイルとディレクトリにアクセスしようとする際には、通常の DAC ルールが適用されます。上記の一連のデフォルト値をこのファイルシステムに使用すると、次のようになります。

機密ラベルが PUBLIC のウィンドウからは、このファイルシステム内にあるファイル (/public/stock.quotes など) にアクセスできる
ファイルがファイルシステム /public に存在する限り、ファイルの機密ラベルをユーザーが変更することはできない
ファイルシステム /public 内のファイルを可変ファイルシステムにコピーまたは移動させるとき、ファイルの機密ラベルは、コピーを実施したプロセスの機密ラベルに変更され、ファイルの残りのセキュリティ属性も変更できるようになる

Trusted Solarisの NFS マウント

Trusted Solaris NFS クライアント上で mount(1M) を呼び出し、NFS タイプのマウントを実行するときに、NFS サーバーが必ずしも Trusted Solaris オペレーティング環境を実行しているとは限りません。NFS サーバーはそのファイルシステムをローカルに保有し、ローカルなファイルシステムの種類として、hsfs、pcfs、tmpfs、ufsなどを使用します。NFS サーバーは、ファイルシステムを share(1M) を使用してエクスポートします。share コマンドとそのオプションは、コマンド行または dfstab(4) ファイルに指定することができます。

Trusted Solaris と NFS

Trusted Solaris では、標準 Solaris オペレーティング環境とTrusted Solaris 1.x リリースでサポートされているネットワークファイルシステム (NFS) プロトコルを両方ともサポートしています。

NFS バージョン 2 (V2) (Solaris 1.x 環境)
NFS バージョン 3 (V3) (Solaris 2.5 およびそれ以降の互換環境)

Solaris ホストが上記 NFS プロトコルの 1 つを使ってファイルシステムをエクスポートするとき、Trusted Solaris 7、2.5.1 または 2.5 が動作しているホストの管理者は、対応する NFS プロトコルバージョンを指定することによって、単一ラベルでファイルシステムにアクセスできます。

Trusted Solaris ホストは、適切なNFS プロトコルを指定して、独自のファイルシステムをラベルなしのクライアントホストにエクスポートすることができます。ラベルなしのクライアントは、Trusted Solaris セキュリティ属性を無視します。ラベルなしのクライアントにエクスポートされたファイルまたはディレクトリの機密ラベルが、トラステッドネットワーキングデータベース内にあるそのクライアントホストのエントリの機密ラベルと同等の場合、それらのファイルまたはディレクトリは書き込み可能になります。ラベルなしのクライアントにエクスポートされたファイルまたはディレクトリが読み取り可能になるのは、そのクライアントホストの機密ラベルが、エクスポートされたファイルまたはディレクトリの機密ラベルより優位な場合です。

Trusted Solaris 7、2.5.1、2.5 では、Trusted Solaris 1.1 および 1.2 ホストとデータを共有するために、トラステッド NFS のバージョン 1.x を部分的にサポートしています。これらのプロトコルではクライアントの部分だけはサポートされているので、Trusted Solaris 1.x ホストは、それ以降のバージョンの Trusted Solaris オペレーティング環境を実行しているホストにファイルシステムをエクスポートできます。しかし、一部の拡張機能 (特権など) が Trusted Solaris の動作環境のバージョンによって異なっているので、すべての属性がエクスポートできるわけではありません。特に、エクスポートできる拡張属性は、機密ラベル、アクセス権ビット DAC だけに限られます。ACL については Trusted Solaris 1.x と互換性があるという保証はありません。Trusted Solaris 1.x ホストから実行されたファイルについては、保証されません。特に、特権付きのプログラムは、Trusted Solaris 1.x ホストからは実行できません。

注 -

Trusted Solaris 2.5、2.5.1 または 7上の特権プロセスは、その特権を Trusted Solaris 1.x サーバー上では正しく解釈できない可能性があります。

バージョン 2.4 以前の Solaris または Trusted Solaris 1.x を稼動させている NFS サーバーからファイルシステムをマウントする場合は、vers=2 および proto=udp というマウントオプションを指定する必要があります。

どの NFS プロトコル (NFS V2/V3、TNFS、TSIG/TNFS) を使用するかは、ローカルファイルシステムの種類ではなく、エクスポートを実行するホストのオペレーティングシステムの種類によって決まります。mount コマンドまたはリモートファイルシステムの vfstab に指定するファイルシステムの種類は、常に nfs です。

他のホストがマウントするためにディレクトリをエクスポートする

他のシステムがマウントするためにディレクトリをエクスポート (共有) する方法は、基本 Solaris システムの場合と同様です。ファイルシステムを共有する場合は、2 つの新規のマウントオプションである nodevices と nopriv も使用できます。「他のホストがマウントするためにディレクトリを共有するには」を参照してください。

マウント時の障害を追跡する

標準 Solaris システムの手順 (『Solaris のシステム管理 (第 2 巻)』を参照のこと) に従って必要な標準セットアップを実行したにもかかわらず、マウントが失敗した場合は、「マウント時の障害を追跡するには」を参照してください。

ファイルおよびファイルシステム関連の手順

ファイルおよびディレクトリのラベルと特権を変更するには

セキュリティ管理者役割になります。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

ファイルマネージャを起動し、特権またはラベルを変更したいファイルを強調表示します。

特権を変更する場合は、「選択 (Selected)」メニューから「特権 (Privileges)」を選択します。

次に、ファイルマネージャの「特権 (Privileges)」ダイアログボックスを示します。
1. ファイルマネージャの「特権 (Privileges)」ダイアログボックスで、「許容された特権 (Allowed)」または「強制された特権 (Forced)」のボタンをオンにします。
2. 目的の特権を「含まない (Excluded)」リストから「含む (Included)」リストに移動させます。
3. 「了解 (OK)」をクリックします。

ラベルを変更する場合は、「選択 (Selected)」メニューから「ラベル (Labels)」を選択します。

ファイルマネージャのラベルビルダーダイアログボックスが表示されます。
1. ファイルマネージャのラベルビルダーダイアログボックスで、ラベルを入力します。
  
  次の手順のいずれかを実行します。
  1. 「更新後のラベル (Update Label With)」の下のテキストフィールドに入力します。
  2. 目的の格付け、コンパートメント、マーキングを必要に応じてクリックします。
2. 「了解 (OK)」をクリックします。

ローカルファイルシステムの作成時に、代替セキュリティ属性を指定するには

システム管理者役割になり、ADMIN_LOW ワークスペースに移動します。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

ファイルマネージャ、または pfsh(1M) シェルで mkdir(1) コマンドを使用して、マウントポイントとなるディレクトリを作成します。
$ mkdir /newpublic

「マウント・ポイントの設定 (Set Mount Points)」アクションを使用して、 vfstab(4) ファイルを開き、編集します。

必要に応じて、「管理アクションを起動するには」を参照してください。

vfstab(4) ファイルにファイルシステムのエントリを作成します。
/dev/dsk/c0t3d0s3 /dev/rdsk/c0t3d0s3 /newpublic ufs 2 yes-

ファイルを保存し、閉じます。
:wq

セキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動します。

プロファイルシェル pfsh(1M) で、目的の代替セキュリティ属性を指定して newsecfs(1M) コマンドを実行し、ファイルシステムをマウントします。

次の例は、機密ラベル範囲を SECRET から SECRET に設定しています。
$ newsecfs -l "Secret;Secret" /newpublic $ mount /spublic

ファイルシステム上でセキュリティ属性を設定するには

システム管理者役割になり、ADMIN_LOW ワークスペースに移動します。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

プロファイルシェルで、umount(1M) と入力し、ファイルシステムをマウント解除します。
$ umount /spublic

「マウント・ポイントの設定 (Set Mount Points)」アクションを使用して、vfstab(4) ファイルを開き、編集します。

必要に応じて、「管理アクションを起動するには」を参照してください。

vfstab(4) ファイルにファイルシステムのエントリが存在することを確認します。
/dev/dsk/c0t3d0s4 /dev/rdsk/c0t3d0s4 /spublic ufs 2 yes -

セキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動します。

プロファイルシェルで、該当する引数を指定して setfsattr(1M) コマンドを実行し、ファイルシステムを再度マウントします。

次の例は、機密ラベル範囲を SECRET から SECRTT に設定しています。
$ setfsattr -l "Secret;Secret" /public $ mount /spublic
注意 -
マウントするファイルシステムには、機密度の高い情報を含む名前は使用しないでください。マウントするファイルシステムの名前は、全ユーザーに表示されます。

マウント時にコマンド行でセキュリティ属性を指定するには

システム管理者役割になり、ADMIN_LOW ワークスペースに移動します。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

プロファイルシェルで、mount コマンドを入力し、-S オプションに続けて、希望のセキュリティ属性を指定します。
$ mount -F tmpfs -S "allowed=all;forced=all" swap /mnt
上記の例は、tmpfs タイプのファイルシステムである swap を /mntt 上にマウントします。許容された特権と強制された特権がすべて設定されます。

マウント時に auto_direct ファイルにセキュリティ属性を指定するには

注 -

ファイルシステムが自動マウントされる際に、auto_direct ファイルまたは autofs マップ内にセキュリティ属性が存在しない場合、属性は /etc/security/tsol/vfstab_adjunct file ファイルから取得されます。必要であれば、「マウント時に vfstab_adjunct ファイルにセキュリティ属性を指定するには」を参照してください。また、セキュリティ属性を指定した自動マウントの詳細については、automount(1M) のマニュアルページを参照してください。

セキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動します。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

「管理用エディタ (Admin Editor)」アクションを使って、/etc/auto_direct ファイルを開き、編集します。

必要に応じて、「管理アクションを起動するには」を参照してください。

ファイルシステムとそのセキュリティ属性のためのエントリを作成します。

次に、エントリの例を示します。
/usr/doctools -S allowed=all ardilla:/export/doctools

変更を保存し、ファイルを閉じます。
:wq

マウント時に vfstab_adjunct ファイルにセキュリティ属性を指定するには

システム管理者役割になり、ADMIN_LOW ワークスペースに移動します。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

「マウント・ポイントの設定 (Set Mount Points)」アクションを使用して、vfstab(4) ファイルを開き、編集します。

必要に応じて、「管理アクションを起動するには」を参照してください。

マウントポイントを指定し (vfstab のマニュアルページを参照)、必要に応じて、ファイルシステムに固有なセキュリティオプションをマウントオプションに追加します。

ファイルシステムタイプについては、mount_* のマニュアルページのファイルシステム固有のオプションを参照してください。

次の例は、ファイルシステムのタイプに ufs を指定し、標準 Solaris オペレーティング環境の nosuid オプションに加え、Trusted Solaris のマウントオプション、nodevices と nopriv を指定します。
/dev/dsk/c0t3d0s4 /dev/rdsk/c0t3d0s4 /spublic ufs 2 yes nodevices,nopriv,nosuid

ファイルを保存し、閉じます。
:wq

セキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動します。

「マウント属性の設定 (Set Mount Attributes)」アクションを使用して、vfstab_adjunct(4) ファイルを開き、編集します。

ファイルの先頭部分で、テンプレートのエントリをコピー、ペーストし、そのコピーを修正します。

次の例は、次のセキュリティ属性を /spublic に設定します。ファイルシステム内の全ファイルは、SECRET A という機密ラベルを (slabel) 持っているので、これらのファイルへは、その機密ラベルか、またはその機密ラベルより完全に優位な機密ラベルでのみアクセスできます。

#
 #       Yank the following entry and use as a template.
 #
 #<mount point>; ¥
 #acc_acl=; ¥
         . . .
 #audit_psa=;
 #
 #       attributes for an unlabeled file system
 #
 /spublic;¥
 acc_acl=; mode=; attr_flg=; gid=; uid=; ¥
 slabel="Secret A"; forced=; allowed=; low_range="Secret A";¥
 hi_range="Secret A"; mld_prefix=; mnt_flg=; audit_psa=;
 #
 #       attributes for an HSFS file system to mount from a
 #       CD-ROM
 #
 /cdrom;¥
 acc_acl=; mode=; attr_flg=; gid=; uid=; ¥
 slabel=; forced=127; allowed=all; low_range=;hi_range=;¥
 mld_prefix; mnt_flg=; audit_psa=;
 #
 #       automatically mounted by /etc/init.d/MOUNTFSYS
 #
 /tmp;¥
 acc_acl=; mode=; attr_flg=; gid=; uid=; ¥
 slabel=; forced=127; allowed=all; low_range=;hi_range=;¥
 mld_prefix; mnt_flg=; audit_psa=;

ファイルを保存し、閉じます。
:wq

他のホストがマウントするためにディレクトリを共有するには

システム管理者役割になり、ADMIN_LOW ワークスペースに移動します。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

「ファイルシステムの共有 (Share Filesystems)」アクションを使用して、/etc/dfs/dfstab ファイルを開き、編集します。

必要に応じて、「管理アクションを起動するには」および dfstab(4) のマニュアルページを参照してください。

エクスポートしたいファイルシステムのエントリを作成します。

次の例は、ユーザーのホームディレクトリを、 nodevices、nopriv、nosuid、および rw オプションでエクスポートします。
share -F nfs -o nodevices,nopriv,nosuid,rw -d "My Home Directory" /export/home/roseanne

ファイルを保存し、閉じます。
:wq

プロファイルシェル [pfsh(1M)] で、shareall(1M) を実行し、NFS デーモン nfsd(1M) に dfstab(4) を再度読み込むよう指示します。
$ shareall

NFS デーモンが動作していることを確認します。
1. ps(1) の出力を grep(1) に入力して、nfsd が動作しているかどうかを確認します。
  $ ps -ef | grep nfs root 303 1 0 10:35:42 ? 0:00 /usr/lib/nfs/nfsd -a 16
  注 -
  NFS デーモンが自動的に起動するには、ブート時に dfstab ファイル内にエントリが存在していなければなりません。
2. NFS デーモンが動作していない場合、手順 7 に進み、NFS デーモンを起動します。
3. NFS デーモンが動作している場合、手順 8 に進みます。

必要に応じて、NFS デーモンを起動します。
1. プロファイルシェルで、/etc/init.d ディレクトリに移動します。
2. nfs.server start コマンドを入力します。
  $ ./nfs.server start
3. NFS デーモンが動作していることを確認します。
  $ ps -ef | grep nfs root 303 1 0 10:35:42 ? 0:00 /usr/lib/nfs/nfsd -a 16

share(1M) コマンドをオプションなしで入力して、ファイルシステムがエクスポートされていることを確認します。
$ share - /spare/manuals rw "manuals"

コマンド行を使用して、TMPFS タイプのファイルシステムをマウントするには

システム管理者役割になり、ADMIN_LOW ワークスペースに移動します。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

プロファイルシェルで、mount コマンドを入力し、-S オプションに続けて希望するセキュリティ属性を指定します。
$ mount -F tmpfs -S "allowed=all;forced=all" swap /mnt
例では、tmpfs タイプのファイルシステムである swap を /mnt 上にマウントします。

HSFS タイプのファイルシステムで CD-ROM をマウントするには

任意のユーザーまたは役割になり、cd_rom_N デバイスを割り当てます。

割り当てられた CD-ROM デバイスに装着されている CD にファイルシステムが含まれている場合は、そのファイルシステムをマウントするかどうかが尋ねられます。これに対し yes と答えると、ファイルシステムは自動的にマウントされます。

オーディオ CD-ROM の CD プレイヤーを自動的に起動するには

第 15 章「デバイスの管理」の「CD-ROM デバイスの処理方法」で説明するように、割り当てられた CD-ROM デバイスにオーディオ CD を装着し、かつ rmmount.conf でオーディオ動作が指定されている場合は、オーディオ動作が実行されます。

セキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動します。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

「管理用エディタ (Admin Editor)」アクションを使用して /etc/rmmount.conf ファイルを開き、編集します。

必要に応じて、「管理用エディタアクションを使用してファイルを編集するには」を参照してください。

自動的に CD プレイヤーを起動するアクションを追加します。

次の例は、セキュリティ管理者役割が /usr/bin にインストールされている CD プレイヤー workman のためのアクションを rmmount.conf で作成する方法を示しています。
action cdrom action_workman.so /usr/bin/workman

ファイルを保存し、閉じます。
:wq

ユーザーまたは役割として、オーディオ CD を聞くには

スピーカーが CD-ROM デバイスに接続され、電源が入っていることを確認します。

「オーディオ CD-ROM の CD プレイヤーを自動的に起動するには」ための手順を確認します。

ワークスペースの機密ラベルでオーディオデバイスと cd_rom_N デバイスを割り当てます。

オーディオ CD をデバイスに挿入するよう要求されたら、挿入します。

すると、指定の CD プレイヤープログラムが自動的に起動されます。

マウント時の障害を追跡するには

ファイルシステムを共有するホストの IP アドレスが、マウント操作を行う Trusted Solaris ホスト上の tnrhdb(4) ファイルに設定されていることを確認します。

NIS+ ネームサービスを利用する場合は、ファイルシステムを共有するホストの IP アドレスを NIS+ ドメインの tnrhdb テーブルに設定しておく必要があります。ネームサービスを利用しない場合は、ファイルシステムを共有するホストの IP アドレスがマウント操作を行う Trusted Solaris ホストの /etc/security/tsol/tnrhdb ファイルに存在していなければなりません。

ホスト上で Trusted Solaris オペレーティング環境が動作していない場合は、有効な機密ラベルがテンプレート tnrhtp(4) でホストに割り当てられていること、その機密ラベルがマウントにも使用されていること、そして、ラベル範囲が mount -S コマンド行に続けて指定されているか、あるいは、/etc/security/tsol/vfstab_adjunct ファイル内に指定されていることを確認します。

ローカルホストのリブート以降、トラステッドネットワークデータベースに単一ラベルのリモートホストを新たに追加した場合や、テンプレートが変更された場合は、単一ラベルホストのエントリを tnctl -h hostname (ホストの追加後) または tnctl -t templatename (テンプレートの変更後) で更新したことを確認します。

マウントが、実行プロファイルに指定された mount コマンドを使用して、管理者役割によって実行されたことを確認します。

デフォルトの構成では、セキュリティ管理者役割は、マウントのセキュリティ属性を指定し、システム管理者役割は、Solaris の通常のマウントを担当します。

2.4 以前の Solaris バージョンを実行している NFS サーバー、または Trusted Solaris 1.x を実行している NFS サーバーから、ファイルシステムがマウントされている場合は、mount(1M) に vers=2 および proto=udp の各オプションが指定されていることを確認します。

第 12 章 NIS+ 管理

複数の Trusted Solaris ホストを持つ 1 つのセキュリティドメイン内では、ユーザー情報、ホスト情報、ラベル情報の一貫性を実現するために、サンの NIS+ ネームサービスを利用した各種設定情報の配布が行われます。

NIS+ の管理方法については Solaris 7 System Administrator Collection の次のマニュアルを参照してください。

『NIS+ への移行』
『Solaris ネーミングの設定と構成』
『Solaris 7 System Administrator Collection』
『Solaris ネーミングの管理』

NIS+ マスターサーバーおよび NIS+ クライアントの設定方法については、『Trusted Solaris のインストールと構成』を参照してください。

この章では、Trusted Solaris 環境における NIS+ の管理方法の特徴を説明します。この章では次の項目について説明します。

この章では次の操作手順を説明します。

「NIS+ テーブルを保存し、Trusted Solaris の再インストール後にそれを復元するには」

1 つのセキュリティドメイン内における複数の Trusted Solaris ホストの管理

Trusted Solaris の NIS+ マスターを使うと、Trusted Solaris の NIS+ クライアントまたは標準 Solaris の NIS+ クライアント用のデータを管理できます。 NIS 互換モードを使っている場合、Trusted Solaris の NIS+ マスターは NIS クライアント (1.x バージョンの Trusted Solaris オペレーティング環境が動作しているホストなど) の日付も管理できます。NIS 互換モードでは、標準の NIS+ サーバーと若干異なる設定手順が必要になります。NIS 互換モードは、NIS+ テーブルのセキュリティに影響を与えます。NIS 互換モードの相違点とセキュリティに対する影響については、『NIS+ 移行ガイド』の「NIS 互換モードの使用方法」を参照してください。

また、Trusted Solaris ホストは、Solaris NIS+ マスターのクライアントにはなれません。

1 つのセキュリティドメインは、通常、単一の NIS+ マスターを持つ単一の NIS+ ドメインとして管理されます。単一の NIS+ ルートマスターの下に複数の NIS+ マスターのサブドメインがぶら下がるような階層構造を利用して、複数のセキュリティドメインをまとめて管理することも可能です。作成できる NIS+ ルートマスターは 1 台のみですが、NIS+ 照会サービスを補強するために複数の複製サーバーを作成できます。複製サーバーは特定の NIS+ マスター (ルートまたは非ルート) に関連付けられており、主マスターが応答できない場合、これに代わって NIS+ 照会要求に応じます。

何らかの理由で NIS+ 経由では管理できない設定ファイル群は、個々のホストで集中して管理し、何らかの方法で各ホストにコピーしなければなりません(「変更した構成ファイルのネットワーク上のホストへの配布」を参照してください)。

スタンドアロン型の Trusted Solaris ホストの管理

Trusted Solaris ホストは、他のオペレーティングシステムが動作しているホストとネットワーク接続することはもちろん、スタンドアロンで使用することもできます。スタンドアロン型の Trusted Solaris ホストは、それが自分自身の NIS+ マスターサーバーとなるように設定することも、またはネームサービスを使わないように設定することもできます。後者の場合、設定情報は /etc、/etc/security、/etc/security/tsol の各ディレクトリに保持されます。Trusted Solaris 版 Solstice AdminSuite の管理ツールを使うと、管理役割はネームサービスを使わないように指定し、設定情報がローカルに格納されるよう設定できます。

スーパーユーザー役割または新しい役割への NIS+ 管理の許可

サイトのセキュリティポリシーが許すならば、スーパーユーザーの機能を拡張して、スーパーユーザー役割が NIS+ クライアントから NIS+ を管理できるように設定することも可能です。ただし、これはお勧めできません。新しい役割が NIS+ を管理できるように設定するには、その役割の名前を主体 (プリンシパル) 名として NIS+ の admin グループ内に追加する必要があります。

root が NIS+ クライアントから NIS+ を管理できるように設定するには、nisgrpadm(1) コマンドを使って、その NIS+ クライアント名を NIS+ の admin グループに追加する必要があります。この手順については、「スーパーユーザーまたは新しい役割が NIS+ を管理できるように設定するには」を参照してください。

新しい管理役割を作成して NIS+ テーブルを管理できるように設定するには、その役割の主体名 (たとえば、nnewrole.security.sun.com.) 用のエントリを NIS+ の admin グループに追加する必要があります。この手順については、「スーパーユーザーまたは新しい役割が NIS+ を管理できるように設定するには」を参照してください。

新たに導入された Trusted Solaris の NIS+ テーブルと、NIS+ 経由で管理されないファイル

新たに導入された Trusted Solaris の NIS+ テーブルを次の表に示します。

表 12-1 新たに導入された NIS+ テーブル


マップ名	定義
`tsoluser`	ユーザーや役割アカウントに指定されたTrusted Solaris属性および実行プロファイルを格納。
`tsolprof`	実行プロファイルを格納。
`tnrhdb`	ホストとネットワークアドレス間の対応、および `tnrhtp(4)` 内のテンプレートを格納。
`tnrhtp`	ホストやネットワークに割り当てられる、`tnrhdb(4)` 内のテンプレートを格納

次の表に、通常すべてのマシンで同一でなければならない設定ファイルのうち、NIS+ 経由で管理されないものを示します。システム構築後にこれらのファイルが変更された場合、管理者は変更されたファイルを各ホストに配布しなければなりません。

表 12-2 NIS+ 経由で管理されない設定ファイル


ファイル名
`label_encodings(4)`
`system(4)`

トラステッド NIS+ テーブルの追加

標準 Solaris では、管理者役割は保護されたデータフィールドを持つ NIS+ テーブルを追加することができます。詳細は NIS+ 管理に関する一連のマニュアルを参照してください。

注意 -

デフォルトの NIS+ テーブルに新たに行を追加したり、テーブルフィールド用に定義されたアクセス規則を変更したりしないでください。

新しいホストの追加と資格の付与

新しい NIS+ クライアントを追加する場合、管理者役割はそのホスト名と IP アドレスを hosts データベースに入力すると、ホストマネージャを使ってそのホストと NIS+ マスターとの関係を設定し、そのホストの持つ NIS+ 資格を指定します。ホストマネージャによって新しいホストに割り当てられるデフォルトの Secure RPC パスワードは nisplus になります。

注意 -

データベースマネージャは、NIS+ クライアントでないホストだけに使ってください。データベースマネージャはホストの名前と IP アドレスを hosts データベースに記録するだけで、その他の設定は行いません。

NIS+ 関連の操作手順

NIS+ テーブルを保存し、Trusted Solaris の再インストール後にそれを復元するには

(省略可能) 何らかの手段 (スクリプトの作成など) によって、NIS+ テーブルの内容を ASCII ファイルにダンプします。

注 -

NIS+ テーブルの内容は定期的に (少なくとも NIS+ 設定を変更した場合には必ず) ASCII ファイルにダンプしておくことをお勧めします。

スクリプトを作成するには、セキュリティ管理者役割になり、「管理用エディタ (Admin Editor)」アクションを使って、スクリプトファイルを ADMIN_LOW で作成します。

次に示すスクリプト nisscript は、システム管理者役割が NIS+ テーブルの内容を ASCII ファイルにダンプするために使うものです。また、このスクリプトは、将来グループテーブルが再度作成される場合に備えて、グループ番号のリストを生成します。

#!/bin/sh
# nisscript
# nisplus tables into ascii files
#
 
mkdir -p /var/nis-backup
chmod 700 /var/nis-backup
cp /etc/.rootkey /var/nis-backup/dot-rootkey
 
# standard Solaris and Trusted Solaris tables
# NOTE: Add any tables created at your site 
 
cd /var/nis/data
for i in aliases bootparams ethers group hosts netgroup ¥
netmasks networks passwd protocols rpc services ¥
timezone tnrhdb tnrhtp tsolprof tsoluser shadow
do echo $i
/usr/lib/nis/nisaddent -d $i >/var/nis-backup/$i
done
 
# Use the following if you have any key value tables
 
for i in sendmailvars tntime
do echo $i
/usr/lib/nis/nisaddent -d -t $i.org_dir key-value >/var/nis-backup/$i
done
 
# get a list of each group and list each member in each group
 
mkdir -p /var/nis-backup/groups.list
chmod 700 /var/nis-backup/groups.list
for i in `nisls groups_dir | grep -v `:'`
do nisgrpadm -l $i >> /var/nis-backup/groups.list/group.members
done

スーパーユーザー (root) 役割になり、ADMIN_LOW ラベルで前の手順で作成した nisscript を実行します。

グループごとに nisgrpadm -l group_name を実行して、そのグループの各メンバーの一覧を表示し、その出力を保存します。この出力は、手順 7 で使います。
$ nisgrpadm -l group_name

インストール時に上書きされないパーティションに、生成された ASCII ダンプファイルを含むディレクトリをコピーします。またはそのファイルを tar でテープやフロッピーにコピーします。

インストール時に上書きされないパーティションに ASCII ダンプファイルをコピーしなかった場合、インストール終了後に、ADMIN_LOW ラベルのスーパーユーザー (root) 役割のまま NIS+ テーブルの ASCII ダンプ用の作業ディレクトリを作成し、テープやフロッピーに収めた ASCII ダンプファイルをそのディレクトリ内に復元します。

テープに収めた ASCII ダンプファイルを /setup/files ディレクトリ内に復元する例を以下に示します。
# cd /setup/files # tar xv bootparams ethers . . .

『Trusted Solaris のインストールと構成』の「NIS+ ルートマスターの構成」で説明している適切な時点で、NIS+ 環境を再作成します。
# nisserver -r -d domain-name.
上記のコマンドを実行する場合、ドメイン名 (domain-name) の末尾にピリオド (.) が付いていることを確認してください。

nisserver コマンドを実行した後、セキュリティ管理役割になり、ADMIN_LOW ラベルで、プロファイルシェル内から次のような nispopulate コマンド (-F オプションと -p オプション、その後に ASCII ダンプファイルが格納されているディレクトリ名を指定したもの) を実行します。
# nispopulate -F -p /setup/files

NIS+ グループを再度作成し、手順 1 の nisscript で作成されたグループメンバーのリストを使って、この NIS+ グループにメンバーを手動で追加します。

NIS+ グループを自動的に再作成する簡単な方法はありません。

第 13 章 Trusted Solaris カーネルスイッチ設定の変更

多くの Trusted Solaris カーネルスイッチの設定は、変更できるようになっています。この章では次の項目と操作手順に関して説明します。

設定可能な Trusted Solaris カーネルスイッチ

この節では、system(4) ファイルの設定可能なカーネルスイッチの定義を示します。詳細は、「/etc/system ファイル内のカーネルスイッチ設定を変更するには」を参照してください。

注 -

デフォルトのスイッチ設定は、編集を行なった場合にのみ上書きされます。

tsol_admin_high_to_cipso

この tsol_admin_high_to_cipso スイッチはデフォルトの /etc/system ファイルには含まれていませんが、必要に応じて追加することができます。カーネルのデフォルト設定は 0 です。「I.P. ラベルの型 (IP Label Type) 」に CIPSO が指定されている TSIX タイプのホストとの通信を可能にする場合、このスイッチを1に設定する必要があります。

第 10 章「トラステッドネットワークデータベースにおけるセキュリティ属性の指定とルーティング設定」で説明してあるように、宛先ホストに割り当てられている tnrhtp テンプレートが CIPSO ラベルインジケータの 1 つを持つように指定されている場合、トラステッドネットワークソフトウェアはメッセージの機密ラベルから CIPSO ラベルを生成し、この CIPSO ラベルをメッセージパケットの IP オプション部分に挿入します。Trusted Solaris 2.x のADMIN_HIGH 機密ラベルは CIPSO ラベルをマップするにはサイズが大きすぎるため、デフォルトでは ADMIN_HIGH 機密ラベルで CIPSO 型のホストに送信されたメッセージは転送されません。

セキュリティ管理者役割は、値 1 を設定した tsol_admin_high_to_cipso スイッチを /etc/system に追加できます。これを行うと、パケット上の ADMIN_HIGH 機密ラベルのうち最上位の格付けを持ち、すべてのコンパートメントが有効なラベルにマップされて転送されます。詳細は、「パケットの CIPSO ラベル」を参照してください。

tsol_clean_windows

オブジェクトの再利用をサポートするため、tsol_clean_windows スイッチはデフォルトで 1 に設定されています。この設定では、システムコールから戻るたびにアクティブでない登録ウィンドウが消去されます。このスイッチを 0 に設定すると、アクティブでない登録ウィンドウは、システムコールの復帰時に消去されなくなります。したがって、システムコールはアクティブでない登録ウィンドウからもカーネル情報を返すことができる可能性があります。

tsol_flush_buffers

ブロックが i ノードにリンクされてからディスクに書き込まれるまでの間にクラッシュが発生すると、fsck(1M) でファイルシステムを回復した後でも、古い (おそらくは高いラベルの) ディスクブロックがファイルシステムにリンクされたままになる可能性があります。tsol_flush_buffers スイッチはデフォルトで 1 に設定されています。この設定では、データブロックは i ノードがディスク上で更新される前にフラッシュされます。この設定は、パフォーマンスに若干の悪影響をおよぼします。このスイッチを 0 に設定すると、データブロックは i ノードが更新される前にフラッシュされなくなります。

tsol_hide_upgraded_names

「ファイルの機密ラベルを昇格」承認を持つユーザーのアクションやfile_mac_write および file_upgrade_sl 特権を持つプロセスは、親ディレクトリの機密ラベルよりも完全に優位な機密ラベルを持つ新しいファイルやサブディレクトリを作成したり、既存のファイルやサブディレクトリのラベルを親ディレクトリの機密ラベルよりも完全に優位なラベルに変更したりすることができます。このような場合、これらのファイルやディレクトリは「昇格される」といい、昇格されたファイルやディレクトリの名前を「昇格された名前」と呼びます。

昇格された名前を機密情報とみなすサイトでは、tsol_hide_upgraded_names スイッチを使うことにより、セキュリティ管理者は昇格された名前が表示されないようなシステムを構築できます。このフラグをセットすると、ファイルの昇格された名前が getdents(2) によって戻されることを抑止できます。ただし、この場合、結果が呼び出し元プロセスに戻される前に、すべてのディレクトリエントリを調査することが必要になるため、システムのパフォーマンスは悪くなります。このスイッチはデフォルトではオフであり、昇格された名前は表示されます。

tsol_privs_debug

このスイッチを使うと、管理者は runpd(1M) を使って、プログラムがどの特権を利用すべきかを調べることができます。これを行うには追加の設定が必要であり、詳しい操作手順については第 16 章「ソフトウェアの追加」の「アプリケーションに必要な特権を調べるには」を参照してください。アプリケーションに必要な特権を調べ終ったら、このスイッチをリセットしてマシンをリブートする必要があります。このスイッチはデフォルトではオフであり、特権デバッグは無効です。

変更したカーネルスイッチ設定情報をネットワーク内のホストに配布するには

各サイトでインストールおよびシステム設定が完了した後は、system ファイルを変更する必要はほとんどありません。ただし、特権デバッグを有効にする場合は例外です。特権デバッグは、通常単一ホスト上で有効にします。必要があれば、スーパーユーザー役割は rdist(1) コマンドを使って、分散システム内のすべてのホストに、特定のファイルのまったく同じコピーを自動的に配布することができます。詳細は、第 2 章「その他の作業と操作手順」の「構成ファイルをリモート操作で配布するには」を参照してください。

/etc/system ファイル内のカーネルスイッチ設定を変更するには

セキュリティ管理者役割になり、アプリケーションマネージャの「システム管理 (System_Admin)」フォルダの「管理用エディタ (Admin Editor)」アクションを使って、/etc/system ファイルを開き、編集します。

詳細は、「ログイン後、特定の管理役割になるには」および「管理用エディタアクションを使用してファイルを編集するには」を参照してください。

必要に応じて、変数を設定します。

ファイルの内容を保存し、ファイルを閉じます。
:wq

「トラステッドパス (TP)」メニューの「シャットダウン (Shut Down)」オプションを使ってシステムをシャットダウンし、モニターのプロンプトで boot コマンドを入力します。
OK boot

第 14 章印刷管理

標準の Solaris 印刷ユーティリティおよびデータベースは、Trusted Solaris の条件に合わせて修正されています。プリンタ管理業務はシステム管理者とセキュリティ管理者の両方の役割で共有されています。いずれの管理者も、『Solaris のシステム管理 (第 2 巻)』に記述されているプリンタ管理の概念について、熟知していることが必要です。

この章では、Trusted Solaris 環境での印刷に関する特徴を理解して、管理を行うために、以下の項目の背景知識について説明します。

この章では、以下の手順についても説明しています。

印刷ジョブにラベルを割り当てる

各印刷ジョブには、ユーザーが作業している機密ラベルに対応する機密ラベルが自動的に割り当てられます。次の図では、社員が INTERNAL_USE_ONLY の機密ラベルが付けられた電子メールを読んでいます。この社員が「メッセージ (Message)」メニューの「印刷 (Print)」オプションを選択し、電子メールをプリンタに送ると、この印刷ジョブには、自動的に INTERNAL_USE_ONLY の機密ラベルが割り当てられます。

図 14-1 印刷ジョブの自動ラベル付け

プリンタのラベル範囲を使用して印刷できるジョブを制御する

プリンタは、制限されたラベル範囲内のラベルを持つジョブだけを印刷するように設定することができます。ジョブを実行できないときは、電子メールで送信者に通知されます。

たとえば、法務部門のプリンタが、次の 3 つのうちのいずれかのラベルで送られたジョブだけを印刷するように設定されているとします。

NEED_TO_KNOW LEGAL
INTERNAL_USE_ONLY
PUBLIC

上記のように設定されている法務部門のプリンタは、次の図に示すようにこの 3 つの機密ラベル以外のジョブを拒否します。

図 14-2 ラベル範囲を制限しているプリンタの例

プリンタへのラベル範囲制限の設定は、管理者がデバイス割り当てマネージャを使用して行います。これについては、次の「Trusted Solaris プリンタサーバに接続されたプリンタにラベル範囲制限を設定するには」で説明しています。「Trusted Solaris プリンタサーバに接続されたプリンタにラベル範囲制限を設定するには」

注意 -

機密情報を印刷するプリンタの場合、プリンタへの物理的なアクセスを制限する必要があります。

情報のラベル付けとプリンタへのアクセス制御

Trusted Solaris 印刷サブシステムには、デフォルトで以下の機能が組み込まれています。

すべての印刷ジョブのバナーページとトレーラページには、印刷ジョブの機密ラベルに基づく処理情報 (サイトで構成可能) や、ジョブの開始と終了を識別する識別番号が示されます。

注 -
組織によっては、バナーページとトレーラページの情報に基づいて、印刷出力の取り扱いと配布を管理する担当者を置いている場合があります。通常その担当者は、ポリシーに従って、バナーとトレーラページの識別番号が一致しないジョブを廃棄します。
印刷ジョブと印刷データ自体についてのセキュリティ関連情報は保護されます。
印刷待ち行列内のジョブの状態情報は、MAC および DAC によって制御されます。
プリンタごとに機密ラベル範囲の制限を設定し、そのプリンタで印刷するジョブを制御できます。
異なる機密ラベルの情報は、MLD (マルチレベルディレクトリ) として構成されている標準の印刷サービスディレクトリ内にある SLD (シングルレベルディレクトリ) に格納されます。

バナーページとトレーラページ、および本文ページの最上部と最下部のラベルの印刷は、承認されたユーザーまたは役割アカウントがコマンド行オプションを使用することにより抑制することができ、また、管理アクションを使用して、すべてのユーザーに対してこれらの機能を無効にすることができます。

システムの MAC および DAC ポリシーは、それぞれの印刷要求に含まれるデータに対して適用されます。これが適用されるのは、印刷要求が提示された時点から要求されたデータが物理的なページに印刷されるまでの間です。ジョブがプリンタに送信されるのは、印刷ジョブのラベルがプリンタのラベル範囲内にあるときだけです。保護規定を破ったり回避しようとする試みはすべて検出され、監査トレールが生成されます。

注意 -

ラベルなしホスト間で送受信される印刷ジョブには、ホストに割り当てられているトラステッドネットワークテンプレートから UID とデフォルトの機密ラベルが割り当てられます。ラベルなしホスト (unlab) のデフォルトのテンプレートでは、デフォルトの UID は nobody で、デフォルトの機密ラベルは ADMIN_LOW です。デフォルトの UID は変更可能であり、デフォルトの機密ラベルは変更しなければなりません。テンプレート例において ADMIN_LOW 機密ラベルが使われているのは、label_encodings ファイルにおけるユーザーレベルのラベルの設定がサイトごとに異なるためです。セキュリティ管理者役割はデフォルトの機密ラベルを、サイトのユーザー認可範囲内に収まるようなラベルに変更する必要があります。そうしなければ、通常のユーザーは ADMIN_LOW では操作を行えないので、印刷することはできません。

プリンタ出力の処理は、サイトごとに、サイトのセキュリティポリシーと手順に従って制御されます。機密情報を印刷するプリンタは、見る権限のない人がアクセスできないように物理的に保護する必要があります。また、その印刷出力も、サイトに固有な手順に従って、見る権限のない人がアクセスできないように物理的に保護する必要があります。

Trusted Solaris オペレーティングシステムが動作しているホストからのすべてのプリンタの出力には、サイトの要件に従って自動的にラベルが印刷されます。

次のディレクトリが MLD として作成されます。

/var/spool/print

/var/spool/lp/requests/system_name

/var/spool/lp/tmp/system_name

/var/spool/lp/tmp/.net/requests/system_name

/var/spool/lp/tmp/.net/tmp/system_name

ジョブの一覧表示に関するアクセス制御

デフォルトでは、待ち行列一覧表示コマンド (lpstat と lpq) は、ユーザーが発行したジョブの中で、そのユーザーの現在の機密ラベルと同じかまたはそれよりも優位な機密ラベルを持つジョブだけを表示します。他のユーザーが発行したジョブを表示できるのは、承認されたユーザーだけです。Trusted Solaris に固有な lpstat と lpq の -M オプションを使うと、承認されたユーザーはすべての機密ラベルのジョブを一覧表示できます。承認の一覧については、「印刷デフォルトを回避するための承認」を参照してください。

注 -

単一ラベルのホストから Trusted Solaris 7 印刷サーバーにジョブを発行したユーザーは、待ち行列内のジョブを見ることができません。ユーザーがラベル付きホストからジョブを送信した場合、トラステッドネットワークは印刷要求を送信したユーザーの UID を提供します。ユーザーがラベルなしホストからジョブを送信した場合、ジョブを送信したユーザーの UID は利用できません。したがって、印刷ジョブに割り当てられた UID はそのジョブを発行したユーザーの UID と一致しません。

ジョブの取り消しに関するアクセス制御

デフォルトでは、待ち行列一覧表示コマンド (lpstat と lpq) は、ユーザーが発行したジョブの中で、そのユーザーの現在の機密ラベルを持つジョブだけを取り消します。他のユーザーが発行したジョブを取り消すことができるのは、承認されたユーザーだけです。Trusted Solaris に固有な lpstat と lpq の -M オプションを使うと、承認されたユーザーはすべての機密ラベルのジョブを一覧表示できます。承認の一覧については、「印刷デフォルトを回避するための承認」を参照してください。

注 -

単一ラベルのホストから Trusted Solaris 7 印刷サーバーにジョブを発行したユーザーは、そのジョブを取り消すことができません。ユーザーがラベル付きホストからジョブを送信した場合、トラステッドネットワークは印刷要求を送信したユーザーの UID を提供します。ユーザーがラベルなしホストからジョブを送信した場合、ジョブを送信したユーザーの UID は利用できません。したがって、印刷ジョブに割り当てられた UID はそのジョブを発行したユーザーの UID と一致しません。

プリンタ出力にラベルおよびその他の情報を印刷する

本節では次の項目について説明をします。

tsol_separator.ps ファイル
本文ページに印刷されたラベル
バナーページとトレーラページに印刷されたラベルとその他の情報
どのようにしてデフォルトラベルおよび情報が変更できるか

`/usr/lib/lp/postscript/tsol_separator.ps`

セキュリティ管理者役割は、印刷サーバー上にある /usr/lib/lp/postscript ディレクトリ内の tsol_separator.ps ファイルを変更することによって、次の処理を行うことができます。

バナーページとトレーラページのテキストの各国語対応
バナーページとトレーラページのさまざまなフィールドまたは本文ページの最上部と最下部に印刷される代替ラベルの指定
テキストまたはラベルの変更または省略

上記以外のカスタマイズまたは国際化を行う方法については、tsol_separator.ps ファイル内のコメントを参照してください。次の節では、どの設定がどのラベルや情報を変更し、設定値がどのように変更されるかについて説明します。

本ページにラベルを印刷する

デフォルトでは、印刷ジョブの機密ラベルはすべての本文ページの最上部と最下部に印刷されます。

セキュリティ管理者役割は、次のいずれかの方法により、本文ページに印刷される機密ラベルのデフォルト設定を変更できます。

本文ページにラベルを付けずにジョブを印刷できる承認をユーザーに与える
印刷サーバー上の tsol_separator.ps 設定ファイルのフィールドを次のように再定義する
- すべてのユーザーについて、本文ページにラベルが印刷されないようにする
- すべてのユーザーについて、機密ラベルの別の情報や、他の語句、ラベルが本文ページに印刷されるようにする

「/usr/lib/lp/postscript/tsol_separator.ps」を参照してください。また、次の関連手順も参照してください。

機密ラベルの外見は、tsol_separator.ps ファイル内では /Job_SL_External と呼ばれ、バナーページとトレーラページの最上部と最下部に印刷されるように /HeadLabel 定義によって指定されています。/HeadLabel 定義を変更すれば、バナーページとトレーラページの最上部と最下部に異なる文字列を印刷したり、何も印刷しないようにできます。

図 14-3 本文ページに印刷される機密ラベル

バナーページとトレーラページ上のラベル、ジョブ番号、および取り扱い情報

次の図に、デフォルトのバナーページを示し、デフォルトのトレーラページとの違いを示します。トレーラページでは、グレーのフレームの代わりに黒い太線が印刷され、ページ種類の識別子が JOB START から JOB END に変わっています。すべてのデフォルト値は、サイトの要件に合わせて変更できます。

図 14-4 一般的な印刷ジョブのバナーページ

図 14-5 トレーラページでの変更点

印刷ジョブに表示されるすべてのテキスト、ラベル、および警告はサイトごとに設定可能です。各国語対応のために、テキストは別の言語のテキストに置き換えることができます。

ジョブの機密ラベルの格付けと label_encodings ファイルに定義されている minimum protect as classification を比較した場合、"Protect As" 格付けは優位な格付けです。

"Protect As" 格付け自体は、tsol_separator.ps ファイル内では /Job_Classification と呼ばれ、バナーページとトレーラページの最上部と最下部に印刷されるように /PageLabel 定義によって指定されています。/PageLabel 定義を変更すれば、バナーページとトレーラページの最上部と最下部に別の文字列を印刷したり、何も印刷しないようにできます。

"Protect As" 格付けがジョブの機密ラベル内のコンパートメントといっしょに印刷される場合、両者は、tsol_separator.ps ファイル内では /Job_Protect と呼ばれます。この値は、"Protect As" 文に印刷されるように /Protect 定義によって指定されています。デフォルトの /Protect定義を変更すれば、別の値を印刷したり、何も印刷しないようにできます。
"Protect As" 文の 2 つのテキスト行は、tsol_separator.ps ファイル内の /Protect_Text1 定義と /Protect_Text2 定義で指定されます。デフォルトの /Protect_Text1 定義と /Protect_Text2 定義を変更すれば、別の語句を印刷したり、何も印刷しないようにできます。
PRINTER BANNERS 値と CHANNELS 値は、ジョブの機密ラベル内のコンパートメントに基づいた変数値を印刷するように、label_encodings ファイル内で定義されています。PRINTER BANNERS は tsol_separator.ps ファイル内では /Job_Caveats と呼ばれ、/Caveats 定義で使われるように指定されています。CHANNELS は /Job_Channels と呼ばれ、/Channels 定義で使われるように指定されています。デフォルトの /Caveats 定義と /Channels 定義を変更すれば、別の値を印刷したり、何も印刷しないようにできます。

label_encodings ファイル内の minimum protect as classification、PRINTER BANNERS 値、および CHANNELS 値を設定する方法については、『Trusted Solaris ラベルの管理』の「プリンタ出力のためのラベルの指定と取り扱い上のガイドライン」を参照してください。

使用可能なプリンタ

ページラベル、バナーページ、およびトレーラページをサポートするプリンタは PostScript プリンタだけです。PostScript 以外のプリンタも、正しく機能しますが、ページラベルや、バナーページおよびトレーラページをサポートしていないため、Trusted Solaris の印刷要件を満たしていません。

警告 -

PostScript プリンタのようなインテリジェントなプリンタを使用する場合は、オブジェクトの再使用に関連した問題が発生する可能性があります。これは、次のジョブを受け付ける前に、プリンタのメモリー内のすべてのデータをパージできるとはかぎならいためです。また、知識のあるプログラマであれば、処理中のジョブや以降のジョブのラベルを偽装する PostScript 印刷ジョブを作成できる可能性があります。

トラステッド Solaris 以外の印刷サーバーに接続されたプリンタ

Trusted Solaris を実行していないホスト (印刷サーバー) に接続または管理されているプリンタでも、Trusted Solaris ホストから送られたジョブの印刷を行うことができます。ただし、このジョブは、ラベルなし、トレーラページなし、バナーページ上のセキュリティ情報なしで印刷されます。ラベルのないサーバーに接続されている印刷サーバーは、Trusted Solaris ホスト上のトラステッドネットワークデータベースに格納されている印刷サーバー用に設定された単一ラベルでのみジョブを印刷します。

サイトのセキュリティポリシーに合致していれば、セキュリティ管理者役割は、Trusted Solaris を実行していない印刷サーバーに接続されたプリンタで印刷を行うように設定できます。この場合、次の作業が必要です。

セキュリティ管理者役割は、特定の機密ラベルを持つ印刷サーバーホストを設定する
ユーザーは、印刷サーバーに割り当てられているのと同じ機密ラベルで、単一ラベルプリンタに印刷ジョブを送信する

単一ラベルは tnrhdb(4) ファイルまたは tnrhtp(4) ファイル内で、ラベルなし印刷サーバーの IP アドレスに割り当てられます。セキュリティ管理者がラベルなしのホストに単一の機密ラベルを割り当てる方法については、第 10 章「トラステッドネットワークデータベースにおけるセキュリティ属性の指定とルーティング設定」を参照してください。

ラベルなしホストから Trusted Solaris 印刷サーバーへの印刷

ラベルなしホストからの印刷がサポートされています。単一ラベルのホストから Trusted Solaris 印刷サーバーにジョブを発行したユーザーは、そのジョブを取り消したり、印刷待ち行列からそのジョブを削除したりすることはできません。ユーザーがラベル付きホストからジョブを送信した場合、トラステッドネットワークは印刷要求を送信したユーザーの UID を提供します。ユーザーがラベルなしホストからジョブを送信した場合、ジョブを送信したユーザーの UID は利用できません。したがって、印刷ジョブに割り当てられた UID はそのジョブを発行したユーザーの UID と一致しません。

ネットワークプリンタ

スタンドアロンのネットワークプリンタは、Trusted Solaris ホスト上で印刷マネージャの「ネットワークプリンタをインストール (Install Network Printer)」オプションを使って設定できます。ネットワークプリンタは単一ラベルのジョブだけを印刷できます。単一ラベルは、tnrhdb(4) ファイルまたは tnrhtp(4) ファイル内でラベルなし印刷サーバーの IP アドレスに割り当てられます。セキュリティ管理者が単一機密ラベルをラベルなしホストに割り当てる方法については、第 10 章「トラステッドネットワークデータベースにおけるセキュリティ属性の指定とルーティング設定」を参照してください。

ネットワークプリンタがローカルの Trusted Solaris ホストにネットワークプリンタとしてインストールされている場合、あるいは、プリンタマネージャの「NIS+」オプションを使って NIS+ テーブルに登録されている場合、そのネットワークプリンタは、本文ページ、バナーページ、およびトレーラページにラベルを印刷できます。「ラベル付きで出力するようにネットワークプリンタを構成するには」を参照してください。

Trusted Solaris 1.x のサポート

Trusted Solaris 1.x システムとの要求の送受信がサポートされています。ただし、Trusted Solaris 7 以降の印刷サーバーからのクライアント要求は、Trusted Solaris 1.x 印刷サーバーには転送されません。

Trusted Solaris 2.x のサポート

Trusted Solaris 2.x システムとの要求の送受信がサポートされています。Trusted Solaris 7 以降のバージョンでは、他のユーザーの印刷ジョブを一覧表示または取り消すときの制御方法が異なっています。Trusted Solaris 2.x では、他のユーザーの印刷ジョブを一覧表示または取り消すときに DAC と MAC を無視できるかどうかは、クライアントの特権によって制御されます。Trusted Solaris 7 以降のバージョンでは、特権ではなく、承認によって制御されます。「印刷デフォルトを回避するための承認」を参照してください。

ユーザーが Trusted Solaris 2.x システム上のプリンタの印刷ジョブを一覧表示または取り消せるようにするには、lpstat コマンドと cancel コマンドに必要な特権 (file_dac_read、file_dac_write、file_mac_read、file_mac_write) を追加するプロファイルを作成します。

PostScript ファイルの印刷に関する問題

デフォルトでは、ユーザーは PostScript ファイルを印刷できません。この制限は、知識のある PostScript プログラマであれば、プリンタ出力のラベルを変更する PostScript ファイルを作成できてしまうためです。

この制限を回避するために、セキュリティ管理者役割は、「PostScript ファイルを印刷」という承認を信頼できるユーザーや役割アカウントに割り当てます。セキュリティ管理者役割がこの処理を行うのは、そのアカウントがプリンタ出力のラベルを偽装することがなく、また PostScript ファイルを印刷することをすべてのユーザーに許可することが、サイトのセキュリティポリシーに合致している場合だけです。「印刷デフォルトを回避するための承認」を参照してください。

ファイルの内容のサポートされている部分とされていない部分

Trusted Solaris 印刷システムに組み込まれているフィルタは、テキストファイルを PostScript に変換します。インストールされているフィルタプログラムによって PostScript に変換されたファイルは、認証ラベルとバナーおよびトレーラページテキストを持っていることが保証されます。これは、フィルタプログラムが印刷デーモンによって実行されるトラステッドプログラムであるためです。

サイト管理者は、追加のフィルタをインストールすることができ、そのフィルタは、認証ラベルとバナーおよびトレーラページを持つことが保証されます。フィルタの追加方法については、『Solaris のシステム管理 (第 2 巻)』を参照してください。

公開ジョブをラベル付きページなしのデフォルトで印刷できるようにする

テクニカルライターなど、ユーザーによっては、ページの最上部と最下部にラベルを印刷せずに、誰もが読めるドキュメントを作成したい場合があります。Solaris 印刷サーバーに接続されたプリンタが使用可能な場合、セキュリティ管理者役割のユーザー環境の設定によって、公開ジョブは Solaris ホストに接続されているプリンタに、それ以外のラベルのジョブは Trusted Solaris ホストに送ることができるようになります。この処理を行うには、第 3 章「ユーザーアカウントの管理」に説明されているユーザーアカウントの設定方法と、第 10 章「トラステッドネットワークデータベースにおけるセキュリティ属性の指定とルーティング設定」に説明されているホストネットワークエントリについて理解している必要があります。「ラベルなしの印刷サーバーから公開印刷ジョブを設定するには」を参照してください。

プリンタを設定する

システム管理者役割は、以下の管理アプリケーションを使用して、プリンタの設定を行います。

プリンタマネージャ−ローカルおよびリモートプリンタの設定。「Solstice アプリケーション (Solstice_Apps)」フォルダ上の「アプリケーションマネージャ」フォルダからプリンタマネージャを起動します。「プリンタマネージャを起動するには」を参照してください。
デバイス割り当てマネージャの「管理」ダイアログボックス−プリンタのラベル範囲制限の指定。フロントパネルの「トラステッド・デスクトップ」サブパネルから、または「トラステッドパス (TP)」メニューの「デバイスを割り当てる」オプションを使ってデバイス割り当てマネージャを起動します。

「Trusted Solaris 印刷サーバーに接続されたプリンタをインストールするには」、「Trusted Solaris プリンタサーバに接続されたプリンタにラベル範囲制限を設定するには」、および「リモートプリンタへのアクセスを追加するには」を参照してください。

修正されているユーティリティおよびマニュアルページ

以下の一覧表に示したコマンドおよびファイルは、Trusted Solaris セキュリティポリシーに従って動作するように修正されています。次の表の 3　番目の欄が Y となっているコマンドを使用するには、アカウントに「印刷を管理」承認が必要です。これらのコマンドの詳細および Trusted Solaris での違いに関しては、マニュアルページを参照してください。

表 14-1 印刷関連コマンド


コマンド	説明	「印刷を管理」承認が必要か Y または N
`accept(1M)`/`reject(1M)`	印刷要求を待ち行列に入れることの許可または拒否	Y/Y
`enable(1)`/`disable(1)`	LP プリンタの有効化、無効化	Y/Y
`in.lpd(1M)`	BSD 印刷プロトコルアダプタ	Y
`lp(1)`/`cancel(1)`	LP 印刷サービスへの要求の送信/取り消し	N
`lpadmin(1M)`	LP 印刷サービスの設定	Y
`lpc(1B)`	(BSD) ラインプリンタ制御コマンド	Y
`lpfilter(1M)`	LP 印刷サービスで使われるフィルタの管理	Y
`lpforms(1M)`	LP 印刷サービスで使われるフォームの管理	Y
lpq(1B)	(BSD) 印刷ジョブの待ち行列の表示	N
`lpr(1B)`	(BSD) プリンタへのジョブの送信	N
`lprm(1B)`	(BSD) プリンタ待ち行列からのジョブの削除	N
`lpsched(1M)`/`lpshut(1M)`/`lpmove(1M)`	LP 印刷サービスの起動/停止	Y/Y/Y
`lpstat(1)`	LP 印刷サービスの状態に関する情報の印刷	Y
`lpset(1M)`	`/etc/printer.conf` または FNS における印刷構成の設定	Y
`lpsystem(1M)`	印刷サービスへのリモートシステムの登録	Y
`lptest(1B)`	(BSD) ラインプリンタのリプルパターンの生成	Y
`printers(4)`	ユーザー構成可能なプリンタ別名データベース	適用されない
`printers.conf(4)`	システム印刷構成データベース	適用されない

印刷デフォルトを回避するための承認

次の表は、印刷に関連する承認の定義を示しています。ユーザーまたは役割が、目的欄に記述されている処理を実行できるようにするためには、そのユーザーまたは役割に割り当てられているプロファイルのいずれかに承認が含まれている必要があります。プロファイルは、印刷サーバー上のアカウントに対して有効になっていなければなりません。「アカウントに印刷関連の承認を割り当てるには」を参照してください。

表 14-2 印刷に関連する承認


名前	目的	デフォルトプロファイル	プロファイルが割り当てられているデフォルトの役割
印刷を管理	ユーザーまたは役割が管理ユーティリティを使用して、印刷デーモンの起動と停止、他のユーザーの印刷ジョブのリスト作成と取り消しなどの印刷の管理を行えるようにします。この承認を必要とするコマンドの一覧については、「修正されているユーティリティおよびマニュアルページ」を参照してください。	Printer Security All Authorizations	secadmin なし
`印刷システムの MAC チェックを省略`	`「全印刷ジョブの取り消し」` 承認が有効な場合、ユーザーまたは役割が任意の機密ラベルの印刷ジョブを取り消しまたは一覧表示できるようにします。さらに、`「全印刷ジョブのリスト」` 承認が有効な場合、任意の機密ラベルの印刷ジョブを一覧表示できるようにします。	Printer Security All Authorizations	secadmin なし
`全印刷ジョブの取り消し`	ユーザーまたは役割が他のユーザーが発行した印刷要求を取り消せるようにします。	Printer Security	secadmin
`全印刷ジョブのリスト`	ユーザーまたは役割が待ち行列に入っているすべてのユーザーの印刷ジョブを一覧表示できるようにします。	Printer Security	secadmin
`PostScript ファイルを印刷`	ユーザーまたは役割に PostScript ファイルの印刷を許可します。	Printer Security Convenient Authorizations	secadmin なし
`バナーなしで印刷`	ユーザーまたは役割が `lp` `-o nobanner` オプションを使用して印刷要求を投入したり、バナーおよびトレーラページの印刷を抑制できるようにします。注: このオプションを有効にするには、そのプリンタのプリンタマネージャエントリの「常にバナーを印刷 (Always Print Banners)」チェックボックスをオフにしておく必要があります。	Printer Security	secadmin
`ラベルなしで印刷`	ユーザーが、`-o nobanner` オプションを指定した `lp` コマンドを使用して、印刷ジョブの本文ページの最上部と最下部にラベルが印刷されないように指定した印刷要求を投入できるようにします	Printer Security Convenient Authorizations	secadmin なし

プリンタの構成と保守

セキュリティ管理者役割は、Trusted Solaris 印刷サーバーに接続されているプリンタを 2 段階の手順で設定します。「Trusted Solaris 印刷サーバーに接続されたプリンタをインストールするには」を参照してください。

プリンタがシリアルポートに接続されている場合、Solstice シリアルマネージャを使って、正しいボーレートが設定されていることを確認します。
Solstice プリンタマネージャを使って、ローカルプリンタを追加します。
必要に応じて、デバイス割り当てマネージャを使って、プリンタのラベル範囲を制限します。

注 -

プリンタクライアントは、プリンタクライアントホストとプリンタサーバー用のトラステッドネットワークデータベースエントリが許可するラベルでのみ印刷要求を発行できます。ラベル範囲は、ローカルに接続されたプリンタ、リモートプリンタ、およびスタンドアロンのネットワークプリンタに適用されます。

デフォルトでは、セキュリティ管理者役割には、プリンタを追加し、そのラベル範囲を指定するために必要な承認、コマンド、アクション、および特権を提供するプロファイルが割り当てられています。

プリンタセキュリティプロファイル
デバイスセキュリティプロファイル

印刷関連の手順

プリンタマネージャを起動するには

セキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動します。

必要があれば、「ログイン後、特定の管理役割になるには」を参照してください。

フロントパネルの「アプリケーションマネージャ (Application Manager)」のアイコンをクリックして開きます。

「Solstice アプリケーション (Solstice_Apps)」アイコンをダブルクリックします。

「プリンタマネージャ (Printer Manager) 」アイコンをダブルクリックします。

次の図のようなプリンタマネージャの「読み込み (Load)」ダイアログボックスが表示されます。

ネームサービスとして「なし (None)」または「NIS+」を選択します。

次の図のようなプリンタマネージャが表示されます。

「Trusted Solaris 印刷サーバーに接続されたプリンタをインストールするには」、「ラベル付きで出力するようにネットワークプリンタを構成するには」、または「リモートプリンタへのアクセスを追加するには」に進んでください。

Trusted Solaris 印刷サーバーに接続されたプリンタをインストールするには

プリンタのインストールマニュアルの記述に従って、適切なケーブルを使用し、印刷サーバー上のシリアルポートまたはパラレルポートにプリンタを接続します。

画面の例では、プリンタは /dev/term/b というシリアルポートに接続されています。

プリントサーバー上でセキュリティ管理者役割になり、 ADMIN_LOW ワークスペースに移動します。

必要があれば、「ログイン後、特定の管理役割になるには」を参照してください。

プリンタがシリアルポートに接続されている場合、「Solstice アプリケーション (Solstice_Apps)」フォルダの「シリアルポートマネージャ (Serial Manager)」を使って、ボーレートが正しく設定されていることを確かめます。
1. 「Solstice アプリケーション (Solstice_Apps)」フォルダの「シリアルポートマネージャ (Serial Manager)」アイコンをダブルクリックします。
  
  必要があれば、「管理アプリケーションを起動するには」を参照してください。
2. 「シリアルポートマネージャ (Serial Port Manager)」ダイアログボックスで、プリンタが接続されているポートのエントリをダブルクリックします。
  
  シリアルポートマネージャの「変更 (Modify)」ダイアログボックスが表示されます。次の図を参照してください。
3. シリアルポートマネージャの「変更 (Modify)」ダイアログボックスで、ポートに指定されているボーレートの設定が正しいことを確認します。
  
  正しいボーレートについては、プリンタのマニュアルを参照してください。

「Solstice アプリケーション (Solstice_Apps)」フォルダからプリンタマネージャを起動します。

必要に応じて、「プリンタマネージャを起動するには」を参照してください。

次の図のように、「編集 (Edit)」メニューの「ローカルプリンタのインストール (Install Printer)」を選択します。

プリンタマネージャの「ローカルプリンタのインストール (Install Printer)」ダイアログボックスが表示されます。

プリンタを設定します。
1. プリンタ名を指定します。
  
  プリンタがネットワークプリンタの場合、手順 2 で割り当てたプリンタのホスト名を使います。
2. 必要に応じて説明を入力します。
3. プリンタを接続するポートの名前を「プリンタポート (Printer Port)」メニューから選択します。プリンタが標準以外のポートに接続されている場合は、「その他 (Other)」を選択し、代替ポートの名前を入力します。
  
  ttya と ttyb はシリアルケーブル用で、 bpp0 はパラレルケーブル用です。
4. 「プリンタタイプ (Printer Type)」および「ファイルの形式 (File Contents)」の設定は、PostScript のままにしておきます。
  
  警告 -
  PostScript に設定されているデフォルトの「プリンタタイプ (Printer Type)」および「ファイルの形式 (File Contents)」の値を変更しないでください。変更すると印刷は行われません。
5. 必要に応じて、「デフォルトプリンタ (Default Printer)」チェックボックスをオンまたはオフにします。
6. バナーページおよびトレーラページなしで印刷することをユーザーに許可していないサイトでは、「常にバナーを印刷 (Always Print Banners)」チェックボックスをオンにします。
  
  注 -
  バナーおよびトレーラページなしの印刷の承認をユーザーに付与するサイトに関しては、「常にバナーを印刷 (Always Print Banners)」チェックボックスをオフにします。
7. 必要に応じて、「アクセス可能ユーザー (User Access List)」にユーザーを追加します。
  
  特定のユーザーのユーザー名を追加すると、それ以外のすべてのユーザーは除外されます。この一覧を空のままにしておくと、すべてのユーザーにアクセスが与えられます。
8. 「了解 (OK)」をクリックし、変更内容を保存して、ダイアログボックスを閉じます。
  
  プリンタマネージャは、device_allocate(4) ファイルにプリンタ用のエントリを作成します。したがって、そのプリンタ名はデバイス割り当てマネージャの一覧に表示されます。

ラベル付きで出力するようにネットワークプリンタを構成するには

プリンタのマニュアルを参照しながら、プリンタを設定し、IP アドレスを割り当てます。

システム管理者役割になり、ホストマネージャを使って、プリンタ用のエントリを作成します。
1. プリンタ名を指定します。
2. 「Solstice アプリケーション (Solstice_Apps)」フォルダにある「ホストマネージャ (Host Manager)」アイコンをダブルクリックします。
  
  必要であれば、「管理アプリケーションを起動するには」を参照してください。
3. プリンタの名前と IP アドレスを指定します。

データベースマネージャを使って、tnrhdb(4) ファイル内でプリンタの IP アドレスにテンプレートを割り当てます。

「データベースマネージャからトラステッドネットワークデータベースにアクセスするには」を参照してください。

必要であれば、「データベースマネージャ (Database Manager)」を使って、tnrhtp(4) ファイル内でテンプレートを変更します。

プリンタマネージャを起動します。

必要であれば、「プリンタマネージャを起動するには」を参照してください。

「ネットワークプリンタをインストール (Install Network Printer)」を選択します。

「プリンタ名 (Printer Name)」フィールドにプリンタ名を入力します。この名前は、hosts(4) ファイルや NIS+ テーブルで割り当てられているプリンタ名でも、そのプリンタの別名でもかまいません。

「あて先 (Destination)」フィールドにプリンタのホスト名または IP アドレスを入力します。

「了解 (OK)」をクリックして、変更を保存し、プリンタマネージャを閉じます。

Trusted Solaris プリンタサーバに接続されたプリンタにラベル範囲制限を設定するには

セキュリティ管理者役割になって、ADMIN_LOW ワークスペースに移動します。

必要があれば、「ログイン後、特定の管理役割になるには」を参照してください。

デバイス割り当てマネージャを起動します。

トラステッドパス (TP) メニューの「デバイスを割り当てる (Allocate Device)」オプションを選択するか、またはフロントパネルの「トラステッド・デスクトップ」サブパネルから「デバイス割り当てマネージャ (Device Allocation Manager)」を起動します。

「デバイスの管理 (Device Administration)」ボタンをクリックし、デバイス割り当てマネージャの「管理 (Administration)」ダイアログボックスを表示します。

「デバイス (Device)」リスト上で、新しいプリンタの名前を選択します。

「構成 (Configure)」ボタンをクリックし、デバイス割り当てマネージャの「構成 (Configuration)」ダイアログボックスを表示します。次の図を参照してください。

必要に応じて、「最下位のラベル (Min Label)」および「最上位のラベル (Max Label)」をクリックして目的のラベル範囲に変更し、ラベルビルダーを使用して目的の機密ラベルを選択します。

「構成 (Configuration)」ダイアログボックスの「了解 (OK)」をクリックして、ラベルの変更を保存し、「管理 (Administration)」ダイアログボックスの「了解 (OK)」をクリックして、ダイアログボックスを閉じます。次に、デバイス割り当てマネージャを終了します。

リモートプリンタへのアクセスを追加するには

リモートプリンタへの印刷が設定されているローカルホスト上でプリンタマネージャを起動します。

必要があれば、「プリンタマネージャを起動するには」を参照してください。

注 -
印刷サーバーを構成するときにネーミングサービスとして NIS+ が指定されている場合、ドメイン内の NIS+ クライアントではこの手順は必要ありません。

次の図のように、「編集 (Edit)」メニューの「プリンタへのアクセスの追加 (Add Access to Printer)」を選択します。

プリンタマネージャの「プリンタへのアクセスの追加 (Add Access to Printer)」ダイアログボックスが表示されます。

ローカルホストからリモートプリンタへのアクセスを指定します。
1. 「プリンタ名 (Printer Name)」フィールドにリモートプリンタの名前を入力します。
  
  注 -
  スタンドアロンのネットワークプリンタを指定するときは、データベースマネージャを使ってプリンタをホストとして構成し、tnrhdb(4) ファイル内でホスト名にラベルなしホストタイプのテンプレートを割り当てます。
  
  スタンドアロンのプリンタ名を「プリンタ名 (Printer Name)」フィールドと「印刷サーバー (Print Server)」フィールドの両方に入力します。
  
  注 -
  スタンドアロンのネットワークプリンタまたは Trusted Solaris 以外のホストに送信できるのは、そのプリンタまたはホストに割り当てられている、 tnrhtp(4) 内のテンプレートで指定されたラベルのジョブだけです。
2. 「印刷サーバー (Print Server)」フィールドに印刷サーバーの名前を入力します。
3. 「説明 (Description)」フィールドに説明を入力します (オプション)。
4. 「デフォルトプリンタ (Default Printer)」チェックボックスをオンにします (オプション)。
5. 「了解 (OK)」をクリックします。変更内容が保存され、ダイアログボックスが閉じます。

必要に応じて、リモート印刷クライアント用のプリンタへのアクセスを指定します。
1. 「追加 (Add)」および「削除 (Delete)」ボタンの上のフィールドに、リモート印刷クライアントの名前を入力します。
2. 「プリンタ名 (Printer Name)」フィールドにプリンタの名前を入力します。
3. 「印刷サーバー (Print Server)」フィールドに印刷サーバーの名前を入力します。
4. 「構成 (Description)」フィールドに説明を入力します (オプション)。
5. 「デフォルトプリンタ (Default Printer)」チェックボックスをオンにします (オプション)。
6. 「追加 (Add)」ボタンをクリックし、印刷クライアントの名前をリストに追加します。
  
  処理が終了したら次の手順に進みます。さらにクライアントを追加するときは、手順 a に戻ります。
7. 「了解 (OK)」をクリックし、変更内容を保存して、ダイアログボックスを閉じます。

特定のユーザーにバナーとトレーラのないジョブの印刷を許可する

注意 -

プリンタマネージャの「常にバナーを印刷 (Always Print Banner)」チェックボックスがオンになっている場合、「バナーなしで印刷」承認を持つユーザーが lp に -o nobanner オプションを使用しても、バナーページとトレーラページは常に印刷されます。

印刷サーバー上でプリンタマネージャを起動します。

必要があれば、「プリンタマネージャを起動するには」を参照してください。

プリンタマネージャの「常にバナーを印刷 (Always Print Banner)」チェックボックスがオフになっていることを確認します。

プリンタマネージャを終了します。

バナーとトレーラページなしで印刷することを許可されている各ユーザーまたは役割に割り当てられているプロファイルに「バナーなしで印刷」承認が含まれていることを確認します。

必要に応じて、「アカウントに印刷関連の承認を割り当てるには」を参照してください。

ユーザーまたは役割がジョブを投入するときは、必ず -o nobanner オプションを指定して lp を実行します。
trustworthy% lp -o nobanner staff.mtg.notes

アカウントに印刷関連の承認を割り当てるには

セキュリティ管理者役割になります。

必要があれば、「ログイン後、特定の管理役割になるには」を参照してください。

ユーザーマネージャを起動します。

必要があれば、「管理アプリケーションを起動するには」を参照してください。さらに、このマニュアルの第 5 章「ユーザーマネージャを使ったアカウントの設定」を参照してください。

「プロファイル」ボタンをクリックして、「プロファイル」ダイアログボックスを開きます。
1. 必要な印刷関連承認がユーザーの実行プロファイルの 1 つに含まれていることを確認してください。
2. 必要に応じて、印刷関連の承認が含まれているプロファイルを「利用可能」リストに移動します。
  
  必要に応じて、表 14-2を参照してください。
  
  デフォルトが変更されていなければ、ユーザーのプロファイルリスト内に上記のプロファイルを 1 つ組み込むことで、そのユーザーに概当する承認が与えられます。
  
  注 -
  デフォルトの実行プロファイルに適切なものがない場合、セキュリティ管理者は、必要な印刷関連承認を含めた新しいプロファイルを作成することができます。このとき、承認だけを使用して作成することも、プロファイルのユーザーが目的の作業を行うために必要な他のコマンド (たとえば、lp や lpadminなど) を付加して作成することもできます。新しいプロファイルの作成方法については、このマニュアルの第 8 章「ユーザーおよび役割のための実行プロファイルの管理」で説明しています。
3. 「プロファイル」ダイアログボックスの最下部の「適用」または「了解」ボタンをクリックして変更内容を保存します。
  
  「適用」をクリックすると変更が保存されます。ダイアログボックスが表示された状態のままで「了解」をクリックすると変更が保存され、ダイアログボックスが閉じます。
4. ユーザーマネージャの「ナビゲータ」ダイアログボックスの「完了」または「保存」をクリックします。

ユーザーマネージャの「ファイル」メニューから「終了」オプションを選択して、すべてのユーザーマネージャのウィンドウを閉じます。

すべての印刷ジョブでページラベルの印刷を抑制するには

セキュリティ管理者役割になります。

必要があれば、「ログイン後、特定の管理役割になるには」を参照してください。

「管理用エディタ」アクションを使って、編集のために/usr/lib/lp/postscript/tsol_separator.ps ファイルを開きます。

必要があれば、「管理用エディタアクションを使用してファイルを編集するには」を参照してください。

次の行を探します。

%% To eliminate page labels completely, change this line to
%% set the page label to an empty string: /PageLabel () def
%% To eliminate page labels completely, change this line to 
%% set the page label to an empty string: /PageLabel
() def
           /PageLabel Job_PageLabel def

注 -

「Job_PageLabel」の値は、サイトによって変更されている可能性があります。

/PageLabel の値を空の括弧と置き換えます。

%% To eliminate page labels completely, change this line to 
%% set the page label to an empty string: /PageLabel () def
%% To eliminate page labels completely, change this line to 
%% set the page label to an empty string: /PageLabel
() def
           /PageLabel () def

特定のユーザーにページラベルなしの印刷ジョブを許可するには

各ページの最上部と最下部のラベルなしで印刷することを許可されている各ユーザーまたは役割に割り当てられているプロファイルに「ラベルなしで印刷」承認が含まれていることを確認します。

必要に応じて、「アカウントに印刷関連の承認を割り当てるには」を参照してください。

ユーザーまたは役割がジョブを投入するときは、必ず -o nolabels オプションを指定して lp を実行します。
trustworthy% lp -o nolabels staff.mtg.notes
この処理を行うことにより、承認を持つユーザーまたは役割は、どの機密ラベルで作業を行なっているときでも、ラベルなしでジョブを印刷できるようになります。

ラベルなしの印刷サーバーから公開印刷ジョブを設定するには

Solaris 印刷サーバーを定義する tnrhdb ならびに tnrhtp エントリで、一般に公開できるファイルを識別する機密ラベルを印刷サーバーに割り当てます。

たとえば、あるサイトでは、一般に公開できるファイルに PUBLIC または UNCLASSIFIED というラベルを付けることができます。

ページラベルなしで公開ファイルを印刷することが許可されたユーザーまたは役割ごとに、以下の 3 つの手順を実行します。
1. 一般公開できることを示すラベル (公開ラベルと呼びます) が、各アカウントに割り当てられている機密ラベルの範囲内にあることを確認します。
2. 公開ラベルを持つユーザーのホームディレクトリ SLD に PRINTE 変数を定義する方法を個々のユーザーに指示します。
  1. 公開ラベルを持つホームディレクトリ SLD に移動します。
  2. .login ファイルまたは .profile を開き、編集します。
  3. PRINTER 変数に Solaris 印刷サーバーに接続されているプリンタの名前を定義します。
    
    nolabels という名前のプリンタが、PUBLIC というラベルの付いた単一ラベル印刷サーバーに接続されているときは、PUBLIC SLD ディレクトリの .login または、.profile ファイルには、以下の環境変数が定義されています。
    setenv PRINTER nolabels
  4. ファイルを保存して、処理を終了します。
3. 他のすべての SLD に PRINTER 変数を定義する方法を個々のユーザーに指示します。作業を行う残りの SLD に関して、個々に以下の処理を行うように指示します。
  1. ホームディレクトリ SLD に移動します。
  2. .login または .profile ファイルを開き、編集します。
  3. PRINTER 変数に Trusted Solaris 印刷サーバーに接続されているプリンタの名前を定義します。
  4. ファイルを保存して、処理を終了します。
4. 作業を行なった各アカウントは、ログアウトして、再度ログインし、変更したプリンタ定義を有効にします。
5. 作業を行なった各アカウントは、一般公開できるラベルの SLD からラベルなしの印刷をするジョブを作成し、印刷を行います。

第 15 章デバイスの管理

この章では、デバイス上の企業情報を保護する方法について説明します。説明内容は、次の項目のとおりです。

また、デバイスに関連した次のような操作手順を紹介します。

デバイスアクセスポリシー

Trusted Solaris システムでは、他の UNIX システムの場合と同様、デバイスはデバイス特殊ファイルというファイルで表されます。また、デバイスに対する任意アクセス規則も、他の種類のファイルに適用されるのと同じ UNIX のアクセス権ビットに基づいています。一方、デバイスに適用される必須アクセス規則は、ファイルやディレクトリに適用される規則とは多少異なっています。次の表は、デフォルトの必須アクセス制御ポリシーを示したものです。システムに新しいデバイスが追加されると、これらのポリシーが自動的に適用されます。

表 15-1 デフォルトのデバイスアクセスポリシー


ポリシーの移動	内容	デフォルトポリシー
`data_mac_policy`	デバイスへのアクセスに必要な SL	読み取りや書き込みを行うためには、プロセスの SL はデバイスの SL と必ず同等
`attr_mac_policy`	デバイス属性へのアクセスに必要な SL (`ac(2)`、`chmod(2)`、 `chown(2)`、`stat(2)` を使用	デバイス属性への読み取りアクセスでは、プロセスの SL はデバイスの SL より優位。デバイス属性への書き込みアクセスでは、プロセスの SL はデバイスの SL と同等
`open_priv`	デバイスファイルを開く特権	なし
`str_type type`	STREAMS デバイスの場合のみ、カーネル STREAMS ヘッドによる STREAMS メッセージの制御方法を指定	デバイスタイプストリーム。ラベルなしの STREAMS メッセージも使用可能

セキュリティ管理者役割は、/etc/security/tsol/device_policy ファイルを編集し、デフォルトポリシーを変更して、ホストごとに新しいポリシーを定義することができます。使用するキーワードと値については、device_policy(4) のマニュアルページを参照してください。また、「新規デバイスへのポリシーの設定と既存デバイスのポリシーの修正」も参照してください。

デバイス割り当てによって対応できるセキュリティ問題

ある種の入出力デバイスを使用すると、セキュリティリスクが発生することがあります。たとえば、共通にアクセスすることができるテープデバイスを使用する場合、悪意のあるユーザーによって、デバイスの中のテープから密かに情報が読みとられる恐れがあります。デバイス割り当て機構には、こうしたリスクを制御する働きがあります。

セキュリティ管理者役割は、必要な承認を与えたり、承認を差し控えることができ、これによって特定のデバイスへのアクセスをユーザーごとに制御することができます。デフォルトの Trusted Solaris 分散システムで承認されていないユーザーが、テープドライブ、CD-ROM ドライブ、フロッピーディスクドライブなどのデバイスを割り当てることはできません。

あるユーザーがデバイスにアクセスしている間、他のユーザーが同じデバイスにアクセスすることはできません。デバイスを割り当てて使い終わった後は、そのデバイスの割り当てを解除し、そのデバイスを別のユーザーが利用できるようにする必要があります。

取り外し可能媒体でデバイスを割り当て解除する前に、システムはデバイス情報を消去するようにユーザーに求めます。割り当て解除は、ユーザーが取り外し可能媒体 (テープやフロッピーディスクなど) を取り出した時点で完了します。ユーザーは、その内容を見る権限のないユーザーがアクセスできないように、媒体の取り扱いに責任を持つ必要があります。

その他のデバイス (フレームバッファー、コンピュータメモリー、ディスクなど) の場合、割り当てと割り当て解除は自動的に行われます。また、この種のデバイスに格納されている情報も、自動的に消去されます。

デバイスラベル範囲に関連する MAC の問題

デバイス割り当て承認を持つ一般ユーザーは、単一機密ラベルでのみ情報のインポートまたはエクスポートが可能です。このときの機密ラベルは、そのユーザーがデバイスを割り当てる機密ラベルです。デバイス割り当て承認の詳細については、「デバイス関連の承認」を参照してください。

割り当て可能なデバイスには、それぞれ ADMIN_LOW から ADMIN_HIGH までのデフォルトの機密ラベル範囲があります。セキュリティ管理者は、デバイスマネージャを使って、この範囲を制限することができます。ラベル範囲は、割り当て不可能なデバイスにも設定できます。割り当て不可能なデバイスとは、フレームバッファーとプリンタのことです。特に、フレームバッファーにラベル範囲を設定した場合、コンソールログインを制限することができます。一般ユーザーは、作業を許可されているラベルがデバイスのラベル範囲に含まれていない場合、そのデバイスにアクセスすることができません。

ラベル範囲の限界を設定すると、特定の認可上限を持つユーザーだけにアクセスが制限され、物理的に保護できないデバイスへのアクセスを制御することができます。ラベル範囲の設定方法については、「最下位のラベルと最上位のラベル」を参照してください。

ホストのラベル範囲

コンソールから直接ログインするアクセスを制限するため、セキュリティ管理者役割は、フレームバッファーにラベル範囲の限界を設定します。

ローカルプリンタのラベル範囲

ホストにローカルプリンタが接続されている場合、セキュリティ管理者役割は、そのプリンタにラベル範囲の限界を設定し、印刷を行うジョブのラベル範囲を制限することができます。

デバイス割り当ての管理とデバイスラベル範囲の設定

セキュリティ管理者役割は、Trusted Solaris をインストールして、構成を行うときに、デバイスとその定義済特性のデフォルト構成をそのまま使用したり、変更したりします。システムの設定と実行が完了してから新しいデバイスを追加する場合、そのデバイスを割り当て可能にするかどうかはセキュリティ管理者役割が決定します。

デバイス割り当てマネージャから「デバイスの管理 (Device Administration)」ダイアログボックスを表示し、デフォルトの設定に次のような変更を加えることができます。

新しいデバイスまたは既存のデバイスの設定
- 1つまたは複数の承認により割り当て可能にする
- 承認されていない任意のユーザーによる割り当てを可能にする
- 割り当て不可能にする

デバイス上のラベル範囲の制限

変更は随時行うことができます。「デバイス割り当てマネージャの「管理 (Administration)」ダイアログボックスを表示するには」のほか、次の手順を参照してください。

システム構成の前に行う決定

デフォルトの device_allocate(4) ファイルに記述されているデバイスと、そのデフォルト定義の内容を確認します。
そのデフォルトがサイトのセキュリティポリシーに合致しているか判断し、合致していない場合は、変更するデフォルトを決定します。

割り当て可能なデバイスを追加するかどうかを決定します。

一般ユーザーにデバイスの割り当てを許可する場合、そのユーザーを決定します。

割り当て不可能なデバイスのリストに設定されているデフォルトのラベル範囲をそのまま使用するか、変更するかを決定します。

たとえば、ホストへのアクセスを制限するには、制限されたラベル範囲をフレームバッファ上に設定します。たとえば、ホストが公共の領域にある場合、セキュリティ管理者役割はフレームバッファ上のラベル範囲を PUBLIC ラベルに制限してもかまいません。

デバイス割り当てマネージャ

ユーザーによる割り当てが可能なデバイスや、一部の割り当て不可能なデバイスは、デバイス割り当てマネージャを使用して、割り当て、設定を行い、管理することができます。次の図に示すデバイス割り当てマネージャには、セキュリティ管理者が割り当てることのできるデバイスのリストが表示されています。

デバイス割り当てマネージャの使用は、「デバイスを割り当てる」というデバイス割り当て承認を持っているアカウントに限定されています。承認されていないユーザーに対しては、「使用可能デバイス (Available Devices)」の下のリストは空の状態で表示されます。また、その時点で他のユーザーによって割り当てられているデバイスや使用不可能な状態のデバイスは、「使用可能デバイス (Available Devices)」の下のリストには表示されません。これは、承認されているユーザーに対しても同じです。

デバイスが使用不可能な場合

「使用可能デバイス (Available Devices)」リストにデバイスが表示されていないときは、担当の管理者に連絡してください。

承認されていないユーザーが割り当てを行う必要がある場合、セキュリティ管理者役割は、そのアカウントのプロファイルの 1 つに「デバイスを割り当てる」承認を追加することができます。

デバイスがすでに割り当てられているか、割り当てエラーの状態にあって、リストに表示されていない場合、強制的にデバイスの割り当てを解除したり、エラー状態から回復させるための承認は、セキュリティ管理者役割に与えられています。

承認ユーザーのトレーニングと定義、セキュリティ作業維持の実行

デフォルトでは、デバイス割り当ての承認を受けるユーザーは、セキュリティ管理者役割が決定します。デバイスの使用を承認されるユーザーは、熟練者で、次の処理を任せられなくてはなりません。

機密情報を格納する媒体に適切なラベルを付け、正しく取り扱うことによって、許可されていないユーザーに入手されるのを防ぐ

たとえば、「NEED TO KNOW ENGINEERING」のラベルの付いた情報がフロッピーディスク上に保存されている場合、その情報を外部に持ち出すユーザーは、フロッピーディスクに実際に「NEED TO KNOW ENGINEERING」のラベルを付け、その情報を知る必要のある技術者グループのメンバーだけがアクセスできる場所に保管する必要があります。
デバイス上の媒体からインポート (読み取り) されるすべての情報について、適切なラベル管理を行う

承認ユーザーは、インポートする情報のラベルと同じラベルのデバイスを割り当てなくてはなりません。たとえば、フロッピードライブを PUBLIC で割り当てた場合、PUBLIC 以外のラベルでは情報をインポートすることはできません。また、NEED TO KNOW ENGINEERING のラベルの付いたフロッピーは、デバイスが NEED TO KNOW ENGINEERING ラベルで割り当てられている場合以外は、インポートできません。

セキュリティ管理者役割には、上記の要件が遵守されるように管理する責任もあります。

デバイス関連の承認

他のすべての承認と同様、デバイス関連の承認がアカウントに対して有効になるためには、次のアカウントの実行プロファイルのいずれかに指定されていること、そして、その実行プロファイルがセキュリティ管理者によってまず、そのデバイスがアカウントに割り当てられていることが必要です。詳細については、このマニュアルのパート IIを参照してください。また、「アカウントにデバイス関連の承認を割り当てるには」も参照してください。

サイト独自の割り当て承認を定義することもできます。たとえば、デバイスの種類ごとに、「テープデバイスを割り当てる (allocate tape device)」または「フロッピーデバイスを割り当てる (allocate floppy device)」などの異なる承認を設定することができます。必要に応じてデフォルトのリストに新しい承認を追加する場合は、このマニュアルの「拡張可能なセキュリティ機能の追加」をお読みの上、第 2 章「その他の作業と操作手順」の「承認を追加するには」に記述されている手順を実行してください。

新しい承認を追加すると、その承認は、デバイス割り当てマネージャの「承認 (Authorizations)」ダイアログボックスの「必須でない (Not Required)」リストに表示されます。「承認」を参照してください。

次の表に、デバイス関連の承認を示します。

表 15-2 デバイスの割り当て、設定、および管理承認


承認名	内容
デバイスを割り当てる	ユーザーに、デバイスの割り当てを許可する。また、そのデバイス経由でインポートまたはエクスポートされる情報に関連付ける機密ラベルの指定を許可する
デバイスの属性を構成	管理者に、デバイスの設定を許可する。デバイスの設定には、デバイス名、デバイスの種類、ラベル範囲、割り当て可能状態、割り当て承認リストの設定が含まれる
デバイスを回収または再設定	管理者に、現在割り当てられているデバイスの割り当てを解除したり、割り当てエラー状態をリセットしてデバイスを再度割り当て可能にすることを許可する

デバイス割り当てマネージャの「管理 (Administration)」ダイアログボックス

以下の図の「デバイスの管理 (Device Administration)」ボタンは、デバイス割り当てマネージャの下部にあります。ただし、表示されるのは、デバイスの管理に必要な「デバイスの属性を構成」または「デバイスを回収または再設定」のいずれか、または両方の承認を持つ管理者アカウントに対してのみです。これらの承認の目的については、表 15-2 を参照してください。

図 15-1 デバイス割り当てマネージャ

下の図に示すように、「デバイスの管理 (Device Administration)」ボタンをクリックすると、デバイス割り当てマネージャの「管理 (Administration)」ダイアログボックスが表示されます。このダイアログボックスは、代替承認を再要求、取り消し、および指定するとき、さらに、デバイスを構成するときに使います。

図 15-2 デバイス割り当てマネージャ「管理 (Administration)」ダイアログボックス

このダイアログボックスには、構成時に管理者が利用できるデバイスの一覧が表示されます。さらに、強調表示されている (選択している) デバイスの「状態 (State)」、「所有者 (Owner)」、および「デバイスの機密ラベル (Device Label)」も表示されます。

解除

「解除 (Revoke)」ボタンが有効になっているとき、強調表示されているデバイスの「状態 (State:) 」フィールドには、「割り当て済み (Allocated)」が表示されます。アカウントに「デバイスを回収または再設定」承認がある場合、「解除 (Revoke)」ボタンをクリックすると、選択しているデバイスの割り当てが強制的に解除され、状態が「未割り当て (Not Allocated)」に変わります。

再利用

「再利用 (Reclaim)」ボタンが有効になっているとき、強調表示されているデバイスの「状態 (State:) 」フィールドには、「割り当てエラーの状態 (Allocate Error State)」が表示されます。アカウントに「デバイスを回収または再設定」承認がある場合、「再利用 (Reclaim)」ボタンをクリックすると、選択しているデバイスが割り当てエラーから解放され、状態が「未割り当て (Not Allocated)」に変わります。

構成

アカウントに「デバイスの属性を構成」承認がある場合、「構成 (Configure)」ボタンをクリックすると、デバイス割り当てマネージャの「構成 (Configuration)」ダイアログボックスが表示されます。図 15-2 を照してください。

「構成 (Configuration)」ダイアログボックス

この節では、前の図に示したデバイス割り当てマネージャの「構成 (Configuration)」ダイアログボックスを使用してデバイスに指定できる情報について説明します。

デバイス名とデバイスタイプ

「デバイス名 (Device Name)」と「デバイスタイプ (Device Type)」のフィールドには、選択したデバイスに関する情報が表示されます。この 2 つのフィールドは編集できません。

最下位のラベルと最上位のラベル

「最下位のラベル (Min Label)」ボタンや「最上位のラベル (Max Label)」ボタンをクリックすると、ラベルビルダーが起動します。セキュリティ管理者役割はこれを使用して、最下位ラベルや最上位ラベルを指定できます。デバイス作成時に最下位ラベルが指定されない場合、デフォルトで ADMIN_LOW が指定されます。また、最上位ラベルが指定されない場合、デフォルトで ADMIN_HIGH が指定されます。デバイスのラベル範囲の設定については、「デバイス割り当ての管理とデバイスラベル範囲の設定」を参照してください。「最下位のラベル (Min Label)」、「最上位のラベル (Max Label)」のフィールドは、割り当て可能なデバイスと割り当て不可能なデバイスとでは異なります。

Clean プログラム

セキュリティ管理者役割は、「Clean プログラム」フィールドに、割り当て可能なデバイスの device_clean(1M) スクリプトのパスを入力することができます。デバイス作成時に device_clean スクリプトが指定されない場合、デフォルトは /bin/true になります。このスクリプトの記述方法については、「デバイス clean スクリプト」を参照してください。

割り当てを行えるユーザー

割り当て可能デバイスに関しては、「割り当てを行えるユーザー (Allocatable By)」スクロールリストに、割り当てを行うユーザーが表示されます。次の 3 つの選択肢があります。

承認されたユーザー (Authorized users)
すべてのユーザー (All users)
なし (No users)

デバイス作成時に承認が指定されない場合、デフォルトは「すべてのユーザー (All users)」になります。承認が指定されている場合、デフォルトは「承認されたユーザー (Authorized users)」になります。

注意 -
「割り当て可能なデバイスの追加 (Add Allocatable Device)」アクションの設定では、すべてのユーザーが新しいデバイスを割り当てられる状態になります。そのため、フレームバッファープリンタなどのデバイスの割り当てを行えるユーザーを制限する必要があるときは、セキュリティ管理者役割が手作業で割り当てるを行える「なし (No users)」に指定する必要があります。

承認

「承認 (Authorizations)」ボタンは、デバイスに「割り当てを行えるユーザー (Allcatable By)」フィールドに「承認されたユーザー (Authorized Users)」が指定されているとき有効です。「承認 (Authorizations)」フィールドのデフォルトは、「デバイスを割り当てる」です。セキュリティ管理者役割は、「承認 (Authorizations)」ボタンをクリックし、他の承認に変更したり、複数の承認を指定することができます。次の図に 2 つのダイアログボックスを示します。

図 15-3 「承認 (Authorizations)」ボタンをクリックしてデバイス割り当てマネージャの「承認 (Authorizations)」ダイアログボックスを表示する

リモートデバイス管理

add_allocatable(1M)、remove_allocatable(1M) コマンド、「割り当て可能なデバイス (Add Allocatable Device)」アクション、デバイス割り当てマネージャのそれぞれを使って、ホスト上のdevice_allocate(4) と device_maps(4) のローカルファイルを変更することができます。ネットワーク内の複数のホストに同じ変更を行うには、 rdist(1) を使用して、変更後の device_allocate ファイルと device_maps ファイルをリモート操作で配布します。ただし、新しいデバイスを追加した場合には、各ホストにリモートでログインし、必要な補助ファイルを手動で作成する必要があります。

割り当て可能デバイス用の補助ファイル

割り当て可能デバイスには、補助ファイルがあります。これは、ゼロ長ファイルで、/etc/security/dev ディレクトリに格納されています。補助ファイルは、DAC ファイルとも呼ばれます。なぜならデバイスを割り当て可能にするためには、補助ファイルが存在していること、および、補助ファイルに特定の DAC アクセス権セット、所有者、グループが設定されている必要であるためです。デバイスの割り当て状態と、補助ファイルの DAC アクセス権セット、所有者、グループ、機密ラベルの設定の対応関係については、次の表を参照してください。

未割り当て
割り当て済み
エラー状態

表 15-3 デバイスの割り当て状態と補助ファイルの設定


	DAC アクセス権 (モード)	所有者	グループ	SL
未割り当て	0000	bin	bin	`ADMIN_LOW`
割り当て済み	0600	`ユーザー`	`ユーザーのグループ`	`ユーザーのプロセスの SL`
エラー状態	0100	bin	bin	`ADMIN_HIGH`

割り当てエラー状態

表 15-3 に示すように、デバイス補助ファイルのモードが 0100で、機密ラベルが ADMIN_HIGH、所有者がユーザー bin とグループ bin である場合、割り当て可能デバイスはエラー状態になります。デバイス割り当てがエラー状態になる原因としては、 device_clearn(1M) スクリプトの使用が考えられます。デバイス clean スクリプトを使用すると、割り当て解除中にユーザーがスクリプトからのプロンプトに応答し、取り外し可能な媒体を取り出すまで、デバイスが割り当てエラー状態になります。デバイスをエラー状態から復帰させるには、デバイス割り当てマネージャの「管理 (Administration)」ダイアログボックスの「再利用 (Reclaim)」ボタンを使用します。このボタンは、承認されたユーザーが使用することができます。「再利用」を参照してください。

デバイス clean スクリプト

デバイス clean スクリプトは、デバイスが割り当てられるか、割り当て解除されるときに、随時実行されます。通常、割り当て解除は、デバイスを割り当てたユーザーによって行われます。必要に応じて、承認されたユーザーが、デバイス割り当てマネージャの「管理 (Administration)」ダイアログボックスの「解除 (Revoke)」ボタンを使用して、デバイスの割り当てを強制的にします。強制的な割り当て解除の詳細については、「解除」を参照してください。

サイトでシステムに割り当て可能デバイスを追加する場合、追加デバイス用に新しいスクリプトが必要になることがあります。既存のデバイス clean スクリプトの機能については、次の説明を参照してください。また、「新しいデバイス clean スクリプトを作成する」も参照してください。

テープ装置用のデバイス cleanスクリプト

テープ装置としては、次の表に示す 3 種類がサポートされています。デバイス clean スクリプト st_clean は、すべてのテープ装置に使用できます。

表 15-4 使用可能なテープ装置


テープ装置のタイプ
SCSI 1/4 インチテープ
Xylogics 472 1/2 インチテープ
Archive 1/4 インチテープ

st_clean スクリプトは、mt(1) コマンドに -rewoffl オプションを使用して、デバイスのクリーンアップを行います。システムのブート中に実行すると、スクリプトはデバイスがオンラインになっているか、記憶媒体がその中にセットされているかを確認します。さらに必要に応じてプロンプトを表示し、オペレータに記憶媒体を取り出すように指示し、その記憶媒体の物理的なラベルに記述する適切なラベルを表示します。

割り当てが完全に解除されるまで、1/4 インチテープデバイスは割り当てエラー状態になり、1/2 インチテープデバイスはオフラインになります。割り当てエラー状態になった場合、再度ユーザーによる割り当を行えるようにするためには、承認されたユーザーが手作業でデバイスのクリーンアップを行う必要があります。

フロッピーディスクと CD-ROM 用のデバイス clean スクリプト

disk_clean スクリプトは、フロッピーディスクドライブと CD-ROM デバイスの両方に使用されます。システムのブート中に disk_clean スクリプトを実行する場合、デバイス内に媒体が検出されると、取り出されます。ブート時やデバイスの割り当て解除時にスクリプトが実行される場合、eject コマンドが成功すると、ユーザーは媒体に適切なラベルを記入した物理ラベルを貼るように指示されます。eject(1) コマンドが失敗すると、デバイスは割り当てエラー状態になります。

割り当ての一環としてフロッピーまたは CD-ROM からファイルシステムがマウントされる場合、カレントディレクトリをマウント先に設定したファイルマネージャが表示されます。セキュリティ管理者役割は、手順 1に従って、ファイルマネージャを自動表示しないようにすることができます。フロッピーディスクからファイルシステムをマウントする場合と、 CD からファイルシステムをマウントする場合では、処理方法が異なります。違いについては、次の節で説明します。

CD-ROM デバイスの処理方法

CD-ROM デバイスが割り当てられたとき、ユーザーは CD-ROM をマウントするかどうかという質問を受けます。CD にファイルシステムが入っている場合は、ユーザーは「yes」と答えるべきです。答えが「yes」のときは、ファイルシステムが自動的にマウントされます。割り当てられた CD-ROM デバイスにオーディオ CD が入っている場合、ユーザーは「no」と答えるべきです。答えが「no」の場合、オーディオアクションが rmmount.confで指定されていれば、オーディオアクションが実行されます。デフォルトではオーディオアクションは指定されていません。オーディオ CD をかけるためには、ユーザーはオーディオデバイスと CD-ROM デバイスの両方を割り当てなければなりません。デバイスの割り当て後、ユーザーは必要に応じて手動でオーディオプレイヤーアプリケーションを実行することができます。

たとえば、一般的に使用されている CD プレイヤー workman がインストールされているサイトでは、セキュリティ管理者役割は、rmmount.conf に次のようなアクションを設定し、ローカルの /usr/local/bin にインストールされたworkman を自動的に起動することができます (/pathname/to/workman は workman へのパスを示します)。

action cdrom action_workman.so /usr/local/bin/workman

フロッピーデバイスの処理方法

フロッピーディスク上のファイルシステムの場合、割り当て時に自動マウントされることはありません。これは、フロッピー上にすでに存在しているファイルシステムの上に、新しいファイルシステムを作成するより要求される可能性があるからです。フロッピーデバイス上のファイルシステムがマウントされない場合に限り、fdformat(1) または newfs(1M) などのプログラムで新しいファイルシステムを作成することができます。このため、フロッピー上の既存のファイルシステムをマウントする前に、disk_clean スクリプトはファイルシステムをマウントするかどうかをユーザーに確認します。

フロッピーディスクがフォーマットされていない場合、disk_clean スクリプトは、フロッピーディスクをフォーマットするかどうかをユーザーに確認します。

フロッピー上のファイルシステムがデバイス割り当ての一環としてマウントされるとファイルマネージャがホップアップします。ここでは、カレントディレクトリはマウント先に設定されています。

オーディオ用のデバイス clean スクリプト

オーディオツールデバイスのクリーンアップには、audio_clean プログラムを使用します。

このプログラムは、AUDIO_DRAIN ioctl を実行してデバイスをフラッシュし、その後 AUDIO_SETINFO ioctl をリセットしてデバイス構成をデフォルトに戻します。さらに、このプログラムは、AUDIOGETREG ioctl でオーディオチップのレジスタを取得し、デフォルトと異なるレジスタが存在しているときは、AUDIOSETREG ioctl でリセットします。オーディオデバイスには取り外しの可能な媒体が含まれていないため、外部に物理的なラベルを付ける必要はありません。そのため、audio_clean スクリプトは機密ラベルを表示しません。

新しいデバイス clean スクリプトを作成する

サイトで割り当て可能にできるデバイスには、たとえばモデム、端末、グラフィックスタブレットがあります。これらのデバイスを割り当て可能にする場合、新しいデバイス clean スクリプトを作成することになります。デバイス clean スクリプトは、テープ装置を追加した場合にも作成します。例外は、Xylogics テープ装置と Archive テープ装置です。これらのテープ装置では、デフォルトの device_clean(1M) スクリプト (/etc/security/lib/st_clean) を使用できるため、新規にスクリプトを作成する必要はありません。

デバイスクリーンスクリプトのデフォルトの場所は /etc/security/lib

デバイスクリーンスクリプトは、正常終了の場合 0 を、エラーが発生した場合 0 より大きい値を返す

強制的な媒体の取り出しができなかったり、取り出しに失敗した場合は、そのデバイスを割り当てエラー状態にする

deallocate コマンドは、デバイスクリーンスクリプトに、次の 4 つのパラメータを渡します。

st_clean -[I|F|S] -[A|D] device_name sensitivity_label

オプションの -I、-F、-S は、スクリプトの実行モードを決定します。-I は、システムブート時のみ必要になります。これにより、すべての出力がシステムコンソールに送られます。また、-F はクリーンアップを強制し、-S は標準のクリーンアップを行います。これらのパラメータは対話型で、ユーザーがプロンプトに応答することを前提としています。-F オプションを指定すると、クリーンアップの一部が失敗した場合に、スクリプトはクリーンアップを完了させなくてはなりません。

[-[A]-[D]] は、デバイスクリーンスクリプトが allocate または deallocate のどちらから呼び出されたかを示します。

device_name はデバイス名を示す文字列、sensitivity label は機密ラベルを表す 16 進数です。

ブート時の割り当て済みデバイスの処理方法

ブート時には、割り当て済みデバイスは、再割り当てされ、再マウントされます。-r オプションを指定して boot コマンドを入力すると、デバイスの割り当てが強制解除されます。

情報のインポート時とエクスポート時の考慮点

情報をエクスポートする (記憶媒体に書き込む) には

テープ装置、フロッピーデバイスなどの媒体デバイスは、デバイス上に格納されている情報の機密ラベルで割り当てます。

情報をインポートする (記憶媒体から読み取る) には

情報の格納に使用されるテープまたはフロッピーが入っているデバイスが読み取り用に割り当てられているときは、テープに実際に貼りつけられたラベルの機密ラベルで、テープデバイスを割り当てます。

`tar` を使ったデバイス割り当て

ユーザー用のコマンドとしては、tar(1) だけが、Trusted Solaris セキュリティ属性の保管と抽出用に拡張されています。拡張された tar コマンドでは、Trusted Solaris セキュリティ属性を含む tar ファイルの作成、更新、目次のリスト抽出が可能になりました。特権がなければ、tar コマンドは Trusted Solaris セキュリティポリシー内で作動します。特権を持たない通常のユーザーによって実行された場合、tar は単一の機密ラベルで動作し、現在のワークスペースの機密ラベルで tar ファイルを作成することにしか使えません。また、ユーザーが前もって、記憶媒体を割り当てていない場合は、tar は動作しません。この場合には、次の図のようなエラーメッセージが表示されます。

trusted4% tar -cvT *
 
tar: /dev/rmt/0: Permission denied

tar には、Trusted Solaris セキュリティ属性の保管と抽出のための新しいオプションが追加されました。

tar コマンドは検出したすべての MLD を処理対象とします。 tar プロセスの機密ラベルより優位でない SLD も対象に含まれます。適切な無効化特権がある場合には、すべての SLD を処理対象にすることができます。

`tar` ファイルの補助ファイル

Trusted Solaris の拡張されたセキュリティ属性を持つファイルがアーカイブされる際には、拡張されたセキュリティ属性を持つ補助ファイルが、それぞれのファイルに先行して作成されます。補助ファイルの名前は、対応するアーカイブファイル名の末尾に文字列 "(A)" が付加されたものです。次の図は、セキュリティ属性を保持するための -T オプションと冗長出力を行うための -v オプションを指定した tar で、2 つのファイルをアーカイブした際の出力例を示します。この図の中で示された両方のファイルにはそれぞれの補助ファイルが先行しています。たとえば、Dtapps.bw.xbm ファイルの前には補助ファイル Dtapps.bw.xbm(A) が出力されています。

a Dtapps.bw.xbm(A) 1 tape blocks
 
a Dtapps.bw.xbm 2 tape blocks
 
a FrontPanel.Workspace.admin.menu.rs(A) 1 tape blocks
 
a FrontPanel.Workspace.admin.menu.rs 593 tape blocks

Trusted Solaris で追加された `tar` のオプション

それぞれのファイルのセキュリティ属性の保管と抽出のために、-T オプションが追加されました。また、Trusted Solaris 1.x の tar ファイルからセキュリティ属性を抽出するために、-d オプションが追加されました。この d オプションは、-T および -x オプションと一緒に使用します。

`-T` オプション

-c オプション、-r オプション、-u オプションと一緒に -T オプションを使用すると、tar はディレクトリの MLD 情報と SLD 情報を含む各ファイルのセキュリティ属性を保管します。-x オプションと一緒に -T オプションを使用すると、tar はそのファイルとともにセキュリティ属性も抽出します。

-t オプションと一緒に -T を使用すると、tar ファイルの内容は、1 つのアーカイブファイルを 1 行として、また 1 つの補助ファイルを 1 行として表示されます。

T オプションを x オプションと一緒に使用して、tar ファイルを抽出する場合、tar プログラムは MLD 情報と SLD 情報、拡張されたセキュリティ属性を使って、それぞれのアーカイブファイルを復元します。

`-d` オプション

-d オプションは、tar ファイルが Trusted Solaris 1.x 形式である場合に使用します。-d オプションは、-t オプション、-T オプション、-x オプションと一緒に使用する場合にのみ有効になります。-t および -T と一緒に -d オプションを使用すると、Trusted Solaris 1.x 形式の tar ファイルの内容が、各補助ファイルおよびアーカイブされたファイルごとに 1 行として表示されます。

-d オプションを -x オプションと一緒に使用して tar ファイルを抽出する場合、tar プログラムは Trusted Solaris 1.x の形式に従って入力 tar ファイルを処理します。x および T と一緒に -d オプションを使用すると、Trusted Solaris システム上で有効な、適切な MLD 情報と SLD 情報、そしてその他の拡張されたセキュリティ属性は、アーカイブされた各ファイルが復元された時点で適用されます。

-c と一緒に -d オプションを使用すると、その他の情報とともに tar ファイルの中に ACL が作成されます。

注 -

ACL を含む tar ファイルが前のバージョンの tar によって抽出されると、エラーが発生します。

「テープデバイスの割り当てと、tar を使ってテープに書き込む情報のセキュリティ属性を保管する方法」では、-cT オプションを指定した tar を使って、拡張されたセキュリティ属性を保管する tar ファイルを作成する方法を説明しています。詳細については、tar(1) のマニュアルページを参照してください。

以前のバージョンのTrusted Solaris オペレーティング環境で作成されたファイルの抽出

tar ファイルを抽出する際には、その tar ファイルが作成されたときに有効であった label_encodings(4) ファイルと現在インストールされている label_encodings ファイルとの間に互換性がなくてはなりません。Trusted Solaris 1.x の tar ファイルが Trusted Solaris 2.5 またはそれ以降のシステム上で復元された場合、SYSTEM_HIGH ラベルは ADMIN_HIGH ラベルに、SYSTEM_LOW ラベルは ADMIN_LOW ラベルにマップされます。Trusted Solaris 1.x での特権とファイル監査マスクは復元されたファイル上には適用されません。これは、Trusted solaris 1.x の特権とファイル監査マスクの形式が、Trusted Solaris の以降のバージョンでの同等のセキュリティ属性に対して互換性を持っていないためです。

デバイス関連のコマンドとデータベース

次のコマンドとデータベースに関しては、マニュアルページを参照してください。

表 15-5 デバイス関連のコマンドとデータベース


コマンドまたはファイル名	説明
`allocate(1M)`	デバイス割り当てのコマンド行インタフェース
`add_allocatable(1M)`	`device_allocate(4)`、`device_maps(4)` にデバイスを追加し、`/etc/security/dev` に補助ファイルを作成
`deallocate(1M)`	デバイス割り当て解除のコマンド行インタフェース
`device_clean(1M)`	デバイス clean プログラム
`dminfo(1M)`	`device_maps` ファイル内の指定したデバイスエントリに関するレポートを作成
`list_devices(1M)`	`device_maps` ファイル内で指定したデバイスのリストを表示
`remove_allocatable(1M)`	`device_allocate`、`device_maps` からデバイスを削除し、`/etc/security/dev` から補助ファイルを削除
`device_allocate(4)`	割り当て可能デバイスと一部の割り当て不可能デバイスを管理するためのデータベース
`device_maps(4)`	デバイスを割り当て可能にしたり、そのラベルを制限するために必要なデバイスエントリ用データベース

デバイス管理手順

テープデバイスの割り当てと、`tar` を使ってテープに書き込む情報のセキュリティ属性を保管する方法

この手順は、プロファイルの中に tar コマンドを持つユーザーであれば誰でも実行できます。

デバイス割り当てマネージャを使用して、テープデバイスを割り当てます。

この例では、mag_tape_0 と名付けられたデバイスを割り当てます。デバイスを割り当てる方法と、デバイスに割り当てるラベルを指定する方法の詳細は「Trusted Solaris ユーザーズガイド」を参照してください。

テープに現在のプロセスの機密ラベルを表示した物理的なラベルが付けられていることを確認し、プロンプトに応じてテープをテープデバイスに挿入します。

この例ではウィンドウは「Device Allocation for mag_tape0」という名前のウィンドウが表示されます。
st_clean: Insert tape into mag_tape0 st_clean: Make sure the tape is labeled CONFIDENTIAL Press RETURN to quit window...

-T セキュリティオプションを指定して、tar コマンドを実行します。

trusted% tar -cvT tartest
a tartest/(A) 1K
 
a tartest/ 0K
 
a tartest/file1(A) 1K
 
a tartest/file1 0K
 
a tartest/mld1/(A) 1K
 
a tartest/mld1/ 0K
 
a tartest/mld1/(A) 1K
 
a tartest/mld1/ 0K
 
a tartest/mld1/file50(A) 1K
 
a tartest/mld1/file50 1K
 
. . .

デバイス割り当てマネージャを使用してデバイスの割り当てを解除します。

プロンプトに応じて、デバイスからテープを取り出してください。
Please eject the tape in mag_tape_0

テープに入れられた情報が、テープに付けた物理ラベル上のセキュリティレベルで保護されるようにします。

新規デバイスへのポリシーの設定と既存デバイスのポリシーの修正

セキュリティ管理者役割になって、ADMIN_LOW ワークスペースに移動します。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

そのデバイスの名前 (driver_name)、マイナー名 (minor_name)、デバイス特殊ファイルの名前を決めます。

新しいデバイスに対しては、次のことを行います。

デバイス用のハードウェアのマニュアルを調べて、デバイス名、マイナー名、すべての物理的デバイス名を控えておきます。

『Writing Device Drivers』(800-6502) も参照してください。

/etc/security/device_maps ファイルにあるデバイスに対する新しいエントリを作成します。

デバイスには任意の名前を付けることができます。3 つめのフィールドには、そのデバイスに対する物理的デバイス名をすべてリストしてください。

cdrom_0:¥
        sr:¥
        /dev/sr0 /dev/rsr0 /dev/dsk/c0t6d0s0 /dev/dsk/c0t6d0s1
/dev/dsk/c0t6d0s2 /dev/dsk/c0t6d0s3 /dev/dsk/c0t6d0s4 /dev/dsk/c0t6d0s5
/dev/dsk/c0t6d0s6 /dev/dsk/c0t6d0s7 /dev/rdsk/c0t6d0s0 /dev/rdsk/c0t6d0s1
/dev/rdsk/c0t6d0s2 /dev/rdsk/c0t6d0s3 /dev/rdsk/c0t6d0s4 /dev/rdsk/c0t6d0s5
/dev/rdsk/c0t6d0s6 /dev/rdsk/c0t6d0s7:¥

この例は cdrom_0 デバイスに対するすべての物理デバイスと論理デバイスの名前を示しています。

既存のデバイスについては、デバイスをロング形式でリスト (ls-l)して、デバイス名とマイナー名を確認してください。
# ls -l /dev/dsk/c0t6d0s2 lrwxrwxrwx 1 root root 51 Feb 29 1998 /dev/dsk/c0t6d0s2 -> ../../devices/sbus@1f,0/SUNW,fas@e,8800000/sd@6,0:c
パス名の最後の部分にある、@ 文字の前の文字列 (上記の例の sd) は、ドライバー名で、コロンの後の文字列 (上記の例の c) はマイナー名です。

「管理用エディタ」アクションを使用して、編集用に /etc/security/tsol/device_policy ファイルを開きます。

必要に応じて、「管理用エディタアクションを使用してファイルを編集するには」を参照してください。

デバイスのデフォルトポリシーがサイトのセキュリティポリシーに合致しないときは、新しいデバイス用に固有のエントリまたはワイルドカードのエントリを作成するか、すでに指定されたデバイス用の既存のエントリを修正します。

次の表に、デフォルトのデバイスポリシーを示します。他のポリシー設定を指定する方法については、device_policy(4) マニュアルページを参照してください。

表 15-6 デフォルトのデバイスポリシー


ポリシーの種類	内容	デフォルトポリシー
`data_mac_policy`	デバイスへのアクセスに必要な SL	読み取りや書き込みを行うためには、プロセスの SL はデバイスの SL と必ず同等
`attr_mac_policy`	デバイス属性へのアクセスの処理方法 `acl(2)`、`chmod(2)`、`chown(2)`、 `stat(2)` を使用	デバイス属性への読み取りアクセスでは、プロセスの SL はデバイスの SL より優位。デバイス属性への書き込みアクセスでは、プロセスの SL はデバイスの SL と同等
`open_priv`	デバイスファイルを開く特権	なし
`str_type` `type`	STREAMS デバイスの場合のみ、カーネル STREAMS ヘッドによる STREAMS メッセージの制御方法を指定します。	デバイスタイプストリーム。ラベルなしの STREAMS メッセージも使用可能

ファイルの内容を書き込んで、エディタを終了します。

デバイス割り当てマネージャの「管理 (Administration)」ダイアログボックスを表示するには

セキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動します。あるいは、「デバイス属性を構成」 承認または 「デバイスを回収または再設定」 承認を持つユーザーとしてログインします。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

トラステッドパス (TP) メニューから「デバイスを割り当てる (Allocate Device)」オプションを選択するか、またはフロントパネルの「ツール (Tools)」サブパネルからデバイス割り当てマネージャ (Device Allocation Manager)を起動します。

「デバイスの管理 (Device Administration)」ボタンをクリックすると、デバイス割り当てマネージャの「管理 (Administration)」ダイアログボックスが表示されます。

目的のデバイスの名前を選択して強調表示にし、「状態 (State:)」フィールドでデバイスの状態を確認します。

デバイスの状態が「エラー状態」である場合、「割り当てエラー状態を解決するには」の処理を行なって、エラー状態を解決してください。

デバイスの状態が「割り当て済み (Allocated)」である場合、次のいずれかの処理を行います。
1. デバイスの割り当て解除を行うように所有者に連絡します。
2. 「デバイス割り当てを強制解除するには」の処理を行なって、割り当てを解除します。

デバイスを構成するには、「既存のデバイスを構成するには」の処理を行います。

割り当てエラー状態を解決するには

セキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動します。あるいは、「デバイスを回収または再設定」 承認を持つユーザーとしてログインします。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

デバイス割り当てマネージャの「管理 (Administration)」ダイアログボックスを開きます。

必要に応じて、「デバイス割り当てマネージャの「管理 (Administration)」ダイアログボックスを表示するには」を参照してください。

デバイス名を強調表示にします。

「状態 (State)」フィールドに「エラー状態」と示されている場合、「再利用 (Reclaim)」をクリックし、エラー状態を回復します。

「了解 (OK)」をクリックして変更を保存し、ダイアログボックスを閉じます。

デバイス割り当てを強制解除するには

セキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動します。あるいは、「デバイスを回収または再設定」 承認を持つユーザーとしてログインします。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

デバイス割り当てマネージャの「管理 (Administration)」ダイアログボックスを開きます。

必要に応じて、「デバイス割り当てマネージャの「管理 (Administration)」ダイアログボックスを表示するには」を参照してください。

デバイス名を強調表示にします。

「状態 (State)」フィールドに「割り当て済み (Allocated)」と示されている場合、「解除 (Revoke)」をクリックし、強制的にデバイスの割り当てを解除します。

「了解 (OK)」をクリックして変更を保存し、ダイアログボックスを閉じます。

新しい割り当て可能デバイスまたは割り当て不可能デバイスを追加するには

必要に応じて、Solaris の『Installing Device Drivers』マニュアルの指示に従って処理を行い、次に、Trusted Solaris 固有の手順を実行します。

新しい割り当て可能デバイスを追加する場合、必要に応じてデバイス clean スクリプトを作成します。

Xylogics テープドライブまたは Archive テープドライブの場合は、デフォルトの st_clean スクリプトをそのまま使用するか、サイトのセキュリティポリシーに合わせて修正することができます。それ以外のデバイスの場合には、新しいデバイス clean スクリプトが必要です。必要に応じて「デバイス clean スクリプトを変更・追加するには」を参照してください。

セキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動します。あるいは、「デバイス属性を構成」 承認を持つユーザーとしてログインします。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

「割り当て可能なデバイスの追加 (Add Allocatable Device)」アクションを実行します。

必要に応じて、「管理アクションを起動するには」を参照してください。

「割り当て可能なデバイスの追加 (Add Allocatable Device)」アクションを使って、デバイス割り当てデータベースのデバイス用のエントリの作成または更新を行い、補助ファイルを作成します。
1. デバイスの名前を入力します。
2. デバイスの種類を入力します。
3. そのデバイスに関連するすべてのデバイス特殊ファイルのパス名をスペースで区切って入力します。
4. 入力内容を保存し、終了します。

ラベル範囲、デバイス clean スクリプトのパス名、デバイス割り当ての可否、割り当てに必要な承認などのデフォルト設定を変更するには、デバイス割り当てマネージャの「管理 (Administration)」ダイアログボックスを使用します。

必要に応じて、「デバイス割り当てマネージャの「管理 (Administration)」ダイアログボックスを表示するには」を参照してください。

次の表は、「割り当て可能なデバイスの追加 (Add Allocatable Device)」アクションを使用してデバイスを追加したときや、 add_allocatable(1M) コマンドを使用して作成されたデバイスに値が指定されなかったときに有効になるデフォルト値を示します。

表 15-7 デバイスのデフォルト値


値	デフォルト
最下位のラベル	`ADMIN_LOW`
最上位のラベル	`ADMIN_HIGH`
clean プログラム	`/bin/true`
割り当てを行えるユーザー	すべてのユーザー (All Users)
承認	なし (None)

既存のデバイスを構成するには

注 -

デバイス割り当てマネージャを使用して管理するには、device_maps(4) ファイルと、device_allocate(4) ファイルにデバイスのエントリがあり、/etc/security/dev ディレクトリに補助ファイルがあることが必要です。必要に応じて、「新しい割り当て可能デバイスまたは割り当て不可能デバイスを追加するには」の処理を行なってください。

セキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動します。あるいは、「デバイス属性を構成」 承認を持つユーザーとしてログインします。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

デバイス割り当てマネージャの「管理 (Administration)」ダイアログボックスを開きます。

必要に応じて、「デバイス割り当てマネージャの「管理 (Administration)」ダイアログボックスを表示するには」を参照してください。

設定したいデバイスの名前を選択し、「構成 (Configure)」ボタンをクリックします。

下の図に示されているように、デバイス割り当てマネージャの「構成 (Configuration)」ダイアログボックスが表示されます。

最下位機密ラベルのデフォルト ADMIN_LOW を変更する必要がある場合は、「最下位のラベル (Min Label)」ボタンをクリックし、ラベルビルダーで新しいラベルを指定します。

最上位機密ラベルのデフォルト ADMIN_HIGH を変更する必要がある場合は、「最上位のラベル (Max Label)」ボタンをクリックし、ラベルビルダーで新しいラベルを指定します。

device_clean(1M) スクリプトの名前を変更する必要がある場合は、「clean プログラム」フィールドに新しいパス名を入力します。

「割り当てを行えるユーザー (Allocatable By)」フィールドを変更する必要がある場合は、マウスの右ボタンでメニューを開いて、次の 3 つの選択肢のうちいずれかを選択します。
承認されたユーザー (Authorized users) すべてのユーザー (All users) なし (No users)
注意 -
プリンタ、フレームバッファー、その他の割り当て可能にできないデバイスを設定するときは、このフィールドで必ず「なし (No users)」を指定してください。デバイスが「割り当てを行えるユーザー: 承認されたユーザー」のように指定されている場合、「承認 (Authorizations)」ボタンが使用可能になり、「承認 (Authorizations)」フィールドにはデフォルトで「デバイスを割り当てる (allocate device)」が表示されます。

必要に応じて、新しいデバイスを割り当てるための承認を追加します。

新しい承認を追加する方法については、「拡張可能なセキュリティ機能の追加」を参照してください。システムに新しい承認を追加すると、次にデバイス割り当てマネージャの「承認 (Authorizations)」ダイアログボックスが表示されるときに、「必須でない (Not Required)」リストにその承認が表示されます。「承認 (Authorizations)」ボタンは、デバイスが「割り当てを行えるユーザー: 承認されたユーザー」のように指定されている場合のみ使用可能になります。「承認 (Authorizations)」フィールドのデフォルトは、「デバイスを割り当てる」です。

必要に応じて、デフォルトの「デバイスを割り当てる」承認を変更します。
1. 「承認 (Authorizations)」ボタンをクリックします。
  
  デバイス割り当てマネージャの「承認 (Authorizations)」ダイアログボックスが表示されます。
2. デフォルトの「デバイスを割り当てる」承認を削除する必要がある場合は、「必須 (Required)」リストで承認を選択し、左矢印ボタンで「必須でない (Not Required)」リストに移動させます。
3. 承認を追加したり、削除した承認を置き換える必要がある場合は、「必須でない (Not Required)」リストで承認を選択し、右矢印ボタンで「必須 (Required)」リストに移動させます。
4. 「了解 (OK)」をクリックして変更内容を保存し、「承認 (Authorizations)」ダイアログボックスを閉じます。

デバイス割り当てマネージャを終了します。
1. 「構成 (Configuration)」ダイアログボックスで「了解 (OK)」をクリックして変更内容を保存し、ダイアログボックスを閉じます。
2. 「管理 (Administration)」ダイアログボックスで「了解 (OK)」をクリックしてダイアログボックスを閉じます。
3. デバイス割り当てマネージャの左上角のマイナス (-) をダブルクリックして終了します。

必要に応じて、デバイスにデフォルト以外のポリシーを設定します。

デフォルトポリシーの変更方法については、「新規デバイスへのポリシーの設定と既存デバイスのポリシーの修正」を参照してください。

アカウントにデバイス関連の承認を割り当てるには

セキュリティ管理者役割になり、ユーザーマネージャを起動します。

必要に応じて、第 1 章「特定の役割への移行と役割ワークスペースでの作業」および「管理アプリケーションを起動するには」第 5 章「ユーザーマネージャを使ったアカウントの設定」を参照してください。

「プロファイル (Profiles)」ボタンをクリックしてプロファイルダイアログボックスを開き、ユーザーの実行プロファイルのいずれかに、必要なデバイス割り当て承認やその他のデバイス関連承認が含まれていることを確認します。

必要に応じて、デバイス割り当て承認を含むプロファイルを「利用可能 (Available)」リストに移動します。

デフォルトが変更されていない場合は、次の表に示すプロファイルの 1 つをユーザーのプロファイルリストに追加すると、そのユーザーに「デバイスを割り当てる」承認が与えられます。

表 15-8 デフォルトデバイス割り当て承認とそれを含むデフォルトプロファイル


承認の目的	承認名	デフォルトプロファイル
デバイス割り当て	デバイスを割り当てる	All Authorizations
		Convenient Authorizations
		Device Management
		Media Backup
		Media Restore
		Object Label Management
		Software Installation

必要に応じて、「デバイスを回収または再設定」承認を含むプロファイルを「利用可能 (Available)」リストに移動します。

注 -

「デバイスを回収または再設定」承認は、管理プロファイルにあります。管理役割アカウント以外には付与しないでください。

次の表に、「デバイスを回収または再設定」承認とそれを含むデフォルトのプロファイルを示します。

表 15-9 「デバイスを回収または再設定」承認、それを含むデフォルトのプロファイル、それを割り当てるデフォルトの役割


承認の目的	承認名	デフォルトプロファイル	プロファイルを割り当てるデフォルトの役割
デバイスの割り当ての強制解除、またはデバイスの割り当てエラー状態の訂正	デバイスを回収または再設定	Device Management All Authorizations	セキュリティ管理者役割デフォルトでは割り当てられない

必要に応じて、「デバイスを回収または再設定」承認を含むプロファイルを「利用可能 (Available)」リストに移動します。

次の表に、「デバイスを回収または再設定」承認とそれを含むデフォルトのプロファイルを示します。

表 15-10 「デバイスの属性を構成」承認、それを含むデフォルトのプロファイル、それを割り当てるデフォルトの役割


承認の目的	承認名	デフォルトプロファイル	プロファイルを割り当てるデフォルトの役割
デバイスの device_clean スクリプト、ラベル範囲、必要な属性など、各属性を設定する	`デバイスの属性と構成`	Device Security Printer Security All Authorizations	セキュリティ管理者役割セキュリティ管理者役割デフォルトでは割り当てられない

注 -

デフォルトの実行プロファイルの中に、再構成するアカウントに適切なものがない場合、セキュリティ管理者役割が、デバイス割り当ての承認を含む新しいプロファイルを作成することができます。このプロファイルには、デバイス割り当ての承認だけを含めることも、プロファイルのユーザーが目的の作業を行うために必要な他のコマンド (allocate、deallocate、tar などなどのコマンド) を一緒に含めることもできます。新しいプロファイルの作成方法については、本書の第 8 章「ユーザーおよび役割のための実行プロファイルの管理」で説明しています。

割り当ての後、ファイルマネージャが自動表示されないようにするには

セキュリティ管理者役割になって、ADMIN_LOW ワークスペースに移動します。

必要に応じて、「ログイン後、特定の管理役割になるには」を参照してください。

「管理用エディタ」アクションを使って編集用に rmmount.conf ファイルを開きます。

必要に応じて、「管理用エディタアクションを使用してファイルを編集するには」を参照してください。

CD-ROMとフロッピーのどちらか、または両方の設定をファイルマネージャを通知するために、アクションをコメントアウトにします。

この例では CD-ROM とフロッピーデバイスの両方について、action_filemgr.so を含む行がコメントアウトにされています。
# action cdrom action_filemgr.so # action floppy action_filemgr.so

デバイス clean スクリプトを変更・追加するには

物理デバイス中のすべての使用可能データを消去し、正常終了時に 0 を返すスクリプトを記述します。

取り外し可能な媒体を使用するデバイスについては、ユーザーが媒体を取り出していない場合、スクリプトで取り出すようにし、媒体が取り出されないときは、その媒体を割り当てエラー状態にするようにします。

このスクリプトを ADMIN_LOW で /etc/security/lib ディレクトリに格納します。

デバイス割り当てマネージャを使用して、デバイスに新しいスクリプトを指定します。
1. ADMIN_LOW ワークスペースで、システム管理者としてデバイス割り当てマネージャを起動します。
  
  トラステッドパス (TP) メニューの「デバイスを割り当てる (Allocate Device)」オプションを選択するか、フロントパネルの「ツール (Tools)」サブパネルから「デバイス割り当てマネージャ (Device Allocation Manager)」を起動します。
2. 「デバイスの管理 (Device Administration)」ボタンをクリックしてデバイス割り当てマネージャの「管理 (Administration)」ダイアログボックスを表示します。
3. 「デバイス (Devices)」リストで、新しいスクリプトを割り当てるデバイスの名前をポイントし、強調表示にします。
4. 「構成 (Configure)」ボタンをクリックしてデバイス割り当てマネージャの「構成(Configuration)」ダイアログボックスを表示します。
5. device_clean(1M) スクリプトの名前を変更する必要がある場合は、「clean プログラム」の右側のテキスト入力フィールドの名前を編集します。
6. 「構成 (Configure)」ダイアログボックスで「了解 (OK)」をクリックし、ラベルの変更を保存します。次に、「管理 (Administration)」ダイアログボックスで「了解 (OK)」をクリックしてダイアログボックスを閉じてから、デバイス割り当てマネージャを終了します。

第 16 章ソフトウェアの追加

この章では、次の項目について説明します。

この章では、次の操作手順について説明します。

用語と概念の確認

セキュリティ管理者は、次のタイプのソフトウェアを追加することができます。

Trusted Solaris のセキュリティポリシーを認識したり施行したりしないサンの別パッケージの製品やサン以外のアプリケーション
Trusted Solaris プログラミングインタフェースを使用して作成したラベルと MAC (必須アクセス制御) を認識し、Trusted Solaris セキュリティポリシーの範囲内で動作する新しいプログラム
新しいアクション (セキュリティ管理者役割によって作成、または認可されたもの)
シェルスクリプト (セキュリティ管理者役割によって作成、または認可されたもの)
セキュリティ管理者は、実行制御スクリプトに、起動時に実行されるコマンドを追加したり、修正することができます。

この章では、Trusted Solaris システムで使用する、コマンド、アクション、スクリプトの作成方法や使用方法が、標準 Solaris の場合とどう違うかをまとめています。また、特権がコマンドやアクションによってどのように使用されるかを確認し、次の作業を行う方法を紹介します。

新しいソフトウェアを導入する
ソフトウェアの実行に特権が必要な場合、必要な特権を検出する
新しいソフトウェアに必要な特権を与えることがサイトのセキュリティポリシーと矛盾しないかどうかを判断する
ソフトウェアが特権を使用できるようにする
実行制御スクリプト内のコマンドが特権を使用できるようにする

プログラマーが特権を使用する方法については、『Trusted Solaris 開発ガイド』を参照してください。

デフォルトのシステム構成では、セキュリティ管理者役割とシステム管理者役割の両方が、次の処理を行えます。

複数の機密ラベルでソフトウエアをインポートまたはエクスポートする
公共のディレクトリ (/etc や /usr/binなど) 内に ADMIN_LOW でソフトウェアをインストールし、複数のユーザーがあらゆる機密ラベルでソフトウェアを使用できるようにする
プログラムファイルに特権を付与する。この権限は、必要な承認を割り当てれば、他のアカウントに付与することもできる
プロファイルマネージャを使用して、トラステッドプロセスでコマンドやアクションが実行されるときに有効になる特権を割り当てる。このとき、コマンドやアプリケーションはトラステッドプロセスから特権を継承している

注 -
外部または内部から取得したアプリケーションやシェルスクリプトは、コマンドとしてサイトの実行プロファイルに追加されるため、この章では、アプリケーション、サイトで開発された実行可能プログラム、シェルスクリプトのこともコマンドといいます。

コマンドに特権を付与すること、コマンドやアクションが特権を継承するということについては、「特権」と、次の節の定義を参照してください。

通常、プログラムやスクリプトのインポート、作成、使用の前に、セキュリティ管理者役割による審査は必要ありません。ただし、そのソフトウェアが次の条件を満たしている場合に限ります。

実行時、特権を使用しない
起動したユーザーの実際の UID または GID と同じ実効 UID または GID を使用する
シングルラベルで実行する

ソフトウェアの作成と使用の制限

セキュリティ管理者役割は、デフォルトのシェルとしてプロファイルシェルをユーザーに割り当てることによって、プログラム、アクション、およびスクリプトを作成できるユーザーを制御できます。All Commands プロファイルは、すべてのコマンドへのアクセスを許可します。All Actions プロファイルは、すべてのアクションへのアクセスを許可します。All プロファイルは、すべてのコマンドおよびアクションへのアクセスを許可します。

ユーザーまたは役割アカウントが「アクション作成 (Create Action)」アクションなどのファイル編集ツールへのアクセス権を持っていない場合、そのアカウントはアクションを作成できません。アカウントがアクションを作成できる場合でも、セキュリティ管理者役割の協力がなければ、アカウントは新しいアクションを使うことができません。すべてのユーザーが新しいアクションを使えるようにするには、セキュリティ管理者役割は、そのアクションを 1 つまたは複数のプロファイルに追加し、そのプロファイルをアカウントに割り当てる必要があります。あるいは、セキュリティ管理者役割は、All プロファイルまたは All Actions プロファイルのいずれかをアカウントに割り当てることもできます。

ソフトウェアのインポートの制限

同様の機構が、プログラム、アクション、スクリプトのインポートを制御するためにも用意されています。セキュリティ管理者は、個々にデバイスの割り当て承認を付与したり取り消したりすることで、ソフトウェアを導入できるユーザーを制御します。デバイスの割り当て承認を付与されたアカウントの場合、データのインポートまたはエクスポートを認可上限内の単一機密ラベルに制限されます。

特権

特権を持っているということは、セキュリティポリシーのある面を無効にする権限があるということです。

標準の UNIX システムでは、ユーザー ID 0 で実行されるコマンドにはスーパーユーザーの全権限があるのに、それ以外のユーザー ID で実行されるコマンドには権限がありません。一方 Trusted Solaris システムでは、どのユーザー ID を使用するコマンドでも、標準の UNIX システムのスーパーユーザーに割り当てられた権限の一部を使用するように構成することができます。 Trusted Solaris システムでは、UNIX のスーパーユーザーの権限 (アクセス制限の回避、制限されたコマンドの実行、他のユーザーが使用できないコマンドオプションの使用など) は、特権に置き換えられます。標準 Solaris のオペレーティング環境やその他の UNIX オペレーティングシステムのスーパーユーザーが、すべての DAC 制限を回避する権限をはじめ、システム内のすべての特権を持っているのに対し、Trusted Solaris の特権機構では、スーパーユーザーの権限を細分化し、MAC 制限を回避するために必要な補助的な権限を提供します。特権を個々に付与することで、プログラムに不要な特権は付与せず、作業上必要な特権だけを割り当てます。

必須特権

コマンドやそのオプション、アクションなどを正しく実行するために特権が必要な場合、その特権を必須特権といいます。必須特権を使用できない場合は、コマンド、オプション、アクションは全く動作しません。必須特権は、次の文に示すように、マニュアルページ上では、「必要です (must have)」という言葉で表されます。「ifconfig(1M)コマンドには、ネットワークインタフェースを変更するためのsys_net_config 特権が必要です。」

無効化特権

コマンドまたはアクションがセキュリティポリシー内で動作するように設計されていて、特定の DAC または MAC の検査に合格しないとエラーになるときは、セキュリティ管理者役割の判断で、無効化特権を割り当てることができます。アクセス制限を無効化するために使用される特権の名前は、マニュアルページ上では、「エラー (ERRORS)」の節に記述されています。

DAC 無効化特権は、file_dac_read と file_dac_write です。MAC 無効化特権は、file_mac_read と file_mac_write です。セキュリティ管理者役割は、ユーザーがファイルへの DAC または MAC アクセス権を持っていない場合、どちらのアクセス権を適用するか、読み取り、書き込みのどのアクセス権が必要かによって、コマンドやアクションにこれらの無効化特権の 1 つまたは両方を割り当てることができます。

特権の割り当て以外の方法

コマンドまたはアクションを実行するためには、無効化特権を割り当てる以外の方法もあります。セキュリティ管理者役割は、次のオプションを利用することができます。

実効 UID を割り当てる
実効 GID を割り当てる
コマンドが実行するラベル範囲を制限するための、あるいは、単一ラベルに制限するための機密ラベルを割り当てる

セキュリティ管理者役割は、特権の使用を避けるために、コマンドやアクションが他のユーザー ID や代替グループ ID を使用して実行されるように構成したり、他の ID のアクセス権や ACL に基づいてファイルまたはディレクトリにアクセスするように設定します。呼び出したユーザーの実際の UID (GID) 以外の UID (GID) を使ってソフトウェアを実行することを、「実効 UID (GID) を使って実行する」といいます。コマンドやアクションが MAC 無効化特権を付与する必要のない機密ラベルで実行されるように指定することもできます。

最少特権の法則

最少特権の法則とは、システム内の各コマンドまたはアクションに、ユーザーが作業を行うために必要な最低限の特権しか付与しないことを言います。具体的な方法としては、プログラムに必要なときだけ特権を使用できるようにしたり、特権ブラケットを使用することが考えられます。特権ブラケットとは、プログラムの特権の使用・不使用を切り換えるためにプログラム内で使用するものです。特権ブラケットを使用すると、特権は、プログラムの実行中、特定の目的のために使用されている間しか有効になりません。特権ブラケットの詳細は、『Trusted Solaris 開発ガイド』参照してください。

ファイル特権セット

実行可能プログラムファイルには、「強制された特権」と「許容された特権」の 2 つのファイル特権セットを割り当てることができます。「許容セット」とは、プログラムが使用を許可される特権のセットです。「強制セット」はプログラムを実行するシェルやユーザーに関係なく常に使用可能な特権のセットです。

Trusted Solaris で 2 つの標準プログラムが特権を使用する方法

ls(1)、mount(1M) が特権を使用する方法を例に挙げて、これまでに説明した法則の一部についてわかりやすく説明します。

lsは、一般的なプログラムの 1 つです。DAC 制限と MAC 制限によって参照することが許可されているファイルを一覧表示する場合であれば、このプログラムに特権は必要ありません。つまり、ls には必須特権はありません。ただし、何らかの理由で、ls が DAC または MAC のセキュリティポリシーを回避する必要がある場合は、セキュリティ管理者役割によって、無効化特権が割り当てられます。

一般ユーザーが自分のコンピュータにマウントされているファイルシステムを確認する目的で実行する場合、mount(1M) には特権は必要ありません。けれども、mount コマンドでファイルシステムをマウントする場合は、sys_mount 特権が必ず必要になります。つまり、sys_mount は mount の必須特権です。リモート操作でファイルシステムをマウントするために使用するのか、マウント時のセキュリティ属性を指定するために使用するのかによって、いくつかの無効化特権が必要になることもあります。デフォルトの設定では、mount の実行可能プログラムファイルには、すべての「許容された特権」が指定され、「強制された特権」は一切指定されていません。デフォルトでシステム管理者役割に割り当てられる System Management プロファイルには、ファイルシステムをマウントするときに mount が継承する必要のあるすべての特権が定義されています。mount の特権要件に関する詳細は、mount(1M) マニュアルページを参照してください。

アクション

アクションとは、CDE からアクセスできる機能のことです。Trusted Solaris 環境でも広範囲にわたるアクションを使用できますが、その使用法や作成法には、いくつかの制限があります。これは、Trusted Solaris セキュリティポリシーとの互換性を保つためです。アクションの使用上および作成上の制限については、「アクションを追加する場合」で説明します。

アクションとは、各種作業を自動化するために書かれた指示「アプリケーションの編集や実行のためにファイルを開く」などのことです。アクションは、アプリケーションマクロやプログラミング関数とほぼ同様に定義され、アクションごとに、実行時に使用する名前が定義されます。アクションは、アイコン、フロントパネル上のアイテム、メニューアイテムに割り当てられます。

コマンドやアクションの使用に対する実行プロファイル

セキュリティ管理者役割は、アカウントの実行プロファイルに次のいずれかを指定することにより、そのアカウントがシステムのセキュリティポリシーを回避できるようにします。

承認
特定のコマンドまたはアクションに割り当てられた特権
特定のコマンドまたはアクションに割り当てられた実効 UID (実効 GID)

実行プロファイルに指定された特権は、コマンドやアクションに継承され、使用可能になります。

コマンドは、特権を継承し、プロファイルシェルかシステムシェル内で呼び出される場合に限って、このコマンドを呼び出したユーザーのプロファイルに指定された実効 UID (GID) や機密ラベルを使用して実行されます。
アクションは、特権を継承し、ウィンドウシステムのトラステッドプロセスから起動された場合に限って、実効 UID (GID) や特定の機密ラベルを使用して実行されます。これについては、「プロファイルシェル、システムシェル、トラステッドプロセス」で説明します。

ユーザーアカウントには、All プロファイルを付与することができます。こうすると、そのアカウントは標準の UNIX ユーザーと同様、すべてのアクションやコマンドに自由にアクセスすることができるようになります。ただし、このとき「継承可能な特権」は与えられません。

標準の UNIX シェルがデフォルトシェルである場合、または、プロファイルの 1 つに標準 UNIX シェルが記述されている場合、ユーザーはそのシェルで使用できるすべてのコマンドを実行することができます。ただし、継承可能な特権は与えられません。また、アカウントのプロファイルに設定されているアクションの内容によっては、すべてのアクションを起動できないことがあります。ユーザーや役割アカウントは、All または All Action プロファイルを割り当てられている場合以外は、自分の実行プロファイルに明示的に指定されているアクションセットしか使用できません。一方、ユーザーや役割アカウントが使用できるコマンドはアカウントのプロファイルに記述されているコマンドのみとなります。ただし、アカウントのデフォルトシェルがプロファイルシェルである場合に限ります。

1 つのアカウントには、複数のプロファイルを割り当てることができます。この場合、プロファイルを割り当てる順序が重要で。これは、ウインドウシステム内のプロファイルシェルやトラステッドプロセスが、ユーザーマネージャで指定されている順序でプロファイルを検索するからです。プロファイルシェルやトラステッドプロセスは、複数のプロファイルやコマンドを検索してアクションを検出します。そして、コマンドやアクションには、それが検出された最初のプロファイルに割り当てられているセキュリティ属性が付与されます。

たとえば、表 16-1 に示す、roseanne というアカウントのプロファイルセットには、プロファイルが、All、A、B、C の順で割り当てられています。

表 16-1 アカウントリスト内の誤った順番のプロファイルの例


アカウント名	デフォルトシェル	プロファイル	コマンド
roseanne	pfsh	All	inheritable privs=none が指定されたすべてのコマンド
		プロファイル A	inheritable privs=1,2,3 が指定された `command1`
		プロファイル B	inheritable privs=2,3,5 が指定された `command1`
		プロファイル C	inheritable privs=7,9, 12 が指定された `command1`

roseanne が command1 を実行すると、プロファイル機構により、検索がスタートします。すると、まず All プロファイルが検出され、ここで検索が終了します。All プロファイルには、特殊な属性なしで任意のコマンドの使用を許可する働きがあり、ここで、roseanne は、特権またはその他の特別な属性なしでコマンドを実行できるようになります。command1 に特権 7、9、12 が付与されていなければ roseanne の作業が失敗する場合は、セキュリティ管理者役割が、プロファイル C を roseanne のプロファイルリストの先頭 (All プロファイルの前) に移動させます。

All プロファイルを割り当てる場合は、アカウントのプロファイルリストの最後に設定し、コマンドの代替機構として働くようにします。すると、アカウントの他のプロファイルにコマンドが明示的に指定されていなくても、特権、実効 UID (GID)、指定された機密ラベルなしで、任意のコマンドを使用することができます。

プロファイルシェル、システムシェル、トラステッドプロセス

プロファイルシェル pfsh(1M) は、セキュリティ管理者役割、システム管理者役割およびスーパーユーザー役割のデフォルトのシェルです。ただし、セキュリティ管理者役割の判断により、プロファイルシェルを他のユーザーまたは役割アカウントのデフォルトシェルとして割り当てることもできます。プロファイルシェルで作業しているアカウントは、自分の実行プロファイルに指定されているコマンド以外は使用できません。

システムシェル sysh(1M) は、実行制御 (rc) スクリプトから実行されるコマンドによって、特権の使用を制御することができます。sysh は、すべてのコマンドの実行を許可しますが、コマンドの実行時に使用する特権、実効ユーザー ID、実効グループ ID、機密ラベルについては、プロファイルで確認します。sysh に関する詳細は、「ブート時にコマンドを実行するには」を参照してください。

ウィンドウシステムのトラステッドプロセスには、次のものがあります。

フロントパネル
フロントパネルのサブパネル
ワークスペースのメニュー
ファイルマネージャ
アプリケーションマネージャ

ウィンドウシステム内のトラステッドプロセスは、だれでも使用できます。ただし、ウィンドウシステムからアクセスできるアクションは、自分の実行プロファイルに指定されたアクションのみです。たとえば、アプリケーションマネージャの「システム管理 (System_Admin)」フォルダにある一連の管理アクションは、アカウントのプロファイルに指定されている場合に限って使用できます。したがって、デフォルトではセキュリティ管理者役割は、セキュリティ管理者役割に割り当てられている Object Label プロファイル内の「エンコーディングの編集 (Edit Encodings)」アクションを使用できますが「マウント・ポイントの設定 (Set Mount Points)」アクションを使用することはできません。

ファイルマネージャでは、アカウントのプロファイルに指定されていないアクションのアイコンは表示されません。ワークスペースのメニューには、アカウントのプロファイルに指定されていないアクションも表示されますが、そのアクションを呼び出すとエラーになります。

CDE ウィンドウマネージャー dtwm(1) は、Xtsolusersession スクリプトを呼び出します。このスクリプトをウィンドウマネージャーと組み合わせて使用すると、ウィンドウシステムで起動しアクションを呼び出すことができます。ユーザーがコマンドを実効する際にプロファイルシェルがユーザーのプロファイルを調べるのと同様、 Xtsolusersession も、アクションの起動時に、ユーザーのプロファイルを調べます。このときアクションがユーザーのプロファイルに指定されていれば、そのアクションはユーザーのプロファイル内で指定されているそのアクションのための特権、実効 UID、実効 GID などの属性を使用して実行されます。

プロセス、プログラム、その特権

プロセスは、実行可能プログラムが格納されているファイルから派生し、常にプログラムを実行しています。プロセスは、fork(2) システムコールを使用して作成されます。 fork(2) とは、呼び出し元プロセスの複製を作成するシステムコールです。こうして作成された新しいプロセスは、現在実行中のプログラムを含め、親の属性をすべて継承します。また、プロセスは、exec(2) システムコールを使用して、実行中のプログラムを変更することができます。このシステムコールには、プロセスのアドレス空間全体を、exec コールで指定されたプログラムファイルから派生した新しいバージョンに置き換える働きがあります。

たとえば、pfsh というプロファイルシェルを実行しているプロセスで exec を使用し、mount コマンドを実行することができます。

プロセス特権セット

各プロセスには、次の 4 種類の特権セットが割り当てられます。

許可セット (P)

そのプロセスが使用を許可されている特権のセットです。
有効セット (E)

プロセスが現在使用している特権のセットです。特権をチェックするシステムコールによってチェックされます。
継承可能セット (I)

exec(2) によって新しい別のプログラムが呼び出された際に、新しいプロセスに引き渡す特権のセットです。

新しいプログラムを呼び出すとき、継承可能特権セットは最初、現在のプログラムを呼び出したプロセスと同じ継承可能特権に設定されます。
I[new]=I[old]
保存セット (S)

「保存セット (S)」には、最初は、「既存の継承可能セット」とファイルの「許容された特権」に共通する特権が設定されます。
S=(I[process] intersected by A)

プロセスが execve(2) システムコールを使用してプログラムを実行すると、「許可セット (P)」と「有効セット (E)」は、プログラムファイルの「許容された特権 (A)」、「強制された特権 (F)」、プロセスの以前に存在していた「継承可能な特権 (I)」のすべてを集めた特権のセットになります。

P=E=(I[process] union F[program] restricted by A[program])

実行中のプログラムの「強制された特権」または「許容された特権」を参照せずに「継承可能な特権」を設定する利点については、「継承可能な特権が重要な理由」を参照してください。

setuid(2) によって元の UID とは異なる実効 UID が設定された場合、「有効セット (E)」が「保存セット (S)」にコピーされ、「有効セット (E)」は消去されます。

S=E; E=0

プロセスが実効ユーザー ID を元の値に戻すと、「保存セット (S)」が「有効セット (E)」にコピーされ、特権の状態が復元されます。

E=S

プロセスが特権を獲得する方法の例

次の例では、プログラムの実行時にプロセスが特権を獲得する方法を標準の UNIX シェルの場合とプロファイルシェルの場合で比較しています。標準の UNIX シェルで実行される場合、プログラムのプロセスが使用できるのは、プログラムの「強制セット」と「許容セット」両方に (共通に) 含まれる特権だけです。プロファイルシェルで実行される場合、プログラムのプロセスは、シェルの「継承可能セット」から特権を獲得し、このうちプログラム自身の「許容セット」と共通の特権を使用することができます。説明を簡潔にするため、例の中では、特権には、名前ではなく番号が割り当てられています。

標準のシェルの場合

図 16-1 の左側の円は標準の UNIX シェルのプロセスを表しています。ここで、ユーザーは programX というコマンドを入力します。シェルのプロセスのものとして示される継承可能セットは、空 (null) になっています。これは、標準シェルのプロセスが特権を持っていないためです。

図 16-1 通常のユーザーシェルで実行時に強制された特権を獲得するプロセス

図 16-1 では、中央の四角形は programX を表し、このプログラムには、「強制された特権」と「許容された特権」があります。強制された特権は、1、3、5、許容された特権は、1、3、5、11、12、19 です。右側の円は、programX を実行するプロセスを表しています。ここでは、「許容セット」と「有効セット」に、プログラムファイルに割り当てられた「強制された特権」が与えられています。図 16-1 では、親プロセスが標準のシェルで、「継承可能な特権」はありません。そのため、新しいプロセスに割り当てられる特権セットには、プログラムファイルから獲得した「強制された特権」のみが含まれ、新しいプロセスの「継承可能セット」は空のままになっています。

プロファイルシェルの場合

図 16-2 は、ユーザーや役割アカウントが、プロファイルシェルで programY を実行する場合を表しています。

図 16-2 プロファイルシェルから特権を継承するプロセス

上の図 1-2 では、プロファイルシェルは、どのユーザーまたは役割がコマンドを実行しているのかを確認し、そのコマンドがアカウントのプロファイルに含まれていることを確かめます。また、アカウントのプロファイルにそのコマンドに対する特権が指定されているかどうかを確認して、指定された特権だけを自分の「継承可能セット」に追加します。図に示すように、実行可能な programY 自体は「強制された特権」を持たず、「許容セット」には、10、12、19 が含まれています。programY の「許容セット」には 10、12、19 の 3 つの特権が含まれているため、programY を実行するプロセスは、親プロセスから特権 10、12、19 を継承し、プロセスの「有効セット」と「許可セット」には特権 10、12、19 が設定されます。

プログラムファイルの「許容セット」に特権がない場合、そのプログラムを実行するプロセスの「許可セット」と「有効セット」は、常に空になります。

`mount` コマンドを実行するプロセスが特権を獲得する方法

この節では、「Trusted Solaris で 2 つの標準プログラムが特権を使用する方法」で例に挙げた mount コマンドがプロファイルシェルのプロセスでどのように実行され、どのように特権を獲得するかを説明します。mount がプロファイルシェルで実行されるとき、pfsh を実行しているプロセスは、次の処理を行います。

コマンドを呼び出したユーザーのプロファイルに mount コマンドがあることをチェックする
sys_mount 特権と、呼び出し元のユーザーのプロファイルに含まれるその他の特権を、pfsh の「継承可能セット」に指定する
exec を呼び出して、mount コマンドを実行する

mount のプロセスでは、「継承可能な特権」は、mount を呼び出したプロファイルシェルのプロセスの「継承可能な特権」と同じに設定されます。次に、mount のプログラムファイルの「強制された特権」と「許容された特権」が「継承可能セット」と組み合わされプロセスの許可された特権、「有効な特権」、「保存された特権」が決定します。

「許可セット」と「有効セット」を決定するためには、まず、プロセスの「継承可能な特権」と、プログラムファイルの「強制された特権」の中の追加特権とが組み合わされます。mount には、「強制された特権」がないため、ここではこの特権は適用されません。「継承可能な特権」と「強制された特権」の組み合わせは、プログラムファイルに指定されている「許容された特権」に制限されますが、mount プログラムファイルに「許容された特権」すべてがあるため、すべての「継承可能な特権」を使用することができます。その結果、mount を実行するプロセスの「許可セット」および「有効セット」は、「継承可能な特権」のセットと同じになります。

mount の「保存セット」には、「継承可能セット」と、mount のプログラムファイルの「強制された特権」および「許容された特権」が設定されます。

継承可能な特権が重要な理由

「継承可能な特権」については、「プロセス特権セット」で詳しく説明しています。継承可能な特権がセキュリティ管理者役割にとって重要である理由は、特権の継承が次のように使用されるためです。

プロファイルシェルで呼び出されたコマンドに特権を引き渡すプロファイル機構
システムシェルで、呼び出されたコマンドに特権を引き渡す
ウィンドウシステムのトラステッドプロセスで、アクションに特権を引き渡す

「プロセス特権セット」で説明したように、プロセスが新しいプログラムを実行する場合、プロセスの新しい「継承可能な特権セット」は、新しいプログラムが実行される前のプロセスの古い「継承可能な特権」セットと同じに設定されます (I[new]=I[old])。その結果、あるプログラムから他のプログラムに引き渡すことが可能な「継承可能な特権」は、現在実行中のプログラムの「強制された特権」や「許容された特権」の影響を受けません。プログラムファイルの「強制セット」や「許容セット」を参照せずに「継承可能セット」を保守することには、次の 2 つの利点があります。
「許容された特権」を参照せずに I[new]=I[old] を設定すると、特権を使用できないプログラムを実行しているプロセスから特権を使用できるプロセスに特権を引き渡すことができる

詳細については、「プログラムファイルが「許容された特権」を持っていない場合」を参照してください。
「強制された特権」を参照せずに I[new]=I[old] を設定すると、「強制された特権」がシェルスクリプトによって使用されない

詳細については、「プログラムファイルが「強制された特権」を持っていない場合」を参照してください。

プログラムファイルが「許容された特権」を持っていない場合

プログラムファイルが「許容された特権」を持っていない場合、プログラムを実行するプロセスの「継承可能な特権セット」は、プログラムの「許容された特権」に合わせて削減されることがありません。「許容された特権」を持たないプログラムを実行するプロセスは、特権を使用することができません。これは、他のトラステッドプロセスから特権を継承したとしても、「有効セット」に特権を設定することができないからです。ただし、このようなプロセスは、「継承可能な特権」を他のプログラムに引き渡すことができます。そのプログラムが「許容された特権」を持っていれば、「継承可能な特権」を使用することができます。次の図を参照してください。

図 16-3 特権を使用できないプログラムが使用できるプログラムに特権を引き渡す方法

プログラムファイルが「強制された特権」を持っていない場合

プロセスの「継承可能セット」が、プログラムの「強制された特権」によって増加することはありません。シェルスクリプトの「強制された特権」が、強制特権シェルスクリプトで呼び出されたコマンドに渡されることはありません。つまり、標準の UNIX シェル sh(1)、csh(1)、ksh(1) で実行されるシェルスクリプトで特権が使用されることはありません。次の図を参照してください。

図 16-4 強制された特権シェルスクリプトが「強制された特権」をコマンドに渡さないようにする方法

特権がコマンドとアクションに割り当てられる方法

ここまで説明したように、デフォルトの Trusted Solaris のコマンドとアクションは評価済みであり、実行するために特権が必要なものには、特権が割り当てられています。サイトの構成後に特権が付与されるコマンドやアクションは、それを呼び出すユーザーが信頼できる方法で特権を使用すると確信できたものに限定されます。特権の付与はサイトのセキュリティ管理者役割が行います。

セキュリティ管理者役割は、次の方法で特権を使用可能にします。

実行可能ファイル (コマンドの場合のみ) 自体に強制された特権を割り当てる
プロファイルシェルやウィンドウシステムのトラステッドプロセスから呼び出されたコマンドまたはアクションによって継承可能にする

コマンドに「強制された特権」を付与する

セキュリティ管理者役割は、コマンドの実行可能ファイルに「強制された特権」を割り当てることができます。特権の割り当ては、ファイルマネージャの「特権 (Privileges)」ダイアログボックスを使用するか、プロファイルシェルに setfpriv(1) コマンドを入力することによって行います。この方法については、「コマンドに強制された特権を付与するには」を参照してください。

「強制された特権」を持つコマンドと実行する場合、「強制された特権」は、実行プログラムの「有効セット」に組み込まれます。特権を持つコマンドの実行を禁止する唯一の方法は、コマンドへのアクセスを制御することです。プロファイルシェルをアカウントのデフォルトシェルとして、そのアカウントのプロファイルにコマンドやその他のシェルを一切割り当てないようにします。

実行可能ファイルの特権を変更するには、プロセスの機密ラベルによって、ファイルへの MAC 書き込みアクセスが許可されていなくてはなりません (DAC 書き込み許可は必要ありません)。ファイルの「強制セット」と「許容セット」を変更できるのは、同じかそれより低い機密ラベルの所有者 (write-equal または write-up) か、ADMIN_LOW ワークスペースの (デフォルトシステムに設定) セキュリティ管理者役割 (write-up) だけです。

つまり、ファイルの「強制セット」と「許容セット」を変更できるのは、次のユーザーまたはプロセスに限られます。

ファイルの所有者
file_setpriv 特権を持つプロセス
「ファイルの特権を設定」承認を持つアカウント

setfpriv(1) マニュアルページも参照してください。

注 -
ファイルマネージャの「特権 (Privileges)」ダイアログボックスで「強制された特権」を割り当てると、同じ内容の「許容セット」も自動的に割り当てられます。ただし、「強制された特権」がファイルの許容セット内にある場合か、同じコマンド行で「許容セット」と「強制セット」を適切に設定した場合を除いて、setfpriv コマンドによる「強制された特権」の設定は行えません。

コマンドやアクションに「継承可能な特権」を付与する

セキュリティ管理者役割は、プロファイルマネージャを使用して実行プロファイルにコマンドまたはアクションの「継承可能な特権」を指定し、ユーザーマネージャを使用してユーザーまたは役割アカウントにそのプロファイルを割り当てることができます。ユーザーマネージャとプロファイルマネージャの使用方法については、第 5 章「ユーザーマネージャを使ったアカウントの設定」、第 8 章「ユーザーおよび役割のための実行プロファイルの管理」を参照してください。

注 -

コマンドの「許容セット」に指定されていない特権を「継承可能な特権」に指定することはできません。

特権プログラムがトラステッド共用ライブラリを使用する理由

ほとんどのアプリケーションは、共用ライブラリルーチンを使用します。Trusted Solaris 環境では、セキュリティ管理者役割は、特権を必要とするアプリケーションで使用する共用ライブラリを常にトラステッドディレクトリ内に設定しておかなくてはなりません。特権アプリケーションが非トラステッドのライブラリにリンクしようとすると、エラーが発生し、リンクに失敗します。

ld.so.1: fatal: application-name: open failed: No such file or directory. Killed.

Trusted Solaris と標準 Solaris の両方の環境において、LD_LIBRARY_PATH は setuid プログラムと setgid プログラムだけが使用できるように制限されています。さらに Trusted Solaris では、LD_LIBRARY_PATH は特権プログラムだけが使用できるように制限されています。setuid、setgid、および特権プログラムの場合、動的ライブラリは次の表に示すトラステッドディレクトリ以外からは読み込めません。

表 16-2 共用ライブラリが格納されているデフォルトのディレクトリ


Trusted C 関数ライブラリ	X サーバーへの Trusted 拡張機能
`/usr/lib`	`/usr/openwin/lib`
`/etc/lib`	`/usr/dt/lib`

setuid、setgid、または特権プログラムからのライブラリへのアクセスを許可する最良の方法は、そのライブラリを上記デフォルトのトラステッドディレクトリの 1 つに移動することです。ディレクトリは、必須アクセス制御 (MAC) および任意アクセス制御 (DAC) によって保護されているため、管理者以外のユーザーが書き込みやライブラリファイルの変更を行うことはできません。

ライブラリの移動が不可能なサイトの場合、Trusted Solaris では、rtld ファイルにエントリを作成することによって、トラステッドディレクトリの一覧を拡張できます。

セキュリティ管理者役割は「管理用エディタ (Admin Editor)」アクションを使って、/etc/security/tsol/rtldファイルを作成または変更できます。あるいは、このファイルの中に、トラステッドディレクトリの一覧に追加する、コロンで区切ったディレクトリ群を指定できます。詳細は、「トラステッドプログラムをトラステッドライブラリにリンクするには」を参照してください。

rtld ファイルに登録されているアプリケーションのライブラリは「信頼できる」ようになるため、間違って変更されることがないように、これらのライブラリにはデフォルトのライブラリと同じレベルの保護が必要です。セキュリティ管理者役割は、rtld ファイル内のディレクトリ上に、デフォルトのトラステッドライブラリと同じ MAC および DAC のアクセス権があることを確認する必要があります。

オブジェクトファイルのリンクエディタと rtld ファイルに関する詳細は、ld(1) マニュアルページを参照してください。

トラステッドパスについての注意点

トラステッドパス属性は、ブート時、あるいはプログラムが管理役割ワークスペースで動作しているときに使用できます。多くの管理コマンドおよびアクションにはトラステッドパス属性が必要です。詳細は、「トラステッドパス属性」を参照してください。

トラステッドパス属性をプログラムで利用可能にする

コマンドがトラステッドパス属性を取得できるのは、そのコマンドがブートファイルに登録されているか、あるいは、管理役割に割り当てられているプロファイル内にあるときだけです。管理役割がプログラムを実行したとき、そのプログラムが管理役割のどの実行プロファイル内にもない場合、トラステッドパス属性は無効になります。

新しいプログラムまたはスクリプトを追加するとき、そのプログラムまたはスクリプトが、トラステッドパス属性を必要とする、次のようなプログラムではないことを確認します。

管理役割ワークスペース内にウィンドウを作成するコマンドまたはスクリプト (多くのインストールスクリプトなど) で、トラステッドパス属性を持っていない場合には正常に動作しないもの
プロファイルシェルスクリプトやシステムシェルスクリプトで、トラステッドパス属性を持っていない場合には管理役割が正常に実行できないもの

トラステッドパスの警告

デフォルトのシステムでは、作業しやすくなるように、管理役割には All Commands プロファイルが割り当てられています。All Commands プロファイルが割り当てられている役割は、特権または他の拡張セキュリティ属性なしにコマンドを実行できます。あるプログラムが役割のどのプロファイルにも明示的に指定されていない場合、プロファイルシェルはトラステッドパス属性を無効にし、次のようなメッセージを表示します。

WARNING: Command operating outside of the Trusted Path!

プログラムが成功したときでも、この警告メッセージは表示されます。プログラムの実行時にエラーが発生したとき、この警告メッセージは、そのプログラムがトラステッドパス属性を持っていないことを知らせます。この警告メッセージを抑制するには、-Q オプションを使います。つまり、管理役割はプロファイルシェルのコマンド行で set -Q と入力するか、$HOME/.profile ファイルに set -Q を設定します。

ほとんどの管理作業で使われる Solstice AdminSuite ツールはトラステッドパス属性を調べます。したがって、表 4-1 にあるプログラムやオプションにアクセスする必要がある新しい役割をセキュリティ管理者役割が作成する場合、新しい役割は管理役割でなければなりません。

ソフトウェアを追加するときのセキュリティ管理者役割の作業

デフォルトの Trusted Solaris プログラムやアクションには、あらかじめ、その機能を果たすために必要な特権、実効 UID、実効 GID などが割り当てられています。この節では、次の種類のソフトウェアを追加する際の問題や作業について説明します。

Trusted Solaris のセキュリティポリシーを認識したり施行したりしないサンの別パッケージの製品やサン以外のアプリケーション
Trusted Solaris プログラミングインタフェースを使用して作成したラベルと MAC (必須アクセス制御) を認識し、Trusted Solaris セキュリティポリシーの範囲内で動作する新しいプログラム
新しいアクション (セキュリティ管理者役割によって作成または、認可されたもの)
シェルスクリプト (セキュリティ管理者役割によって作成または、認可されたもの)

プログラムの中には、単一レベルで実行され、特権が必要ないため、セキュリティ管理者役割が ADMIN_LOW で公開ディレクトリにインストールするだけで、ユーザーや役割の実行プロファイルに必要なコマンドを割り当てることのできるものがあります。このとき、プログラムを機能させるために特権を割り当てたり、その他の属性を修正する必要はありません。一方、セキュリティポリシーを回避する必要のあるプログラムの場合は、あらかじめ分析やテストを行なった上で、特権を割り当てる必要があります。

既存のプログラムを追加する場合

既存のプログラムを Trusted Solaris システムに追加する場合は、そのプログラムが社外で作成されたアプリケーション、Solaris の別パッケージのソフトウェアプログラム、社内で作成されたプログラムのいずれの場合でも、次の指示に従って作業を行なってください。

そのアプリケーションが Trusted Solaris システム内で変更なしに正しく実行できることを確認します。

特権を付与したり修正を加えたりしないで実行できる場合、ここで作業は終了です。
プログラムが失敗した場合は、その原因を見つけます。

Trusted Solaris オペレーティング環境には、セキュリティポリシーを施行するために特別な修正が加えられています。そのため、Solaris 用に作成された別パッケージのソフトウェアやサン以外のアプリケーションの中には、Trusted Solaris 環境で実行できないものもあります。たとえば、カーネルとリンクするソフトウエアは、Trusted Solaris 用に修正されたカーネルデータ構造とは互換性がない場合があります。同様の理由で、読み込み可能なデバイスドライバやその他のソフトウエアも、コードを変更しない限り、この環境で実行できない可能性があります。

アプリケーションがカーネルにリンクしているか、オペレーティングシステムの修正された部分に依存している場合、そのプログラムに特権を付与しても、コードを変更しない限り、Trusted Solaris で実行できない可能性があります。
Solaris オペレーティングシステムの Trusted Solaris 用に修正された部分には依存していないプログラムで、特権を使用しないとエラーが発生する場合、必要な特権やその他の属性を判断します。
特権の使用が必要な場合、プログラムが信頼できる方法で特権を使用するかどうかを調査します。

「特権を使用しないとエラーが発生するプログラム」を参照してください。
プログラムが、特権またはその他の必要な属性を使用して、Trusted Solaris のセキュリティポリシーや独自に導入しているセキュリティポリシーに違反することなく安全に実行できる場合は、必要な特権を割り当てます。この方法については、「特権がコマンドとアクションに割り当てられる方法」参照してください。
プログラムのソースコードへのアクセス権がある場合、コードを修正した後、セキュリティを熟知したセキュリティコンサルタントやプログラマが特権を追加できる場合もあります。

このような修正では、特権ブラケットを使用したり、プログラムに Trusted Solaris のセキュリティポリシーを認識させるためのコードを追加したりします。
プログラムで特権を使用できるようにする場合、そのプログラムが使用するライブラリがトラステッドとして認識されるかどうかを確認する必要があります。「特権プログラムがトラステッド共用ライブラリを使用する理由」を参照してください。
プログラムが信頼できる方法で特権を使用できない場合や、修正が不可能な場合は、特権を使用可能にしてはなりません。

特権を使用しないとエラーが発生するプログラム

Trusted Solaris 環境において特権がないためにエラーを発生するもっとも典型的なプログラムは、標準 Solaris 環境でスーパーユーザーとして実行する必要があるプログラムです (たとえば、setuid をスーパーユーザーにして動作するようなプログラム)。この種類のプログラムには、プロファイルでスーパーユーザーの実効 UID を割り当てることができます。あるいは、実 UID を必要とする場合は、(セキュリティ管理者役割の判断により)、そのプログラムをスーパーユーザー役割に割り当てることもできます。

ほとんどのアプリケーションは、MAC などの Trusted　Slaris のセキュリティ機構を持たない環境で作成されます。このため、セキュリティと、新しいプログラムで実現しようとしている内容について完全に理解しなければ、プログラムを評価することができません。

ユーザーに代わってあらかじめ厳密なチェックを行なったとしても、DAC に違反するような標準 UNIX アプリケーション管理者が、MAC と同様のチェックを行うことはありません。つまり、このようなプログラムに MAC の無効化特権を付与した場合、ユーザーが任意で MAC を無効にできる方法を提供してしまうことになります。

セキュリティ上の考慮が必要な点について、UNIX プログラムで一般的に使用される rcp(1) の動作を例に挙げて説明します。rcp コマンドは、ネットワーク内でファイルをコピーするコマンドで、setuid を root として実行されます。root として実行すると、プログラムは、標準の UNIX システムのすべての特権を使用して実行されます。このプログラムは DAC 制限の回避を許可されていますが、ファイルの DAC アクセス権をチェックして、rcp コマンドを実行したユーザーが、ファイルへのアクセス権を持っていることを確認します。ただし、rcp では MAC 制限は行われません。また、 file_mac_read 特権や file_mac_write 特権を付与したとしても、ファイルへのアクセス時に MAC 関連のチェックを行う組み込み機能もありません。したがって、rcp は、システムのセキュリティポリシーを実現するために割り当てられた特権を使用することができません。

これと類似したプログラムに、実行に必要な特権を単純に割り当て、Trusted Solaris のセキュリティポリシーに従って動作するように修正しなかった場合、そのプログラムはシステムセキュリティに違反することになります。システムセキュリティに違反せずに実行できるようにするには、プログラムのソースコードにコードを追加する必要があります。たとえば、ファイルの読み取りや書き込みを行うときに MAC 制限を回避しなければならない場合、必要な MAC チェックを行うコードを追加して、ソースコードを変更する必要があります。

ソフトウェアの中には、特権が必要な理由が明確でないものもあります。さらに、プログラムの実行に特権が必要ないものもあります。けれども、システムのセキュリティポリシーに違反するような機能を持たないプログラムであっても、共用ログファイル中の処理の履歴を追跡したり、/dev/kmem (mem(7D) を参照) から読み取りを行うなど、セキュリティに違反する内部作業を行なっている可能性があります。内部で発生するポリシー違反は、ユーザーに便利な機能を提供するだけで、アプリケーションを正しく操作するためには特に重要でない場合があります。サイトでソースコードを調べられる場合は、アプリケーションのパフォーマンスに影響を与えることなく、ポリシーの無効化を必要とする操作を削除できないか検討します。

MAC 検査を行わずにファイルの読み取りや書き込みを行うなど、いくつかの面で Trusted Solaris のセキュリティポリシーに違反するプログラムについては、可能であれば、ソースコードに必要な MAC 検査を追加します。そうでなければ、そのプログラムの移植は控えてください。

アプリケーションをスーパーユーザーがインストールする場合

通常、特殊なアプリケーションやパッケージをインストールするソフトウェアの場合、正常に処理を行うためには、スーパーユーザーの実効 UID が必要です。プロファイル機構では、アプリケーションに実効 UID を割り当てられるのはセキュリティ管理者役割だけなので、インストールプログラムのプロファイルにスーパーユーザーの UID を割り当てるのは、セキュリティ要件に適合しません。コマンドがスーパーユーザーの実 UID で実行できるようにする唯一の方法は、スーパーユーザー役割がそのコマンドを実行することです。セキュリティ管理者役割は、アカウントにスーパーユーザー役割を割り当て、Custom Root Profile などのプロファイルにコマンドを追加できます。詳細は、「アプリケーションの設定: スーパーユーザーの実 UID を使用して実行する」を参照してください。

アプリケーションをスーパーユーザーが実行する場合

スーパーユーザーが実行するアプリケーションについては、次の 3 つのオプションを使用して、サイトのセキュリティポリシーと矛盾がないか評価する必要があります。これはセキュリティ管理者役割の業務です。

アプリケーションの実行にスーパーユーザーの実効 UID が必要ない場合、スーパーユーザーの実効 UID を使用するように設定する

「アプリケーションの設定: スーパーユーザーの実効 UID を使用して実行する」を参照してください。
アプリケーションに必要な特権を特定し、アプリケーションがその特権を信頼できる方法で使用することを確認してから、必要な特権だけを割り当てる

「アプリケーションに必要な特権を調べるには」を参照してください。
必要なアカウントにスーパーユーザーの役割を一時的または常に割り当て、そのアカウントのプロファイルの 1 つにコマンドを割り当てる

「アプリケーションの設定: スーパーユーザーの実 UID を使用して実行する」を参照してください。

プログラムに必要な特権の検索

runpd(1M) コマンドは任意のコマンドを実行して、そのコマンドが使った特権を記録します。

runpd コマンドにはトラステッドパス属性が必要です。コマンドがトラステッドパス属性を取得できるのは、そのコマンドがプロファイル中に指定されており、管理役割によって実行されるときだけです。したがって、通常のユーザーは runpd を実行して、通常のユーザーに必要な特権を見つけることはできません。runpd を実行するためにスーパーユーザー役割を使ってはなりません。これは、UID 0 が他の UID よりも多くのアクセス権をコマンドに与えてしまうためです。runpd コマンドを使うと、コマンドが使用されるラベルにおいて、そのコマンドがどの特権を使うのかテストできます。管理役割 (スーパーユーザー役割を除く) として runpd を実行すると、コマンドがユーザーの認可範囲内の機密ラベルで実行された場合、通常のユーザーに必要な特権が記録されます。

デフォルトでは、セキュリティ管理者役割は、そのプロファイル内に runpd コマンドが割り当てられている唯一の役割です。「アプリケーションに必要な特権を調べるには」で説明している手順に従うと、特権デバッグを有効にできます。その手順では、特権デバッグ専用の管理役割を作成する方法についても説明しています。

コマンドが必要とする特権は、自動的に割り当ててはなりません。特権を割り当てる前に、他の方法を検討してください。

プログラムがファイルにアクセスするときに DAC または MAC の制限を回避する必要がある場合、セキュリティ管理者役割は実効 UID または GID を割り当てることによって、特権を不要にすることも可能です。詳細は、「特権の割り当て以外の方法」を参照してください。

ソフトウェアに特権、あるいは代替の UID または GID が割り当てられているとき、そのソフトウェアは、Trusted Solaris セキュリティポリシーを無効にできるという意味で「トラステッド (信頼できる)」になります。したがって、「信頼できない」ソフトウェアでも「トラステッド (信頼できる)」になってしまうことに注意してください。セキュリティ管理者役割は、ソフトウェアが信用に値する方法で特権を使うことが確信できるまで、そのソフトウェアに特権を与えてはなりません。ソフトウェアを十分に調べ、システムのセキュリティポリシーの範囲内で特権を使っていることが判明した場合にのみ、そのソフトウェアは「信頼のおける」プログラムであると言えます。

新しいトラステッドプログラムを追加する場合

プログラムの開発者がソースコードに組み込む特権をセットを操作できてもセキュリティ管理者役割がプログラムに必要な特権を割り当てなければ、プログラムで特権を使用することはできません。セキュリティポリシーを無効にできなければ、そのプログラムは期待通りの処理を完全に行えなかったり、Trusted Solaris システムで実行することができなかったりします。

開発者の業務

Trusted Solaris システムに追加されるプログラムを作成する開発者には、次の条件が必要です。

プログラムが機能するために特権が必要かどうか判断できる
特権ブラケットなどの技術を習得しており、プログラムで安全に特権を行使するために使用できる
プログラムに特権を割り当てるときは、セキュリティの実現に注意し、プログラムがセキュリティポリシーに違反しないことを確認する
セキュリティ管理者役割との共同作業により、「特権プログラムがトラステッド共用ライブラリを使用する理由」の説明に従って、プログラムにリンクされた共用ライブラリをトラステッドディレクトリ内に格納する。また、プログラムをコンパイルするときは、「」に従って、トラステッドディレクトリの場所を使用する

プログラム内で特権を使用する方法については、『Trusted Solaris 開発ガイド』を参照してください。

セキュリティ管理者役割の業務

セキュリティ管理者役割は、Trusted Solaris のシステムコールやルーチンを使用してセキュリティポリシーの範囲内で処理を行うプログラムが、絶対に Trusted Solaris システムのセキュリティに違反しないようにする必要があります。

プログラマやプログラム配布プロセスが信頼できることを確認する
次の情報源から、プログラムに必要な特権を決定する
1. プログラマに確認する
2. ソースコードを調べて、プログラムが使用する予定の特権を検索する
3. runpd を使用する。これについては、「アプリケーションに必要な特権を調べるには」で説明しています。
ソースコードを綿密に調査し、処理に必要な特権を使用する際に信頼できる方法で動作することを確認する

アクションを追加する場合

Trusted Solaris システムでアクションを作成し、使用する方法は、標準 Solaris の場合とほとんど変わりません。アクションの追加方法については、『Solaris 共通デスクトップ環境上級ユーザ及びシステム管理者ガイド』で説明しています。

Trusted Solaris では、アクションの使用は実行プロファイル機構によって制御されます。アクションには、任意の実行プロファイルに特権、実効 ULD、実効 GID などのセキュリティ属性を割り当てることができ、継承可能セットからアクションに特権を引き渡すことのできるウィンドウシステムのトラステッドプロセスの中で呼び出された場合は、特権を使用して実行することができます。Trusted Solaris システムでは、多数のアクションの実行プロファイルに特権が割り当てられていて、そのプロファイルはデフォルトで特定の役割に割り当てられています。表 16-3 に、Trusted Solaris システムでアクションを作成したり使用するときの重要な相違点についてまとめます。

表 16-3 Trusted Solaris の制限下でアクションを作成したり使用する際の相違点


標準 CDE	Trusted Solaris
新しいアクションは、だれでも自分のホームディレクトリ内に作成できる。また、作成者は自動的に新しいアクションを使用できるようになる。	アクションは、ユーザーや役割の実行プロファイルに含まれている場合だけ使用可能。
	プロファイルに、「アクション作成 (Create Action)」アクションまたはコマンド、ファイルの編集を許可するアクションがある場合、ユーザーや役割は、自分のホームディレクトリ内に新しいアクションを作成することができる。ただし、それを使用することはできない。
	ユーザーが新しいアクションを使用するためには、セキュリティ管理者役割が新しいアクションの名前をアカウントの実行プロファイルの 1 つに追加するか、All プロファイルが割り当てられていることが必要。All プロファイルは、アクションに対するすべてのチェックを無効にするため、ユーザーは、常駐するアクションでも、一時的アクションでも、すべてのアクションを使用することができる。
	実行プロファイルによってアクションの使用を許可されているアカウントであれば、ファイルマネージャを使用してホームディレクトリからアクションを起動することができる。デフォルトのシステム管理者役割とセキュリティ管理者役割は、公開ディレクトリにアクションを配置することが許可されている。
アクションをフロントパネルにドラッグ＆ドロップすることが可能。	フロントパネルは、トラステッドパスの一部。ウィンドウマネージャは、システム全体のアクションファイルが保存されている `/usr/dt` および `/etc/dt` サブディレクトリにある、管理者が追加したアクションだけを認識する。したがって、一般ユーザーまたは管理役割以外のアカウントが自分のホームディレクトリに新しいアクションを作成し、All Accounts プロファイルを持っていたとしても、ユーザーのホームディレクトリからフロントパネルにドラッグされた新しいアクションは、ウィンドウマネージャに認識されない。ウィンドウマネージャは公開ディレクトリ内だけを検索する。
アクションが特権を付与された処理を行うためには、スーパーユーザー (root) によって実行されなくてはならない。	呼び出し元のアカウントの実行プロファイルで、特権を持つことが指定されているアクションの場合、トラステッドプロセスから起動されたときは、特権を継承することができる。つまり、アクションが特権を付与された処理を行うためには、アカウントのプロファイルに特権を割り当てておかなくてはならない。

シェルスクリプトの作成方法と使用方法

通常の UNIX シェル (sh, csh, csh) が割り当てられているユーザーは、特権を使用しないでシステム内の任意のコマンドを実行する、新しいシェルスクリプトを作成することができます。このスクリプトに特権を必要とするコマンドが含まれていない場合、ソフトウェアへのアクセス権を持ち、シェルスクリプトを解釈するためのシェルを実行できるユーザーは全員、シェルスクリプトを使用することができます。

シェルスクリプトで実行されるコマンドに特権を付与することができるのは、セキュリティ管理者役割だけです。シェルスクリプトの実行時に特権を使用するかどうかに影響する Trusted Solaris の制約について確認します。

特権を使用してコマンドを実行できる 2 つの方法を確認します。

コマンドの実行可能ファイルの強制セットと許容セットの両方に必要な特権が設定されている
コマンドに必要な特権が、コマンドを呼び出すユーザーまたは役割に割り当てられたプロファイルに設定されている。コマンドのプログラムファイルに必要な特権が許容セットに設定されている。コマンドが特権を継承できるプロファイルシェルで呼び出される

「強制された」特権コマンドは、どのシェルでも特権を使用して実行できます。これは、プログラムファイルに付与された「強制された特権」が、シェル自体に特権がなくても、コマンドの実行に適用されるからです。「強制された特権」を csh、sh、ksh シェルスクリプトに割り当てても、シェルスクリプトが実行するコマンドに特権を付与することにはなりません。これは、スクリプトから起動されたシェルが「強制された特権」を使用して実行された場合でも、シェルの「継承可能セット」に特権が設定されていないからです。プロセスが特権を取得する方法については、「プロセス特権セット」で説明した規則を参照してください。

注意 -

実行可能プログラムを編集する際、オブジェクトコードやシステムスクリプトが無許可で改ざんされないようにするために、そのファイルに付与されていた「強制された特権」と「許容された特権」は削除されます。プログラムファイルの「許容セット」が空の場合、継承可能な特権は「許容セット」にマスクされ、使用することができません。ただし、プロファイル機構は、「継承可能な特権」を使用可能にするときに、シェルスクリプトの「強制された特権」と「許容された特権」を参照しません。このため、シェルスクリプトは修正されても気付かれないことがあります。セキュリティ管理者役割は、「継承可能な特権」を使用するシェルスクリプトを使用可能にする前に、改ざんに対する保護が、プログラムに有効であってもシェルスクリプトに対しては有効でないことに留意しておく必要があります。

Trusted Solaris システムにおけるシェルスクリプトの動作のまとめ

I特権を必要とするコマンドを含まないスクリプトであれば、テキストエディタを使用できるどのユーザーでも作成することができる
ソフトウェアへのアクセス権を持ち、シェルスクリプトを解釈するためのシェルを実行できるユーザーであれば、だれでもシェルスクリプトを使うことができる
シェルスクリプトの「強制された特権」は、その中のコマンドに特権を引き渡さない
シェルスクリプトの「許容された特権」によって、シェルスクリプトによって実行されるプログラムで使用できる特権が変わることはない

スクリプトのファイルの「許容セット」ではなく、呼び出されたシェルのファイルの「許容セット」がチェックされます。
呼び出したユーザーのプロファイルに設定されているシェルスクリプトに、そのコマンドに必要な特権が指定されている場合に限り、プロファイルシェルで呼び出された標準のシェルスクリプトは実行するコマンドに特権を引き渡すことができる

コマンドがそのプログラムファイル上に「許容された特権」を持っていれば、シェルスクリプトは、そのコマンドによって継承される特権を引き渡すことができます。コマンドは標準のシェル内で実行されるため、呼び出すアカウントのプロファイルに特権を指定してコマンドを設定することは無意味です。これは、標準のシェルがプロファイルデータベースを参照しないからです。次の図を参照してください。

図 16-5 `pfsh` で呼び出されたシェルスクリプトがコマンドに継承可能特権を引き渡す方法

呼び出したユーザーのプロファイルに必要な特権と一緒にコマンドが設定されている場合、プロファイルシェルを使用するシェルスクリプトは、使用するシェルの種類に関わらずコマンドに特権を引き渡すことができる

プロファイルシェルを呼び出すシェルスクリプトの詳細

#!/bin/pfsh という行で始まるシェルスクリプトを一般ユーザーが呼び出した場合、その動作は管理役割が呼び出した場合の動作とは異なります。

一般ユーザーが呼び出した場合の動作

プロファイルシェルを呼び出すシェルスクリプトは、一般ユーザーによって任意のシェルのコマンド行から実行可能
ユーザーがプロファイル内に All Commands を登録している場合、特定のプロファイルシェルの名前をそのユーザーのプロファイルに明示的に追加する必要はない
プロファイルシェルスクリプト内のすべてのコマンドはユーザーのプロファイルに登録されていなければならない。あるいは、ユーザーに All Commands プロファイルが必要。特権が必要なコマンドは、その特権とともにユーザーのプロファイルに登録されている必要がある

管理役割が呼び出した場合との違い

プロファイルシェルスクリプト (#!/bin/pfsh を使う) は、常に、プロファイルシェルのコマンド行から実行する必要がある
役割は、コマンド行から、あるいはトラステッドパスを持たないシェルスクリプト (GUI を起動する) からプロファイルシェルを実行できない。通常のユーザーは、コマンド行からも、あるいはトラステッドパスを持たないプロファイルシェルからもプロファイルシェルを実行できる
役割は、トラステッドパスを利用するために、#!/bin/pfsh を使うスクリプトの名前を Custom role_name Profile などのプロファイル内に明示的に登録する必要がある (障害追跡を簡単にするため、Custom role_name Profile だけを変更することをお勧めする)

注 -
すべての役割が All Commands プロファイルを持っている場合でも、All Commands プロファイルを持っている一般ユーザーとは異なり、役割の場合は、スクリプト名がプロファイル内に明示的に登録されていなければならない
一般ユーザーの場合と同様に、プロファイルシェルスクリプト内のすべてのコマンドはユーザーのプロファイルの 1 つにも登録されていなければならない

詳細は、「特権コマンドを実行するプロファイルシェルスクリプトを作成するには」を参照してください。

プログラムファイルが編集された場合、継承可能な特権を使用できないようにする方法

オブジェクトコードに対し承認されていない変更が行われるのを防ぐために、実行可能プログラムが編集された場合には必ず、そのファイルに以前与えられた「強制された特権」や「許容された特権」はすべて削除されます。この措置により、何者かが本来の意図とは異なる目的で特権を利用することを防ぐことができます。セキュリティ管理者役割は、そのようなファイルの編集を行う前に、同ファイルに与えられた特権のリストを保存しておき、編集後に復元することができます。詳細は、「ファイルを編集したときに特権を保存および復元するには」を参照してください。

ブート時にコマンドを実行するには

標準 Solaris システムの場合と同じく、Trusted Solaris システムのブート時に実行されるコマンドは、管理アクションによって追加したり、もしくは変更したりすることが可能です。基本的な動作については、『Solaris のシステム管理 (第 1 巻)』の実行制御スクリプトに関する記述、および init.d(4) のマニュアルページに説明されています。システムサービスを開始するスクリプトに付ける番号に関するガイドラインについては、各 /etc/rcn.d 内のREADME ファイルを参照してください。次節「前提知識」にも簡単な説明があります。

以下の節では、システムのブート時に起動されるサービスが必要とする Trusted Solaris の拡張セキュリティ属性を提供するために、セキュリティ管理者役割が行わなければならない事項について説明します。このようなサービスは、特権の継承、特定の機密ラベルや ADMIN_LOW 以外の認可上限を使った起動、スーパーユーザー以外の UID や GIDの割り当てなどを行う必要があります。詳細については、「デフォルトの Trusted Solaris ブートスクリプト」、「新しい Trusted Solaris ブートスクリプト」、「ブート時に実行するコマンドに拡張セキュリティ属性を使用するかどうかを指定するには」を参照してください。

前提知識

ブート時に、各 /sbin/rcn スクリプトは、それぞれに対応する /etc/rcn.d ディレクトリに含まれている一連のスクリプトを実行します。これらの実行制御スクリプト名とそれに対応するディレクトリ名に付けられている番号 n は、実行レベルを表しています。

/etc/rcn.d ディレクトリに含まれている一連のスクリプトは、/etc/init.d ディレクトリに実際に置かれているスクリプトに対するハードリンクになっています。たとえば、次の例に示すように、/etc/rc0.d、rc1.d、rc2.d ディレクトリには、それぞれ異なる名前を持つ sendmail スクリプトが 1 つずつ存在しますが、これらは実際にはいずれも /etc/initd.d/sendmail スクリプトへのハードリンクになっています。

/etc/rcn.d ディレクトリ内に存在する /etc/initd.d/sendmail へのリンク

/etc/rc0.d/K57sendmail
 /etc/rc1.d/K57sendmail
 /etc/rc2.d/S88sendmail

/etc/rcn.d ディレクトリ内のスクリプトのうち、起動オプションで実行される必要があるものには接頭辞 S で始まる名前が付けられており、停止オプションで実行される必要があるものには接頭辞Kで始まる名前が付けられています。上記の図に示すように、接頭辞 K で始まる名前の sendmail ファイルが rc0.d および rc1.d に置かれている場合、実行レベルが 0 および 1 に移行すると sendmail(1M) は停止します。同様に、接頭辞 S で始まる名前の sendmail ファイルが rc2.d に置かれている場合、実行レベルが 2 に移行すると sendmail(1M) は起動されます。

/etc/init.d に新しいスクリプトをインストールした場合、セキュリティ管理者役割は以下のことを行います。

ブートシーケンスのどの時点でスクリプトを起動または停止するかを決定する
1 つまたは複数の /etc/rcn.d ディレクトリ内に、/etc/init.d 内のそのスクリプトへのリンクを作成する
起動用か停止用かに応じて、適切な接頭辞を含む名前を対象となるファイルに付ける
特定の実行レベルへの移行時に、そのスクリプトが実行される順番が判るように、適切な番号を含む名前を対象となるファイルに付ける

新しいスクリプトをブートシーケンスのどの時点で実行するかによって、スクリプトにより実行されるコマンドをローカルファイルに置くかそれとも NIS+プロファイルデータベースに置くかを決定し、「ネームサービス (Naming Service)」メニューで「なし (none)」または「NIS+」のどちらを選択します。詳細については、「ブート時に実行するコマンドに拡張セキュリティ属性を使用するかどうかを指定するには」を参照してください。

デフォルトの Trusted Solaris ブートスクリプト

Trusted Solaris システムでは、起動されるサービスが特権や拡張セキュリティ属性を必要とすることがあるために、/sbin/rcn スクリプトが sh(1)(Bourneシェル)ではなく、 sysh(1M)(システムシェル)を使うように変更されています。デフォルトの Trusted Solaris システムでは、ブート時に起動されるコマンドのための拡張セキュリティ属性を指定するようにブート実行プロファイルが設定されています。/sbin/rcn スクリプトでは、/bin/sysh が引数としてのプロファイル名なしで使われていますが、これは同スクリプトがデフォルトでブートスクリプトを参照するようになっているためです。

警告 -

boot プロファイルや /sbin/rcn スクリプトは変更しないでください。

新しい Trusted Solaris ブートスクリプト

各サイトでブート時に実行するコマンドを追加する必要がある場合、セキュリティ管理者役割は #!/sbin/sysh で始まるシステムシェルスクリプトを作成し、そのスクリプトでローカルに作成したブート時の実行プロファイルを指定します(これを行うには setprof コマンドを使います)。セキュリティ管理者役割はブート時実行プロファイルを作成して、セキュリティ属性を必要とするコマンドに割り当てます。次の例に示すように、このシステムシェルブートスクリプトの先頭行には #!/sbin/sysh が、2 番目の行には setprof local_boot_profile コマンドが含まれています。

#!/sbin/sysh
 setprof local_boot_profile

システムシェル (sysh) は、local_boot_profile を参照することにより、スクリプトによって起動されるコマンドにどのような拡張セキュリティ属性が割り当てられているかを判断します。たとえば、コマンドが ADMIN_LOW 以外の機密ラベルや認可上限を必要とする場合、プロファイルは、そのコマンド用に機密ラベル (min_SL フィールド) と認可上限 (max_ＳＬフィールド)を設定する必要があります。さらに、コマンドがスーパーユーザー (root) の UID や別の GID を必要とする場合、プロファイルはこれを指定しなければなりません。

セキュリティ管理者役割は、「ブート時に実行するコマンドに拡張セキュリティ属性を使用するかどうかを指定するには」の手順に従って、スクリプトによって実行されるコマンドの名前を持つ新しいプロファイルを作成する必要があります。また、sysh の setprof オプションを使用して新しいプロファイルを参照するように指定し、スクリプト内で sysh シェルを使用する必要があります。

`/etc/init.d` ディレクトリのスクリプトを使用してサービスを開始・停止する

Solaris では、スーパーユーザーは、コマンド名とその後に start または stop オプションのいずれかを入力することにより、/etc/init.d ディレクトリ内の任意のコマンド (サービスとも呼ばれます) を開始または停止することができます。たとえば、次のように入力できます。

# /etc/init.d/sendmail start

および

 # /etc/init.d/sendmail stop

上の図に示すように、sendmail など、Trusted Solaris システム内のコマンドを停止または開始するには、特権は必要ありません。ただし、コマンドは、管理者役割によって、トラステッドパス属性を持つ管理役割のワークスペースで実行されなくてはなりません。同時に、スクリプト名がアカウントの実行プロファイルの 1 つに指定されている必要もあります。

ソフトウェアを追加する手順

パッケージを追加するために CD-ROM をマウントするには

システム管理者役割になり、ADMIN_LOW ワークスペースに移動します。

必要に応じて「ログイン後、特定の管理役割になるには」を参照してください。

CD-ROM デバイスを割り当てます。

「トラステッドパス (Trusted Path)」メニューの「デバイスを割り当てる (Allocate Device)」オプションを使うか、フロントパネルの「トラステッドデスクトップ (Trusted Desktop)」サブパネルからデバイス割り当てマネージャを起動します。「デバイス割り当てマネージャ (Device Allocation Manager)」ダイアログボックスが表示されます。

「利用可能なデバイス (Available Devices)」一覧から CD-ROM デバイスの名前をダブルクリックして、「割り当てられたデバイス (AllocatedDevices)」一覧に移動します。

「デバイス割り当て: ラベルを選択 (Device Allocation: Select Label)」ダイアログボックスが表示されます。

「ラベルを選択 (Select Label)」ダイアログボックスにおいて、機密ラベルとして ADMIN_LOW が指定されていることを確認し、「了解 (OK)」をクリックします。

次のようなプロンプトが現れて、指定したラベルが表示されます。
Insert disk into /dev/dsk/c0t6d0s0. Make sure disk is labeled: ADMIN_LOW Press RETURN when cdrom_0 is ready or ^C to cancel...

CD-ROM をドライブに挿入し、Return キーを押します。

次のようなプロンプトが表示されます。
Do you want cdrom_0 mounted: (y/n)?

y と答えます。

/cdrom ディレクトリが存在しない場合は作成されます。そして、/cdrom ディレクトリに CD-ROM がマウントされます。

プロンプトが表示されたら、Return キーを押して、ウィンドウを閉じます。

アプリケーションの設定: スーパーユーザーの実 UID を使用して実行する

セキュリティ管理者役割になり、ユーザーマネージャを使用して、インストール作業を担当する信頼できるユーザーのアカウントにスーパーユーザー役割を割り当てます。

詳細は、第 5 章「ユーザーマネージャを使ったアカウントの設定」を参照してください。

プロファイルマネージャを使用して、スーパーユーザーに割り当てられているプロファイルの 1 つにアプリケーションプログラムの名前を割り当てます。

詳細は、第 8 章「ユーザーおよび役割のための実行プロファイルの管理」を参照してください。

(推奨) ユーザーマネージャを使用し、作業が終了した時点でアカウントからスーパーユーザーの役割を削除します。

アプリケーションの設定: スーパーユーザーの実効 UID を使用して実行する

プロファイルマネージャを使用して、適切なプロファイルにアプリケーションプログラムのコマンド名を割り当て、コマンドにスーパーユーザーの UID を付与します。

詳細は、第 8 章「ユーザーおよび役割のための実行プロファイルの管理」を参照してください。

ユーザーマネージャを使用して、プロファイルシェルを持つ任意のアカウントに、追加されたコマンドが登録されているプロファイルを割り当てます。

第 5 章「ユーザーマネージャを使ったアカウントの設定」を参照してください。

アプリケーションに必要な特権を調べるには

セキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動します。

詳細は、「ログイン後、特定の管理役割になるには」を参照してください。

(省略可能) 新しいプロファイルを作成し、そのプロファイルを管理役割に割り当てます。

注 -
デフォルトの構成において、セキュリティ管理者役割は runpd コマンドが割り当てられている唯一の役割です。この手順では、特権デバッグ専用の管理役割も作成できます。この役割を使うと、通常のユーザーがユーザー認可範囲内のラベルでコマンドを実行したとき、あるいは管理役割が管理ラベルのいずれかでコマンドを実行したとき、そのコマンドに必要な特権を見つけることができます。
1. プロファイルマネージャを使って、/usr/sbin/runpd、/bin/getfpriv、および /bin/setfpriv 特権、「システムをシャットダウン」、「ログインを有効化」、および 「ファイルの特権を設定」 承認、さらに、必要であれば、「管理用エディタ (Admin Editor)」アクションを持つ新しいプロファイルを作成します。そして、/usr/sbin/runpd を実行する前に、役割が以下の手順に従って特権デバッグを実行できるように設定します。
2. ユーザーマネージャを使って、管理役割 (たとえば prvdbg) を作成し、その役割に上記プロファイルを割り当てます。必要であれば、All プロファイルも割り当てます。
3. 特権デバッグ役割をアカウントに割り当てます。

「管理用エディタ (Admin Editor)」アクションを使って、/etc/system ファイル内の tsol_privs_debug 設定を 1 に変更します。
set tsol_privs_debug=1

「管理用エディタ (Admin Editor)」アクションを使って、/etc/syslog.conf ファイル内の kern.debug から始まる行の前にあるコメントマーク (#) を削除します。

次の行は、システムコールやデーモンに必要な特権を /var/log/privdebug.log ファイルに記録します。
kern.debug;daemon.debug;local0.debug /var/log/privdebug.log

「トラステッドパス (TP)」メニューの「シャットダウン」オプションを使ってコンピュータをシャットダウンし、リブートします。
ok boot

ログインし、セキュリティ管理者役割になります。あるいは、特権デバッグ専用の役割を作成した場合 (手順 2 を参照)、特権デバッグ専用の役割になります。

適切な機密ラベルを持つ端末エミュレータで、runpd コマンド、検査対象のコマンド、およびそのコマンドがどのように特権を使うのかを調べるためのオプションを (この順番で) 入力します。

注 -

ワークスペースの機密ラベルは、コマンドが通常実行される機密ラベルである必要があります。管理役割が管理ラベルでアプリケーションを実行することもあれば、一般ユーザーがユーザー認可範囲内のラベルで同じアプリケーションを実行することもあります。

次の例に示すように、runpd は、プログラムが正常に実行されるために必要な特権の名前、試行されたアクセスの種類 (たとえば create)、資源の名前 (たとえば RAW_SOCKET) を並べて表示します。

$ runpd pathname_of_command_and_any_options

runpd: child terminated with a status of 0

process pathname_of_command pid process_ID lacking privilege privilege_name
to perform type_of_access upon resource resource_name (MM DD HH:MM)

次の例は、ping(1M) で runpd(1M) を実行した結果を示しています。この例の目的は、ping の強制された特権が削除されていることを確認することです。

$ runpd /usr/sbin/ping sif 
sif is alive runpd: child terminated with a status of 0 
process /usr/sbin/ping pid 5138 lacking privilege net_rawaccessto create raw
socket (Oct 25 18:33) process /usr/sbin/ping pid 5138 lacking privilege sys_
net_config to manage transport opts (Oct 25 18:33)

ADMIN_HIGH ワークスペースに移動し、ログファイルに特権デバッグのメッセージがあるかどうかを調べます。

次に、典型的な特権デバッグのログエントリを示します。

$ cat /var/log/privdebug.log
Mar 29 12:18:43 hostname unix: DEBUG: pathname_of_command pid 
process_ID lacking privilege number to 
number_of_type_of_access number_resource

次の例は、ping で runpd を実行したときの privdebug.log エントリを示しています。

Oct 25 18:33:35 tribble unix: DEBUG: /usr/sbin/ping pid 5138 lacking privilege
36 to create raw socket
Oct 25 18:33:35 tribble unix: DEBUG: /usr/sbin/ping pid 5138 lacking privilege
68 to manage transport opts

「privilege」の後に特権番号が表示されます。この特権番号を /usr/include/sys/tsol/priv_names.h ファイルで検索すると、特権の名前がわかります。たとえば、特権番号 36 は、net_rawaccess という名前の特権に割り当てられています。特権番号とその後の「to」に続く番号は、試行されたアクセスの種類で、その後に資源の番号が表示されます。

必要な特権を割り当てる方法については、「コマンドに強制された特権を付与するには」を参照してください。また、プロファイルマネージャを使用して継承可能な特権を割り当てる方法については、第 8 章「ユーザーおよび役割のための実行プロファイルの管理」を参照してください。

注 -
コマンドが強制された特権または継承可能な特権を使用するためには、その特権がコマンドの許容された特権セットで使用可能になっている必要があります。

特権デバッグを無効にするには、手順 3 から手順 4 までで変更した /etc/system ファイルと /etc/syslog.conf ファイルの内容をすべて元に戻し、コンピュータを再起動します。

コマンドに強制された特権を付与するには

ファイルの所有者、ファイル所有者承認の役割を持つユーザー、またはセキュリティ管理者として、プログラムファイルが格納されているディレクトリに移動します。

指定のディレクトリに移動するにはファイルマネージャを使うか、コマンド行から cd(1) コマンドを使います。詳しくは、『OpenWindows ユーザーズガイド』および『Solaris 共通デスクトップ環境ユーザーズ・ガイド』を参照してください。

ファイルが実行可能であることを確認します。

ファイルマネージャの「アクセス権 (Permissions)」ダイアログボックスで所有者、グループ、その他の「実行 (Execute)」チェックボックスにチェックマークが付いていることを確認します。ファイルマネージャの「アクセス権 (Permissions)」オプションについての詳細は、『Trusted Solaris ユーザーズガイド』を参照してください。プロファイルに setfpriv（1） コマンドが設定されていて、コマンドのプログラムファイルの所有者でもある場合、デフォルトのセキュリティ管理者役割である場合、あるいは「ファイルの所有者を変更」承認を持っている場合は、コマンド行から setfpriv（1） を実行して、他のユーザーがそのコマンドを実行できるようにすることもできます。

コマンドに割り当てられている「許容された特権」が、これから割り当てる予定の「強制された特権」と同じであることを確認します。
1. ファイルマネージャの「アクセス権 (Permissions)」ダイアログボックスで、「許容された特権 (Allowed)」を選択して許容された特権を割り当て、次に「強制された特権 (Forced)」を選択して強制された特権を割り当てます。
2. 自分に割り当てられているプロファイルの 1 つに、必要な特権と一緒に setfpriv(1) が設定されている場合 (デフォルトでは、セキュリティ管理者役割) は、setfpriv を使用して許容セットと強制セットに同じ特権を割り当てます。
  
  次の例では、file_dac_read と file_dac_write を許容された特権と強制された特権に設定しています。
  $ setfpriv -s -f file_dac_read,file_dac_write -a file_dac_read,file_dac_write test.priv.file

トラステッドプログラムをトラステッドライブラリにリンクするには

セキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動します。

詳細は、「ログイン後、特定の管理役割になるには」を参照してください。

可能な場合は、特権アプリケーションが使用する共用ライブラリを表 1-4 に示したデフォルトのトラステッドライブラリディレクトリに移動します。
表 16-4 共用ライブラリのデフォルトディレクトリ

トラステッド C 関数ライブラリ X サーバー用トラステッド拡張

/usr/lib /usr/openwin/lib

/etc/lib /usr/dt/lib

特権を必要とするアプリケーションの共用ライブラリをトラステッドディレクトリに移動できない場合は、rtld ファイルにそのライブラリ用のディレクトリ名を追加します。
1. 「管理用エディタ」アクションを使用して、/etc/security/tsol/rtld ファイルを新規に作成するか、既存のファイルを開いて編集します。
  
  詳細は、「管理用エディタアクションを使用してファイルを編集するには」を参照してください。
2. ライブラリディレクトリのパス名を指定します。
  
  複数のパス名を指定するときは、それぞれをコロンで区切らなければなりません。
  /usr/lib/libname1:/usr/lib/libname2
3. rtld ファイルを保存し、処理を終了します。
  :wq

特権コマンドを実行するプロファイルシェルスクリプトを作成するには

注 -

継承された特権を使ってコマンドを実行するプロファイルシェルスクリプトを追加する場合、プロファイルマネージャを使って適切なプロファイルを更新する必要があります。この手続きによってシェルスクリプト内で動作するコマンドが登録され、コマンドに適切な特権が割り当てられます。ある役割が、新しいプロファイルシェルスクリプトを使う必要がある場合、特権を必要とするすべてのコマンドを、そのスクリプト名とともに、役割に適用される Custom role_name またはその他のプロファイルに追加します。これは、セキュリティ管理者役割の仕事です。

プロファイルシェルスクリプトを作成するための条件は、テキストエディタを使用できることです。

スクリプトの 1 行目は /bin/pfsh （この他のシェルは使用しません）で開始します。
#!/bin/pfsh

特権が必要なコマンドと、このコマンドに必要な特権を判断します。

次の例では、/usr/lib/fs/nfs/nfsfind は cron ジョブで、スーパーユーザーが所有しています。これを ADMIN_HIGH で正常に実行するには、特権が必要です。tfind コマンドには file_dac_search 特権と file_dac_read 特権が必要で、rm コマンドには file_dac_search、file_mac_write、file_dac_read、file_mac_write の各特権が必要です。詳細は、「アプリケーションに必要な特権を調べるには」を参照してください。

#!/bin/pfsh
# Copyright (c) 1993, 1997, 1998, 1999 by Sun Microsystems, Inc.
#ident  "@(#)nfsfind.sh 1.5     97/05/21 SMI; TSOL 2.x"
#
# Check shared NFS filesystems for .nfs* files that
# are more than a week old.
# 
# These files are created by NFS clients when an open file
# is removed. To preserve some semblance of Unix semantics
# the client renames the file to a unique name so that the
# file appears to have been removed from the directory, but
# is still usable by the process that has the file open.
if [ ! -s /etc/dfs/sharetab ]; then exit ; fi
 for dir in `awk '$3 == "nfs" {print $1}' /etc/dfs/sharetab`
do 
    tfind $dir -M -name .nfs¥* -mtime +7 -mount -exec rm -f {} ¥;
done

セキュリティ管理者役割になり、ADMIN_LOW シェルに移動します。

詳細は、「ログイン後、特定の管理役割になるには」を参照してください。

プロファイルマネージャを使用して適切なプロファイルを更新します。シェルスクリプト内で実行するコマンドを記述し、そのコマンドに必要な特権を割り当ててください。

詳細は、「管理アプリケーションを起動するには」を参照してください。

この例の場合、スーパーユーザーが必要な特権を使用して cron スクリプトを実行するためには、セキュリティ管理者がプロファイルマネージャで Custom Root プロファイル (デフォルトでスーパーユーザーに割り当てられています) を更新します。プロファイルは、file_dac_search 特権と file_dac_read 特権を持つ tfind コマンドと file_dac_search、file_dac_write、file_dac_read、file_mac_write の各特権を持つ rm コマンドを含むように変更されます。

注意 -
プロファイルにコマンドを追加し、そのコマンドに特権やその他のセキュリティ属性を付与すると、そのコマンドは、プロファイルシェルスクリプト内だけでなく、プロファイルシェルのコマンド行から呼び出された場合でも、付与された特権を使用して実行されます (呼び出し元のユーザーにコマンドが追加されたプロファイルが割り当てられている場合)。プロファイルが複数割り当てられている場合は、その順番も重要です。これは、プロファイルシェルでコマンドやアクションを実行する際、最初のプロファイルに指定されているセキュリティ属性が使用されるためです。たとえば、tfind が特権付きで Custom Root プロファイルに登録されており、このプロファイルが tfind を含む最初のプロファイルである場合、スーパーユーザー役割がプロファイルシェルのコマンド行から tfind を実行すると、tfind は Custom Rootプロファイルに指定された特権を継承します。

プロファイルシェルで特権コマンドを実行する標準シェルスクリプトを作成するには

注 -

ユーザーは、特権付きのコマンドを実行する標準シェルスクリプトを作成できます。作成したスクリプトをプロファイルに追加し、スクリプトに含まれるコマンドに必要なすべての特権を使って実行されるように指定してください。すると、このスクリプトを含むプロファイルを持つユーザーによってプロファイルシェルから呼び出されるとき、スクリプトは特権を継承します。

スクリプトの 1 行目は、(/bin/pfsh ではなく) 任意の標準シェルで開始します。
#!/bin/csh
シェルスクリプトを記述するための条件は、テキストエディタを使用できることです。

特権が必要なコマンドと、このコマンドに必要な特権を判断します。

詳細は、「アプリケーションに必要な特権を調べるには」を参照してください。autosetpriv という例では、セキュリティ管理者は、強制された特権と許容された特権の定義済みセットを executable と呼ばれるファイルに割り当てます。このスクリプトの setfpriv コマンドには、 file_setpriv 特権が必要です。

注 -
このシェルスクリプトは、例として作成されています。通常のシェルスクリプトは特権とファイル名を引数として受け取り、エラー検査を行います。ここで紹介するシェルスクリプトは、例の中で指定した特権を executable という実行可能ファイルに割り当てる目的以外では、使用できません。これを実行したユーザーは全員は、「強制された特権」と「許容された特権」を使用できるようになります。
#!/bin/csh setfpriv -s -f ipc_mac_write,ipc_upgrade_il,proc_setsl,sys_trans_label -a ipc_mac_write,ipc_upgrade_il,proc_setsl,sys_trans_label executable

セキュリティ管理者役割になり、ADMIN_LOW シェルに移動します。

詳細は、「ログイン後、特定の管理役割になるには」を参照してください。

プロファイルマネージャを使って適切なプロファイルを更新します。シェルスクリプト内で実行されるコマンドを記述し、そのコマンドに適切な特権を割り当ててください。

詳細は、「プロファイルマネージャを起動するには」を参照してください。

setfpriv コマンドに必要な file_setpriv 特権を使用して autosetpriv と呼ばれるスクリプトを実行するためには、セキュリティ管理者がプロファイルマネージャで Object Privileges プロファイル (デフォルトでセキュリティ管理者役割に割り当てられています) を更新し、autosetpriv スクリプトを追加し、autosetpriv に file_setpriv 特権を割り当てます。

必要に応じて、プロファイルシェル内でシェルスクリプトのテストやデバッグを行なったり実行したりします。
$ autosetpriv

ブート時に実行するコマンドに拡張セキュリティ属性を使用するかどうかを指定するには

注 -

デフォルトの boot プロファイルに、ブート時に Trusted Solaris の拡張セキュリティ属性を使って呼び出されるコマンドを追加することは避けてください。デフォルトのプロファイルを変更するのではなく、新しいプロファイルを作成し、新しい sysh(1M) スクリプト内で setprof コマンドを使うようにしてください。次に、この手順を説明します。

希望のコマンドを呼び出したり停止させたりする新しい sysh スクリプトを作成します。

詳細は、『Solaris のシステム管理 (第 1 巻)』の実行制御スクリプトに関する記述、sysh(1M)マニュアルページ、「ブート時にコマンドを実行するには」を参照してください。このスクリプトの先頭行は次のようになります。
#!/bin/sysh
注 -
シェルスクリプトを作成するための条件は、テキストエディタを使用できることです。

setprof オプションを使って実行プロファイルの名前を指定します。

このスクリプトの 2 行目は次のようになります。new_profile_name は特定のプロファイル名で置き換えます。
setprof new_profile_name

セキュリティ管理者役割になり、ADMIN_LOWワークスペースに移動します。

詳細は、「ログイン後、特定の管理役割になるには」を参照してください。

このスクリプトを /etc/init.d ディレクトリにインストールし、このスクリプトに対するハードリンクを適切な /etc/rcn.d 内に作成します。

以下の例では、/etc/init.d 内の新しいスクリプトの名前を new_script とします。new_script を /etc/rc2.d/S89new_script と /etc/rc2.d/K8new_script にリンクするには次のように入力します。
$ pwd /etc/init.d $ ln new_script /etc/rc2.d/S89new_script $ ln new_script /etc/rc2.d/K89new_script
1. コマンドを呼び出したり停止させたりする各実行レベルに対応する /etc/rcn.d ディレクトリに移動し、適切な名前を持つ対象ファイルから /etc/init.d ディレクトリへのリンクを作成します。
2. 対象ファイルの名前には、コマンドの呼び出しならば S 、停止ならば K という接頭辞を付けます。
3. 各実行レベルへの移行時にスクリプトが実行される順番が判るように、対象ファイルの名前には適切な番号を含めます。
  $ cd /etc/rc2.d $ ln /etc/init.d/scriptname [S|K]nnscriptname

新しいプロファイルを作成し、新しいスクリプト内のコマンドに対して Trusted Solaris セキュリティ属性を割り当てます。
1. プロファイルマネージャを起動し、ネームサービスを選択します。
  
  詳細は、「実行プロファイル中内にコマンドを指定するには」を参照してください。
2. ネットワークサービスが開始される前にコマンドを呼び出す場合は、プロファイルマネージャの「ネームサービス(Naming Service)」メニューで「なし (None)」を選択し、プロファイルが /etc/security/tsol/tsolprof 内にローカルに作成されるようにします。
3. ネットワークサービスが開始されてからコマンドを呼び出す場合は、プロファイルマネージャの「ネームサービス(Naming Service)」メニューで「NIS+」を選択し、プロファイルが NIS+ マスター上の tsolprof NIS+ マップ内に作成されるようにします。
4. プロファイルマネージャを使用して、コマンドを設定し、GID、機密ラベル、認可上限を割り当てる、新しいプロファイルを作成します (任意)。

「トラステッドパス (TP)」メニューの「シャットダウン」オプションを使ってコンピュータをシャットダウンし、起動監視プロンプトからリブートします。
ok boot

ファイルを編集したときに特権を保存および復元するには

セキュリティ管理者役割になり、getfpriv(1) を使って、実行可能ファイルの特権の一覧を表示し、その出力を保存します。

次の例では、一覧の出力を一時ファイルに保存しています。
$ getfpriv executable_file > tempfile

実行可能ファイルを編集してから、ファイルマネージャを使用して、必要に応じてファイルを実行可能にし、一時ファイル内に保存されている特権を復元します。

パート III ホストおよびネットワーク管理

第 9 章 Trusted Solaris におけるホスト管理およびネットワーク管理の概念

トラステッドネットワーク通信の確認

トラステッドネットワークの目的

Trusted Solaris ネットワークの例

同機種セキュリティドメインの例

図 9-1 単一のセキュリティドメイン

異機種システム混在ネットワーク

図 9-2 異機種システム混在ネットワーク

ホストタイプ、テンプレート、プロトコル

図 9-3 tnrhtb データベースのテンプレート名一覧 : 「追加 (Add)」メニュー

複数のセキュリティドメイン例

図 9-4 2 つのセキュリティドメイン

ネットワーク認可範囲の条件

図 9-5 認可範囲の異なる 2 つのセキュリティドメイン

ネットワークにおけるセキュリティ属性の搬送方法

IP オプション

パケットの CIPSO ラベル

パケットの RIPSO ラベル

ルーティング

背景

修正版 TCP/IP ルーティング機能

用語と概念

ルーター

ルーティングテーブル

SRI

拡張 RIP

拡張メトリック

sec_response パケット

クラスタ / 雲

図 9-6 イントラネット内のクラスタの例

トンネリング

図 9-7 イントラネット内の非 Trusted Solaris クラスタを通過するトンネリング

静的ルーティング

動的ルーティング

in.rdisc

in.routed

動的ルーティングまたは静的ルーティングの決定

図 9-8 ホストが使用するルーティングの種類の確定方法

認可チェック

送信メッセージにおける MAC の実施

転送メッセージにおける MAC 検査

着信メッセージにおける MAC の実施

静的ルーティングの設定

図 9-9 単一セキュリティドメインの 4 台のホスト間で行われるホップ数 0 の通信例

図 9-10 単一ゲートウェイで構成された 2 つのセキュリティドメインのデフォルトルートとネットワークルートの例

図 9-11 3 つのネットワーク間通信に設定された tsolgateways ファイルの例

図 9-12 複雑なゲートウェイ構成とルーティングテーブルの例

トラステッドルーティングの設定

トラステッドルーティングの考慮事項

図 9-13 送信側ホストのトラステッドネットワークファイルの定義

図 9-14 パケット転送前にゲートウェイで実行される検査

図 9-15 受信側ホストで実行される検査

単一ラベルのゲートウェイで複数のラベルのパケットを転送可能にするには

第 10 章 トラステッドネットワークデータベース におけるセキュリティ属性の指定とルーティング設定

トラステッドネットワークデータベース

図 10-1 データベースマネージャの「読み込み (Load)」リストで選択された Tnidb

各ホストタイプに設定可能なセキュリティ属性

テンプレートマネージャで各ホストタイプに割り当てられるテンプレート

TRUSTED SOLARIS 7、2.5.1、2.5 (sun_tsol) ホストタイプ

図 10-2 Tnrhtp で Trusted Solaris 7、2.5.1、2.5 ホストタイプに設定できるフィールド

TSIX (tsix) ホストタイプ

図 10-3 Tnrhtp で TSIX ホストタイプに設定できるフィールド

TRUSTED SOLARIS 1.2、1.1 (msix) ホストタイプ

図 10-4 Tnrhtp で TRUSTED SOLARIS 1.2、1.1 ホストタイプに設定できるフィールド

CIPSO (cipso) ホストタイプ

図 10-5 Tnrhtp で CIPSO ホストタイプに設定できるフィールド

RIPSO (ripso) ホストタイプ

図 10-6 Tnrhtp で RIPSO ホストタイプに設定できるフィールド

ラベルなし (unlabeled) ホストタイプ

図 10-7 Tnrhtp でラベルなしホストタイプに設定できるフィールド

トラステッドネットワークデータベースにおけるエントリの作成

tnrhdb オプションを使用して、閉鎖型または開放型ネットワーク構成を実現する

階層型代替機構

ワイルドカードを使用した開放型ネットワーク構成

閉鎖的制御型のネットワーク構成

テンプレートの設定

トラステッドネットワークデータベースの属性に関する優先規則

図 10-8 属性の優先規則

図 10-9 Tnidb データベースの le0 インタフェースへのデフォルトエントリ

`in.rdisc`

`in.routed`

図 9-11 3 つのネットワーク間通信に設定された `tsolgateways` ファイルの例

第 10 章トラステッドネットワークデータベースにおけるセキュリティ属性の指定とルーティング設定

ホストテンプレートまたはネットワークインタフェースエントリに認可範囲を設定するには

第 11 章ファイルおよびファイルシステムの管理