IPA:セキュアなインターネットサーバー構築に関する調査

(1)

(2)

1. 本書の概要 ... 1 1.1. 調査の概要 ... 1 1.2. 調査期間 ... 1 1.3. 調査対象 ... 1 1.4. 調査方法 ... 2 1.5. 想定される読者... 4 2. Trusted Solaris の概要 ... 5 2.1. Trusted Solaris の変遷 ... 5 2.2. Trusted Solaris のセキュリティアーキテクチャー ... 6 2.2.1. DAC（任意アクセス制御）と MAC（強制アクセス制御） ... 7 2.2.2. RBAC（役割ベースのアクセス制御）... 7 2.2.3. 最小特権（Least Privileges）... 11 2.2.4. TP（高信頼経路）... 12 2.2.5. MLS（マルチレベルセキュリティ）... 13 2.2.6. トラステッドネットワーク... 15 3. 構築 ... 17 3.1. 本章の目的 ... 17 3.2. OS インストール ... 18 3.2.1. ハードウェア要件... 18 3.2.2. インストール作業... 18 3.2.3. インストール後の作業... 27 3.3. カーネルパラメータ... 32 3.3.1. /etc/system... 32 3.3.2. /etc/security/tsol/label_encodings... 37 3.4. セキュリティポリシーのファイル構成... 47 3.4.1. 定義ファイル... 47 3.4.2. 設定ツール... 48 3.4.3. RBAC 定義 ... 52 3.4.4. 特権定義... 77 3.4.5. ラベル定義... 87 3.4.6. 特権デバック... 89 3.4.7. トラステッドネットワーク定義... 95 3.5. セキュリティポリシーの定義... 107

(3)

3.5.1. Web サーバー ... 113 3.5.2. DNS サーバー ... 120 3.5.3. SMTP サーバー ... 139 3.5.4. FTP サーバー ... 162 3.5.5. セキュリティポリシーの妥当性確認... 168 4. 運用 ... 185 4.1. 本章の目的 ... 185 4.2. 導入計画 ... 185 4.2.1. Trusted Solaris 導入におけるメリット ... 185 4.2.2. Trusted Solaris 導入におけるデメリット ... 186 4.3. 信頼性の確保... 187 4.3.1. 保護対象... 187 4.3.2. 保護非対象... 188 4.3.3. 信頼性確保の基本方針... 190 4.4. システム管理... 191 4.4.1. 監査および診断... 191 4.4.2. 保護範疇外の管理指針... 204 5. コスト評価 ... 207 5.1. 対象者のスキル... 207 5.2. 実施手順 ... 208 5.3. 結果 ... 208 5.3.1. 理解度 ... 209 5.3.2. 作業工数... 210 5.3.3. 設定ミス・設定漏れ... 211 5.4. 評価・分析 ... 212 5.4.1. 理解度 ... 213 5.4.2. 作業工数... 214 5.5. 結論 ... 215

(4)

変更履歴変更日時箇条番号変更内容 2003/4/14 1.4 「調査方法」説明の追加 2003/4/14 1.5 「想定される読者」説明の追加 2003/4/14 2.2.6 「トラステッドネットワーク」説明の追加 2003/4/14 3.4.4.1 「特権の定義と確認」項目および説明の追加 2003/4/14 3.4.4.2 「特権の取得と継承」タイトルの変更 2003/4/14 3.4.4.2(1) 「プロセスが特権を取得する方法」説明の追加と修正 2003/4/14 3.4.4.2(2) 「プロセスの特権が無効となる状態など」説明の追加と修正 2003/4/14 3.4.5 「ラベル定義」項目および説明の追加 2003/4/14 3.4.6 「特権デバッグ」項目レベルの変更(3.4.5 の追加に伴う変更) 2003/4/14 3.4.7 「トラステッドネットワーク定義」概要の削除(2.2.6 への移動) 2003/4/14 3.5(1) 「基本方針」マルチラベル構成に関する説明の削除(3.5.5.4 への移動) 2003/4/14 3.5(2) 「インターネットサーバ構築上の要領」タイトルの変更と説明の追加 2003/4/14 3.5.1-3.5.4 作業手順の統一化ネットワーク属性定義に関する説明の追加マルチラベル構成に関する説明の削除(3.5.5.4 への移動) 2003/4/14 3.5.5 妥当性の確認手順の変更 2003/4/14 3.5.5.4 「インターネットサーバの要塞化」項目および説明の追加 2003/4/14 4.3.1.1 「最小特権による保護」タイトルの変更 2003/4/14 4.3.1.2 「強制アクセス制御による保護」タイトルの変更 2003/4/14 5. コスト評価の項を全面修正

(5)

1. 本書の概要

1.1. 調査の概要

本書は、Sun Microsystems, Inc.が開発した Trusted Solaris を利用してインターネットサーバーを構築する際の理想的な設定・運用指針をまとめたものである。

Trusted Solaris は Solaris のセキュリティ機能を強化したセキュア OS である。Trusted Solaris は Solaris と同様サーバーやワークステーションとして用いることができる UNIX オペレーティング環境である。しかし、Trusted Solaris を用いてシステムの構築や運用またはアプリケーションの開発を行うには特別な知識が必要となっている。なぜならば、セキュリティ機能は強化されると同時に細分化されており、厳格なセキュリティポリシーに関する知識が必要となっているからである。しかしながら、Solaris と比べて、システム構築や運用またはアプリケーションの開発に関する情報量は極めて少なく、現在の最新バージョンである Trusted Solaris 8 については日本語マニュアルも存在していない。そこで、 Trusted Solaris の概要、機能を調査した上で、代表的なインターネットサーバーを構築する例を挙げ、ポリシーの定義、設定手順および運用手順を明確にしてゆく。これにより Trusted Solaris をベースとしたインターネットサーバーを構築・運用する際のガイドラインとしてまとめる。同時に Solaris と比べた場合の難易度・手間・負担といったものを読者に感じ取らせるという目的も含まれている。

1.2. 調査期間

本ガイドライン作成にあたっての調査実施期間は、2002 年 12 月から 2003 年 2 月である。

1.3. 調査対象

本ガイドラインは、Trusted Solaris8 4/01 を対象に調査をおこなった。また、調査対象となったインターネットサービスおよびバージョンを表 1-1 に示す。

(6)

表 1-1 調査・分析対象インターネットサービス

サービス名プログラム名バージョン URL

Web サーバー Apache 1.3.27 http://www.apache.org BIND 9.1.2rc http://www.isc.org DNS サーバー djbdns 1.0.5 http://cr.yp.to/djbdns.html sendmail 8.12.6 http://www.sendmail.org qmail 1.03 http://www.qmail.org SMTP サーバー postfix 2.0.0.2 http://www.postfix.org FTP サーバー wu-ftpd 2.6.1 http://www.wu-ftpd.org

1.4. 調査方法

本ガイドライン作成にあたっての調査では、標準、製品情報、およびインターネット上で入手可能な公開情報による文献調査に加え、Trusted Solaris のセキュリティポリシーの定義および妥当性の確認を実施することにより、以下の観点からの調査を実施した。構築面 Trusted Solaris のセキュリティ強化機能を理解するのに必要な概念を明らかにする。 Trusted Solaris のセキュリティポリシーを定義するファイルを明らかにし、その詳細について、構成内容、各項目の意味、また、留意すべき点などを明らかにする。 Trusted Solaris のセキュリティポリシーを定義する際の、設定方法、確認方法、また、具体的な構築例における、セキュリティポリシーの考え方や、注意すべき点などを明らかにする。運用面 Trusted Solaris 導入にあたっての留意点を明らかにする。 Trusted Solaris によって確保される信頼性の範囲を明らかとし、その留意点を明らかとする。 Trusted Solaris 導入後のシステム管理者に関する指針・留意点を明らかとする。コスト面

一般的な UNIX によるインターネットサーバー構築経験者が、Trusted Solaris を利用してインターネットサーバーを構築する際にかかる工数を明らかとする。

(7)

調査環境

調査環境として図 1-1 に示すネットワークを構築した。Public Network と Private Network の間にはファイアーウォールが存在し、DMZ 内にマシンを配置し各ソフトウェアを構築、調査するものとする。

WWW/FTP サーバー、SMTP/DNS サーバー、および構築や管理のためのクライアントの一台が Trusted Solaris 8 4/01 である、また、Solaris 8 との比較を行うための検証や確認のためのサーバー、および構築や管理のクライアントのための一台は Solaris 8 4/01 である。各種の設定や検証の作業については Private Network 内の構築・管理用のマシンから DMZ のマシンに接続しておこなった。なお、今回の調査ではファイアーウォールは対象の範囲外である。 Private Network DMZ F/W Public Network WWW/FTP SMTP/DNS 検証・確認構築・管理構築・管理図 1-1 調査環境表 1-2 調査対象サーバ # サーバホスト名 IP アドレス FQDN ホスト名 1 SMTP/DNS macaroni 192.168.0.102 macaroni.tscorp.com 2 WWW/FTP gpan 192.168.0.103 gpan.tscorp.com

(8)

1.5. 想定される読者

本ガイドラインは、Trusted Solaris を利用してインターネットサーバーを構築するための指針をまとめたものである。Trusted Solaris は、Solaris をベースであるためコマンドおよび設定ファイル等は非常に類似している。そのため、Solaris におけるアクセス制御、 RBAC、audit 等セキュリティに関することに精通されている読者は比較的理解できるであろう。本ガイドラインは、以下に挙げるスキルを有している読者を想定して作成されている。 UNIX の利用者の経験がある UNIX のインストール経験がある UNIX のインターネットサーバーの構築経験があるまた、以下に挙げるスキルについて有していることが望ましい。 UNIX の業務システムの構築または運用の経験がある TCSEC など歴史的なセキュリティの概念を理解しているなお、本調査はセキュア OS である Trusted Solaris におけるインターネットサーバーのガイドラインを定義するものでマニュアルではないことを考慮して頂きたい。そのため調査するソフトウェアについては、基本的な設定のみを記述し詳細な内容については割愛している。より詳細な設定を行いたい場合は、ソフトウェアのマニュアル等を参考にして頂きたい。

(9)

2. Trusted Solaris の概要

2.1. Trusted Solaris の変遷

Trusted Solaris は、Sun Microsystems, Inc.が、自社のオペレーティング環境である Solaris のカーネルやライブラリのセキュリティに関わる機能について、その機能強化を行っているオペレーティング環境である。最新バージョンである Trusted Solaris 8 4/01 は、Sun Microsystems, Inc.が、TCSEC の B1 を満たすオペレーティングシステムとして初めて米国でリリースした Trusted Solaris 1.1 からマイナーとメージャーなバージョンアップを合わせて 7 世代目になる。

また、Trusted Solaris のセキュリティ評価基準への対応については、Trusted Solaris 1.1 の時代には TCSEC による評価を試みたが、機密性を重視したセキュリティ機能の評価から多様なセキュリティ機能の評価が可能となる評価基準自体の世代変革に応じて、ITSEC また Common Criteria による評価へ変遷してきている。

Trusted Solaris 2.5.1 は ITSEC の E3/F-B1 および E3/F-C2 の認定を取得している。また Trusted Solaris 8 4/01 は、Common Criteria の CAPP1_、RBACPP2_{および LSPP}3_{のプロテクショ}

ンプロファイルについて EAL4 の認定を取得している。また、評価対象としてネットワーク分散環境やウィンドウ・システムを含めて行っていることが特徴である。

リリース時期4 _{Trusted Solaris バージョン (オリジナルバージョン)}

1994 年 4 月 Trusted Solaris 1.1 (SunOS 4.1.3) 1995 年 5 月 Trusted Solaris 1.2 (SunOS 4.1.3) 1997 年 7 月 Trusted Solaris 2.5 (Solaris 2.5.1) 1998 年 9 月 Trusted Solaris 2.5.1 (Solaris 2.5.1) 1999 年 11 月 Trusted Solaris 7 (Solaris 7) 2000 年 11 月 Trusted Solaris 8 (Solaris 8)

2002 年 1 月 Trusted Solaris 8 4/01 (Solaris 8 4/01)

Trusted Solaris の Solaris からの機能強化点の最も特徴的なことは、従来のスーパーユーザベースのセキュリティモデルを役割ベースのセキュリティモデルに変更し、完全なスーパーユーザの排除を実現していることである。このモデルは Trusted Solaris 1.1 の時代に既に確立されており、現在は Solaris 自体にもこれをモデルとした基本的な機能が実装されている。

1_{Controlled Access Protection Profile, Issue 1.d} 2_{Role Based Access Control Protection, Issue 1.0} 3_{Labeled Security Protection Profile, Issue 1.b}

(10)

2.2. Trusted Solaris のセキュリティアーキテクチャー

オペレーティングシステムにおけるセキュリティの概念では、サブジェクトとオブジェクトという抽象化した表現が用いられ、サブジェクトのオブジェクトに対するアクセスを制御するポリシーやアーキテクチャーが重要とされている。この概念は UNIX のアーキテクチャーに直接的に関連付けることが可能である。概ねサブジェクトはプロセスとその属性でありオブジェクトはファイルとその属性と考えることができる。そもそも UNIX は処理を行うプロセスとその対象であるファイルという単純化されたモデルに基づいて設計されている。そしてファイルにはディレクトリ、シンボリックリンク、ディスクなどのハードウェアデバイス、ターミナル、プリンタシステム、メモリなどの仮想デバイス、パイプ、ソケットなどの通信のための抽象化されたファイル、などすべてのデータ入出力の対象となるものが含まれている。

Trusted Solaris も Solaris も UNIX であり、オペレーティング環境としてのセキュリティ機能は、プロセスの属性とファイルの属性に基づいている。セキュリティに関わるプロセスの属性はクレデンシャルとして実装されおり、ファイルの属性は抽象化された仮想ノー

(11)

ド属性として実装されている。

一方、Trusted Solaris は Solaris のセキュリティ機能を強化したものであることに違いはないが、世代が進むにつれ互いのセキュリティ機能は共通する部分が多くなってきている。現在、Trusted Solaris 8 と Solaris 8 や Solaris 9 では、任意アクセス制御、役割ベースのアクセス制御、セキュリティ属性を格納するプロファイルの機構、またこれらに関連するデーターベースファイル、および管理ツールが統合されている。

2.2.1. DAC

5

_{（任意アクセス制御）と MAC}

6

_{（強制アクセス制御）}

DAC（任意アクセス制御）が、管理者および利用者の任意によりアクセス制御が行われるという意味であるのに対して、MAC（強制アクセス制御）は、システムにより決められたポリシーに基づいたアクセス制御が強制されるという意味である。従来のオペレーティングシステムで採用されている DAC の機構では、オブジェクトの属性の一つは所有者であり、サブジェクトの属性の一つはユーザ識別である。オブジェクトの所有者はオブジェクトに対するサブジェクトのアクセスを許可したり禁止したりすることを任意に設定することが可能となっている。また、このアクセス制御方針では、ユーザ識別の一つとして、スーパーユーザと呼ばれる特別なユーザ識別が存在し、その識別を持つサブジェクトはすべての権限が許可される、スーパーユーザ権限を持つことになる。 MAC の機構では、オブジェクトの属性とサブジェクトの属性が拡張され、システムで決められたポリシーに基づく制御の判断をするための属性が付加されている。その一つは機密度を表すタグであり、これはラベルと呼ばれ、MLS（マルチレベルセキュリティ）の要となっている。このアクセス制御方針については、2.2.5 において解説している。

Solaris では、DAC のみを実装しているが、Trusted Solaris では、DAC と MAC の両者を実装している。ただし Trusted Solaris ではスーパーユーザと呼ばれる特別な識別は存在しない。

2.2.2. RBAC

7

_{（役割ベースのアクセス制御）}

従来のオペレーティングシステムは、スーパーユーザになれるユーザ（管理者）全員にスーパーユーザ権限が与えられることになり、管理者に必要以上の権限が与えられている。それに対し RBAC（役割ベースのアクセス制御）の機構は、管理のための一連の作業を担うユーザに制限付きの管理権限を割り当てることを可能にする。この管理権限には一連の管

5 _{Discretionary Access Control} 6_{Mandatory Access Control}

(12)

理作業を果たすために必要十分な権限が含まれ、これにより管理者に必要以上の権限を与えず、危機の最小化と分散を実現するものである。

Trusted Solaris 8 と Solaris 8 や Solaris 9 では次の機構により RBAC を実装している。

役割一連の管理作業の実行を目的とした特殊なユーザアカウントプロファイル特殊な属性を持つ承認と実行属性をグループ化する機構承認制限付きの機能へのアクセス権を付与する権限実行属性プロセス実行時に特別に付与されるセキュリティ属性セキュリティ管理者は、特定の作業のための、承認、実行属性、その他のセキュリティ属性を含むプロファイルを作成する。作成されたプロファイルは、ユーザまたは役割に割り当てることができる。役割は、ユーザに割り当てることができる。役割を割り当てられたユーザは、役割へのアクセス権を取得する。

ところで、Solaris 8 や Solaris 9 が、スーパーユーザ（通常、uid=0(root)）が制限を受けずすべての権限が与えられる、スーパーユーザポリシーモデルのシステムであることには変わりがない。それ対し、Trusted Solaris 8 では次の変更と拡張がされている。スーパーユーザの排除（uid=0(root)の無効化）ユーザや役割に定義できるセキュリティ属性プロファイルに定義できる承認とコマンドおよびアクションコマンドやアクションに定義できるセキュリティ属性（最小特権の採用）

(13)

図 2-2 RBAC の構成

2.2.2.1. ユーザと役割（Roles）

役割は、一連の管理作業を行うための特殊なユーザアカウントである。役割にアクセスするためには、特定の役割になることを許可されたユーザが自分自身のユーザアカンントにログインした後に、特定の手続きにより役割へのアクセスの認証を受けなればならない。たとえば CDE8_{のログインウィンドウから、通常のログインを行う手順ではこのアカウント} にアクセスすることができない。役割へのアクセスが許可されたユーザは、役割へのアクセスの認証の後、通常のアカウントでは使用できない特殊なセキュリティ属性による作業が可能となる。

Trusted Solaris 8 では Solaris 8 や Solaris 9 より、役割やユーザに与えることができるセキュリティ属性が拡張されている。また、役割になる手続きや、役割の作業を行う環境では、Trusted Path をベースとする、強化された保全機構が実装されている。Trusted Solaris 8 では次の手続きにより役割になることができる。

(14)

特定の役割になることが許可されたユーザが、CDE のログインウィンドウから、自分自身のユーザアカウントにログインした後に、拡張された CDE の「Trusted Path (TP) menu」から「Assume rolename Role」を選択して、役割のアカウントにログインする。

2.2.2.2. プロファイル（Execution/Rights Profiles）

プロファイルは、承認や実行属性をグループ化し、それをユーザや役割に割り当てるための統合機構である。プロファイルは、一定のセキュリティポリシーをユーザや役割に適応すべき状況において、セキュリティポリシーを統合できる環境を提供し、セキュリティポリシーの構築や管理を行う上で、強力なツールである。

Trusted Solaris 8 では Solaris 8 や Solaris 9 より、きめ細かく細分化されたセキュリティ属性からなるセキュリティポリシーを管理するために、プロファイルは不可欠の機構となっている。また、プロファイルは、システムで提供されるサービスに対して、様々な承認や実行属性を付与するための環境としても利用されている。そのようなプロファイルとしては次のものが挙げられる。 boot プロファイルブート時に起動するサービスに対して、承認や実行属性を付与する。 inetd プロファイル inetd により、随時起動されるサービスに対して、承認や実行属性を付与する。

2.2.2.3. 承認（Authorizations）

承認は、制限された機能へのアクセス権を付与する権利である。承認は、何が承認されていて、誰が承認を作成したかを示す固有の文字列で表される。制限された機能をユーザや役割が実行できるかどうかは、特定の特権プログラムが承認を検査して判定する。

Trusted Solaris 8 では Solaris 8 や Solaris 8 より、利用できる承認の種類が拡張されている。

2.2.2.4. 実行属性（Execution Attributes）

実行属性は、コマンドのアクションの実行などにより派生するプロセスに対して、実行時に付与することができるセキュリティ属性である。

(15)

プロセスに付与されるセキュリティ属性（通常、クレデンシャル）として、ID（実 UID、実 GID、実効 UID、実効 GID）9_{が挙げられる。}

Trusted Solaris 8 では Solaris 8 や Solaris 9 に対して、最小特権や機密ラベルをベースとする変更と拡張がされている。

2.2.3. 最小特権（Least Privileges）

最小特権は、RBAC を補完する機構である。スーパーユーザポリシーモデルのシステムでは、アクセス制御（通常、任意アクセス制御）の機構内で、スーパーユーザの ID（通常、 uid=0(root)）は常に特別な意味を持ち、すべての制限を回避することができる、つまりスーパーユーザの ID を持つプロセスはすべての権限を得ることになる。 Solaris 8 や Solaris 9 では、役割に対して、コマンド単位に特別の ID を付与して実行することを許可することにより、必要十分なコマンドを特別な ID で実行する実行権を与え、管理作業を可能としている。 Trusted Solaris では、アクセス制御の機構内において、スーパーユーザの ID は特別な意味を持たず、スーパーユーザの ID を持つプロセスも通常の ID を持つプロセスも違いがなくなっている。そして、その代わりとしてきめ細かな特権を定義し、プロセスにきめ細かな特権を付与して実行することを可能とし、コマンドやアクションにより実行される個々プロセスに対して、必要十分な権限のみを与える、よりきめ細かな最小特権を実現している。 Trusted Solaris では、アプリケーションの実行可能ファイルに割り当てられた特権および呼出プロセスまたは親プロセスに対応付けられた特権に基づいて、プロセスの有効な特権が決定される。アプリケーションで特権を有効には、次の二つ以上の特権セットをアプリケーションに割り当てる。どれに割り当てるかは、アプリケーションをどのようにユーザに許可するか、または、アプリケーションの起動方法やプログラムの呼び出し関係によりに決定される。許容セットアプリケーションの実行可能ファイルに対応付けられる「許容された特権」は、他の条件が満たされていることを前提に、アプリケーションで使用することができる。許容された特権セットは、プロセスが特権を使うことができるかどうかを決める一般的な判定要因であるため、ここから特権を除外すると、どのユーザも、アプリケーションで、その特権を有効にできなくなる。強制セット

(16)

Ⅰ-12 Copyright © 2003 IPA, All Rights Reserved. アプリケーションの実行可能ファイルに対応付けられる「強制された特権」は、アクセス権のあるユーザがアプリケーションを実行すると、無条件に有効になる。なお、許容セットに含まれていない特権を強制セットに追加することはできない。継承可能セットアプリケーションのプロセスに対応付けられる「継承可能な特権」は、プロファイルでアプリケーションに割り当てられた特権と、呼び出しプロセスから継承された特権の組み合わせで、プロセスが起動すると有効になる。ただし、アプリケーションの許容された特権セットに含まれていることが前提である。

2.2.4. TP

10

_{（高信頼経路）}

TP（高信頼経路）は、TCSEC で定義された、TCB11_{（高信頼コンピューティング基盤）}_、およびセキュリティカーネルの概念のなかで、権限を持つユーザ（通常、管理者）が、信頼できないアプリケーションやオペレーティングシステムの信頼できない層を介さずに、直接 TCB にアクセスできることを保証するための機構である。 Trusted Solaris では、プロセスに付与されるセキュリティ属性の一つとして TP を実装している。そして、役割のシェル（プロファイルシェル）や CDE のワークスペースは、正当な手続きにより役割になった場合のみ、TP のセキュリティ属性を持ち、それが有効である限りにおいてのみ、制限された特権を持つコマンドやアクションを実行することを可能としている。つまり TP の範囲内でのみ権限の行使を可能としている。 10_{Trusted Path}

(17)

図 2-3 TCB の構成

2.2.5. MLS

12

_{（マルチレベルセキュリティ）}

MLS（マルチレベルセキュリティ）は、TCSEC で定義された、MAC を実現する、すべてのサブジェクト（ユーザやプロセスなど）とオブジェクト（ファイル、ディレクトリ、デバイス、ウィンドウ､ソケットなど）に対して、ユーザの信用度、情報の機密度、重要度などに応じたラベルを付与し、アクセスの制御を実現する機構である。MLS では、サブジェクトには機密ラベル（SL : Sensitivity Label）と許可上限（Clearance）が付与され、オブジェクトに対するアクセスを行う場合には、オブジェクトに付与された機密ラベルルとの優位性により、アクセスを許可するかのどうかの判定を行う。 Trusted Solaris では、次の二つの条件が満たされれば、一方の機密ラベルはもう一方よりも「優位」であるとみなされる。一方の機密ラベルの格付けがもう一方の格付けと同等であるか、それよりも高い場合

(18)

Ⅰ-14 Copyright © 2003 IPA, All Rights Reserved. 一方のコンパートメントのセットにもう一方のコンパートメントがすべて含まれる場合格付けが同じで、持っているコンパートメントのセットが同じである場合、二つのラベルは「同等」とみなされる。ラベルが同等の場合は、互いに優位であると言えるため、アクセスが許可される。一方のラベルの格付けがもう一方のラベルの格付けよりも高い場合や、一方のラベルのコンパートメントにもう一方のラベルのコンパートメントがすべて含まれる場合、前者のラベルは後者のラベルよりも「完全に優位」であるとみなされる。ラベルに優劣が付けられない場合は、これらのラベルは「無関係」または「比較不能」とみなされる。さらにラベルを理解する上で重要な事項を以下に示す。管理ラベル（Administrative Label）

Trusted Solaris には、「ADMIN_HIGH」と「ADMIN_LOW」の 2 種類の特別な管理ラベルが提供されており、これらを機密ラベル、認可上限として使用する。この 2 種類のラベルは管理者用で、通常のユーザが使用することはできない。「ADMIN_HIGH」は、システム内の最上位のラベルで、管理データベースや監査トレールなどのシステムデータが読み取られないよう保護するためのものである。 ADMIN_HIGH のラベルのデータを読み取るには、作業を ADMIN_HIGH (一般に管理役割に設定) に切り替えるか、上位読み取り用の特権が必要になる。「ADMIN_LOW」は、システム内の最下位のラベルである。必須アクセス制御により、ユーザは、サブジェクトの機密ラベルよりも低い機密ラベルのファイルにはデータを書き込めない。したがって、最下位の機密ラベルである ADMIN_LOW をファイルに適用すれば、一般ユーザは、そのファイルを読み取ることしかできなくなる。ADMIN_LOW は、通常、一般の実行可能ファイルと定義ファイルが変更されないように保護する目的で使用される。ADMIN_LOW で作業しているユーザと下位書き込み用の特権を持ったユーザだけが、このラベルを持つファイルに書き込むことができる。認可範囲（Accreditation Ranges）認可範囲は、ユーザのクラスに適用されるラベル範囲である。この範囲は、組織のセキュリティポリシーの一部として、セキュリティ管理者により承認され設定されるものである。

システム認可範囲（System Accreditation Ranges）

管理者が使用する全機密ラベルである。ここには管理ラベルが含まれる。システム認可範囲の規則は、システムが許可していないラベルの組み合わせを除外するためのものである。

ユーザ認可範囲（User Accreditation Ranges）

システム認可範囲内で 1 人のユーザが潜在的にアクセスできる最も広範なラベルのセット、つまり、システム認可範囲のサブセットである。ここには管理ラベルは含まれない。

(19)

なお、Trusted Solaris のラベルの定義ファイル（label_encodings ファイル）は、米国防情報局(Defense Intelligence Agency)の標準的なラベル作成のためのラベル作成ソフトウェアリリース 2.2 で処理される標準的なエンコーディング指定の形式(関連文書：国防情報局発行 DDS-2600-6215-93)に基づいた、ラベルの名前およびビットエンコード形式などを記述している。図 2-4 ラベルの概念

2.2.6. トラステッドネットワーク

Trusted Solaris では各種のトラステッドネットワークプロトコルをサポートしている。トラステッドネットワークプロトコルは、標準のプロトコルに対して拡張されたセキュリティ属性、許可上限、機密ラベル、実効 UID/GID、特権、監査などを付加することを可能とする。これにより、ネットワークを介した End-to-End の通信において、ラベルの許可範囲の指定や、異なる Trusted OS のシステム間における、拡張されたセキュリティ属性の解釈を可能としている。 Trusted Solaris 8 でサポートするトラステッドネットワークプロトコルのセキュリティ

(20)

オプションのタイプを次に示す。

unlabeled ラベル属性を持たない標準の IP

sun_tsol Trusted Solaris で用いられるラベル属性を持つ IP ripso Revised IP Security Option をサポートする IP cipso Commercial IP Security Option をサポートする IP

tsix TSIG(Trusted System Interoperability Group)の TSIX(RE) 1.1 また、これらの IP フレームにおける実装位置の違いを図 2-5 に示す。IP オプションに実装される CIPS や RIPSO の場合は、経由するネットワーク機器が対応してない場合があるので注意が必要である。それに対して、SAMP に実装される TSIX や TSOL の場合は、経由するネットワーク機器の対応を気にする必要がないものである。

(21)

3. 構築

3.1. 本章の目的

本章では、Trusted Solaris を利用してインターネットサーバーを構築する上での、システム設定やセキュリティポリシー設定に関する留意点をガイドラインとしてまとめる。構成は、「インストール」、「カーネルパラメータ」、「セキュリティポリシーのファイル構成」、そして「セキュリティポリシーの定義」からなっている。「インストール」では、Trusted Solaris のインストールに関する留意点を記述する。「カーネルパラメータ」では、Trusted Solaris カーネルパラメータおよびラベルエンコーディングに関する留意点を記述する。「セキュリティポリシーのファイル構成」では、Trusted Solaris のセキュリティポリシーを設定する上で必要となる、また知っておかなければならない各ファイルの構成やその目的を説明する。さらに、Trusted Solaris で追加・変更されたツールやコマンドに関しても説明する。最後に、「セキュリティパラメータの定義」では表 3-1 に示す代表的なインターネットサービスを構築する場合の、セキュリティポリシーに関する実例を示して解説を行い、セキュリティポリシー設定時の留意点についてまとめる。表 3-1 代表的なインターネットサービスプログラム # サービス名プログラム名 URL

1 Web サーバー Apache http://www.apache.org/

2 BIND 9 http://www.isc.org/products/BIND/ 3 DNS サーバー djbdns http://cr.yp.to/djbdns.html 4 sendmail http://www.sendmail.org/ 5 qmail http://www.jp.qmail.org/ 6 SMTP サーバー postfix http://www.postfix.org/ 7 FTP サーバー wu-ftpd http://www.wu-ftpd.org/

(22)

3.2. OS インストール

ここでは、SPARC アーキテクチャにおいて Trusted Solaris 8 をインストールする方法を説明する。Trusted Solaris は、Solaris 同様 CD-ROM インストールの他にネットワークを利用したインストール（Jumpstart インストールを含む）がサポートされている。ネットワークインストール（Jumpstart インストール）は、CD-ROM が利用できないシステムや一度に数多くのインストールを行う際に有効なインストール方法である。

3.2.1. ハードウェア要件

執筆での最新版の Trusted Solaris は Trusted Solaris 8 （4/01)となっている。これは、 Solaris 8 （4/01)ベースに開発されており Trusted Solaris における対応ハードウェアはこれに準拠する。また、最低限必要なハードウェア要件を以下にまとめた。

SPARC CPU（Ultra SPARCⅡi 以上推奨)

ハードディスク 2G バイト（4G バイト以上推奨) メモリ 128M （256M バイト以上推奨）

3.2.2. インストール作業

CD-ROM を利用したインストールは、Solaris と特別違いはない。そのため、Solaris をインストールした経験がある場合は、簡単にインストールすることができると思う。Network インストール（Jumpstart）も特に違いはないが、インストールサーバーとして Trusted Solaris を利用する場合は、いくつかの事前設定が必要になる。また、今回 Jumpstart を用いたインストール方法は省略する。Jumpstart に必要な rules、profile、sysidcfg ファイル等の内容は Solaris と同様であるため、Trusted Solaris または Solaris のマニュアルを参考にして頂きたい。

3.2.2.1. CD-ROM インストール

ここでは、CD-ROM を利用したインストール方法を説明する。また、前提条件として 1.2.1 のハードウェア要件を満たしているシステムかつフレームバッファを搭載した

(23)

システム13_{を対象としている。}

(1) 最初の作業

まず、システムの電源をいれる。すると、OBP（Open Boot Program)が起動する。この際、PROM の環境変数 auto_boot=true になっている場合は、Stop + A ボタンを押し起動を停止する。すると ok プロンプトが表示される。そこで、Trusted Solaris Software 1 of 2 CD（SPARC)を CD-ROM ドライブに挿入し以下のようにブートをおこなう。

リスト 3-1 CD-ROM からのブート ok boot cdrom

ブートして数十秒後、以下の言語の選択画面が表示されるので、ここでは 4. Japanese を選択する。次にロケールは、0. Japanese EUC (ja)を選択する。

(24)

Ⅰ-20 Copyright © 2003 IPA, All Rights Reserved. リスト 3-2 言語選択 Select a Language 0. English 1. French 2. German 3. Italian 4. Japanese 5. Korean 6. Simplified Chinese 7. Spanish 8. Swedish 9. Traditional Chinese

Please make a choice (0 ‐ 9), or h or ? for help: 4 リスト 3-3 ロケール選択 Select a Language

0. Japanese EUC (ja)

1. Japanese PC Kanji (ja_JP.PCK) 3. Japanese UTF-8 (ja_JP.UTF-8) 4. Go Back to Previous Screen

Please make a choice (0 - 3), or press h or ? for help: 0

ここまで選択すると OpenWindows ディスクトップが起動し対話式にインストールが継続される。以後は、表示されるウィンドウ名とそれに対するアクションを示す。

(25)

表 3-2 対話式インストールウィンドウ名アクション Solaris インストールプログラム [継続]ボタンを押すシステムを確認してください。 [継続]ボタンを押すネットワーク接続性ネットワークを利用するので「はい」を選択して[継続]ボタンを押す。 DHCP DHCP は利用しないため[いいえ]を選択し[継続]ボタンを押す。ホスト名 Trusted Soaris のホスト名を入力し[継続]ボタンを押す。 IP アドレスホスト名に対応した IP アドレスをを入力し [継続]ボタンを押す。サブネットサブネットを設定するため、[はい]を選択して[継続]ボタンを押す。ネットマスクシステムのネットマスクを入力し[継続]ボタンを押す。 IPv6 IPv6 は利用しないため、[いいえ]を選択し[継続]ボタンを押す。情報の確認現在までに設定をおこなった項目の確認し、間違いがなければ[継続]を押す。間違いおよび変更がある場合は、[変更]を押す。セキュリティポリシーの構成 Kerberos 認証は利用しないため、[いいえ]を選択し、[継続]を押す。情報の確認 Kerberos の情報に間違いがなければ[継続]を押す。間違いおよび変更がある場合は、[変更] を押す。ネームサービスネームサービスは、インストール後に設定を行うため[None]を選択し[継続]を押す。情報の確認ネームサービスの情報を確認し、間違いがなければ[継続]を押す。間違いおよび変更がある場合は、[変更]を押す。時間帯時間帯は、[地域]、[GMT との時差]どちらで指定しても構わない。ここでは、[地域]を利用することとする。[地域]を選択し[設定]を押す。地域地域は[Asia, Eastern]、時間帯は[Japan]を選択し[継続]を押す。日付と時刻特に現在の時刻に間違いがなければ[継続]を押す。情報の確認時間帯、日時と時刻の確認を行い間違いがなければ[継続]を押す。間違いおよび変更がある場合は、[変更]を押す。 Solaris 対話式インストールここでは新規インストールのため[初期]を押す。 Solaris 対話式インストール [継続]を押す。

地域の選択アジア- Japanese EUC (ja)を選択し[継続]

を押す。

ソフトウェアの選択サーバーのインストールに必要なソフトウェアが含まれている[Entire Distribution]を選択する。また、[Solaris 64 ビットサポートをインストールする]が選択できる場合は

(26)

Ⅰ-22 Copyright © 2003 IPA, All Rights Reserved. ディスクの選択インストールするディスクが[選択されたディスク]にない場合は、[使用可能なディスク]からディスクを選択し”>”で追加する。また、ブートディスクを変更する場合は、[ブートディスクの選択]で変更する。完了後、[継続]を押す。データを保存しますか？ディスクに保存するディスクが存在する場合は[保存]、ない場合は[継続]を押す。ファイルシステムを自動配置しますか？自動配置を行う場合は[自動配置]、手作業で配置する場合は[手作業による配置]を押す。ここでは、[手作業による配置]を行う。ファイルシステムとディスク配置ファイルシステムを構成する場合、[カスタマイズ]を押す。ディスクの容量に応じて各スライスに割り当てる。割り当て完了後、[了解]、 [継続]と押す。リモートファイルシステムをマウントしますか？特にリモートマウントの必要性がなければ [継続]を押す。プロファイルプロファイル情報を確認し、間違いがなければ[インストール開始]を押し、変更および間違いがあれば[変更]を押す。リブートインストール後、自動リブートまたは手動リブートを選択する。ここでは[自動リブート] を押す。以上までの項目に答えるとインストールが開始される。Software 1 of 2 のインストールが完了すると自動的にリブートする。 (2) リブート後の作業システムのリブート後、インストールの続きが開始される14_{。その前に、root のパ} スワードを入力する必要がある。リスト 3-4 パスワード入力 Root password:

Press Return to continue.

次に、Solaris 8（SPARC）Software 2 のインストールのメディアタイプを聞かれるので、1. CD を選択する。選択は、1 を入力後、[Enter]を押す。その後、Trusted Solaris Software 2 of 2 CD（SPARC）を CD-ROM ドライブに挿入するように要求されるので、メディア挿入後[Enter]を押す。

以上を行うと Trusted Solaris Software 2 of 2 CD（SPARC）のインストールが開

14_{システムによっては以下の電源管理に関する質問が出る場合がある。サーバーとして利用する場合は、}

(27)

始される。完了後、2 を入力後[Enter]を押すと CD が取り出される。次に、Solaris 8 Languages（SPARC）のインストールに進むが、Trusted Solaris では、Language CD が存在しないため、ここでは 3. Skip を選択する。その後、システムがリブートする。

3.2.2.2. ネットワークインストール

ネットワークインストールでは、システムに Trusted Solaris をインストールする前にインストールサーバーを設定する必要がある。このインストールサーバーは、Trusted Solaris、Solaris どちらでも構わない。また、Solaris においては Intel Solaris でもインストールサーバーを設定することが可能である。

(1) インストールサーバーの設定

(A) インストールサーバーが Solaris の場合

Trusted Solaris Software 1 of 2 CD（SPARC）を CD-ROM ドライブに挿入しマウントする。このマウントは、Volume Management 機能を利用しても手動でマウントしても構わない。また、ディスクに CD-ROM イメージをコピーするため、2G バイト以上の空き容量があることを確認しておく。以下にインストールサーバーを設定するための手順を示す。設定はすべて primaryadmin にて行う。リスト 3-5 インストールサーバーの設定（Solaris）（特権シェルを起動する。） $ sh （CD イメージをコピーするディレクトリを作成する。） # mkdir -p /jumpstart/TS8

（Trusted Solaris Software 1 of 2 CD（SPARC）を挿入しコピーする。） # cd /cdrom/tsol_8_401_sparc/s0/Trusted_Solaris_8/Tools

# ./setup_install_server /jumpstart/TS8 # cd /

# eject cdrom

（Trusted Solaris Software 2 of 2 CD（SPARC）を挿入しコピーする。） # cd /cdrom/tsol_8_401_sparc_2/Solaris_8/Tools

# ./add_to_install_server /jumpstart/TS8 # cd /

(28)

(B) インストールサーバーが Trusted Solaris の場合

インストールサーバーが Trusted Solaris の場合は、Trusted Network 情報としてホストの属性データベース（tnrhdb データベース）にホスト情報を登録する必要がある。

この設定は、Solaris Management Console15_{を利用するか、または primaryadmin}

役割16_{の特権シェルにて tnrhdb データベースを直接編集する。直接編集した場合に} は tnctl コマンドにより tnrhdb データベースの更新を行う。リスト 3-6 tnrhdb ファイルクライアントのテンプレート名の追加 127.0.0.1:tsol 0.0.0.0:admin_low 192.168.0.102:tsol 192.168.0.103:tsol リスト 3-7 tnrhdb の更新 tnctl -H /etc/security/tsol/tnrhdb

さらに、インストールサーバーが Trusted Solaris の場合は、Volume Management 機能は標準では利用できない。CD-ROM などのデバイスを利用するためには、マウントを行う前に Allocate Device 機能によるデバイスの割り当てを行う必要がある。

この設定は、CDE のアクションを利用するか、または primaryadmin 役割の特権シェルにおいてコマンドラインで行う。

15_{Solaris Management Console につていは 3.2.3.1 にて解説する。} 16_{primaryadmin 役割については 3.2.3.1 にて解説する。}

(29)

リスト 3-8 デバイスの確認 $ sh

# list_devices -l

（リストの中に device: cdrom_0 が確認でた場合は、このデバイス名が cdrom のデバイスある。）

リスト 3-9 デバイスの割り当て # allocate cdrom_0

Insert disk labeled ADMIN_LOW in cdrom_0. (y to continue, n to cancel) （[y]とタイプする。）

Do you want cdrom_0 mounted? (y/n) （[y]とタイプする） # df -k （確認すると/cdrom/root-cdrom_0/以下にマウントされていることがわかる。）その後、(A)と同様に CD-ROM のイメージをハードディスク内にコピーする。リスト 3-10 インストールサーバーの設定（Trusted Solaris）（CD イメージをコピーするディレクトリを作成する。） # mkdir -p /jumpstart/TS8

（Trusted Solaris Software 1 of 2 CD（SPARC）を挿入しコピーする。） # mount -F hsfs -o ro /dev/dsk/<cd-rom ドライブの指定> /cdrom # cd /cdrom/Trusted_Solaris_8/Tools

# ./setup_install_server /jumpstart/TS8 # cd /

# deallocate cdrom_0

（Trusted Solaris Software 2 of 2 CD（SPARC）を挿入しコピーする。） # mount -F hsfs -o ro /dev/dsk/<cd-rom ドライブの指定> /cdrom # cd /cdrom # cd /cdrom/Solaris_8/Tools # ./add_to_install_server /jumpstart/TS8 # cd / # deallocate cdrom_0 (2) クライアントの設定クライアントの設定は、ネットワークインストールをするクライアントの MAC アドレス、およびホスト名をそれぞれ/etc/ethers、/etc/hosts に登録する。

(30)

Ⅰ-26 Copyright © 2003 IPA, All Rights Reserved. リスト 3-11 ethers ファイルへのクライアント MAC アドレスの追加 8:0:20:c3:45:db macaroni リスト 3-12 hosts ファイルへのクライアント IP アドレスの追加 192.168.0.102 macaroni 次に、サーバー側で NFS サーバーが起動されていない場合は起動する。リスト 3-13 NFS サーバーの起動 # ps -ef ￨ grep nfs （/usr/lib/nfs/nfsd がない場合は起動する。） # /etc/init.d/nfs.server start （/usr/lib/nfs/nfsd がない場合） # share - /jumpstart/TS8 ro.anon=0 “” （ディレクトリが共有されているか確認する。）次に、 /etc/bootparms を作成する。このファイルを作成するために、 add_install_client を利用する。リスト 3-14 bootparam の作成 # cd /jumpstart/TS8/Trusted_Solaris_8/Tools

# ./add_install_client macaroni sun4u

（クライアントホスト名とクライアントプラットフォーム名を入力する。） (3) クライアントの起動サーバーの設定が完了するとクライアントからブートする。ブートは、ok プロンプトから以下のように行う。リスト 3-15 クライアントのブート ok boot net この後については、3.2.2.1 と同様、対話式インストールが開始される。

(31)

3.2.3. インストール後の作業

インストール直後の状態では、ユーザとして install 役割として root のみが存在する。 install ユーザはインストールのみで利用する一時的なもののため、運用に必要なユーザの作成後は削除する必要がある。また、root 役割はインストールに必要な相当の権限が一時的に与えられているため、運用に必要な役割の作成後は権限を他の役割に委譲し利用できないようにする必要がある（root 役割はアプリケーションから通常の root として利用されるため削除することはできない）。

次に Solaris Management Console（SMC）を用いて基本的な役割を作成する。その後ユーザを作成することになるが、ユーザのセキュリティ情報として管理ラベル以外の一般のラベルを設定する必要があるため、ユーザの作成はラベルの定義を行う label_encodings ファイルの設定の後にする方が良い。

3.2.3.1. 役割の作成

インストール直後において、dtlogin 画面からユーザ install でログイン17_{する。ログイ} ンすると図 3-1 の画面を確認することができる。

(32)

図 3-1 install ユーザログインイメージ

install ユーザは root 役割になることが許可されている root 役割のセッションを開始する。この手順については、3.4.2(A)にて解説している。

その後 Solaris Management Console を起動し root 役割のセッションを開始する。この手順については、3.4.2(B)にて解説している。

Note:

(33)

図 3-2 SMC 初期イメージ

標準的なインストールとして、root 役割の他、secadmin 役割、admin 役割、oper 役割の三つの役割を作成する。ここでインターネットサーバー構築に有用な primaryadmin 役割も作成することとする。この手順については 3.4.3.1(2)(A)にて解説している。 (1) secadmin 役割セキュリティ管理者の secadmin 役割の設定情報である。secadmin 役割はセキュリティに関する管理を行う。例えば、パスワードの設定や、拡張されたセキュリティの設定等である。

(34)

表 3-3 secadmin 役割情報

Role Name secadmin

Full Name secadmin

Description security administrator

Role ID Number 101

Role Shell Administrator’s Bourne

Password 任意

Profile Custom Secadmin Role Information Security Rights Security

Home Directory /etc/security/tsol/home/secadmin

Users Assigned 任意

(2) admin 役割

システム管理者の admin 役割の設定情報である。admin 役割は Solaris において root が行う管理タスクの殆ど実行できる。例えば、ファイルシステム追加や、アプリケーションの追加等である。

表 3-4 admin 役割情報

Role Name admin

Full Name admin

Description system administrator

Role ID Number 100

Password 任意

Profile Custom Admin Role

System Administrator

Home Directory /etc/security/tsol/home/admin

(3) oper 役割

オペレーターである oper 役割の設定情報である。oper 役割は運用時のオペレーションを行う。例えば、システムのバックアップ等である。

(35)

表 3-5 oper 役割情報

Role Name oper

Full Name oper

Description Operator

Role ID Number 102

Password 任意

Profile Custom Oper Role

Operator

Home Directory /etc/security/tsol/home/oper

(4) primaryadmin 役割

primararyadmin 役割は、セキュアなインターネットサーバー構築などシステムの開発などを行う場合に便利な役割である。

Note:

primaryadmin 役割に与えられる Privileged Shell プロファイルは、シェル（sh、csh、ksh）を起動すると全特権の利用を許可された特権シェルになる。この特権シェルは緊急目的や開発目的など以外では利用可能とするべきではない。運用時には利用できないようにする。

表 3-6 primaryadmin 役割情報

Role Name primaryadmin

Full Name primaryadmin

Description primary administrator

Role ID Number 104

Password 任意

Profile Privileged Shells

Home Directory /etc/security/tsol/home/primaryadmin

(36)

3.3. カーネルパラメータ

Trusted Solaris のカーネルパラメータは、Solaris のカーネルパラメータを拡張したものであり、/etc/system ファイルに格納されている。また、Trusted Solaris 独自のラベルの定義は、カーネルパラメータと同様にシステムブート時に読み込まれるものとして、 /etc/security/tsol/label_encordigs ファイルに格納されている。ここではこの二つのファイルについて解説する。

3.3.1. /etc/system

Trusted Solaris においても Solaris 同様/etc/system にカーネルパラメータとその値を記述することができる。パラメータとして、Solaris に用意されているもの意外に Trusted Solaris に特化したものも存在する。ここでは、その部分についてのみ説明する。Solaris のカーネルパラメータについては、Solaris のマニュアルを参考にして頂きたい。

3.3.1.1. system ファイルの構成

次に挙げるパラメータは Trusted Solaris でのみ有効なものである。 (1) tsol_admin_high_to_cipso

tnrhtp テンプレートで tsix を利用する場合に必要である。Trusted Solaris では ADMIN_HIGH ラベルは CIPSO ラベルをマップするにはサイズが大きいため、ADMIN_HIGH ラベルで転送できないように設定されている。これを転送できるようにするためには、このパラメータを有効にする必要がある。デフォルトは 0 である。また、デフォルトではこのパラメータは/etc/system に存在しない。追加することで有効にすることができる。 (2) tsol_clean_windows このパラメータは、システムコールから戻る度にアクティブではない登録ウィンドウが消去される。デフォルトでは１に設定されており、0 にするとシステムコールから戻ってきた後登録ウィンドウからカーネル情報を返す可能性がある。

(37)

(3) tsol_flush_buffers ブロックが i ノードにリンクされてからディスクに書き込まれるまでの間に障害が発生したと想定する。その際、次のブートでは、起動の際に fsck が行なわれるが、この fsck 後でもディスクブロックがファイルシステムにリンクされている可能性がある。そこで、データブロックが i ノードが更新される前にフラッシュするように設定を行なうものである。デフォルトでは 1 になっている。 (4) tsol_hide_upgraded_names 通常、ディレクトリやファイルを優位な機密ラベルに変更するにはプロセスに file_mac_write または file_upgrade_sl 特権が必要である。これらによって優位になった機密ラベルのファイルおよびディレクトリは、デフォルトでは、アクセスすることはできないが ls コマンド等でファイルを確認することができる。このパラメータを設定するとプロセスよりも優位な機密ラベルのファイルおよびディレクトリは表示されなくなる18_{。デフォルトでは 0 に設定されている。} (5) tsol_privs_debug プロセスがどの特権を使っているか調べるコマンドとして runpd がある。このコマンドを実行するためには、このパラメータを 1 にする必要がある。デフォルトでは 0 にされている。 Note: runpd の実行を有効にすると、プロセスの特権情報が取得されるだけではなく、特権がなくてもプロセスが起動できるようになるため、必要時のみに設定することを推奨する。

(38)

3.3.1.2. system ファイルのサンプル

リスト 3-16 system

*ident "@(#)system 1.24 00/02/08 SMI; TSOL 2.x" *

* SYSTEM SPECIFICATION FILE *

* moddir: *

* Set the search path for modules. This has a format similar to the * csh path variable. If the module isn't found in the first directory * it tries the second and so on. The default is /kernel /usr/kernel *

* Example:

* moddir: /kernel /usr/kernel /other/modules

* root device and root filesystem configuration: *

* The following may be used to override the defaults provided by * the boot program:

*

* rootfs: Set the filesystem type of the root. *

* rootdev: Set the root device. This should be a fully

* expanded physical pathname. The default is the * physical pathname of the device where the boot * program resides. The physical pathname is * highly platform and configuration dependent. *

* Example:

* rootfs:ufs

* rootdev:/sbus@1,f8000000/esp@0,800000/sd@3,0:a *

* (Swap device configuration should be specified in /etc/vfstab.)

* exclude: *

* Modules appearing in the moddir path which are NOT to be loaded, * even if referenced. Note that `exclude' accepts either a module name, * or a filename which includes the directory.

*

* Examples:

* exclude: win

(39)

* forceload: *

* Cause these modules to be loaded at boot time, (just before mounting * the root filesystem) rather than at first reference. Note that * forceload expects a filename which includes the directory. Also * note that loading a module does not necessarily imply that it will * be installed. * * Example: * forceload: drv/foo * set: *

* Set an integer variable in the kernel or a module to a new value. * This facility should be used with caution. See system(4).

*

* Examples: *

* To set variables in 'unix': *

* set nautopush=32 * set maxusers=40 *

* To set a variable named 'debug' in the module named 'test_module' *

* set test_module:debug = 0x13 * ======================================= * Trusted Solaris Configuration Variables *

* tsol_hide_upgraded_names *

* When operating at a specific SL, there are occasions in which a * directory will contain upgraded files and/or subdirectories. * In some environments, it is required that a process not be able * to learn about upgraded entries. Setting this flag controls * whether upgraded filenames are returned with getdents(2).

* There is a performance penalty in that all directory entries must * be examined before returning the results to the calling process. *

* Value:

* 0 Do not hide upgraded names * 1 Hide upgraded names

set tsol_hide_upgraded_names=0

* tsol_privs_debug *

(40)

* problems with applications. *

* The first step is to enable the debugging functionality. Set * the kernel variable tsol_privs_debug via this file, uncomment * the /var/log/privdebug.log line in the /etc/syslog.conf file, * and reboot the machine.

*

* The second step is to start the program (that you want to

* debug the required privileges of) through the Trusted Path mechanism * and runpd(1M). When started in this fashion, the process

* simply logs the failed operation/privilege combination, then * proceeds as though the privilege were actually in the effective * set. This allows integrators to determine what privileges are * required, and why they are required, to get applications to work. *

* The final step, after the application(s) have been privileged * debugged, is to reset this variable and reboot the machine. *

* Value:

* 0 Disable debugging mechanism * 1 Enable debugging mechanism set tsol_privs_debug=0

* tsol_clean_windows *

* Clean register windows before returning from system call. * This is for object reuse. It is possible for a system call * to return kernel information is an inactive register window. * A value of 1 will prevent this at a cost of clearing

* inactive register windows on return from each system call. *

* Value:

* 0 Disable cleaning of inactive windows after system call * 1 Enable cleaning of inactive windows after system call set tsol_clean_windows=1

* tsol_flush_buffers *

* Controls the order of disk buffer flushing with respect to * inode updates. There is a timing window where blocks could be * linked on to an inode and not yet written to disk and a machine * crash in this state would leave old disk blocks (possibly of * higher label, or another users) linked to a file after fsck * recovers the file system. Setting this switch ensures that * data blocks are flushed before inodes are updated on disk. * There is a small performance penalty.

*

* Value:

* 0 Disable forced data flushing before inode updates * 1 Enable forced data flushing before inode updates set tsol_flush_buffers=1

(41)

3.3.2. /etc/security/tsol/label_encodings

label_encodings ファイルは、MLS を構成する、機密ラベルの名称と値、また、それらの相互運用ポリシーを定義するファイルはである。 Trusted Solaris では次の二つのタイプから構成される機密ラベルを実装している。格付け（Classification）階層的機密分類に用いられるラベル

（例）REGISTERD > NEED_TO_KNOW > INTERNAL_USE_ONLY > PUBLIC コンパートメント（Compartment）

非階層的な組織的分類に用いられるラベル

（例）SYSTEM_ADMINISTRATION, MANUFACTURING, ENGINEERING, HUMAN_RESOURCES これらは label_encodings ファイルにより、システム上では、人に読める文字列として表されるが、システム内部では、格付けは 2bytes の数値、コンパートメントの 256bits のビット列で表されている。

(42)

3.3.2.1. label_encodings ファイルの構成

label_encodings ファイルは米国政府などの組織から支給される場合もある。このファイルはコンパートメントモードワークステーション（CMW）に必要なラベルとエンコードの定義が含まれている。コンパートメントモードワークステーションでは次のラベルが定義されている。認可上限（Clearance）機密ラベル（Sensitivity Label）情報ラベル（Information Label） label_encodings ファイルは次のセクションから構成されており、これらは必須のセクションとなっている。 CLASSIFICATIONS（格付け） INFORMATION LABELS（情報ラベル） SENSITIVITI LABELS（機密ラベル）

(43)

CLEALANCES（許可上限） CHANNEL PRINTER BANNERS ACCREDITATION RANGES（認可範囲） LOCAL DEFINITION label_encodings ファイルに関する詳細の説明とリファレンスについては、Trusted Solarsi 8 4/01 AnswerBook “Compartmented Mode Workstation Labeling : Encodings Format” （http://docs.sun.com/db/doc/816-1051）に記載されている。

Note:

情報ラベルについては、Trusted Solaris 7 以降ではサポートしていない。label_encodings ファイル中の INFORMATION LABEL セクションは SENSITIVITY LABELS セクションで指定するコンパートメントの定義と同様の定義がされている必要がある。

(1) CLASSIFICATIONS セクション

格付けは、機密ラベルまたは認可上限の階層的な部分である。各ラベルには一つのみ格付けがある。ラベル変換ソフトウェア19_{では、格付け値を 256 個に制限している。}

Trusted Solaris では 1∼255 の数値（整数）が、label_encodings ファイル中の各格付けに割り当てられる。値 0 は ADMIN_LOW 管理ラベルに予約されている。機密ラベルのうち格付け部分は、ファイルやディレクトリに含まれる情報の機密度に基づいた機密保護の相対的なレベルを示す。ユーザやアプリケーションを実行するプロセス、ユーザのコマンドなどに割り当てられた認可上限において、格付けは信頼度のレベルを示す。高い値を持つ格付けは、低い値の格付けよりも優位となる。表 3-7 格付けのタグ # タグ有効な値 1 name= 格付け名称 2 sname= 省略名称 3 aname= 代替名称 4 value= 格付けの値（1∼255 の整数） 5 initial compartments= 初期値として定義するコンパートメント

(44)

(2) INFORMATION LABELS/SENSITIVITI LABELS/CLEALANCES セクション

情報ラベル、機密ラベル、許可上限では、機密ラベルの格付け以外の部分を形成するコンパートメントを定義する。（情報ラベルは現在使われていない。）コンパートメントは、機密ラベルまたは認可上限で使用するオプションの一つである。他のトラステッドシステムでは、コンパートメントをカテゴリと呼ぶことがあり、また、政府機関ではチャネルと呼ぶこともある。コンパートメントは、割り当てられたビットで構成され、それらは階層的なものではない。しかし、コンパートメント間に階層関係を確立することもできる。一つコンパートメントのビットが、もう一つのコンパートメントのビットをすべて含む場合、前者は優位となる。

INFORMATION LABELS、SENSITIVITI LABELS、CLEALANCE セクションは次のサブセクションから構成されている。 WORDS REQUIRED CONBINATIONS CONBINATION CONSTRAINTS WORDS サブセクションは、label_encodings ファイルの中ではコンパートメントを定義する部分である。

REQUIRED CONBINATIONS サブセクションと CONBINATION CONSTRAINTS サブセクションではコンパートメントの組み合わせの制限を定義する部分である。表 3-8 コンパートメントのタグ（WORD サブセクション） # タグ有効な値 1 name= コンパートメント名称 2 sname= 省略名称 3 prefix= 接頭文字 4 suffix= 接尾文字 5 compartments= コンパートメントのビット列 6 minclass= このコンパートメントが利用可能な下限の格付け 7 maxclass= このコンパートメントが利用可能な上限の格付け 8 omniclass= initial compartments から隠蔽する文字

(3) CHANNELS/PRINTER BANNERS セクション

CHANNELS、PRINTER BANNERS セクションについては、Trusted Solaris では使われていない。リスト 3-21 のとおりの定義がされている必要がある。