第Ⅰ編 trusted solaris編 - ipa...(iii) 変更履歴変更日時箇条番号変更内容...

第Ⅰ編 Trusted Solaris 編

(i)

目次

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

(ii)

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

(iii)

変更履歴

変更日時箇条番号変更内容

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.　コスト評価の項を全面修正

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

セキュアなインターネットサーバーの設定と運用

Trusted Solaris 編

Ⅰ-1 Copyright © 2003 IPA, All Rights Reserved.

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 に示す。



Trusted Solaris 編


表 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 を利

用してインターネットサーバーを構築する際にかかる工数を明らかとする。



Trusted Solaris 編


調査環境

調査環境として図 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



Trusted Solaris 編


1.5. 想定される読者

本ガイドラインは、Trusted Solaris を利用してインターネットサーバーを構築するため

の指針をまとめたものである。Trusted Solaris は、Solaris をベースであるためコマンド

および設定ファイル等は非常に類似している。そのため、Solaris におけるアクセス制御、

RBAC、audit 等セキュリティに関することに精通されている読者は比較的理解できるであろ

う。

本ガイドラインは、以下に挙げるスキルを有している読者を想定して作成されている。

UNIX の利用者の経験がある

UNIX のインストール経験がある

UNIX のインターネットサーバーの構築経験がある

また、以下に挙げるスキルについて有していることが望ましい。

UNIX の業務システムの構築または運用の経験がある

TCSEC など歴史的なセキュリティの概念を理解している

なお、本調査はセキュア OS である Trusted Solaris におけるインターネットサーバーの

ガイドラインを定義するものでマニュアルではないことを考慮して頂きたい。そのため調

査するソフトウェアについては、基本的な設定のみを記述し詳細な内容については割愛し

ている。より詳細な設定を行いたい場合は、ソフトウェアのマニュアル等を参考にして頂

きたい。



Trusted Solaris 編


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および LSPP3のプロテクショ

ンプロファイルについて 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 4 リリース時期は米国におけるものである。また国内においてすべてがリリースされているわけではない。



Trusted Solaris 編


図 2-1 役割ベースのモデル

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

オペレーティングシステムにおけるセキュリティの概念では、サブジェクトとオブジェ

クトという抽象化した表現が用いられ、サブジェクトのオブジェクトに対するアクセスを

制御するポリシーやアーキテクチャーが重要とされている。この概念は UNIX のアーキテク

チャーに直接的に関連付けることが可能である。概ねサブジェクトはプロセスとその属性

でありオブジェクトはファイルとその属性と考えることができる。

そもそもUNIXは処理を行うプロセスとその対象であるファイルという単純化されたモデ

ルに基づいて設計されている。そしてファイルにはディレクトリ、シンボリックリンク、

ディスクなどのハードウェアデバイス、ターミナル、プリンタシステム、メモリなどの仮

想デバイス、パイプ、ソケットなどの通信のための抽象化されたファイル、などすべての

データ入出力の対象となるものが含まれている。

Trusted Solarisも Solarisも UNIXであり、オペレーティング環境としてのセキュリティ

機能は、プロセスの属性とファイルの属性に基づいている。セキュリティに関わるプロセ

スの属性はクレデンシャルとして実装されおり、ファイルの属性は抽象化された仮想ノー



Trusted Solaris 編


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

一方、Trusted Solaris は Solaris のセキュリティ機能を強化したものであることに違い

はないが、世代が進むにつれ互いのセキュリティ機能は共通する部分が多くなってきてい

る。現在、Trusted Solaris 8 と Solaris 8 や Solaris 9 では、任意アクセス制御、役割ベー

スのアクセス制御、セキュリティ属性を格納するプロファイルの機構、またこれらに関連

するデーターベースファイル、および管理ツールが統合されている。

2.2.1. DAC5（任意アクセス制御）と MAC6（強制アクセス制御）

DAC（任意アクセス制御）が、管理者および利用者の任意によりアクセス制御が行われる

という意味であるのに対して、MAC（強制アクセス制御）は、システムにより決められたポ

リシーに基づいたアクセス制御が強制されるという意味である。

従来のオペレーティングシステムで採用されている DAC の機構では、オブジェクトの属

性の一つは所有者であり、サブジェクトの属性の一つはユーザ識別である。オブジェクト

の所有者はオブジェクトに対するサブジェクトのアクセスを許可したり禁止したりするこ

とを任意に設定することが可能となっている。また、このアクセス制御方針では、ユーザ

識別の一つとして、スーパーユーザと呼ばれる特別なユーザ識別が存在し、その識別を持

つサブジェクトはすべての権限が許可される、スーパーユーザ権限を持つことになる。

MAC の機構では、オブジェクトの属性とサブジェクトの属性が拡張され、システムで決め

られたポリシーに基づく制御の判断をするための属性が付加されている。その一つは機密

度を表すタグであり、これはラベルと呼ばれ、MLS（マルチレベルセキュリティ）の要となっ

ている。このアクセス制御方針については、2.2.5 において解説している。

Solaris では、DAC のみを実装しているが、Trusted Solaris では、DAC と MAC の両者を

実装している。ただし Trusted Solaris ではスーパーユーザと呼ばれる特別な識別は存在

しない。

2.2.2. RBAC7（役割ベースのアクセス制御）

従来のオペレーティングシステムは、スーパーユーザになれるユーザ（管理者）全員に

スーパーユーザ権限が与えられることになり、管理者に必要以上の権限が与えられている。

それに対し RBAC（役割ベースのアクセス制御）の機構は、管理のための一連の作業を担う

ユーザに制限付きの管理権限を割り当てることを可能にする。この管理権限には一連の管

5 Discretionary Access Control 6 Mandatory Access Control 7 Role Based Access Control



Trusted Solaris 編


理作業を果たすために必要十分な権限が含まれ、これにより管理者に必要以上の権限を与

えず、危機の最小化と分散を実現するものである。

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

役割一連の管理作業の実行を目的とした特殊なユーザアカウント

プロファイル特殊な属性を持つ承認と実行属性をグループ化する機構

承認制限付きの機能へのアクセス権を付与する権限

実行属性プロセス実行時に特別に付与されるセキュリティ属性

セキュリティ管理者は、特定の作業のための、承認、実行属性、その他のセキュリティ

属性を含むプロファイルを作成する。作成されたプロファイルは、ユーザまたは役割に割

り当てることができる。役割は、ユーザに割り当てることができる。役割を割り当てられ

たユーザは、役割へのアクセス権を取得する。

ところで、Solaris 8 や Solaris 9 が、スーパーユーザ（通常、uid=0(root)）が制限を

受けずすべての権限が与えられる、スーパーユーザポリシーモデルのシステムであること

には変わりがない。それ対し、Trusted Solaris 8 では次の変更と拡張がされている。

スーパーユーザの排除（uid=0(root)の無効化）

ユーザや役割に定義できるセキュリティ属性

プロファイルに定義できる承認とコマンドおよびアクション

コマンドやアクションに定義できるセキュリティ属性（最小特権の採用）



Trusted Solaris 編


図 2-2 RBAC の構成

2.2.2.1. ユーザと役割（Roles）

役割は、一連の管理作業を行うための特殊なユーザアカウントである。役割にアクセス

するためには、特定の役割になることを許可されたユーザが自分自身のユーザアカンント

にログインした後に、特定の手続きにより役割へのアクセスの認証を受けなればならない。

たとえば CDE8 のログインウィンドウから、通常のログインを行う手順ではこのアカウント

にアクセスすることができない。役割へのアクセスが許可されたユーザは、役割へのアク

セスの認証の後、通常のアカウントでは使用できない特殊なセキュリティ属性による作業

が可能となる。

Trusted Solaris 8 では Solaris 8 や Solaris 9 より、役割やユーザに与えることができ

るセキュリティ属性が拡張されている。また、役割になる手続きや、役割の作業を行う環

境では、Trusted Path をベースとする、強化された保全機構が実装されている。Trusted

Solaris 8 では次の手続きにより役割になることができる。

8 Common Desktop Environment



Trusted Solaris 編


特定の役割になることが許可されたユーザが、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）

実行属性は、コマンドのアクションの実行などにより派生するプロセスに対して、実行

時に付与することができるセキュリティ属性である。



Trusted Solaris 編


プロセスに付与されるセキュリティ属性（通常、クレデンシャル）として、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 では、アプリケーションの実行可能ファイルに割り当てられた特権およ

び呼出プロセスまたは親プロセスに対応付けられた特権に基づいて、プロセスの有効な特

権が決定される。アプリケーションで特権を有効には、次の二つ以上の特権セットをアプ

リケーションに割り当てる。どれに割り当てるかは、アプリケーションをどのようにユー

ザに許可するか、または、アプリケーションの起動方法やプログラムの呼び出し関係によ

りに決定される。

許容セット

アプリケーションの実行可能ファイルに対応付けられる「許容された特権」は、他

の条件が満たされていることを前提に、アプリケーションで使用することができる。

許容された特権セットは、プロセスが特権を使うことができるかどうかを決める一般

的な判定要因であるため、ここから特権を除外すると、どのユーザも、アプリケーショ

ンで、その特権を有効にできなくなる。

強制セット

9 実 UID と実 GID は通常 uid と gid、実効 UID と実効 GID は通常 euid と egid と表現される。



Trusted Solaris 編


アプリケーションの実行可能ファイルに対応付けられる「強制された特権」は、ア

クセス権のあるユーザがアプリケーションを実行すると、無条件に有効になる。なお、

許容セットに含まれていない特権を強制セットに追加することはできない。

継承可能セット

アプリケーションのプロセスに対応付けられる「継承可能な特権」は、プロファイ

ルでアプリケーションに割り当てられた特権と、呼び出しプロセスから継承された特

権の組み合わせで、プロセスが起動すると有効になる。ただし、アプリケーションの

許容された特権セットに含まれていることが前提である。

2.2.4. TP10（高信頼経路）

TP（高信頼経路）は、TCSEC で定義された、TCB11（高信頼コンピューティング基盤）、お

よびセキュリティカーネルの概念のなかで、権限を持つユーザ（通常、管理者）が、信頼

できないアプリケーションやオペレーティングシステムの信頼できない層を介さずに、直

接 TCB にアクセスできることを保証するための機構である。

Trusted Solaris では、プロセスに付与されるセキュリティ属性の一つとして TP を実装

している。そして、役割のシェル（プロファイルシェル）や CDE のワークスペースは、正

当な手続きにより役割になった場合のみ、TP のセキュリティ属性を持ち、それが有効であ

る限りにおいてのみ、制限された特権を持つコマンドやアクションを実行することを可能

としている。つまり TP の範囲内でのみ権限の行使を可能としている。

10 Trusted Path 11 Trusted Computing Base



Trusted Solaris 編


図 2-3 TCB の構成

2.2.5. MLS12（マルチレベルセキュリティ）

MLS（マルチレベルセキュリティ）は、TCSEC で定義された、MAC を実現する、すべての

サブジェクト（ユーザやプロセスなど）とオブジェクト（ファイル、ディレクトリ、デバ

イス、ウィンドウ､ソケットなど）に対して、ユーザの信用度、情報の機密度、重要度など

に応じたラベルを付与し、アクセスの制御を実現する機構である。MLS では、サブジェクト

には機密ラベル（SL : Sensitivity Label）と許可上限（Clearance）が付与され、オブジェ

クトに対するアクセスを行う場合には、オブジェクトに付与された機密ラベルルとの優位

性により、アクセスを許可するかのどうかの判定を行う。

Trusted Solaris では、次の二つの条件が満たされれば、一方の機密ラベルはもう一方よ

りも「優位」であるとみなされる。

一方の機密ラベルの格付けがもう一方の格付けと同等であるか、それよりも高い場

合

12 Multi Level Security



Trusted Solaris 編


一方のコンパートメントのセットにもう一方のコンパートメントがすべて含まれる

場合

格付けが同じで、持っているコンパートメントのセットが同じである場合、二つのラベ

ルは「同等」とみなされる。ラベルが同等の場合は、互いに優位であると言えるため、ア

クセスが許可される。一方のラベルの格付けがもう一方のラベルの格付けよりも高い場合

や、一方のラベルのコンパートメントにもう一方のラベルのコンパートメントがすべて含

まれる場合、前者のラベルは後者のラベルよりも「完全に優位」であるとみなされる。ラ

ベルに優劣が付けられない場合は、これらのラベルは「無関係」または「比較不能」とみ

なされる。さらにラベルを理解する上で重要な事項を以下に示す。

管理ラベル（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 人のユーザが潜在的にアクセスできる最も広範なラベル

のセット、つまり、システム認可範囲のサブセットである。ここには管理ラベルは含

まれない。



Trusted Solaris 編


なお、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 でサポートするトラステッドネットワークプロトコルのセキュリティ



Trusted Solaris 編


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

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 の場合は、経由す

るネットワーク機器の対応を気にする必要がないものである。

図 2-5 トラステッドネットワークプロトコル



Trusted Solaris 編


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/



Trusted Solaris 編


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 のハードウェア要件を満たしているシステムかつフレームバッファを搭載した



Trusted Solaris 編


システム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)を選択する。

13 フレームバッファを搭載していないシステムは、Solaris同様シリアル接続からインストールを行なう。



Trusted Solaris 編


リスト 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 ディスクトップが起動し対話式にインストールが

継続される。以後は、表示されるウィンドウ名とそれに対するアクションを示す。



Trusted Solaris 編


表 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 ビットサポートをインストールする]が選択できる場合は選択し[継続]を押す。



Trusted Solaris 編


ディスクの選択インストールするディスクが[選択されたディスク]にない場合は、[使用可能なディスク]からディスクを選択し”>”で追加する。また、ブートディスクを変更する場合は、[ブートディスクの選択]で変更する。完了後、[継続]を押す。

データを保存しますか？ディスクに保存するディスクが存在する場合は[保存]、ない場合は[継続]を押す。

ファイルシステムを自動配置しますか？自動配置を行う場合は[自動配置]、手作業で配置する場合は[手作業による配置]を押す。ここでは、[手作業による配置]を行う。

ファイルシステムとディスク配置ファイルシステムを構成する場合、[カスタマイズ]を押す。ディスクの容量に応じて各スライスに割り当てる。割り当て完了後、[了解]、[継続]と押す。

リモートファイルシステムをマウントしますか？

特にリモートマウントの必要性がなければ[継続]を押す。

プロファイルプロファイル情報を確認し、間違いがなければ[インストール開始]を押し、変更および間違いがあれば[変更]を押す。

リブートインストール後、自動リブートまたは手動リブートを選択する。ここでは[自動リブート]を押す。

以上までの項目に答えるとインストールが開始される。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 システムによっては以下の電源管理に関する質問が出る場合がある。サーバーとして利用する場合は、

この機能は利用しないのでいずれも[n]とする。



Trusted Solaris 編


始される。完了後、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 / # eject cdrom



Trusted Solaris 編


(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 にて解説する。



Trusted Solaris 編


リスト 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 に登録する。



Trusted Solaris 編


リスト 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 と同様、対話式インストールが開始される。



Trusted Solaris 編


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

インストール直後の状態では、ユーザとして install 役割として root のみが存在する。

install ユーザはインストールのみで利用する一時的なもののため、運用に必要なユーザの

作成後は削除する必要がある。また、root 役割はインストールに必要な相当の権限が一時

的に与えられているため、運用に必要な役割の作成後は権限を他の役割に委譲し利用でき

ないようにする必要がある（root 役割はアプリケーションから通常の root として利用され

るため削除することはできない）。

次に Solaris Management Console（SMC）を用いて基本的な役割を作成する。その後ユー

ザを作成することになるが、ユーザのセキュリティ情報として管理ラベル以外の一般のラ

ベルを設定する必要があるため、ユーザの作成はラベルの定義を行う label_encodings ファ

イルの設定の後にする方が良い。

3.2.3.1. 役割の作成

インストール直後において、dtlogin 画面からユーザ install でログイン17する。ログイ

ンすると図 3-1 の画面を確認することができる。

17 install ユーザの初期パスワードは install である。



Trusted Solaris 編


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

installユーザはroot役割になることが許可されているroot役割のセッションを開始す

る。この手順については、3.4.2(A)にて解説している。

その後 Solaris Management Console を起動し root 役割のセッションを開始する。この

手順については、3.4.2(B)にて解説している。

Note: SMC の最初の起動では初期化処理を行うため、起動まで長い時間を要することがある。



Trusted Solaris 編


図 3-2 SMC 初期イメージ

標準的なインストールとして、root 役割の他、secadmin 役割、admin 役割、oper 役割の

三つの役割を作成する。ここでインターネットサーバー構築に有用な primaryadmin 役割も

作成することとする。この手順については 3.4.3.1(2)(A)にて解説している。

(1) secadmin 役割

セキュリティ管理者の secadmin 役割の設定情報である。secadmin 役割はセキュリ

ティに関する管理を行う。例えば、パスワードの設定や、拡張されたセキュリティの

設定等である。



Trusted Solaris 編


表 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


Profile Custom Admin Role System Administrator

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


(3) oper 役割

オペレーターであるoper役割の設定情報である。oper役割は運用時のオペレーショ

ンを行う。例えば、システムのバックアップ等である。



Trusted Solaris 編


表 3-5 oper 役割情報

Role Name oper

Full Name oper

Description Operator

Role ID Number 102


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


Profile Privileged Shells

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




Trusted Solaris 編


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 にするとシステムコールか

ら戻ってきた後登録ウィンドウからカーネル情報を返す可能性がある。



Trusted Solaris 編


(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 の実行を有効にすると、プロセスの特権情報が取得されるだけではなく、特権がなくてもプロセスが起動できるようになるため、必要時のみに設定することを推奨する。

18 file_mac_read 等の特権をもっているプロセスの場合はこの限りではない。



Trusted Solaris 編


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 * exclude: sys/shmsys



Trusted Solaris 編


* 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 * * There is a three-step process to assist in debugging privilege



Trusted Solaris 編


* 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



Trusted Solaris 編


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 の

ビット列で表されている。



Trusted Solaris 編


図 3-3 ラベル内部表現

3.3.2.1. label_encodings ファイルの構成

label_encodings ファイルは米国政府などの組織から支給される場合もある。このファイ

ルはコンパートメントモードワークステーション（CMW）に必要なラベルとエンコードの定

義が含まれている。コンパートメントモードワークステーションでは次のラベルが定義さ

れている。

認可上限（Clearance）

機密ラベル（Sensitivity Label）

情報ラベル（Information Label）

label_encodings ファイルは次のセクションから構成されており、これらは必須のセク

ションとなっている。

CLASSIFICATIONS（格付け）

INFORMATION LABELS（情報ラベル）

SENSITIVITI LABELS（機密ラベル）



Trusted Solaris 編


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= 初期値として定義するコンパートメント

19 米国防情報局(Defense Intelligence Agency)の標準的なラベル作成のためのラベル作成ソフト



Trusted Solaris 編


(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 のとおりの定義がされている必要がある。



Trusted Solaris 編


(4) ACCREDITATION RANGES セクション

ACCREDITATION RANGES セクションは、格付けに対するコンパートメントの組み合わ

せの制限を定義する。CLASSIFICATIONS セクションで定義された、格付けはすべて定

義する必要がある。

表 3-9 認可範囲のタグ１


1 classification= CLASSIFICATION の格付け

2 only valid compartment combinations: 有効なコンパートメント

3 all compartment combinations valid except: 有効でないコンパートメント

4 all compartment combinations valid; すべてのコンパートメントが有効

表 3-10 認可範囲のタグ２


1 minimum clearance= ユーザ許可上限の最低値

2 minimum sensitivity label= サブジェクトの機密ラベルの下限

3 minimum protect as cliassifications= プリンターバナーページ用

(5) LOCAL DEFINITIONS セクション

LOCAL DEFINITIONS セクションは、Trusted Solaris の拡張機能としての定義をする。

LOCAL DEFINITIONS セクションには、CDE のウインドウのタイトルバーに表示する色

を定義する COLOR NAMES サブセクションがある。

表 3-11 拡張機能のタグ


1 Admin Low Name= 管理ラベル ADMIN_LOW の変更名称

2 Admin High Name= 管理ラベル ADMIN_HIGH の変更名称

3 Default Label View= 管理ラベルの表示・非表示の設定

4 Classification Name= 格付けのデフォルト名

5 Compartments Name= コンパートメントのデフォルト名

Note: “default flags”および”forced flags”については、Trusted Solaris 7 以降ではサポートしていない。リスト 3-21 のとおりの定義がされている必要がある。



Trusted Solaris 編


表 3-12 拡張機能のタグ（COLOR NAMES サブセクション）


1 label= または word= 格付けまたはコンパートメント

2 color= 色の指定

3.3.2.2. label_encodings ファイルの作成

label_encodingsファイルはテキストファイルである。ただし 1行の最大長は 256 バイト

となっている。このファイルを作成または編集する場合には、任意のテキストエディタに

より行なうことが可能である。また、作成または編集した label_encordings ファイルにつ

いては chk_encodingsユーティリティを使って検査する必要がある。

(1) ファイルの編集

root 役割になり、ターミナルを起動して、任意のテキストエディタによりファイル

を新たに編集するか、テンプレートを使用して編集する。

Note: /etc/security/tsol ディレクトには、何種類かの label_encodings ファイルのテンプレート（label_encodings.multi など）が置かれているので、これを利用すると良い。

(2) ファイルの確認

編集し保存したファイル名を指定して、label_encodings ファイルチェックツール

（chk_encondigs）を実行する。

リスト 3-17 エンコーディングチェックの実行

# chk_encodings label_encodings.ipa No errors found in label_encodings.ipa.

Note: chk_encodings の実行時に-a オプションを指定した場合は、ラベル間の関係を分析し表示する。



Trusted Solaris 編


(3) ファイルの有効化

システムをシャットダウンし、シングルユーザモードで起動する。

リスト 3-18 シングルユーザモードの起動

ok boot -s

起動後にメンテナンス用ユーザ（root）でログイン後、label_encodings ファイル

チェックが完了したファイルを/etc/security/tsol/label_encodings にコピーし、さ

らにファイルの属性を確認する。

リスト 3-19 ファイルのコピーと属性の確認

# cd /etc/security/tsol # cp label_encodings.ipa label_encodngs

# ls -l label_encodings -r-------- 1 root sys 3155 1 月 10 13:18 label_encodings # getlabel label_encodings label_encodings: [ADMIN_HIGH]

ファイルのパーミッション、所有者、グループ、およびラベルの設定を確認して、

システムをリブートする。

リスト 3-20 シングルユーザモードを終了しマルチユーザモードで起動

# reboot



Trusted Solaris 編


3.3.2.3. label_encodings ファイルのサンプル

リスト 3-21 label_encodings

* * Simple encodings to show how TSOL can be used in the DMZ * Comments can be placed in the encodings file any place a keyword can start.* Comments begin with a '*' and continue to the end of line. * VERSION= IPA Trusted Solaris Research Version * * WARNING: If CIPSO Tag Type 1 network labels are to be used: * * a) All CLASSIFICATIONS values must be less than or equal to 256.* b) All COMPARTMENTS bits must be less than or equal to 239. * CLASSIFICATIONS: name= PUBLIC; sname= PUB; value= 50; name= PRIVATE; sname= PRI; value= 70; INFORMATION LABELS: * The Information labels section while no longer used, needs be be present * and should just be a copy of the Sensitivity labels section. WORDS: name= services; sname= services;maxclass=PRI;compartments= 51-80; name= web; sname= web; maxclass=PRI;compartments= 51 56; name= script; sname= script; maxclass=PUB;compartments= 61 56; name= mail; sname= mail; maxclass=PRI;compartments= 71 76; name= contents; sname= contents;maxclass=PUB;compartments= 56; name= mailconf; sname= mailconf;maxclass=PUB;compartments= 76; REQUIRED COMBINATIONS: COMBINATION CONSTRAINTS: SENSITIVITY LABELS: WORDS: name= services; sname= services;maxclass=PRI;compartments= 51-80; name= web; sname= web; maxclass=PRI;compartments= 51 56; name= script; sname= script; maxclass=PUB;compartments= 61 56; name= mail; sname= mail; maxclass=PRI;compartments= 71 76; name= contents; sname= contents;maxclass=PUB;compartments= 56;



Trusted Solaris 編


name= mailconf; sname= mailconf;maxclass=PUB;compartments= 76; REQUIRED COMBINATIONS: COMBINATION CONSTRAINTS: CLEARANCES: WORDS: name= services; sname= services;maxclass=PRI;compartments= 51-80; name= web; sname= web; maxclass=PRI;compartments= 51 56; name= script; sname= script; maxclass=PUB;compartments= 61 56; name= mail; sname= mail; maxclass=PRI;compartments= 71 76; name= contents; sname= contents;maxclass=PUB;compartments= 56; name= mailconf; sname= mailconf;maxclass=PUB;compartments= 76; REQUIRED COMBINATIONS: COMBINATION CONSTRAINTS: CHANNELS: WORDS: PRINTER BANNERS: WORDS: ACCREDITATION RANGE: classification= PUB; all compartment combinations valid; classification= PRI; all compartment combinations valid; minimum clearance= PUB; minimum sensitivity label= PUB; minimum protect as classification= PUB; * * Local site definitions and locally configurable options. * LOCAL DEFINITIONS: * * The names for the administrative high and low name are set to * site_high and site_low respectively by the example commands below. * * NOTE: Use of these options could lead to interoperability problems * with machines that do not have the same alternate names. * *Admin Low Name= site_low; *Admin High Name= site_high;



Trusted Solaris 編


default flags= 0x0; forced flags= 0x0; Default Label View is Internal; Classification Name= Security Level; Compartments Name= services; *Default User Sensitivity Label= PUBLIC; *Default User Clearance= PRIVATE; *Default User Clearance= PRIVATE; COLOR NAMES: label= Admin_Low; color= #bdbdbd; label= PUBLIC; color= green; label= PRIVATE; color= yellow; word= services; color= red; word= web; color= cyan; word= mail; color= magenta; label= Admin_High; color= #636363; * * End of local site definitions



Trusted Solaris 編


3.4. セキュリティポリシーのファイル構成

Trusted Solaris 8 のセキュリティポリシーを司る定義ファイルやコマンド、およびツー

ルには、Solaris 8 で提供されるもと同一のもの、Solaris 8 から強化された機能を実装す

るために拡張されたもの、および Trusted Solaris 8 で独自に提供しているものがある。

以降の解説ではこれらを明確するために種別を明記した。種別の欄の各意味は以下のと

おりである。

S8 Solaris 8 とフィールドおよび項目名や値が同一

S8+ Solaris 8 とフィールドは同一であるが項目名や値が拡張されている

TS Trusted Solaris 8 独自

3.4.1. 定義ファイル

定義ファイルに関して、Trusted Solaris 8 と Solaris 8 や Solaris 9 では、RBAC に関

する定義ファイルが共通のものとなっている。ただし、設定項目や設定可能な値について

は Trusted Solaris 8 と Solaris 8 では異なっている。

その他の定義ファイルとしては、Trusted Solaris 8 の独自の機能となっている MLS に関

する定義ファイルなどがある。表 3-13 に Trusted Solaris 8 のセキュリティポリシーの定

義ファイルを示す。

表 3-13 セキュリティポリシーのファイル

# ファイル説明種別

1 /etc/user_attr 拡張ユーザ属性データベース S8+

2 /etc/security/auth_attr 承認属性データベース S8+

3 /etc/security/prof_attr プロファイル属性データベース S8+

4 /etc/security/exec_attr 実行属性データベース S8+

5 /etc/security/policy.conf デフォルトのセキュリティポリシー定義 S8+

6 /etc/security/tsol/tnidb ネットワークインターフェースの属性DB TS

7 /etc/security/tsol/tnrhdb ホストとネットワークの属性 DB TS

8 /etc/security/tsol/tnrhtp プロトコルと属性のテンプレート TS

9 /etc/security/tsol/vfstab_adjunct ファイルの拡張セキュリティ属性の定義 TS

10 /etc/inetd.conf インターネットサーバーの定義 S8+

11 /etc/system カーネルパラメータ S8+

12 /etc/security/tsol/label_encodings 格付けコンパートメントのラベル定義 TS

#1～#4 は Trusted Solaris および Solaris 8 や Solaris 9 に実装されている RBAC を構成

する定義ファイルである。また、#5 はユーザや役割のデフォルトのを定義するファイルで

ある。



Trusted Solaris 編


#6～#9 は Trusted Solaris 独自に実装されているトラステッドネットワークを構成する

定義ファイルである。

#11 および#12 についてはカーネルパラメータに類するファイルであり、3.3 にて解説し

ている。

以降の解説では、これらのセキュリティポリシーに関わるファイルに関する解説、およ

び設定方法について、また、Trusted Solaris の最も特徴的な機能である、特権に関する解

説を行う。

なお、#9 については、Trusted Solaris の拡張セキュリティ属性を持たない通常のファ

イルシステムを Trusted Solaris にマウントする際に、拡張セキュリティ属性を定義する

ファイルである。

また、#10 については、インターネットサーバーの定義において、Trusted Solaris の拡

張セキュリティ属性が定義できるように拡張がされている。

インターネットサーバー構築において、#9 および#10 に関する設定は行うことはないと

考えられるため、本書では特に解説をしていない。こららのファイルの解説についてはマ

ニュアルを参照して頂きたい。

3.4.2. 設定ツール

セキュリティポリシーを設定する方法は、GUI による方法と CUI による方法が用意されて

いる。GUI ツールは Solaris Management Console であり Trusted Solaris 8 と Solaris 8

のどちらも管理することが可能となっている。また、CUI については、Trusted Solaris 8

の独自の機能を設定するものもあるが、Trusted Solaris 8 と Solaris 8 で殆ど同一のコマ

ンドが用意されている。

Trusted Solaris 8 においてセキュリティポリシーを定義する場合は、必要な権限のある

役割により、TP20の範囲内で作業を行う必要がある。具体的には次の方法が可能である。

ローカルまたはリモートのグラフィカル・ディスプレイを持つ Trusted Solaris 8

オペレーティング環境にて、役割を許可されたユーザに CDE ログインし、役割の CDE

セッションを開始する。

Trusted Solaris 8 の Solaris Management Console サーバー（smcwbemserver）の起

動オプションを変更しリモートの Solaris 8 からのログインを可能とし、リモート

のグラフィカル・ディスプレイを持つ Solaris 8 オペレーティング環境にて、Solaris

Management Console のセッションを開始する。

20 Trusted Path（高信頼経路）



Trusted Solaris 編


Note: Solaris Management Console をリモートの Solaris 8 からログイン可能とする方法は、セキュリティが緩くなるので、運用時には利用できないようにしておくことを推奨する。

ここではあらかじめ、前者の方法で Solaris Management Console が利用可能となる状態

までの共通の手順について解説を行っておく。

(A) 役割になることを許可されたユーザが役割のセッションを開始する手順

ログイン後、CDE のフロントパネルにマウスのカーソルを合わせ、右ボタンをク

リックすると[Trusted Path (TP) menu]が表示される。

図 3-4 フロントパネル操作イメージ

[Trusted Path (TP) menu]から[Assume rolename Role]を選択すると、役割のパ

スワード入力イメージが表示される。



Trusted Solaris 編


図 3-5 役割のパスワード入力イメージ

役割のパスワードを入力し承認されると、役割の CDE セッションが開始され役割

の CDE ワークスペースでの作業が可能となる。

(B) Solaris Management Console を起動し役割のセッションを開始する手順

役割のワークスーペースから Solaris Management Console を起動する。ターミ

ナルから起動コマンドを入力するか、アプリケーションマネージャからアイコンを

クリックする。

リスト 3-22 Solaris Management Center の起動

$ smc &



Trusted Solaris 編


図 3-6 SMC 初期イメージ

Navigation から [Trusted Solaris Management Console] - [Scope=Files,

Poliy=TSOL] - [Trusted Solaris Configuration] - [Users]とツリーをクリックし

て行くと、役割へのログインイメージが表示される。

図 3-7 役割へのログインイメージ

役割のパスワードを入力し承認されると、その役割に許可されている設定がツー

ルを使って行えるようになる。



Trusted Solaris 編


3.4.3. RBAC 定義

最初に RBAC を構成する定義ファイルについて解説する。RBAC を構成する定義ファイルは、

拡張ユーザ属性データベース（user_attr）、プロファイル属性データベース（prof_attr）、

承認属性データベース（auth_attr）、実行属性データベース（exec_attr）である。

これらの定義ファイルにより、ユーザや役割のセキュリティ属性が定義されるが、これ

らの中には、ユーザや役割が実行するコマンドや CDE のアクション（以降、アクション）

のセキュリティ属性が含まれ、最終的なプロセスのセキュリティ属性の判断基準となる。

また、システムにより起動されるサービスに関わるプロセスのセキュリティ属性につい

ても、ユーザや役割と関連付けられて同様に定義がされている。

なお、root 役割やローカルのシステム用のユーザアカウントを除いて、すべてのユーザ

と役割に関するデータベースが、NIS または NIS+のネームサービスにより管理することが

可能となっている。

図 3-8 RBAC 構成ファイルの相関関係



Trusted Solaris 編


Note: RBAC の定義ファイルは、従来の passwd ファイルや shadow ファイルを補足するものである。user_attr に定義されるユーザや役割のエントリは、passwd ファイルや shadow ファイルにも存在し、通常のシステムと同様にホームディエクトリ、ログインシェル、パスワードが定義される。

3.4.3.1. ユーザと役割

ユーザと役割は、通常のシステムのユーザと同様、passwd21ファイルと shadow22ファイル

に登録されている必要がある。役割のセッションが開始されるときには、passwd ファイル

の各フィールドはそのまま利用され、shadow ファイルの暗号化されたパスワードによりロ

グイン認証が行われる。つまり、役割も通常のユーザと同様のホームディレクトリやログ

インシェルまたパスワードの管理がされる。そしてユーザと役割は拡張ユーザ属性データ

ベース（user_attr）により区別がされる。

ログインの認証の機構は、拡張ユーザ属性データベース（user_attr）を参照し、役割で

あれば直接ログインを許可しない。また、役割のログインシェルは標準でプロファイルシェ

ルと呼ばれるものとなっている。

プロファイルシェル（pfsh、pfcsh、pfksh）は、通常のシェル（sh、csh、ksh）と互換

のシェルであるが、コマンドやアクションを実行する際に prof_attr および exec_attr を

参照し、実行の許可や実行時のセキュリティ属性を判断する機構が付加されている。また、

役割に対しては、TP 属性を確認し、TP 属性がない場合には、コマンド実行が制限される。

表 3-14 に標準的なインストールにおいて作成される役割を示す。

表 3-14 役割

# 役割主な役割種別

1 secadmin セキュリティ管理者タスク。セキュリティポリシーの定義など。 S8+

2 admin システム管理者タスク。システム設定やインストレーション。 S8+

3 oper オペレータータスク。プリンタ管理やメディアへのバックアップ。 S8+

4 primaryadmin （システム開発用または緊急用。すべての特権が許可される。） TS

5 root （初期インストールに必要な特権が許可される。） S8+

21 /etc/passwd 22 /etc/shadow



Trusted Solaris 編


Note: primaryadmin 役割は、システム開発または緊急用に用意されている役割であり、すべての特権をもつシェル環境を実行することができる。この役割は運用時には利用できないようにしておくこと推奨する。 root 役割は、初期インストールにおいて必要な権限が許可されており、システムの再起動、ファイルシステムのマウント、役割を作成し適切なプロファイルを設定することなどができる。この初期の権限はインストール後に他の役割に委譲すべきで、運用時にはできる限り最小の権限のみとすることを推奨する。または、この役割は運用時にはユーザアカウントに割り与えないことを推奨する。（root 役割はシステムで利用されるため削除することはできない。）

(1) 拡張ユーザ属性データベース（user_attr）の構成

user_attr ファイルは passwd ファイルと shadow ファイルを補足するものである。

設定ツールにより設定を行う場合、これらのすべてのファイルが関連して設定が行

われる。

リスト 3-23 に user_attr ファイルのフィールド定義、および Solaris 8 と Trusted

Solaris 8 における例を示す。表 3-15 に各フィールドの値と意味を示す。

リスト 3-23 user_attr ファイルのフィールド

（フィールド） user:qualifier:res1:res2:attr

（例 ‐ Solaris 8） root:::: type=normal; auths=solaris.*,solaris.grant; profiles=All

（例 ‐ Trusted Solaris 8） root:::: lock_after_retries=no; profiles=Custom Root Role,cron,All; labelview=internal,hidesl; min_label=0x00000000000000000000000000000000000000000000000000000000000000000000; clearance=0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff; type=role



Trusted Solaris 編


表 3-15 user_attr ファイルのフィールドの意味

# フィールド説明種別

1 user passwd および shadow ファイルに登録されているユーザ名 S8

2 qualifier 将来使用 S8

3 res1 将来使用 S8


5 attr ユーザおよび役割のセキュリティ属性

有効キー値と説明種別

type normal|role: 一般アカウント/役割アカウント

S8

auths 割り当てられた承認 S8

profiles 割り当てられたプロファイル S8

roles 割り当てられたロール S8

lock_after_retries yes|no ログイン失敗後ロック有効/無効

TS

gen automatic|manual パスワード自動入力/手動入力

TS

idletime ウインドウのアイドル時間 TS

idlecmd lock|logout アイドル時間経過後の挙動

TS

labelview internal|external 管理用ラベルの表示/非表示 showsl|highdsl ラベル表示/非表示

TS

labeltrans プロセスのラベルの 16 進数表示 TS

min_label 最下位機密ラベル TS

clearance 許可上限 TS

S8+

(2) 拡張ユーザ属性データベース（user_attr）の設定方法

拡張ユーザ属性データベースの設定は、admin役割またはsecadmin役割により行う。

(A) SMC により役割を追加する手順

secadmin 役割にて役割の登録を行う例を示す。admin 役割では新規に役割を追加

することはできない。

最初に、 Navigation から [Trusted Solaris Configuration] - [Users] – [Administrative Roles]とツリーをクリックして行くと、図 3-9 のようなイメージ

が表示される。



Trusted Solaris 編


図 3-9 役割編集初期画面

役割を新たに追加する場合は、[Action]をクリックしメニューから[Add Roles]

を選択する。その後次のステップに従い設定を行う、なお、各ステップでは、[Next]

をクリックする度に次のステップに進む、逆に[Back]をクリックする度に前のス

テップに戻る。

ステップ 1:一般情報

入力・選択項目入力値

Role Name 新規 role（役割）名を入力する

Full Name 役割の正式名称

Description 役割の説明

Role ID Number 役割 ID

Role Shell Administrator’s Bourne|Ksh|Csh Create a role mailing list

管理者のメーリングリストに追加する場合はチェックする

ステップ 2:パスワード


Set Password By Type In|Choose From List

Password Type In を指定した場合パスワードを入力

Confirm Password Type In を指定した場合確認パスワードを入力



Trusted Solaris 編


ステップ 2において、[Choose From List]を選択した場合はパスワードのリスト

が表示されるのでそこから選択し[Type password to confirm]に確認パスワードを

入力する。

ステップ 3:プロファイルの選択


Available Rights 利用可能であるが割り当てられていない Rights（プロファイル）を指定

Granted Rights 割り当てる Rights（プロファイル）を指定

ステップ 3 において、[Available Rights]からプロファイルを選択し[Add]をク

リックすると[Granted Rights]に追加される。逆に[Granted Rights] からプロファ

イルを選択し[Remove]をクリックすると[Granted Rights]から削除される。

Note: プロファイルには優先順位がある。同じアクションやコマンドが違うプロファイルで登録されている場合は、Granted Rights に登録されているプロファイルの上位から優先される。

ステップ 4:ホームディレクトリ


Path ホームディレクトリを指定

ステップ 5：ユーザの割当て


割り当てられるユーザを指定

ステップ 5 において、ユーザ名をテキストボックスに入力して[Add]ボタンを押

すとリストに追加される。なお、ユーザの登録において逆に役割に割り当てること

も可能である。

ステップ 6:確認

ステップ 6 において、最後に設定内容の確認が表示される。間違いがなければ

[Finish]をクリックする。

変更等があれば[Back]をクリックしてステップを戻って行うことが可能である。



Trusted Solaris 編


(B) SMC によりユーザを追加する手順

secadmin 役割または admin 役割にてユーザの登録を行う例を示す。ユーザの追加は

secadmin 役割 admin 役割共に共通して行うことが可能である。

最初に、Navigation から[Trusted Solaris Configuration] - [Users] - [User

Accounts]とツリーをクリックして行くと、図 3-10 のようなイメージが表示される。

図 3-10 ユーザ編集初期画面

ユーザを新たに追加する場合は、[Action]をクリックしメニューから[Add User]

– [With Wizard]を選択する。その後次のステップに従い設定を行う、なお、各ステッ

プでは、[Next]をクリックする度に次のステップに進む、逆に[Back]をクリックす

る度に前のステップに戻る。

Note: この作業はユーザに関する基本情報を設定するものであり、passwd ファイルおよび shadowファイルのみ更新される。(C)の作業により拡張属性の変更を行った際に user_attr ファイルが更新される。

ステップ 1:ユーザ情報



Trusted Solaris 編



User Name 新規ユーザ名（2～32 文字の範囲内）

Full Name ユーザの名前

Description ユーザの説明

ステップ 2:ユーザ ID


User ID Number UserID（100～2147483647 の範囲内）

ステップ 3:パスワード


User set passwrd at first login

ユーザの最初のログイン時にパスワードを設定する場合に指定する

Set Password By Type In|Choose From List

Password Type In を指定した場合パスワードを入力

Confirm Password Type In を指定した場合確認パスワードを入力

ステップ 3において、ユーザの最初のログイン時にパスワードを設定する場合は

[User set password at first login]を選択する。管理者が設定する場合は[set

Pssword by]を選択し、コンボボックスから[Type in]もしくは[Choose From List]

を選択する。[Choose From List]を選択した場合はパスワードのリストが表示され

るのでそこから選択し[Type password to confirm]に確認パスワードを入力する。

ステップ 4:グループ


Primary Group プライマリーグループを指定（コンボボックスから選択）

ステップ 5:ホームディレクトリ


Path ホームディレクトリを指定

ステップ 6:メールサーバー

ステップ 6において、デフォルトの設定が表示される。ローカルホストがメール

サーバーになる。また、/var/mail 以下のユーザ名のファイルがメールボックスに

なる。



Trusted Solaris 編


ステップ 7:確認

ステップ 7 において、最後に設定内容の確認が表示される。間違いがなければ

[Finish]をクリックする。

変更等があれば[Back]をクリックしてステップを戻って行うことが可能である。

(C) SMC によりユーザおよび役割の属性を編集する手順

ユーザまたは役割に設定可能な属性、また secadmin 役割または admin 役割によ

り設定可能な属性、これらは類似するものであるが設定可能な項目が異なっている。

表 3-16 はその関係を示している。設定可能な属性の欄において、”N/A”はユーザ

または役割に設定できない項目を示している。また、”secadmin”はその項目につい

て secadmin 役割のみが設定できることを表している、”admin/secadmin”はその項目

について admin 役割でも secadmin 役割でも設定できることを表している。

なお、#1～#13 については、(A)または(B)において設定される項目である。

表 3-16 ユーザと役割の属性

設定可能な属性 # 属性カテゴリ

役割ユーザ

1 User Information admin/secadmin admin/secadmin

2 Login/Role Shell admin/secadmin admin/secadmin

3

General

Account Availability N/A secadmin

4 Primary Group admin/secadmin admin/secadmin

5

Group

Additional Groups admin/secadmin admin/secadmin

6 Home Directory Information admin/secadmin admin/secadmin

7

Home Directory Home Directory Sharing admin/secadmin admin/secadmin

8 User/Role Password secadmin secadmin

9 Type In Password secadmin secadmin

10

Password

Update Password By secadmin secadmin

11 Password Option

Password Options in Days N/A secadmin

12 Mail Information

Mail Information N/A admin/secadmin

13 Users Users Assigned To This Role secadmin N/A

14 Rights Granted Rights secadmin secadmin

15 Roles Assigned Roles N/A secadmin

16 Labels secadmin secadmin

17

Trusted Solaris Attributes

Account Usage secadmin secadmin

18 Audit User Audit Classes secadmin secadmin

ユーザの属性を編集する場合には、Navigation から [Trusted Solaris

Configuration] - [Users] - [User Accounts]とツリーをクリックして行くと、現



Trusted Solaris 編


在システムに存在するユーザ名が表示されるので、そこから対象のユーザを選択し

て、マウスの右ボタンをクリックし[Properties]を選択する。

役割の属性を編集する場合には、 Navigation から [Trusted Solaris

Configuration] - [Users] – [Administrative Roles]とツリーをクリックして行く

と、現在システムに存在する役割名が表示されるので、そこから対象の役割を選択

して、マウスの右ボタンをクリックし[Properties]を選択する。

Rights

カテゴリ入力・選択項目入力値

Available Rights 利用可能であるが割り当てられていない Rights（プロファイル）を指定

Rights

Granted Rights 割り当てる Rights（プロファイル）を指定

ここで、[Available Rights]からプロファイルを選択し[Add]をクリックすると

[Granted Rights]に追加される。逆に[Granted Rights] からプロファイルを選択し

[Remove]をクリックすると[Granted Rights]から削除される。

Roles


Available Roles 利用可能であるが割り当てられていない Role（役割）を指定

Roles

Assigned Roles 割り当てる Role（役割）を指定

ここで、[Available Roles]から役割を選択し[Add]をクリックすると[Assigned

Roles]に追加される。逆に[Assigned Roles] から役割を選択し[Remove]をクリック

すると[Assigned Roles]から削除される。

Trusted Solaris Attributes


Minimum Label 最小ラベル

Clearance 許可上限のラベル

View System Default|External|Internal

Labels

Label Show|Hide

Lock account after maximum failed login

Yes|No

Idle Time minutes

Account Usage

Idle Action Lock Screen|Logout



Trusted Solaris 編


ここで、Minimum Label、Clearance は共に[Edit]ボタンを押して Label Selection

の中からラベルを選択する。

Audit


Excluded 利用可能であるが割り当てられていない監査クラスを指定

User Audit Class

Included 割り当てる監査クラスを指定

ここで、[Excluded]からクラスを選択し[Add]をクリックすると[Included]に追

加される。逆に[Included]から役割を選択し[Remove]をクリックすると[Included]

から削除される。

3.4.3.2. プロファイル

プロファイルは、ユーザや役割に許可を与える、コマンドや CDE アクション、実行時の

セキュリティ属性などを統合する機構である。プロファイルはタスクやサービスに合わせ

て自由に作成することが可能であるが、その組み合わせは無数にあるため、あらかじめ標

準的な十分なプロファイルが用意されている。

表 3-17、表 3-18、表 3-19、

表 3-20、表 3-21 に各役割に標準的なインストールにおいて定義される、標準で用意さ

れているプロファイルを示す。

また、表 3-22、表 3-23 にシステムにより起動されるサービスのプロファイル、および

その他のプロファイルについて、標準で用意されているプロファイルを示す。



Trusted Solaris 編


表 3-17 secadmin 役割のプロファイル

# プロファイル主な用途種別

1 Rights Security （プロファイル取り纏めプロファイル） TS

2 Custom Secadmin Role secadmin 役割カスタマイズ用 TS

3 Audit Control 監査サブシステムの管理 S8+

4 Object Privilege Management 実行可能ファイルの特権の変更 TS

5 Remote Administration ヘッドレスシステムのリモート管理用 TS

6 Rights Delegation 権限や役割の委任 TS

7 User Security ユーザのセキュリティ属性の定義 S8+

8 Information Security （プロファイル取り纏めプロファイル） TS

9 Device Security デバイスの管理および設定 S8+

10 File System Security ファイルシステムのセキュリティ属性の管理 S8+

11 Name Service Security ネームサービスのプロパティとテーブルの操作 S8+

12 Network Security ネットワークとホストのセキュリティの管理 S8+

13 Object Access Management ファイルの所有者とアクセス権の変更 S8+

14 Object Label Management ファイルのラベルの変更 TS

15 Remote Administration ヘッドレスシステムのリモート管理 TS

Note: User Security プロファイルにより、自分自身のセキュリティ属性を変更することは、制限されている。つまり、secadmin 役割により secadmin 自信のセキュリティ属性を変更することはできない。

表 3-18 admin 役割のプロファイル


1 System Administrator （プロファイル取り纏めプロファイル） S8

2 Audit Review 監査トレールの読み込み S8+

3 Printer Management プリンタデバイスの管理 S8+

4 Cron Management cron および at ジョブの管理 S8+

5 Device Management デバイスの管理 S8+

6 File System Management ファイルシステムの管理 S8+

7 Mail Management sendmail の設定・エリアスとキューの管理 S8+

8 Maintenance and Repair システムの保守または修復 S8+

9 Media Backup ファイルのバックアップ S8+

10 Media Restore バックアップからのファイルの復元 S8+

11 Name Service Management ネームサービスのデーモンの操作 S8+

12 Network Management ネットワークとホストの管理 S8+

13 Object Access Management ファイルの所有者とアクセス権の変更 S8+

14 Process Management cron と at ジョブとカレントのプロセスの管理 S8+

15 Software Installation ソフトウェアのインストレーション S8+

16 User Management ユーザの作成および変更 S8+

17 All 特権無しで全 Command/Action の実行許可 S8+



Trusted Solaris 編


Note: User Management プロファイルにより、自分自身の属性の変更をすることは、制限されている。つまり、admin 役割により admin 役割自信の属性を変更することはできない。

表 3-19 oper 役割のプロファイル


1 Operator （プロファイル取り纏めプロファイル） S8

2 Printer Management プリンタデバイスの管理 S8+

3 Media Backup ファイルのバックアップ S8+


表 3-20 primaryadmin 役割のプロファイル


1 Primary Administrator （プロファイル取り纏めプロファイル） S8+

2 Privileged Shell すべての特権を持った Shell の実行許可 TS

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

表 3-21 root 役割のプロファイル

# プロファイル主な用途種別1 Custom Root Role root 役割カスタマイズ用 TS

2 All Authorizations すべての承認許可 TS

3 Maintenance and Repair （admin 役割に含まれる） S8+

4 Device Management （admin 役割に含まれる） S8+

5 Object Access Management （admin 役割に含まれる） S8+

6 Network Management （admin 役割に含まれる） S8+

7 Network Security （secadmin 役割に含まれる） S8+

8 Name Service Management （admin 役割に含まれる） S8+

9 Name Service Security （secadmin 役割に含まれる） S8+

20 User Security （secadmin 役割に含まれる） S8+

22 cron cron デーモン用（通常 root 役割に割り当てる） TS




Trusted Solaris 編


Note: root 役割に与えられている殆どのプロファイルは、適切な役割や管理者を作成時に委譲されるべきである。運用時には Custom Root Role プロファイルおよび cron プロファイルを除くすべてのプロファイルを外し、不都合がなければ役割自体も管理者に与えないようする。

表 3-22 システムのプロファイル


1 allocate リムーバブルメディアの割り当て TS

2 boot システムシェル（sysh）用 TS

3 cron cron デーモン用（通常 root 役割に割り当てる） TS

4 dtwm ウィンドウマネージャ用 TS

5 inetd inetd デーモンにより起動されるサービス用 TS

6 sbinboot システムシェル（sysh）用（/sbin/*） TS

7 shutdown シャットダウン時のウィンドウマネージャ用 TS

Note: これらはシステムで利用される特別なプロファイルであり削除することはできない。またユーザや役割に与えてはならない。（ただし、cron プロファイルのみ root 役割に与えることは可能） Trusted Solaris の/etc/rcN スクリプトは、システムシェル（sysh）となっている。システムシェルは、スクリプトの実行時に boot プロファイルを参照し、起動するプロセスにセキュリティ属性を付与する。 inetd デーモンは、インターネットサービスの実行時に inetd プロファイルを参照し、起動するプロセスにセキュリティ属性を付与する。



Trusted Solaris 編


表 3-23 その他のプロファイル


1 All Actions 特権無しで全 Action の実行許可 TS

2 All Authorizations すべての承認許可 TS

3 All Commands 特権無しで全 Command の実行許可 TS

4 Basic Actions 特権なしの一般の Action の実行許可 TS

5 Basic Commands 特権なしの一般の Command の実行許可 TS

6 Basic Solaris User All を含む（ユーザデフォルト） S8


8 Convenient Authorizations 便利な承認（CMW の要件を満たす） TS

9 Custom Admin Role admin 役割カスタマイズ用 TS

10 Custom Oper Role oper 役割カスタマイズ用 TS

11 Custom SSP Role システム・サービス・プロセッサ用 TS

12 Enable Login ログイン許可の承認 TS

13 Host Alternate Pathing 代替経路コマンド用 TS

14 Host System Management cvc および power サービス用 TS

15 Outside Accred システム認可範囲外での操作 TS

16 SSP Administration システム・サービス・プロセッサ用 TS

17 SSP Installation システム・サービス・プロセッサ用 TS

18 Sunray Management シン・クライアント用 TS

(1) プロファイル属性データベース（prof_attr）の定義

プロファイルの名前の定義は prof_attr ファイルに格納さる。プロファイルの名前

に帰属する承認の属性は auth_attr に格納される。またプロファイルの名前に帰属す

る実行属性は exec_attr にプロファイルの名前と共に格納される。

リスト 3-24 に prof_attr ファイルのフィールド定義、および Solaris 8 と Trusted


リスト 3-24 prof_attr のフィールド

（フィールド） profname:res1:res2:desc:attr

（例） File System Management:::Manage, mount, share file systems: help=RtFileSysMngmnt.html; auths=solaris.admin.fsmgr.*,solaris.admin.diskmgr.*



Trusted Solaris 編


表 3-24 prof_attr のフィールドの意味


1 profname プロファイル名 S8



4 desc 詳しい記述 S8

5 attr プロファイルの属性


help ヘルプ S8

auth 割り当てられた承認 S8

S8

(2) 定義ファイルの設定方法

プロファイル属性データベースの設定は、admin 役割または secadmin 役割により行

う。

(A) SMC によりプロファイルを追加する手順

secadmin 役割にてプロファイルの登録を行う例を示す。admin 役割では新規にプ

ロファイルを追加することはできない。

最初に、Navigation から[Trusted Solaris Configuration] - [Users] - [Rights]

とツリーをクリックして行くと、図 3-11 のようなイメージが表示される。



Trusted Solaris 編


図 3-11 プロファイル編集初期画面

プロファイルを追加する場合は、[Action] クリックしメニューから[Add Rights]

を選択すると、図 3-12 のようなイメージが表示される。

図 3-12 プロファイル編集



Trusted Solaris 編


プロファイルの登録


Name 新規プロファイル名

Description プロファイルの説明

Help File Name ヘルプファイルの指定

これの入力後[OK]をクリックすると、プロファイルが登録される。ここで、続け

て承認やコマンドとアクションに対する実行属性などを設定することが可能である

が、これらの解説については後述する。

3.4.3.3. 承認

承認は、ユーザまたは役割に直接割り当てるか、プロファイルに承認を割り当て、プロ

ファイルをユーザまたは役割に割り当てることで有効にされる。

(1) 承認属性データベース（auth_attr）の定義

承認はすべて auth_attr ファイルに格納される。

リスト 3-25 に auth_attr ファイルのフィールド定義、および Solaris 8 と Trusted


リスト 3-25 auth_attr のフィールド

（フィールド） authname:res1:res2:short_desc:long_desc:attr

（例） solaris.admin.fsmgr.read:::View Mounts and Shares:: help=AuthFsmgrRead.html



Trusted Solaris 編


表 3-25 auth_attr のフィールドの意味


1 authname 承認を識別する固有の文字列 S8



4 short_desc ユーザインタフェース表示に適する承認の簡略名 S8

5 logn_desc 詳しい記述 S8

6 attr 承認の属性


help ヘルプ S8

S8


承認属性データベースの設定は、admin 役割または secadmin 役割により行う。承認

の割り当ては secadmin 役割 admin 役割共に共通して行うことが可能である。

(A) SMC によりプロファイルに対して承認を割り当てる手順

secadmin役割またはadmin役割にてプロファイルに対して承認の割り当てを行う

例を示す。

3.4.3.2(2)(A)に続けて、[Authorization]タグをクリックすると、図 3-13 のよ

うなイメージが表示される。



Trusted Solaris 編


図 3-13 承認の割り当て

承認の割り当て


Authorizations Excluded 利用可能であるが割り当てられていない承認を指定

Authorizations Included 割り当てる承認を指定

[Authorizations Excluded] から承認を選択し [Add] をクリックすると

[Authorizations Included]に追加される。逆に[Authorizations Included] から承

認を選択し[Remove]をクリックすると[Authorizations Included]から削除される。

これの入力後[OK]をクリックすると、承認が割り当てられる。

3.4.3.4. 実行属性

実行属性は、プロファイルに実行属性を割り当て、プロファイルをユーザまたは役割に

割り当てることで有効にされる。

(1) 実行属性データベース（exec_attr）の構成

実行属性はすべて exec_attr ファイルに格納される。

リスト 3-26 に exec_attr ファイルのフィールド定義、および Solaris 8 と Trusted




Trusted Solaris 編


リスト 3-26 exec_attr のフィールド

（フィールド） profname:policy:type:res1:res2:id:attr

（例 – Solaris 8） File System Management:suser:cmd::: /usr/sbin/mountall:uid=0

（例 – Trusted Solaris 8） File System Management:tsol:cmd::: /usr/sbin/mount:privs=4,5,6,10,11,12,35,55,63,67,71 File System Management:tsol:act::: Vfstab;*;*;*;*:privs=6,15,44

表 3-26 exec_attr のフィールドの意味


1 profname prof_attr に定義されているプロファイル名 S8

2 policy セキュリティポリシー


suser スーパーユーザポリシーモデル S8

tsol 最小特権によるポリシーモデル TS

S8+

3 type エンティティタイプ


cmd コマンド S8

act アクション（policy が tsol の場合定義可能）

TS

S8+



6 id エンティティを表す文字列

有効型と説明種別

cmdid コマンドのフルパス名またはワイルドカード付きパス名

S8

actid;argclass;argtype;argmode;argcount アクション名と引数の定義

TS

S8

7 attr 実行属性


uid 実 UID S8

gid 実 GID S8

euid 実効 UID S8

egid 実効 GID S8

priv 割り当てられた特権 TS

label 最下位機密ラベル TS

clearance 許可上限 TS

S8+

Note: policy の項目において suser の指定は Trusted Solaris では無効である。



Trusted Solaris 編



実行属性データベースの設定は、secadmin 役割により行う。admin 役割では設定も

表示も行うことができない。

(A) SMC によりプロファイルに対して実行属性を割り当てる手順

secadmin 役割にてプロファイルに対して実行属性の割り当てを行う例を示す。

3.4.3.2(2)(A)に続けて、[Commands]タグをクリックすると、表 3-27 のようなイ

メージが表示される。

表 3-27 コマンドの割り当て

コマンドの割り当て


Command Denied 利用可能であるが割り当てられていないコマンドを指定

Command Permitted 割り当てるコマンドを指定

[Command Denied]からコマンドを選択し[Add]をクリックすると[Command

Permitted]に追加される。逆に[Command Permitted] からコマンドを選択し

[Remove]をクリックすると[Command Permitted]から削除される。



Trusted Solaris 編


続けて、コマンドの選択後、[Command Permitted]にリストされている対象のコ

マンドを選択し Security Attribute の[Edit]をクリックすると、図 3-14 のような

イメージが表示される。

図 3-14 コマンド実行属性編集画面

コマンドの属性の設定


User 実行時の実効 UID また実 UID を指定 Ownership

Group 実行時の実効 GID または実 GID を指定

Label 実行時のデフォルトのラベルを指定

Clearance プロセスの許可上限を指定

Executed Attributes

Privileges プロセスの特権（継承可能特権）を指定

Label と Clearance の指定において[Edit]をクリックすると、図 3-15 のイメー

ジからラベルの指定が可能である。また、Privileges の指定において[Edit]をク

リックすると、図 3-16 のイメージから特権の指定が可能である。



Trusted Solaris 編


図 3-15 コマンドのラベル指定

図 3-16 コマンドの特権指定

3.4.3.5. ポリシー

ポリシーファイルでは、プロファイル（3.4.3.2）および承認（3.4.3.3）について、デ

フォルトとなる値の定義をすることができる。ここで定義されたポリシーはシステム全体

に適用される。



Trusted Solaris 編


(1) ポリシーファイル（policy.conf）の構成

policy.conf ファイルは、ユーザと役割に与えられることができる拡張属性を次の

形式で定義する。この定義はシステムを利用するすべてのユーザと役割に適用される。

key=value

リスト 3-27 にデフォルトの定義ファイルを示す。表 3-28 に定義可能なキーと有効

な値を示す。

リスト 3-27 policy.conf の例

# # Copyright (c) 1999-2000 by Sun Microsystems, Inc. All rights reserved. # # /etc/security/policy.conf # # security policy configuration for user attributes. see policy.conf(4) # #ident "@(#)policy.conf 1.4 01/01/09 SMI; TSOL 2.x" # #AUTHS_GRANTED= IDLECMD=lock IDLETIME=30 LABELVIEW=showsl LOCK_AFTER_RETRIES=yes PASSWORD=manual PROFS_GRANTED=Basic Solaris User



Trusted Solaris 編


表 3-28 policy.conf ファイルのキー

# タグ有効な値種別

1 AUTHS_GRANTED= 承認の名称（auth_attr ファイルの authname） S8

2 PROFS_GRANTED= プロファイルの名称（prof_attr ファイルの profname） S8

3 IDLECMD= logout|lock IDELETIME 経過後のアクション

TS

4 IDLETIME= minutes IDLECMD を実行されるまでの時間（有効値は 1～120）

TS

5 LABELVIEW= hidesl|showsl ウインドウラベルの表示と非表示の指定

TS

6 LOCK_AFTER_RETRIES= yes|no /etc/default/loginの RETRIESを超えたログイン失敗に際しアカウントのロックをするかどうかの指定

TS

7 PASSWORD= auto|manual ユーザのパスワード変更をする際の変更方法の指定

TS

3.4.4. 特権定義

従来の UNIX では、プロセスの実効 UID が 0（euid=0）である場合、唯一にして最大の特

権を持つと判断される。その判定はカーネル関数（suser()）が行っている。Trusted Solaris

ではこの関数を排除し、カーネルは細分化された適切な特権の解釈をしている。

特権は、プロファイルにより、コマンド、アクション、シェルやプログラムなどに個別

に割り当てることが可能である。プロファイルに与えられる特権は継承可能特権であり、

fork(2)や exec(2)などのシステムコールによって派生するプロセスに継承される特権であ

る。

また、特権は、実行可能ファイルのファイル属性として割り当てることも可能である。

ファイルの属性として定義される特権は強制特権と許容特権であり、これらは派生するプ

ロセスに継承されることのない特権である。

有効となる特権は、プロセスの実行環境やプロセスの派生状態に応じ、上記の三種類の

特権の組み合わせにより適宜決定される。



Trusted Solaris 編


表 3-29 File System 特権

# 特権 (特権 ID) 主な権限種別

1 file_audit (1) ファイルおよびディレクトリの監査事前選択情報の取得と設定を許可

TS

2 file_chown (2) ファイルの所有者の変更を許可 TS

3 file_dac_execute (3) DAC の制限を超えてファイルの実行を許可 TS

4 file_dac_read (4) DAC の制限を越えてファイルの読込を許可 TS

5 file_dac_search (5) DAC の制限を超えてファイルの検索を許可 TS

6 file_dac_write (6) DAC の制限を越えてファイルの書込を許可 TS

7 file_downgrade_sl (8) ファイルおよびディレクトリに対する優位でない SL の設定を許可

TS

8 file_lock (9) 保持していないファイルロックのロック情報の取得を許可

TS

9 file_mac_read (10) MAC の制限を越えてファイルの読込を許可 TS

10 file_mac_search (11) MAC の制限を超えてファイルの検索を許可 TS

11 file_mac_write (12) MAC の制限を越えてファイルの書込を許可 TS

12 file_owner (14) ファイルの所有者に関わらずアクセス時間・修正時間・監査事前選択属性・特権・ラベルの変更許可

TS

13 file_setdac (15) ファイルおよびディレクトリの所有者にかかわらずパーミッションと ACL の属性の変更を許可

TS

14 file_setid (16) ファイルの所有者の変更や set-user-ID ビットおよび set-group-ID ビットの設定を許可

TS

15 file_setpriv (17) ファイルの所有者が実行可能ファイルに対する特権の設定を許可

TS

16 file_upgrade_sl (19) ファイルおよびディレクトリに対する優位な SLの設定を許可

TS

Note: file_dac_write 特権と file_mac_write 特権はファイル保護の制限を越える特権であるが、共に与えられたプロセスはすべてのファイルへの書込が可能となり、そのようなプロセスが不正に利用された場合は定義ファイルやログファイルなどが改竄される恐れがある。これを防ぐためには対象となるファイル属性を変更することにより特権を与えることを回避する方が望ましい。



Trusted Solaris 編


表 3-30 System V IPC 特権


1 ipc_dac_read (20) DAC の制限を越えて IPC メッセージキュー・セマフォセット・共有メモリセグメントの読取を許可

TS

2 ipc_dac_write (21) DAC の制限を越えて IPC メッセージキュー・セマフォセット・共有メモリセグメントの書込を許可

TS

3 ipc_mac_read (23) MAC の制限を越えて IPC メッセージキュー・セマフォセット・共有メモリセグメントの読取を許可

TS

4 ipc_mac_write (24) MAC の制限を越えて IPC メッセージキュー・セマフォセット・共有メモリセグメントの書込を許可

TS

5 ipc_owner (26) IPC メッセージキュー・セマフォセット・共有メモリセグメントの削除や所有者・パーミッションACL の変更を許可

TS

表 3-31 Network 特権


1 net_broadcast (30) ブロードキャストおよびマルチキャストの送信を許可

TS

2 net_dowgrade_sl (32) 書込中のデータに対する SL の指定またはネットワーク終端のデフォルトに対する優位でない SLの設定を許可

TS

3 net_mac_read (33) マルチレベルのポートのバインドとアクセプトを許可

TS

4 net_privaddr (35) 特権ポート（1-1023 および 6000-6002）のバインドを許可（well-known port を含む）

TS

5 net_rawaccess (36) ネットワーク層への直接アクセスを許可（ネットワークのラベル付けは省略され監査は省略されない）

TS

6 net_reply_equal (37) 最後に受け取ったパケットのラベルでのリプライを許可

TS

7 net_setclr (38) 書込中のデータに対する許可上限の指定またはネットワーク終端のデフォルトに対する許可上限の設定を許可

TS

8 net_setid (39) 書込中のデータに対する実効 UID・実効 GID・付随するグループの指定またはネットワーク終端のデフォルトの実効 UID・実効 GID・付随するグループの設定を許可

TS

9 net_setpriv (40) 書込データに対する特権の設定またはネットワーク終端のデフォルトに対する特権の設定を許可

TS

10 net_upgrade_sl (42) 書込中のデータに対する SL の指定またはネットワーク終端のデフォルトに対する優位な SL の設定を許可

TS



Trusted Solaris 編


Note: net_mac_read 特権と net_reply_equal 特権はインターネットサーバーのプロセスをマルチレベルに対応させる場合に組み合わせて利用する。これにより外部と内部に対して異なるラベルを割り当てたマルチラベルのネットワークアクセスにプロセスが対応することが可能となる。

表 3-32 Process 特権


1 proc_audit_appl (43) Trusted Solaris のTCBイベント番号範囲外の監査イベントについての監査レコード生成を許可

TS

2 proc_audit_tcb (44) Trusted Solaris のTCBイベント番号範囲内の監査イベントについての監査レコード生成を許可

TS

3 proc_chroot (45) ルートディレクトリの変更を許可 TS

4 proc_debug_nontranquitl (29)

プロセスオブジェクトの SL を変更する際にプロセスオブジェクトへの一定のアクセスを許可

TS

5 proc_dumpcore (46) TCBプロセスがset-user-IDまたはset-group-IDが設定されたプログラムの実行またはシグナルを受け取って core ファイルを生成する特権を利用するプログラムの実行を許可

TS

6 proc_mac_read (47) 対する優位な SL を持つプロセスからの読込を許可

TS

7 proc_mac_write (48) 対する優位でない SL を持つプロセスへの書込を許可

TS

8 proc_nodelay (49) 秘密チャネルと識別される操作の際にプロセスを遅延させるとう対策を行わないことを許可

TS

9 proc_owner (51) プロセスの所有者に関わらずプロセスからの読込やプロセスへの書込を許可

TS

10 proc_setclr (52) 現在のプロセスの許可上限と異なる許可上限の設定を許可

TS

11 proc_setid (53) 現在のプロセスの UIG または GID と異なる UIDまたは GID の設定を許可

TS

12 proc_setsl (55) 現在のプロセスの SL と異なる SL の設定を許可 TS

13 proc_tranquil (56) プロセスオブジェクトが他のプロセスに利用されている際に現在と異なる SL の設定を許可

TS

Note: proc_setid特権はsetuid(2)やsetgid(2)により実UIDや実GIDを変更する場合に必要となる特権である。



Trusted Solaris 編


表 3-33 System 特権


1 sys_audit (57) カーネルの監査デーモンの起動を許可 TS

2 sys_boot (58) halt（停止）・re-boot（再起動）・suspend（中断）を許可

TS

3 sys_config (59) メモリマップﾄﾞファイルまたは共有メモリセグメントのロックとアンロックを許可

TS

4 sys_console (60) コンソールの出力を他のデバイスへ切替えることを許可

TS

5 sys_devices (61) デバイスス特殊ファイルの生成を許可 TS

6 sys_fs_config (63) ファイルシステムロックの操作を許可 TS

7 sys_ipc_config (64) IPC メッセージキューのバッファサイズの拡大を許可

TS

8 sys_maxproc (65) プロセスの所有者がプロセスの最大数を超えた際にプロセスの生成を許可

TS

9 sys_minfree (66) ファイルシステムの空き記憶領域が最低値を下回った際にファイルシステムへの書込を許可

TS

10 sys_mount (67) マウント制限されたファイルシステムのマウントを許可

TS

11 sys_net_config (68) ネットワークインターフェースおよびルーティングの設定を許可

TS

12 sys_nfs (69) カーネルの NFS デーモンの起動を許可 TS

13 sys_suser_compat (70) カーネル suser()関数のコールを許可 TS

14 sys_system_door (28) すべてのSLからオープン可能なdoorの生成を許可

TS

15 sys_trans_label (71) プロセスの SL より優位でない SL の「外部文字列形式」とラベルの変換を許可

TS

Note: sys_suser_compat 特権は Trusted Solaris 以外のローダブルモジュールによる suser()関数のコールに対して成功をさせる特権である。



Trusted Solaris 編


表 3-34 Window 特権


1 win_colormap (72) カラーマップの制限を越えることを許可 TS

2 win_config (73) X サーバーにパーマネントに維持されるリソースの設定と削除を許可

TS

3 win_dac_read (74) 所有者となっていないウインドウリソースの読込を許可

TS

4 win_dac_write (75) 所有者となっていないウインドウリソースの書込と生成を許可

TS

5 win_dga (76) X のダイレクトグラフィックアクセスプロトコル拡張の利用を許可

TS

6 win_devices (77) ウインドウの入力デバイスに操作を実行することを許可

TS

7 win_downgrade_sl (79) 現在のウインドウリソースのSLを優位でないSLに設定することを許可

TS

8 win_fontpath (80) フォントパスの設定を許可 TS

9 win_mac_read (81) 対する優位な SL を持つウインドウリソースからの読込を許可

TS

10 win_mac_write (82) 対する優位でない SL を持つのウインドウリソースへの書込と生成を許可

TS

11 win_selection (83) 選択を仲介するプログラムの干渉無しにウインドウ間のデータの移動を要求することを許可

TS

12 win_upgrade_sl (86) 現在のウインドウリソースのSLを優位なSLに設定すること設定を許可

TS

3.4.4.1. 特権の定義と確認

プロファイルの実行属性として与えられる継承可能特権、実行可能ファイルの属性とし

て与えられる強制特権と許容特権、それぞれについて設定と確認の方法、また、実行中の

プロセスの特権についての確認の方法についてまとめる。

(1) 特権の設定方法

プロファイルおよび実行可能ファイルにおける特権を設定するツールを表 3-35 に

示す。

表 3-35 特権の設定ツール

# 設定可能対象特権の種類 GUI ツール CUI ツール種別

1 プロファイル継承可能特権 SMC 3.4.3.4(2)(A)参照

smprofile S8+

2 実行可能ファイル強制特権許容特権

File Manager setfpriv (A)参照

TS



Trusted Solaris 編


(A) setfpriv

setfpriv { -s | -m | -d} -a 許容特権セット -f 強制特権セットファイル名 …

説明：

ファイルに特権を設定する。

オプション：

-s/-m/-d 設定/追加/削除を指定する。

-a 許容特権セットを指定する。

-f 強制特権セットを指定する。

(2) 特権の確認方法

実行環境としてプロファイルおよび実行可能ファイルとして設定されている特権、

また実行中のプロセスとして有効となってい特権を確認するツールを表 3-36に示す。

表 3-36 特権の確認ツール

# 確認可能対象特権の種類 GUI ツール CUI ツール種別

1 プロファイル継承可能セット SMC 3.4.3.4(2)(A)参照

profiles -l (A)参照

S8+

2 実行可能ファイル強制セット許容セット

File Manager getfpriv (B)参照

TS

3 実行中プロセス継承可能セット許可セット実行セット保存セット

N/A ppriv (C)参照

TS

(A) profiles

profiles [-l] [ユーザ名 …]

説明：

ユーザに設定されたプロファイルを表示する。

ユーザ名を省略した場合は自分自身に設定されたプロファイルを表示する。

オプション：



Trusted Solaris 編


-l 各プロファイルに設定されているコマンドとその実行属性を表示する。

(B) getfpriv

getfpriv ファイル名 … getfpriv [-s] -a ファイル名 … getfpriv [-s] -f ファイル名 …

説明：

ファイルに設定された特権を表示する。

オプション：

-a 許容特権セットのみを表示する。

-f 強制特権セットのみを表示する。

-s setfpriv 向きのフォーマットにて表示。-f または-a と共に指定する。

(C) ppirv

/usr/bin/ppriv [-a] [プロセス ID …]

説明：

プロセスに設定された実効特権セットを表示する。

プロセス ID を省略した場合は priv コマンド自身の特権を表示する。

オプション：

-a 全ての特権セット（継承可能・許可・実効・保存）を表示する。

3.4.4.2. 特権の取得と継承

Solaris および Trusted Solaris において、プロセスのセキュリティ属性として次のクレ

デンシャルが実装されている。

実 UID（Cr）と実 GID

実効 UID（Ce）と実効 GID

保存 UID（Cs）と保存 GID

これの他にクレデンシャルに影響を与えるものとして、実行可能ファイルに設定が可能

な次の属性が実装されている。

set-uid または set-gid が設定された場合の所有者の ID（Xu）とグループの ID



Trusted Solaris 編


Trusted Solaris においては、プロセスのセキュリティ属性が拡張され次の特権が実装さ

れている。

継承可能セット（I : Inheritable）

許可セット（P : Permitted Set）

実効セット（E : Effective Set）

保存セット（S : Saved Set）

スタートユーザ ID（x）

このほかに特権に影響を与えるものとしては、実行可能ファイルに設定が可能な次の特

権が実装されている。

許容セット（A : Allowed Set）

強制セット（F : Forced Set）

(1) プロセスが特権を取得する方法

プロセスが最初に特権を取得する場合、また継承されて特権を取得する場合の規則

を次に示す。

(A) 強制セットが設定されているコマンド（プログラム）を実行する場合

この例は、コマンド実行環境においてコマンドを実行した場合に適用されるもの

である。

E[new] = P[new] = F intersect A

(B) プロファイルが解釈されてコマンド（プログラム）を実行する場合

この例は、プロファイルシェル環境におけるコマンドの実行、または、以下のよ

うなプロファイルシェル（pfsh, pfcsh, pfksh）の実行において、アカウントのプ

ロファイルを解釈して実行される場合に適用されるものである。

#!/bin/pfsh command

E[new] = P[new] = ( I union F ) intersect A

S[new] = I intersect A

I[new] = I



Trusted Solaris 編


(C) プロファイルが解釈されてシェルスクリプトを実行する場合

この例は、以下のようなスクリプト自体が、プロファイルに登録されている場合

において、プロファイルシェル環境または、プロファイルシェルの中から、このス

クリプトを実行する場合に適用されるものである。

#!/bin/csh command

シェルスクリプト自体の特権セットは以下のようになる。

E[s] = P[s] = ( I[s] union F[s] union F[i] ) intersect A[i]

S[s] = I[s] intersect A[i]

I[s] = I[s]

コマンドの特権セットは以下のようになる。

E[new] = P[new] = ( I[s] union F ) intersect A

S[new] = I[s] intersect A

I[new] = I[s]

なお、sはシェルスクリプト、iはインタープリター（#!で指定される）を表す。

(2) プロセスの特権が無効となる状態など

特権はクレデンシャルに連動して変化する仕組みを持っている。

(A) set-user-ID ビットによるクレデンシャルの変化

proc_owner 特権を持つ : Cs[new] ← u, Ce[new] ← u

(B) setuid(2)システムコールによるクレデンシャルの変化

proc_setid 特権を持つ : Cs[new] ← u, Ce[new] ← u, Cr[new] ← u

Cr ＝ u ∨ Cs ＝ u : Ce[new] ← u

この仕組みは、Solaris の suser()による判定に変わる Trusted Solaris の仕組

みである。



Trusted Solaris 編


(C) setuid(2)システムコールによる特権の変化

Ce ＝ x ∧ x[new] ≠ x : S[new] ← E, E[new] ← “none” Ce ≠ x ∧ x[new] ＝ x : E[new] ← S

スタートユーザIDと異なるUIDが実効IDとして設定される場合、実効セットは、

保存セットに格納されてクリア（すべての特権が無効化）される。

再び、スタートユーザ IDが実効 IDとして設定される場合、保存セットが実行セッ

トに戻される。

3.4.5. ラベル定義

Trusted Solaris では MLS を実現する、全てのサブジェクトとオブジェクトにラベルを実

装している。

サブジェクトのラベルは、ユーザおよび役割、またはプロファイルにより、コマンド、

アクション、シェルやプログラムなどに個別に割り当てることが可能である。これらに与

えられるラベルは最下位機密ラベルと許可上限であり、特権（proc_setsl）を持つアプリ

ケーションは許可範囲でのラベルの変更が可能となっている。

また、オブジェクトのラベルは、ファイルやディレクトリのファイル属性として割り当

てることが可能である。

3.4.5.1. ラベルの定義と確認

サブジェクトのラベルとして、ユーザおよび役割、またはプロファイルの実行属性に与

えられるラベル、オブジェクトのラベルとして、ファイルの属性として与えられるラベル、

それぞれについて設定と確認の方法、また、実行中のプロセスのラベルについての確認の

方法についてまとめる。

(1) ラベルの設定方法

プロファイルおよびファイルにおけるラベルを設定するツールを表 3-35 に示す。



Trusted Solaris 編


表 3-37 ラベルの設定ツール

# 設定可能対象ラベルの種類 GUI ツール CUI ツール種別

1 ユーザと役割最下位ラベル許可範囲

SMC 3.4.3.1(2)(C)参照

smuser/smrole S8+

2 プロファイル最下位ラベル許可範囲

SMC 3.4.3.4(2)(A)参照

smprofile S8+

3 ファイルオブジェクト・ラベル

File Manager setlabel (A)参照

TS

(A) setlabel

setlabel [-s] [-h] ラベル名ファイル名 …

説明：

ファイルに CMW ラベルを設定する。

オプション：

-s CMW ラベルの機密ラベルを指定する。

-h シンボリック・リンクのラベルを指定する。

(2) ラベルの確認方法

実行環境としてプロファイルおよび実行可能ファイルとして設定されている特権、

また実行中のプロセスとして有効となってい特権を確認するツールを表 3-36に示す。

表 3-38 ラベルの確認ツール

# 確認可能対象ラベルの種類 GUI ツール CUI ツール種別

1 ユーザと役割最下位ラベル許可範囲

SMC 3.4.3.1(2)(C)参照

smuser/smrole S8+

2 プロファイル最下位ラベル許可範囲

SMC 3.4.3.4(2)(A)参照

smprofile S8+

3 ファイルオブジェクト・ラベル

File Manager getlabel (A)参照

TS

4 実行中プロセスサブジェクト・ラベル

N/A plabel (B)参照

TS



Trusted Solaris 編


(A) getlabel

getlabel [-hiI|LsSx] ファイル名 …

説明：

ファイルに設定された CMW ラベルを表示する。

オプション：

-h シンボリック･リンクのラベルを表示する。

-s CMW ラベルの機密ラベルを短縮型で表示する。

-S CMW ラベルの機密ラベルを詳細型で表示する。

(B) plabel

/usr/bin/plabel [-iI|LsS] [プロセス ID …]

説明：

プロセスに設定されたラベルを表示する。

プロセス ID を省略した場合は plabel コマンド自身のラベルを表示する。

オプション：

-s 機密ラベルを短縮型で表示する。

-S 機密ラベルを詳細型で表示する。

3.4.6. 特権デバック

特権デバックは、アプリケーションが動作する際に必要とする特権を検出するための

ツールである。特権デバッグを行う場合は、対象のサービスのプログラムを runpd の後に、

オプションや引数と共に指定する。

runpd プログラムプログラム引数

起動したプロセスおよび派生するプロセスについても特権の検出が可能である。

特権デバッグを行う場合は､できる限り実装のイメージに合わせて実行することが重要



Trusted Solaris 編


である。動作させるラベルを[ADMIN_LOW]以外とする場合は、動作させるラベルに特権デ

バッグを行うワークスペースのラベルを変更してから行う。

3.4.6.1. 特権デバックの有効化

root 役割になり、ターミナルを起動して、/etc/system および/etc/syslog.conf を変更

する。設定後、リブートを行う。

リスト 3-28/etc/system

tsolsys:tsol_privs_debug=1

リスト 3-29/etc/syslog.conf

kern.debug;local7.debug /var/log/privdebug.log

Note: インターネットサーバーのプロセスの殆どは、root(uid=0)で起動するため。特権デバックもroot 役割にて行う必要がある。 root 役割にてプロセスの操作を可能とするために、secadmin 役割にて Custom Root Role プロファイルに Process Management プロファイルを追加しておくと便利である。

3.4.6.2. 特権デバッグ環境の準備

root 役割になり、フロントパネルから root 役割のワークスペースのボタンにマウスの

カーソルを合わせ、右ボタンをクリックするとポップアップメニューが表示される。



Trusted Solaris 編


図 3-17 ワークスペース操作イメージ

ポップアップメニューから[Change Workspace Label]を選択すると、ワークスペースの

ラベル選択イメージが表示される。

図 3-18 ワークスペースのラベル選択イメージ

ラベルを選択して[OK]を押すと、ワークスペースのラベルが変更される。その後そのワー

クスペースからアプリケーションを起動した場合は、そのワークスペースのラベルで実行

される。

3.4.6.3. 特権デバックツール（runpd）の実行

ワークスペースからターミナルを起動して、対象のサービスのプログラムを、runpd を用



Trusted Solaris 編


いて、オプションや引数と共に実行する。

リスト 3-30 特権デバックの実行（root 役割）

# runpd -f /usr/lib/sendmail -bd -q15m …（省略）…

secadmin 役割になり、特権デバッグのログ（privdebug.log）を確認する。

リスト 3-31 特権デバッグログの確認（secadmin 役割）

Feb 14 21:47:06 macaroni genunix_policy: [ID 377770 kern.info] DEBUG: /usr/lib/sendmail pid 1377 lacking privilege 53 to set process gids Feb 14 21:47:06 macaroni genunix_policy: [ID 377770 kern.info] DEBUG: /usr/lib/sendmail pid 1377 lacking privilege 70 to act as superuser Feb 14 21:47:06 macaroni last message repeated 1 time Feb 14 21:47:06 macaroni genunix_policy: [ID 377770 kern.info] DEBUG: /usr/lib/sendmail pid 1377 lacking privilege 68 to modify net table Feb 14 21:47:06 macaroni last message repeated 6 times Feb 14 21:47:07 macaroni genunix_policy: [ID 377770 kern.info] DEBUG: /usr/lib/sendmail pid 1377 lacking privilege 70 to act as superuser Feb 14 21:47:07 macaroni genunix_policy: [ID 377770 kern.info] DEBUG: /usr/lib/sendmail pid 1377 lacking privilege 68 to modify net table Feb 14 21:47:07 macaroni last message repeated 1 time Feb 14 21:47:07 macaroni genunix_policy: [ID 377770 kern.info] DEBUG: /usr/lib/sendmail pid 1377 lacking privilege 70 to act as superuser Feb 14 21:47:07 macaroni genunix_policy: [ID 377770 kern.info] DEBUG: /usr/lib/sendmail pid 1377 lacking privilege 68 to modify net table Feb 14 21:47:07 macaroni genunix_policy: [ID 377770 kern.info] DEBUG: /usr/lib/sendmail pid 1377 lacking privilege 70 to act as superuser Feb 14 21:47:07 macaroni genunix_policy: [ID 377770 kern.info] DEBUG: /usr/lib/sendmail pid 1377 lacking privilege 68 to modify net table Feb 14 21:47:07 macaroni genunix_policy: [ID 377770 kern.info] DEBUG: /usr/lib/sendmail pid 1377 lacking privilege 53 to set process uids Feb 14 21:47:07 macaroni genunix_policy: [ID 377770 kern.info] DEBUG: /usr/lib/sendmail pid 1378 lacking privilege 10 to examine device attrs Feb 14 21:47:07 macaroni genunix_policy: [ID 377770 kern.info] DEBUG: /usr/lib/sendmail pid 1378 lacking privilege 10 to access file Feb 14 21:47:07 macaroni genunix_policy: [ID 377770 kern.info] DEBUG: /usr/lib/sendmail pid 1378 lacking privilege 10 to examine device attrs Feb 14 21:47:07 macaroni last message repeated 3 times …（省略）…

利用方法に従ったテストの作業を繰り返し、確認された全ての特権をまとる。



Trusted Solaris 編


表 3-39 検出された特権

# 特権 (特権 ID)

1 file_chown (2)

2 file_mac_read (10)

3 net_privaddr (35)

4 proc_setid (53)

5 sys_net_config (68)

6 sys_suser_compat (70)

Note: アプリケーションによっては利用方法によって異なる特権が検出される場合があるため、利用方法に従った十分なテストを行っておく必要がある。

3.4.6.4. 特権の割当ておよびテストの実行

secadmin 役割になり、起動するプログラムおよび派生するプログラムのファイルに、強

制特権および許容特権を割り当てる。通常は許容特権のみ割り当てる。この手順は

3.4.4.1(1)(A)に記載している。

リスト 3-32 強制特権と許容特権の割り当て（secadmin 役割）

$ setfpriv -s -f none -a all /usr/lib/sendmail $ setfpriv -s -f none -a all /usr/lib/mail.local

Custom Root Role プロファイルにプログラムを追加し、ラベルや特権の定義を行う。こ

の手順は 3.4.3.4(2)(A)に記載している。



Trusted Solaris 編


図 3-19 プログラム実行属性定義（secadmin 役割）

root 役割になり、対象のサービスのプログラムを、runpd を用いずに、オプションや引

数と共に起動する。

リスト 3-33 サービスプログラムの実行（root 役割）

# /usr/lib/sendmail -bd -q15m

secadmin 役割になり、実行中のプロセスについて、特権およびラベルの確認を行う。こ

の手順は 3.4.4.1(2)(C)および 3.4.5.1(2)(B)に記載している。

表 3-40 サービスプログラムの実行属性の確認（secadmin 役割）

# ps -ef| grep sendmail root 1442 1 0 22:05:29 ? 0:00 /usr/lib/sendmail -bd -q15m root 1444 1165 0 22:05:36 pts/10 0:00 /usr/bin/grep sendmail # plabel 1442 1442: [PUBLIC SERVICES] # ppriv 1442 1442: net_privaddr,proc_setid,sys_net_config,sys_suser_compat

実行中のプロセスが期待通りの設定となっていなければ、関連するプログラムのプロ

ファイルおよび強制特権と許容特権の確認を行う。この手順は 3.4.4.1(2)(A)および

3.4.5.1(2)(A)に記載している。これらが期待通りの設定となるまで作業を繰り返す。結果



Trusted Solaris 編


的に実際にサービスが利用できるか確認する。

3.4.7. トラステッドネットワーク定義

次にトラステッドネットワークを構成する定義ファイルについて解説する。トラステッ

ドネットワークを構成する定義ファイルは、ネットワークインターフェース属性データ

ベース（tnidb）、ホストとネットワークの属性データベース（tnrhdb）、プロトコルと属性

のテンプレート（tnrhtp）である。

トラステッドネットワークプロトコルは、ネットワークを介した End-to-End の通信にお

いて、また異なる Trusted OS のシステム間において、拡張されたセキュリティ属性の交換

が可能とするものであるが、これらの定義ファイルにより、ネットワークインターフェー

スに対する許可範囲や、ホストやネットワークに対するネットワークアクセスについて制

限をかけることも可能となっている。

3.4.7.1. ネットワークインターフェースの属性

Trusted Solaris ではネットワークのインターフェース毎に、次のセキュリティ属性の定

義をすることが可能である。

ネットワークアクセスに対するラベルの認可範囲

ラベルをサポートしないホストのアクセスに対するデフォルトのラベルと許可上限

特権をサポートしないホストのアクセスに対する強制する特権

これらの定義はローカルに管理され、NIS または NIS+のネームサービスで管理すること

はできない。

(1) ネットワークインターフェース属性データベース（tnidb）の構成

tnidb ファイルはホストのすべてのインターフェースに対するセキュリティ属性の

定義を含む。

ネットワークの起動中にこのファイルを変更した場合は、tnctl コマンドにより有

効にされるまで、変更は有効とならない。

リスト 3-34 に tnidb ファイルのフィールド定義、および Trusted Solaris 8 の例

を示す。また、

表 3-41 に各フィールドの値と意味を示す。



Trusted Solaris 編


リスト 3-34 tnidb ファイルのフィールド

（フィールド） interface_name:attr

（例） hme0: min_sl=0x00000000000000000000000000000000000000000000000000000000000000000000; max_sl=0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff; def_label=[0x00000000000000000000000000000000000000000000000000000000000000000000]; def_cl=0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff forced_privs=empty

表 3-41 tnidb のフィールドの意味


1 interface_name インターフェース名 TS

2 attr インターフェース属性


min_sl 最下位 SL TS

max_sl 最上位 SL TS

def_label デフォルトラベル TS

def_cl デフォルト許可上限 TS

forced_privs 強制特権 TS

TS

(2) ネットワークインターフェース属性データベース（tnidb）の設定方法

ネットワークインターフェースの属性の設定は、secadmin 役割により行う。admin

役割では設定の表示のみ可能である。

(A) SMC によりネットワークインターフェース属性を定義する手順

secadmin 役割にてネットワークインターフェースの属性の定義を行う例を示す。

最初に、Navigation から [Trusted Solaris Configuration] – [Interface Manager]とツリーをクリックして行くと、図 3-20 のようなイメージが表示される。



Trusted Solaris 編


図 3-20 ネットワークインターフェース属性編集初期画面

ネットワークインターフェースの定義を新たに追加する場合は、Navigation から

[Interface Manager]を選択し、マウスの右ボタンをクリックするとメニューが現れ

るので、[Add Interface]を選択する。または[Action]をクリックしメニューから

[Add Interface]を選択する。その後図 3-21 のようなイメージが表示される。

図 3-21 ネットワークインターフェース属性編集画面

ネットワークインターフェースの属性の設定



Trusted Solaris 編



Interface Interface インターフェース名

Minimum Label 認可範囲の下限のラベル Accreditation Ranges

Maximum Label 認可範囲の上限のラベル

Label デフォルトのラベル

Clearance デフォルトの許可上限

Default Security Attribute

Forced Privileges デフォルトの強制特権

これらの入力後[OK]をクリックすると、ネットワークインターフェースの属性が

設定される。

3.4.7.2. ホストとネットワークの属性

Trusted Solaris ではネットワーク接続されるホストやセグメントに対して、標準の IP

により通信を行うか、各種の拡張のセキュリティ属性を持つトラステッドネットワークプ

ロトコルによる通信を行うかの定義をすることが可能である。

この定義はtnrhdbファイルおよびtnrhtpファイルにより行う。tnrhdbファイルはtnrhtp

ファイルにより定義された、各種のプロトコルに対応した属性のテンプレートについて、

ホストアドレスまたはネットワークアドレス単位に対応付けを行う。

(1) ホストとネットワークの属性データベース（tnrhdb）の構成

tnrhdb ファイルは、ホストアドレスやネットワークアドレスに対するテンプレート

を定義する。


効にされるまで、変更は有効とならない。

リスト 3-35 に tnrhdb ファイルのフィールド定義、および Trusted Solaris 8 の例

を示す。また、

表 3-42 に各フィールドの値と意味を示す。

リスト 3-35 tnrdb ファイルのフィールド

（フィールド） IP_address:tmplate_name

（例） 192.168.0.0/16:unlab_public



Trusted Solaris 編


表 3-42 tnrdb のフィールドの意味

# フィールド説明種別1 IP_address IP アドレス

有効型(説明) 種別

10.100.100.201 (IPv4 address) TS

10.100.0.0 (IPv4 class A, B, C address) TS

10.100.128.0/17 (IPv4 subnet address) TS

fec0¥:¥:9¥:20ff¥:fea0¥:21f7 (IPv6 address) TS

fec0¥:¥:/10 (IPv6 subnet address) TS

TS

2 template_name テンプレート名 TS

(2) ホストとネットワークの属性データベース（tnrhdb）の設定方法

ホストとネットワークの属性の設定は、secadmin 役割により行う。admin 役割では

設定の表示のみ可能である。

(A) SMC によりホストとネットワークの属性を定義する手順

secadmin 役割にてホストとネットワークの属性の定義を行う例を示す。

最初に、Navigation から[Trusted Solaris Configuration] – [Computer and Networks] – [Security Families]とツリーをクリックして行くと、図 3-22 のよう

なイメージが表示される。



Trusted Solaris 編


図 3-22 ホスト・ネットワーク属性編集初期画面

テンプレートを割り当てるホストやネットワークを追加する場合は、Navigation

からテンプレートを選択し、マウスの右ボタンをクリックするとメニューが現れる

ので、[Add host(s)]を選択する。または[Action]をクリックしメニューから[Add

host(s)]を選択する。その後図 3-23 のようなイメージが表示される。

図 3-23 ホスト・ネットワーク属性編集画面

ホストとネットワークの属性の設定



Trusted Solaris 編



Hosts/Wildcard ホストアドレスかワイルドカードかの指定

Hostname ホスト名の指定（ワイルドカードの場合は指定不要）

IP Address IP アドレスの指定（ワイルドカードは Prefix Length まで）

Prefix Length 頭からのビット長（ホストの場合は指定不要）

Template 適用するテンプレートの指定

これらの入力後[OK]をクリックすると、ホストとネットワークの属性が設定され

る。

3.4.7.3. プロトコルと属性のテンプレート

Trusted Solaris は、標準の IP プロトコル以外に、拡張のセキュリティ属性を持つトラ

ステッドネットワークプロトコルをサポートしている。Trusted Solaris 8 でサポートする

セキュリティオプションのタイプを次に示す。

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

属性はテンプレートとして定義し、ホストのアドレスやセグメントのネットワークアド

レスに対して適用することが可能である。

(1) プロトコルと属性のテンプレート（tnrhtp）の構成

tnrhtpファイルは、各タイプに準拠するIPのセキュリティオプションのテンプレー

トを定義する。


効にされるまで、変更は有効とならない。リスト 3-36 に tnidb ファイルのフィール

ド定義、および Trusted Solaris 8 の例を示す。また、以下の表に各セキュリティオ

プションのタイプに応じたフィールドの値と意味を示す。



Trusted Solaris 編


リスト 3-36 tnrhtp のフィールド

（フィールド） template_name:attr

（例） tsol:host_type=sun_tsol; min_sl=0x00000000000000000000000000000000000000000000000000000000000000000000; max_sl=0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff; allowed_privs=all;ip_label=none;ripso_label=empty;ripso_error=empty;doi=0;

表 3-43 tnrhtp のフィールドの意味（unlabeled タイプ）


1 template_name インターフェース名 TS

2 attr host_type=unlabeled






forced_priv 強制特権 TS

ip_label none|ripso|cipso TS

ripso_label PAF(GENSER|SIOP-ESI|SCI|NSA|DOE)と格付け

TS

ripso_error PAF(GENSER|SIOP-ESI|SCI|NSA|DOE)

TS

doi integer TS

TS

表 3-44 tnrhtp のフィールドの意味（sun_tsol タイプ）


1 tmplate_name インターフェース名 TS

2 attr host_type=sun_tsol




allowed_priv 許容特権 TS



TS


TS

doi integer TS

TS



Trusted Solaris 編


表 3-45 tnrhtp のフィールドの意味（ripso タイプ）

# フィールド説明種別1 tmplate_name インターフェース名 TS 2 attr host_type=ripso








TS


TS

doi integer TS

TS

表 3-46 tnrhtp のフィールドの意味（cipso タイプ）



2 attr host_type=cipso






TS

表 3-47 tnrhtp のフィールドの意味（tsix タイプ）



2 attr host_type=tsix





allowed_priv 許容特権 TS



TS


TS

doi integer TS

TS



Trusted Solaris 編


(2) プロトコルと属性のテンプレート（tnrhtp）の設定方法

プロトコルと属性の設定は、secadmin 役割により行う。admin 役割では設定の表示

のみ可能である。

(A) SMC によりプロトコルと属性のテンプレートを定義する手順

secadmin 役割にてプロトコルと属性のテンプレートの定義を行う例を示す。

最初に、Navigation から[Trusted Solaris Configuration] – [Computer and Networks] – [Security Families]とツリーをクリックして行くと、図 3-24 のよう

なイメージが表示される。

図 3-24 プロトコル属性編集初期画面

テンプレートの定義を新たに追加する場合は、Navigation から[Security

Families]を選択し、マウスの右ボタンをクリックするとメニューが現れるので、

[Add Template]を選択する。または[Action]をクリックしメニューから[Add

Template]を選択する。その後図 3-25 のようなイメージが表示される。



Trusted Solaris 編


図 3-25 プロトコル属性編集画面

General


Name テンプレート名

Host Type Unlabeled|Trusted Solaris|RIPSO|CIPSO|TSIX

Access Control Attributes


Minimum Label 認可範囲の下限のラベル Accreditation Range

Maximum Label 認可範囲の上限のラベル

Label デフォルトのラベル Defaults

Clearance デフォルトの許可上限

Advanced Security Attributes



Trusted Solaris 編



Domain Of Interpretation DOI 整数

IP Label none|ripso|cipso

RIPSO Send Class 格付け

RIPSO Send PAF PAF(GENSER|SIOP-ESI|SCI|NSA|DOE)

IP Options

RIPSO Return PAF PAF(GENSER|SIOP-ESI|SCI|NSA|DOE)

Forced Privileges 強制特権 Privileges

Allowed Privileges 許容特権

Access Control Attribute および Advanced Security Attribute については Host

Type および IP Options の IP Label におけるプロトコルタイプの指定により設定で

きる属性が異なっている。

インターネットサーバー構築においては、RIPSO、CIPSO、TSIX といったトラステッ

ドネットワークプロトコルを使うことはないであろう、また Trusted Solaris 独自

の TSOL プロトコルについても、ネットワークインストールやリモート管理のために

使う以外では使うことはないであろう。



Trusted Solaris 編


3.5. セキュリティポリシーの定義

Trusted Solaris 8 にてインターネットサーバーを構築する上でのガイドラインを示す。

以降の解説において想定しているシステムのイメージは以下の通りである。ここで採用

するネットワークに対するラベルの定義については、外部に公開されるインターネット

サービスをシステムのファイルやサービスから隔離するものである。さらに、外部からの

アクセスと内部からのアクセスを隔離する場合の例について 3.5.5.4 に紹介している。

小規模サイト

各種のサーバーが外部セグメントまたは DMZ セグメントに単体のサーバーとして設置

される場合。

中大規模サイト

各種のサーバーが外部セグメントまたは DMZ セグメントに要塞のサーバーとして設置

され、また内部のセグメントに内部利用のみの（外部から直接参照がされない）サーバー

が設置される場合。

(1) 基本方針

Trusted Solaris 上でシステムを構築する場合、セキュリティポリシーに基づいた、

役割、プロファイル、またラベル（label_encodings）を設計することになる。

インターネットサーバーの構築を行う場合には、特に、インターネットサービスの

セキュリティ属性の定義を行っている、boot プロファイルと inetd プロファイルの設

計は重要である。必要に応じてこれらのプロファイルへの追加または修正をすること

になる。また、ネットワークインターフェースに対する許可範囲の設定とホストやネッ

トワークに対するネットワークアクセスの制限の設定をするため、label_encodings

ファイルの設計も重要である。

なお、boot 時に起動させるサービスについては boot プロファイルに、inetd により

随時起動されるサービスについては inetd プロファイルに、それぞれに必要なプログ

ラムとそのセキュリティ属性を追加または修正をすることが可能であるが、ここで紹

介する構築のガイドラインでは、できる限り標準のプロファイルと区別するため個別

のプロファイルを新たに作成することとする。（ただし qmail および FTP については一

部に inetd により起動されるサービスがあるため inetd プロファイルを修正する。）

また、BIND、sendmail、FTP については、Trusted Solaris 8 に標準でインストール

されている BIND 8.2.2-P5、sendmail 8.10.2、FTP を利用することも可能であり、こ

れらについては必要な定義が既にされているが、ここでは最新のバージョンをインス

トールすることを考慮し、これらは使用しないこととする。



Trusted Solaris 編


(A) 役割とプロファイル

標準の役割から secadmin 役割、admin 役割、oper 役割を有効とする。admin 役割

は各サービスのメンテナンスも行うとものとし、各サービス用プロファイルを追加

する。コンテンツやデータベースのメンテナンスを行うものとして webadmin 役割と

mailadmin 役割を新たに設け、それぞれに必要な業務用のプロファイルを定義する。

また、一部のプログラムについてはコンパイルが必要となるため、構築時のみ

primaryadmin 役割を有効とする。

なお、役割とプロファイルについて、Web と FTP、DNS と SMTP、といった括りで

まとめているが、これは必要なことではない。言い換えると別々にすることは可能

である。通常、これらが連接または同一のサーバ上で構築される場合が多いと考え

られるため、簡易化のためにプロファイルを統合している。

表 3-48 役割

# 役割業務内容追加プロファイル

1 secadmin ファイルのセキュリティ属性の設定プロセスのセキュリティ属性の設定

標準

2 admin スクリプトの作成と編集、サービスの起動と停止パッケージの追加と削除、データのリストア

webservice mailservice

3 oper データのバックアッププリンタの制御

標準

4 primaryadmin プログラムの修正と開発（運用時には無効とする）標準

5 webadmin Web や FTP に関する定義およびコンテンツの管理 webcontrol

6 mailadmin DNS や SMTP に関する定義およびデータベースの管理 mailcontrol

表 3-49 プロファイル

# プロファイル修正内容・追加内容主要コマンド

1 boot 標準のサービス、Web サービス、Mail サービス、DNSサービスの無効化

標準

2 inetd FTP サービスのプログラムのセキュリティ属性を修正

標準

3 webservie Web サービスのプログラムのセキュリティ属性を定義

apatchicntl httpd

4 mailservice Mail と DNS サービスのプログラムのセキュリティ属性を定義

named sendmail

5 webcontrol Web および FTP のコンテンツと同位のラベルと、必要なコマンドを実行可能とする

6 mailcontrol SMTP および DNS のデータベースと同位にラベルと、必要なコマンドを実行可能とする



Trusted Solaris 編


表 3-50 webadmin 役割情報

Role Name webadmin

Full Name webadmin

Description contents administrator

Role ID Number 任意

Password 任意

Primay Group sysadmin

Home Direcgtory /export/contents

Automatically Mount Home Directory しない

Role Shell Administrative Shell

Profile webcontrol

Minimum Label PUBLIC

Clearance PRIVATE SERVICES

表 3-51 mailadmin 役割情報

Role Name mailadmin

Full Name mailadmin

Description mail administrator

Role ID Number 任意

Password 任意

Primay Group sysadmin

Home Direcgtory /export/home/mailadmin

Automatically Mount Home Directory しない

Role Shell Administrative Shell

Profile mailcontrol

Minimum Label PUBLIC

Clearance PRIVATE SERVICES

(B) ラベル

ネットワークインターフェースに対する許可範囲の設定とホストやネットワー

クに対するネットワークアクセスの制限の設定をするため、基本的となるセキュリ

ティを実現する基本的ラベル構成の label_encodings ファイルを定義する。

なお、ラベルの定義として、SMTP と DNS をまとめて、一つのコンパートメントと

している。これは、SMTP が IP アドレス解決に DNS に常に問い合わせを行うため、

これらが別々のコンパートメントであった場合には、SMTP のプロセスが MAC のアク

セス制御を無効にして DNS のプロセスへアクセスを行う必要があり、そのために特

権を付与しなければならなくなるためである。

なお、表 3-52 はここで解説するラベル定義の例である。また、リスト 3-21 は

これに対応するラベル構成を含む label_encodings ファイルの例である。



Trusted Solaris 編


表 3-52 ラベル構成

# ラベル種別主な割り当て対象設定値

1 ADMIN_LOW 格付けシステムのアプリケーションおよび定義ファイル

標準

2 ADMIN_HIGH 格付けシステムのログファイルや監査ファイル標準

3 PUBLIC 格付け外部向けのサービスおよび定義ファイル 50

4 services コンパートメントサービス全体を表す 51-80

基本的ラベル構成のネットワークでは、外部および内部からのアクセスを許可す

るサービスを提供するプロセスは、単一のラベルで実行されものとする。

なお、[PUBLIC SERVICES]ラベルを用いる利点として、サービスを提供するプロ

セスが利用されて、不正なコードが実行された場合、そのプロセスには[PUBLIC

SERVICES]ラベルが付けられているため、[ADMIN_LOW]ラベルがに付けられた実行可

能プログラムや定義ファイルなどを改竄することができない。また[PUBLIC]を含む

他の異なるコンパートメントのサービスに対するアクセスが許可されないため、他

の標準のサービスに影響を与えることができない。などが挙げられる。

ADMIN_LOW

PUBLIC

ADMIN_HIGH

優位度

低

高

services

図 3-26 基本的ラベル空間

なお、対象となるすべてのインターネットサービスについてこのラベル構成にお

ける設定を行う。

(2) インターネットサーバー構築上の要領

Trusted Solaris においてインターネットサーバーを構築する要領を示す。

インタネットサービスに関する構築のガイドラインにおいて、実施する作業項目は



Trusted Solaris 編


以下の通りである。

(1)インストール

通常の Solaris 8 と同様のインストレーションを実施する。プロファイルが解釈される起動スクリプトの定義を実施する。

(2)ファイル定義ファイルおよび実行可能ファイルの場所を確認する。特権デバッグを実施する。（本書では予め実施しているため省略している）

(3)セキュリティポリシーの定義と設定 (A)ファイル属性定義ラベル、強制特権、許容特権、など (B)プロセス属性定義 User/Group、ラベル、継承可能特権、など (C)ネットワーク属性定義ネットワークアクセスに対する許可範囲、など

(A) 構築時の特権シェル

Solaris に対応したパッケージのインストールについては、通常と同様に、pkgadd、

pkgrm、pkginfo などのコマンドにより管理が可能である。またこの作業に必要なコ

マンドや実行権は Software Installation プロファイルに定義されており、標準で

は admin 役割が行うことが可能となっている。

しかし、make や gcc などコンパイルが必要となるアプリケーションの場合には、

あらかじめ定義されている Software Installation プロファイルでは十分でない場

合がある。実際に、事前の設定無しに、作業のすべてを admin 役割で遂行するのは

困難であった。必要なコマンドと実行権をプロファイルに追加定義し、make や gcc

を含むすべてのインストレーション作業について、admin 役割が行うことを可能に

することは理論的に可能であるが、それでは事前に調査する作業が必要以上に発生

してしまう。

特に、root によるインストールを前提に作成されている多くのアプリケーション

のインストールにおいては、スーパーユーザ権限があれば便利である。Privileged

Shells プロファイルはこれを可能にする、緊急用の特別なプロファイルである。標

準では primaryadmin 役割がこのプロファイルを利用可能となっている。

構築のガイドラインにおいても、インストール作業の一部を primaryadmin 役割

により特権シェルの環境において行っている。しかしながら、当然、運用時には、

このプロファイルが不正に利用されてしまうことがないようにすることが重要であ

る。



Trusted Solaris 編


① primaryadmin 役割を許可されたユーザがログインする ② primaryadmin 役割のセッションを開始する ③ ターミナルからシェルを起動する（リスト 3-37）

リスト 3-37 Privileged Shell（primaryadmin 役割）

$ ppriv 1234: none $ sh # ppriv 5678: all

(B) ファイルアクセス特権

Trusted Solaris の特権には、ファイルへのアクセスの制御（DAC と MAC）を無効

にする特権が用意されている。file_dac_write 特権は DAC のアクセス制御に関わら

ないファイルへの書き込みを許可する特権である。また file_mac_write 特権は MAC

のアクセス制御に関わらないファイルへの書き込みを許可する特権である。

file_dac_write 特権について、アプリケーションが PID ファイルを書き込む際や

ログファイルを書き込む際に必要となる場合がある。これは、アプリケーションが

スーパーユーザ権限で動作することを前提としていているため、Solaris 上では問

題は発生しないが、Trusted Solaris では DAC の制限（uid=0 が特別な意味を持たな

いため）により PID ファイルの書き込みやログファイルの書きが許可されないため、

file_dac_write 特権を必要としていることが考えられる。このような場合には、PID

ファイルが書き込まれるディレクトリや、ログファイルが書き込まれるディレクト

リとファイルについて、パーミッションや所有者を変更することで正常に動作させ

ることが可能となることがある。

また、file_mac_write 特権について、この特権はアプリケーションが[ADMIN_LOW]

以外のラベルで動作している場合に、アプリケーションが[ADMIN_LOW]のディレクト

リへの PID ファイルを書き込む場合や[ADMIN_LOW]のディレクトリとファイルにロ

グファイルを書き込む際に必要となる場合がある。このような場合には、PID ファ

イルが書き込まれるディレクトリや、ログファイルが書き込まれるディレクトリや

ファイルについて、ラベルを変更するかまたはマルチレベルディレクトリにするこ

とで正常に動作させることが可能となるがある。

これらの特権はファイルへの書き込みを許可するため、これらが与えられたプロ



Trusted Solaris 編


セスが不正に利用された場合には、ユーザのデータ（インターネットサーバーのコ

ンテンツなど）や設定ファイル（セキュリティポリシーのファイルなど）が改竄さ

れてしまう恐れがある。何れにせよ、これらの特権を与えないことに越したことは

ない。これらの特権を与える前に別の方法での解決策を検討することは重要である。

また、仮に特権を与えることが必要であった場合は、極力その特権が継承しないよ

う影響範囲を最小限に留めるための検討をすることは重要である。

なお、実行可能ファイルに設定される許容特権セットと強制特権セットにより有

効にされた特権は、fork(2)システムコールではそのままコピーされるが、exec(2)

システムコールでは継承されない。特権を継承しないようにする方法としてこの方

法を用いることも有効である。

3.5.1. Web サーバー

3.5.1.1. Apache

Apache については、2002 年 12 月において、http://www.apache.org から入手が可能な

1.3 系と 2.0 系の Apache 1.3.27 と Apache 2.0.43 があり、ここでは、Apache 1.3.27 につ

いての実装と検証を行った。

(1) インストール

ここでは、通常の Solaris におけるインストレーションと同様の手順によるインス

トールを行う。

最初に必要なパッケージの追加やソースの展開を行う（リスト 3-38）。この作業は

admin役割に移行し役割のワークスペースにて行うことが可能である。このときデフォ

ルトのラベルは[ADMIN_LOW]となる。

リスト 3-38 パッケージの追加（admin 役割）

$ cd /usr/local $ gzcat apache_1.3.27.tar.gz | tar xvf -

次の作業は primaryadmin 役割に移行し、特権シェル環境において実行する。

ここでは、httpd の実行ユーザ www およびグループ www を作成する（リスト 3-39）。

なお、簡易に構築するため作業を特権シェル環境により行うが、ユーザとグループの

追加は admin 役割にて SMC を利用することでも可能である。



Trusted Solaris 編


リスト 3-39 ユーザとグループの追加（primaryadmin 役割）

# groupadd -g 80 www # useradd -u 80 -g www -d / -s /bin/false www

次の作業も引き続き特権シェル環境にて行う。

ここでは、Apache 1.3.27 のコンパイルとインストールを行う（リスト 3-40）。

なお、suEXEC を利用するため suexec 関連のオプションを有効にする。

リスト 3-40 コンパイルおよびインストール（primaryadmin 役割）

# PATH=/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/local/bin # export PATH # cd /usr/local/apache_1.3.27 # ./configure --enable-suexec --suexec-caller=www --suexec-uidmin=80 --suexec-gidmin=80 --suexec-docroot=/export # make # make install

次に Apache の基本設定を行う。この作業は admin 役割により行う。

ここでは、コンテンツと CGI スクリプトを置くディレクトリを作成する。また、

webadmin 役割による編集が可能となるように、ディレクトリの所有者を webadmin に

変更する（リスト 3-41）。

リスト 3-41 コンテンツディレクトリの作成（admin 役割）

$ mkdir /export/contents /export/cgi-bin $ chown webadmin /export/contents /export/cgi-bin

ここでは、httpd.conf の編集を行う。admin 役割による編集が可能となるように、

所有者を admin に変更する（リスト 3-42）。

なお、Apache の標準機能であるバーチャルホストを有効にする。理由は、suEXEC

は httpd.conf における<Virtual>で設定されたディレクトリ以下とユーザのディレク

トリ以下で有効になるため、利用するドメインは一つだがバーチャルホストとして動

作させるためである。



Trusted Solaris 編


リスト 3-42 httpd.conf の編集（admin 役割）

$ cd /usr/local/apache/conf $ cp -p httpd.conf httpd.conf.org $ chown admin httpd.conf

リスト 3-43 httpd.conf：基本部分

PidFile /var/run/httpd.pid User www Group www ServerAdmin [email protected] ServerName gpan.tscorp.com DocumentRoot "/export/contents" ... (省略) ... <Directory "/export/contents"> ... (省略) ... <Directory "/export/cgi-bin"> ... (省略) ... ScriptAlias /cgi-bin/ "/export/cgi-bin/"

リスト 3-44 httpd.conf：追加部分

NameVirtualHost 192.168.0.103 <VirtualHost gpan> ServerName gpan.tscprp.com User webadmin Group sysadmin DocumentROot /export/contents ScriptAlias /cgi-bin/ "/export/cgi-bin/" </VirtualHost>

最後に Apache の起動スクリプトの編集を行う。この作業も引き続き admin 役割によ

り行う。

標準でインストールされているApache 1.3.12の起動スクリプトを用いることとし、

これを編集する。admin 役割による編集が可能となるように、所有者を admin に変更

する（リスト 3-45）。

インタープリターをシステムシェル（sysh）に変更し、以降のセキュリティ属性定

義において設定する webservice プロファイルがサービス起動時に有効となるように、

setprof コマンドによる定義を追加する。また、Apache の起動用の環境変数を編集す

る。



Trusted Solaris 編


リスト 3-45 apache スクリプトの編集（admin 役割）

$ cd /etc/init.d $ cp -p apache apache.org $ chown admin apache

リスト 3-46 apache スクリプト：インタープリター

#!/sbin/sysh setprof webservice

リスト 3-47 apache スクリプト：環境変数

APACHE_HOME=/usr/local/apache CONF_FILE=/usr/local/apache/conf/httpd.conf

(2) ファイル

通常の Solaris 8 において適用されるセキュリティ属性、つまりファイルパーミッ

ション、所有者、所属グループについては、特別な理由がない限り変更する必要はな

い。



Trusted Solaris 編


表 3-53 ファイル

# ファイル名パーミッション owner group

1 /usr/local/apache/conf/*

2 /usr/local/apache/logs/*

3 /usr/local/apache/htdocs/*

4 /usr/local/apache/icons/*

5 /usr/local/apache/cgi-bin/*

6 /usr/local/apache/include/*

7 /usr/local/apache/libexec/*

8 /usr/local/apache/man/*

9 /usr/local/apache/proxy/*

10 /usr/local/apache/bin/ab -rwxr-xr-x root root

11 /usr/local/apache/bin/apachectl -rwxr-xr-x root root

12 /usr/local/apache/bin/apxs -rwxr-xr-x root root

13 /usr/local/apache/bin/checkgid -rwxr-xr-x root root

14 /usr/local/apache/bin/dbmmanage -rwxr-xr-x root root

15 /usr/local/apache/bin/htdigest -rwxr-xr-x root root

16 /usr/local/apache/bin/htpasswd -rwxr-xr-x root root

17 /usr/local/apache/bin/httpd -rwxr-xr-x root root

18 /usr/local/apache/bin/logresolve -rwxr-xr-x root root

19 /usr/local/apache/bin/rotatelogs -rwxr-xr-x root root

20 /usr/local/apache/bin/suexec -rws--x--x root root

(3) セキュリティポリシーの定義と設定（基本的ラベル構成のネットワーク）

最初に、基本的ラベル構成のネットワークを想定した、基本的なセキュリティポリ

シーの定義と設定を行う。

この構成では、外部および内部のネットワークともに単一のラベルでのサービスに

対するアクセスが許可される。この場合、サービスに与える特権を少なくする最良の

方法は、サービスを形成する全てのプロセスが同一のラベルで動作するようにするこ

とである。

この作業は secadmin 役割に移行し役割のワークスペースにて行うことが可能であ

る。このときデフォルトのラベルは[ADMIN_LOW]となる。



Trusted Solaris 編


ADMIN_LOW

PUBLIC

ADMIN_HIGH

services

Log,conf contents

suexec httpd

全ての

ネットワークアクセス

に対する許可範囲

図 3-27 シンプルな場合のイメージ図

httpd プロセスの SL は[PUBLIC SERVICES]とし、CGI プロセスの SL も[PUBLIC

SERVICES]とする。CGI の実行環境として Apache の suEXEC を利用する。

ネットワークからのアクセスは全てが[PUBLIC SERVICE]とラベル付けされる。

コンテンツファイルおよびスクリプトファイルの SLは[ADMIN_LOW]とし、ネッ

トワークアクセスに関連するプロセス（httpd および派生するプロセス）から

読み込みのみが許可される。

(A) ファイル属性定義

次のサービス提供に関わるファイル属性をそれぞれのファイルに適用する。なお、

設定の手順については 3.4.4.1(1)(A)に記載している。

表 3-54 ファイル属性

# ファイル名ラベル強制特権許容特権

1 /usr/local/apache/bin/httpd ADMIN_LOW file_dac_write file_mac_write

all



Trusted Solaris 編


Note: 標準のインストレーションでは、httpd に対して file_dac_write 特権および file_mac_write特権ともに必要となるが、これは httpd がログの出力に必要としている特権である。よって、ログディレクトリの所有者を変更することにより、file_dac_write 特権は不要となる。また、ログディレクトリのラベルを変更することにより、file_mac_write 特権は不要となる。 secadmin 役割にて以下の設定を行うことで特権を扶養とすることが可能である。 $ chown www /usr/local/apache/logs $ setlabel “public services” /usr/local/apache/logs

(B) プロセス属性定義

次のサービス提供に関わる実行属性をサービス用の webservice プロファイルに

追加する。なお、設定の手順については 3.4.3.4(2)(A)に記載している。

表 3-55 プロセス属性

# コマンド User Group Label Clearance 特権

1 /usr/local/apache/ bin/apachectl

www www PUBLIC services

PUBLIC services

net_privaddr

(C) ネットワーク属性定義

次のネットワークに関わるセキュリティ属性を適用する。なお、設定手順につい

てはそれぞれに、3.4.7.1(2)(A)、3.4.7.2(2)(A)、3.4.7.3(2)(A)に記載している。

表 3-56 インターフェース属性

# Interface Mini Label Max Label Label Clearance

1 hme0 PUBLIC PRIVATE services

PUBLIC services

PUBLIC services

表 3-57 テンプレート属性

# Template Mini Label Max Label Label Clearance

1 public_services PUBLIC services

PUBLIC services

PUBLIC services

PUBLIC services

表 3-58 ネットワーク属性

# Host/Wildcard Hostname IP Address Prefix Length Template

1 Wildcard N/A 0.0.0.0 N/A public_services



Trusted Solaris 編


3.5.2. DNS サーバー

ここでは、DNS サーバーとして以下のパッケージに関する定義と設定の例を示す。

BIND-9

djdns

3.5.2.1. BIND-9

BIND-9 については、2002 年 12 月において、http://www.isc.org/products/BIND から入

手が可能な BIND 9.2.2rc1 について実装と検証を行った。

BIND-9 に付随して、OpenSSL の入手が必要となるため、同様に Sun Site23からの入手が

可能である、OpenSSL 0.9.6g を利用した。


ここでは、通常の Solaris におけるインスとレーションと同様の手順によるインス


最初に必要なパッケージの追加やソースの展開を行う（リスト 3-48）、この作業は




$ cd /usr/local $ pkgadd -d openssl-0.9.6g-sol8-sparc-local $ gzcat bind-9.2.2rc1.tar.gz | tar xvf -


ここでは、ユーザ bind およびグループ bind を作成する（リスト 3-49）。なお、簡

易に構築するため作業を特権シェル環境により行うが、ユーザとグループの追加は

admin 役割にて SMC を利用することでも可能である。

23 Sun Site http://www.sunsite.tus.ac.jp



Trusted Solaris 編



# groupadd -g 24 bind # useradd -u 24 -g 24 -d / -s /bin/false bind

次の作用も引き続き特権シェル環境にて行う。

ここでは、BIND 9.2.2rc2 のコンパイルに必要となるライブラリのランタイム・リ

ンキング環境を設定する（リスト 3-50）。

リスト 3-50 ランタイム・リンキング環境設定（primaryadmin 役割）

# crle -u -l /usr/local/ssl/lib # crle Configuration file [2]: /var/ld/ld.config Default Library Path (ELF): /usr/lib:/usr/local/lib:/usr/local/ssl/lib Trusted Directories (ELF): /usr/lib/secure Command line: crle -c /var/ld/ld.config -l /usr/lib:/usr/local/lib:/usr/local/ssl/lib -s /usr/lib/secure


ここでは、BIND 9.2.24c2 のコンパイルとインストールを行う（リスト 3-51）。

なお、SSL を有効にするにするためのオプションを指定する。

リスト 3-51 bind の Build（primaryadmin 役割）

# PATH=/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/local/bin # export PATH # cd /usr/local/bind-9.2.2rc1 # ./configure --with-openssl=/usr/local/ssl # make # make install

次に BIND の基本設定を行う。この作業も引き続き特権シェル環境にて行う。

なお、ここでは簡易に構築するため作業を特権シェル環境により行うが、運用時に

はこれらの作業が mailadmin 役割により可能となるようにする。

ここでは、named.conf ファイルと zone ファイルなどを置くディレクトリを作成す

る（リスト 3-52）。



Trusted Solaris 編


リスト 3-52 設定ファイル用ディレクトリの作成（primaryadmin 役割）

# mkdir /etc/named # chown mailadmin /etc/named

ここでは、named.conf ファイルおよび zone ファイルを作成し編集を行う。また、

mailadmin 役割による編集が可能となるように、ファイルの所有者を mailadmin に変

更する（リスト 3-53）。なお、zone ファイルの具体例については省略する。

リスト 3-53 named.conf の作成と編集（primaryadmin 役割）

# cd /etc/named # touch named.conf # chown mailadmin named.conf # chmod 644 named.conf

リスト 3-54 named.conf

options { directory "/etc/named"; forwarders { 200.200.0.1; 200.200.0.2; }; }; zone "." { type hint; file "tscorp.cache"; }; zone "tscorp.com" { type master; file "tscorp.zone"; }; zone "0.0.127.in-addr.arpa" { type master; file "localhost.zone"; }; zone "0.168.192.in-addr.arpa" { type master; file "192.168.0.rev"; };

最後に BIND の起動スクリプトの編集を行う。この作業は admin 役割により行う。

標準でインストールされている sendmail の起動スクリプトに BIND の起動スクリプ



Trusted Solaris 編


トを追加することとし、これを編集する。admin 役割による編集が可能となるように、

所有者を admin 役割に変更する（リスト 3-55）。

インタープリターがシステムシェル（sysh）となっていることを確認し、以降のセ

キュリティ属性定義において設定する mailservice プロファイルがサービス起動時に

有効となるように、setprof コマンドによる定義を追加する。また BIND の起動用のス

クリプトを編集する。なお、BIND は sendmail よりも前に起動しなければならない。

リスト 3-55 sendmail スクリプトの編集（admin 役割）

$ cd /etc/init.d $ cp -p sendmail sendmail.org $ chown admin sendmail

リスト 3-56 sendmail スクリプト：インタープリター

#!/bin/sysh setprof mailserice

リスト 3-57 sendmail スクリプト：named 起動スクリプト

if [ -f /usr/local/sbin/named -a -f /etc/named/named.conf ]; then echo 'starting internet domain name server.' /usr/local/sbin/named -c /etc/named/named.conf & fi

(2) ファイル



い。



Trusted Solaris 編




1 /etc/named/*

2 /usr/local/doc/*

3 /usr/local/include/*

4 /usr/local/lib/*

5 /usr/local/man/*

6 /usr/local/bin/dig -rwxr-xr-x bin bin

7 /usr/local/bin/host -rwxr-xr-x bin bin

8 /usr/local/bin/isc-config.sh -rwxr-xr-x bin bin

9 /usr/local/bin/nslookup -rwxr-xr-x bin bin

10 /usr/local/bin/nsupdate -rwxr-xr-x bin bin

11 /usr/local/sbin/dnssec-keygen -rwxr-xr-x bin bin

12 /usr/local/sbin/dnssec-makekeyset -rwxr-xr-x bin bin

13 /usr/local/sbin/dnssec-signkey -rwxr-xr-x bin bin

14 /usr/local/sbin/dnssec-signzone -rwxr-xr-x bin bin

15 /usr/local/sbin/lwresd -rwxr-xr-x bin bin

16 /usr/local/sbin/named -rwxr-xr-x bin bin

17 /usr/local/sbin/named-checkconf -rwxr-xr-x bin bin

18 /usr/local/sbin/named-checkzone -rwxr-xr-x bin bin

19 /usr/local/sbin/rndc -rwxr-xr-x bin bin

20 /usr/local/sbin/rndc-confgen -rwxr-xr-x bin bin







とである。





Trusted Solaris 編


ADMIN_LOW

PUBLIC

ADMIN_HIGH

services

named.conf etc.

syslog etc.

named

全ての



リスト 3-58 基本的ラベル構成によるサービスのイメージ

named プロセスの SL は[PUBLIC SERVICES]とする。


named.conf および zone ファイルの SL は[ADMIN_LOW]とし、ネットワークアク

セスに関連するプロセス（named および派生するプロセス）から読み込みのみ

が許可される。




表 3-60 サービス用ファイル属性


1 /usr/local/sbin/named ADMIN_LOW none all

2 /usr/local/sbin/lwresd ADMIN_LOW none all

次の管理に関わるファイルの属性をそれぞれのファイルに適用する。なお、実際

には初期設定から変更の必要はない。ただし、DNSSEC の設定および検証は行ってい

ない。



Trusted Solaris 編


表 3-61 管理用ファイル属性


1 /usr/local/bin/dig ADMIN_LOW none none

2 /usr/local/bin/host ADMIN_LOW none none

3 /usr/local/bin/isc-config.sh ADMIN_LOW none none

4 /usr/local/bin/nslookup ADMIN_LOW none none

5 /usr/local/bin/nsupdate ADMIN_LOW none none

6 /usr/local/sbin/dnssec-keygen ADMIN_LOW none none

7 /usr/local/sbin/dnssec-makekeyset ADMIN_LOW none none

8 /usr/local/sbin/dnssec-signkey ADMIN_LOW none none

9 /usr/local/sbin/dnssec-signzone ADMIN_LOW none none

10 /usr/local/sbin/named-checkconf ADMIN_LOW none none

11 /usr/local/sbin/named-checkzone ADMIN_LOW none none

12 /usr/local/sbin/rndc ADMIN_LOW none none

13 /usr/local/sbin/rndc-confgen ADMIN_LOW none none


次のサービス提供に関わる実行属性をサービス用のmailserviceプロファイルに


表 3-62 サービス用プロセス属性

# ファイル名 User Group Label Clearance 特権

1 /etc/init.d/ sendmail

root (euid)

sys (egid)

N/A N/A all

2 /usr/local/sbin/ named

root (uid)

N/A PUBLIC services

PUBLIC services

file_mac_read net_privaddr sys_net_config sys_suser_compat

3 /usr/local/sbin/ lwresd

root (uid)

N/A PUBLIC services

PUBLIC services

file_mac_read net_privaddr sys_net_config sys_suser_compat






Trusted Solaris 編





PUBLIC services

PUBLIC services




PUBLIC services

PUBLIC services

PUBLIC services




3.5.2.2. djbdns

djbdns については、2002 年 12 月において、http://cr.yp.to/djbdns.html から入手が可

能な djbdns-1.05 について実装と検証を行った。

djbdns をインストールするにあたってデーモンの監視およびログの管理を行う

daemontools も併せてインストールするため、http://cr.yp.to/daemontools.html から入

手が可能な daemontools-0.76 について実装と検証を行った。

なお、以下のサービス関するセキュリティ属性の設定が必要になる。これらについては、

基本的なサービスのセキュリティ定義の設定後に行う。

tinydns - 管理する zone の名前解決を行う。

dnscache - 外部の zone の名前解決を行う。

axfrdns - スレーブサーバーへ対してゾーン転送を行う。

ここで、インストールした djbdns および daemontools のディレクトリ構成を表 3-66 に

示す。



Trusted Solaris 編


表 3-66 ディレクトリの構成

# ファイルパス内容

1 /usr/local/admin/daemontools-0.76/command daemontolls のプログラムファイル

2 /command daemontools へのシンボリックリンク

3 /service svscan プログラムの監視対象ディレクトリ

4 /usr/local/djbdns/bin djbdns 関連の実行プログラムのインストール先ディレクトリ

5 /var/dnscache ローカルキャッシュサーバー用管理ディレクトリ

6 /var/dnscachex 外部キャッシュサーバー用管理ディレクトリ

7 /var/tinydns ゾーン DNS サーバー用管理ディレクトリ

8 /var/axfrdns ゾーン転送用管理ディレクトリ


ここでは、通常の Solaris におけるインストレーションと同様の手順によるインス


最初に必要なパッケージの追加やソースの展開を行う、この作業は admin 役割に移

行し役割のワークスペースにて行うことが可能である。このときデフォルトのラベル

は[ADMIN_LOW]となる。

リスト 3-59 ソースの展開（admin 役割）

$ cd /usr/local $ gzcat daemontools-0.76.tar.gz | tar xvf - $ gzcat djbdns-1.05.tar.gz | tar xvf -

(A) ユーザおよびグループの追加

次に djbdns のそれぞれのデーモン、dnscache、tinydns および axfrdns を実行す

るユーザ dnscache、tinydns、axfrdns とログを管理するユーザ djblog を作成する。

なお、簡易に構築するため作業を特権シェル環境により行うが、ユーザとグルー

プの追加は admin 役割にて SMC を利用することでも可能である。



Trusted Solaris 編



# groupadd djbdns # useradd -s /bin/false -d /usr/local/djbdns ‐g djbdns dnscache # useradd -s /bin/false -d /usr/local/djbdns ‐g djbdns tinydns # useradd -s /bin/false -d /usr/local/djbdns ‐g djbdns axfrdns # useradd -s /bin/false -d /usr/local/djbdns ‐g djbdns djblog

(B) daemontools のインストール

daemontools のインストール作業については、特権シェル環境において実行する。

リスト 3-61 daemontools のインストール（primaryadmin 役割）

# PATH=/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/local/bin # export PATH # cd /usr/local/admin/daemontools-0.76 # package/install

deamontools をインストールすると、デフォルトでは inittab に以下の行が追加

され init 経由で起動する。しかし、ここでは rc スクリプトとして起動し djbdns

を監視することとする。よって/etc/inittab に追加された以下の行を削除する必要

がある。

リスト 3-62 /etc/inittab の削除項目

SV:123456:respawn:/command/svscanboot

(C) djbdns のインストール

djbdns のインストール作業については、特権シェル環境において実行する。

なお、デフォルトでは djbdns のバイナリは/usr/local 以下にインストールされる

が、ここではインストール先を/usr/local/djbdns に変更するため conf-home ファイ

ルを変更する



Trusted Solaris 編


リスト 3-63 conf-home

/usr/local/djbdns

リスト 3-64 djbdns のインストール（primaryadmin 役割）

# PATH=/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/local/bin # export PATH # cd /usr/local/djbdns-1.05 # make # make setup check


基本的ラベル構成のネットワークを想定した、基本的なセキュリティポリシーの定

義と設定を行う。




とである。



ADMIN_LOW

PUBLIC

ADMIN_HIGH

services

/var/djbnds/* etc.

tinydns 全ての



dnscache

axfrdns supervice

log

図 3-28 基本的ラベル構成によるサービスのイメージ

djbdns の各デーモンの SL は[PUBLIC SERVICES]とする。




Trusted Solaris 編


設定ファイルおよびゾーンファイルの SL は[ADMIN LOW]とし、ネットワーク

アクセスに関連するプロセス（djbdns のデーモンおよび派生するプロセス）

から読み込みのみが許可される。

ただし、最小特権を考慮し、ログディレクトリは[PUBLIC SERVICES]に変更す

る。


サービス提供および管理に関わる実行可能ファイルについて、「強制特特権を無

し」、「許容特権を全て」とする属性を適用する。なお、設定の手順については

3.4.4.1(1)(A)に記載している。

リスト 3-65 許容特権の設定

$ setfpriv -s -a all /command/* $ find /usr/local/djbdns -type f -exec setfpriv -s -a all {} ¥;




表 3-67 サービス用プロセス属性値

# ファイル名 user group label clearance 特権

1 /usr/local/admin/ daemontools-0.76/ command/svscanboot

root (uid)

N/A public services

N/A net_privaddr proc_chroot proc_owner proc_setid

2 /usr/local/admin/ daemontools-0.76/ command/unvuidgid

N/A N/A public services

N/A net_privaddr proc_chroot proc_setid

次の管理に関わる実行属性を管理用の mailcontrol プロファイルに追加する。



Trusted Solaris 編


表 3-68 管理用プロセス属性


1 /usr/local/admin/ daemontools-0.76/ command/svstat

root (uid)

N/A public services

N/A net_privaddr proc_chroot proc_owner proc_setid

2 /usr/local/admin/ daemontools-0.76/ command/svc

N/A N/A public services

N/A net_privaddr proc_chroot proc_setid

3 /usr/ccs/bin/make root (uid)

sys (gid)

N/A N/A N/A

4 /usr/local/djbdns/ bin/tinydns-conf

root (uid)

sys (gid)

N/A N/A file_chown file_setdac

5 /usr/local/djbdns/ bin/dnscache-conf

root (uid)

sys (gid)


6 /usr/local/djbdns/ bin/axfrdns-conf

root (uid)

sys (gid)


8 /var/djbdns/tinydns/ root/add-alias

root (uid)

sys (gid)

N/A N/A N/A

9 /var/djbdns/tinydns/ root/add-childns

root (uid)

sys (gid)

N/A N/A N/A

10

/var/djbdns/tinydns/ root/add-host

root (uid)

sys (gid)

N/A N/A N/A

11

/var/djbdns/tinydns/ root/add-ns

root (uid)

sys (gid)

N/A N/A N/A

12

/var/djbdns/dnscache /root/add-alias

root (uid)

sys (gid)

N/A N/A N/A

13

/var/djbdns/dnscache/root/add-childns

root (uid)

sys (gid)

N/A N/A N/A

14

/var/djbdns/dnscache/root/add-host

root (uid)

sys (gid)

N/A N/A N/A

15

/var/djbdns/dnscache /root/add-ns

root (uid)

sys (gid)

N/A N/A N/A

16

/var/djbdns/axfrdns/ root/add-alias

root (uid)

sys (gid)

N/A N/A N/A

17

/var/djbdns/axfrdns/ root/add-childns

root (uid)

sys (gid)

N/A N/A N/A

18

/var/djbdns/axfrdns/ root/add-host

root (uid)

sys (gid)

N/A N/A N/A

19

/var/djbdns/axfrdns/ root/add-ns

root (uid)

sys (gid)

N/A N/A N/A






Trusted Solaris 編





PUBLIC services

PUBLIC services




PUBLIC services

PUBLIC services

PUBLIC services




(3) tinydns の設定

管理ゾーンの名前解決を行う tinydns の設定を行う。

(A) エントリの追加

設定ファイルおよび名前情報の保存先を/var/djbdns/tinydns とし、エントリを

追加する。この作業は、mailcontrol プロファイルが割り当てられた役割 mailadmin

によって行う。なお、djbdns の詳細な設定方法については割愛する。以下は必要最

低限の設定例である。

リスト 3-66 tinydns の設定

$ cd /usr/local/djbdns/bin $./tinydns-conf tinydns djblog /var/djbdns/tinydns <ホストの IP アドレス> $ cd /var/djbdns/tinydns $ cd root $ ./add-ns venus.tsol.com 129.158.38.250 $ ./add-ns 38.158.129.in-addr.apra 129.158.38.250 $ ./add-host venus.tsol.com 129.158.38.250 $ make



Trusted Solaris 編


(B) daemontools への登録

djbdns のそれぞれのプロセスは、daemontools を利用してプロセスの起動・停止

を行なっているため、daemontool のみに継承可能特権を付与すれば djbdns は起動

する。しかし、ここでは、詳細については説明しないがマルチラベルの対応を考慮

しておく。もし、daemontools の継承可能特権を利用して SL[PUBLIC SERVICES]で起

動した場合、djbdns のプロセスは[PUBLIC SERVICES]で起動する。今回の設定では、

すべてのプロセスは[PUBLIC SERVICES]で起動するため、これで特に問題ないが、そ

れぞれのプロセスを[PUBLIC SERVICES]以外で起動することはできない。そこで、

djbdns の起動スクリプトである run ファイルを編集する。tinydns における起動ス

クリプトは以下のようになっている。

リスト 3-67 tinydns の起動スクリプト

#!/bin/sh exec 2>&1 exec envuidgid tinydns envdir ./env softlimit ‐d300000 /usr/local/djbdns/bin/tinydns

デフォルトでは、/bin/sh を利用したスクリプトである。これを/bin/sh からシ

ステムシェルである/sbin/sysh に変更する。変更後は以下のスクリプトのようにな

る。

リスト 3-68 システムシェルへの変更

#!/sbin/sysh setprof mailservice exec 2>&1 exec envuidgid tinydns envdir ./env softlimit ‐d300000 /usr/local/djbdns/bin/tinydns

みてもわかると思うがシステムシェルにsetprofでプロファイルを指定している。

これによってこのスクリプトを実行する際は mailservice プロファイルの特権およ

びユーザ情報を参照することになる。なお、設定の手順については 3.4.3.4(2)(A)

に記載している。なお、設定の手順については 3.4.3.4(2)(A)に記載している。

表 3-67 のサービス用プロファイルで指定したように、このファイルで利用する

envuidgid を設定している。設定をこのプロセスのみにしている理由はこのスクリ

プトが exec を利用しているためである。この設定が完了すると deamontools の

/services ディレクトリにリンクを作成する。この作業は、primaryadmin によって

おこなう。



Trusted Solaris 編


リスト 3-69 supervice への登録

# ln -s /var/djbdns/tinydns /services

(C) セキュリティ属性の変更

今までの全作業は、SL[ADMIN_LOW]でおこなってきた。しかし、動作させるプロ

セスの SL は[PUBLIC SERVICES]である。そのため、このまま動作させるには、特権

file_mac_write が必要になる。しかし、ディレクトリおよびファイルの SL を変更

することで、これらの特権を排除することができる。変更するディレクトリは、

/var/djbdns/tinydns 以下であるが、daemontools を一度起動すると作成されるため、

デフォルトでは存在しない。そこで、一度サービスプロセスの svscanboot の label

を[PUBLIC SERVICES]から[ADMIN LOW]に変更する。これによって、tinydns が

[ADMIN_LOW]で起動する。プロセスの起動は、mailservice を割り当てられた役割

admin で行う。

リスト 3-70 svscanboot の起動

$ /command/svscanboot

実行したら、すぐに停止して構わない。停止して/var/djbdns/tinydns 以下を確

認してみると以下のディレクトリが作成されていることがわかる。

リスト 3-71 supervice ディレクトリのリスト

/var/djbdns/tinydns/supervice/* /var/djbdns/tinydns/log/main/* /var/djbdns/tinydns/log/supervise/*

これらのディレクトリおよびこの中に含まれるファイルの SL を[PUBLIC

SERVICES]に変更する。作業は、secadmin によって以下のようにおこなう。



Trusted Solaris 編


リスト 3-72 機密ラベルの設定

$ setlabel -s “public services” /var/djbdns/tinydns/supervice ¥ > /var/djbdns/tinydns/supervice/* $ setlabel -s “public services” /var/djbdns/tinydns/log/main ¥ > /var/djbdns/tinydns/log/main/* $ setlabel -s “public services” /var/djbdns/tinydns/log/supervise ¥ /var/djbdns/tinydns/log/supervise/*

その後、再度サービスプロセスの svscanboot の labelを[ADMIN_LOW]から[PUBLIC

SERVICES]に変更する。

(4) dnscache の設定

管理ゾーンにおいて名前解決ができなかった場合の上位サーバーに問い合わせるた

めの dnscache を設定する方法を説明する。


名前情報の保存先を/var/djbdns/dnscache とし、エントリを追加する。ここでの

エントリとは上位 DNS の IP アドレスである。設定方法は、tinydns と大きく違いは

ない。まずは、mailcontrol プロファイルが割り当てられた mailadmin によって

dnscache の設定をおこなう。

リスト 3-73 dnscache の設定

$ cd /usr/local/djbdns/bin $ ./tinydns-conf dnscache djblog /var/djbdns/dnscache <ホストの IP アドレス> $ cd /var/djbdns $ cd dnscache/root/servers $ mv ¥@ ¥@.org $ echo [上位 DNS IP アドレス] > @ $ cd ../ip $ touch [ネットワークアドレス]

(B) supervice への登録

tinydns 同様、/var/djbdns/dnscahe/run スクリプトを変更して supervice に登

録する。作業は primaryadmin によって行う。スクリプトの変更点および設定方法は

以下のとおりである。



Trusted Solaris 編



#!/sbin/sysh setprof mailservice


# ln -s /var/djbdns/dnscache /services


dnscache も、いくつかのディレクトリとファイルの SL を変更する必要がある。

変更方法は、tinydns 同様サービスプロセスのプロファイルに含まれる svscanboot

の label を[PUBLIC SERVICES]から[ADMIN_LOW]に変更してからディレクトリを作成

し、その後 SL の変更をおこなった方が簡単である。

Note:

/services/tinydns が存在し起動している場合、svscanboot のプロファイルを変更する

とファイルへのアクセス権の問題で一時的に tinydns が起動しなくなる。tinydns のサー

ビスを提供している場合には注意が必要である。

svscanboot を[ADMIN_LOW]で起動後、変更するディレクトリおよびファイルは以

下のとおりである。


$ setlabel -s “public services” /var/djbdns/dnscache/supervice ¥ > /var/djbdns/dnscache/supervice/* $ setlabel -s “public services” /var/djbdns/dnscache/log/main ¥ > /var/djbdns/dnscache/log/main/* $ setlabel -s “public services” /var/djbdns/dnscache/log/supervise ¥ /var/djbdns/dnscache/log/supervise/*

(5) axfrdns の設定

スレーブサーバーに対してのゾーン転送を行う axfrdns について説明する。転送側

のサーバーは、djbdns 以外のサーバーBind 等でも構わない。設定内容および設定方法

は、tinydns、dnscache とほとんど同様である。



Trusted Solaris 編



名前情報の保存先を/var/djbdns/axfrdns とし、エントリを追加する。エントリ

の追加は、mailadmin でおこなう。

リスト 3-77 axfrdns の設定

$ cd /usr/local/djbdns/bin $ ./axfrdns-conf axfrdns djblog /var/djbdns/axfrdns <ホストの IP アドレス> $ cd /var/djbdns $ cd dnscache/root/servers $ mv ¥@ ¥@.org $ echo [上位 DNS IP アドレス] > @ $ cd ../ip $ touch [ネットワークアドレス]

(B) supervice への登録

/var/djbdns/axfrdns /run スクリプトを変更して supervice に登録する。作業は

primaryadmin によって行う。スクリプトの変更点および設定方法は以下のとおりで

ある。


#!/sbin/sysh setprof mailservice


# ln -s /var/djbdns/axfrdns /services


axfrdns に関するディレクトリおよびファイルの SL を変更する。変更の前に

svscanboot を[ADMIN_LOW]で起動し停止する。、その後、作成されたディレクトリを

secadmin によって SL[PUBLIC MAIL]に変更する。



Trusted Solaris 編



$ setlabel -s “public services” /var/djbdns/axfrdns/supervice ¥ > /var/djbdns/axfrdns/supervice/* $ setlabel -s “public services” /var/djbdns/axfrdns/log/main ¥ > /var/djbdns/axfrdns/log/main/* $ setlabel -s “public services” /var/djbdns/axfrdns/log/supervise ¥ /var/djbdns/axfrdns/log/supervise/*

3.5.3. SMTP サーバー

ここでは、SMTP サーバーとして以下のパッケージに関する定義と設定の例を示す。

sendmail

qmail

postfix

3.5.3.1. sendmail

sendmail については、2002 年 12 月において、http://www.sendmail.org から入手が可能

な sendmail 8.12.6 について実装と検証を行った。

sendmail に付随して、BarklayDB が必要となるため、Sun Site からの入手が可能である、

BarklayDB 3.3.11 を利用した。


ここでは、通常の Solaris 8 におけるインストレーションと同様の手順によるイン

ストールを行う。





$ cd /usr/local $ pkgadd -d db-3.3.11-sol8-sparc-local $ gzcat sendmail.8.12.6.tar.gz | tar xvf -




Trusted Solaris 編


ここでは、sendmail の実行ユーザ smmsp およびグループ smmsp を作成する（リスト

3-82）。なお、簡易に構築するため特権シェル環境により行うが、ユーザとグループの

追加は admin 役割にて SMC を利用することでも可能である。


# groupadd -g 25 smmsp # useradd -u 25 -g 25 -d / smmsp


ここでは、sendmail 8.12.6 のコンパイルに必要となるライブラリのランタイム・

リンキング環境を設定する（リスト 3-83）。

リスト 3-83 ランタイム・リンキング環境設定（primaryadmin 役割）

# crle -u -l /usr/local/BerkeleyDB.3.3/lib # crle Configuration file [2]: /var/ld/ld.config Default Library Path (ELF): /usr/lib:/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.3.3/lib Trusted Directories (ELF): /usr/lib/secure Command line: crle -c /var/ld/ld.config -l /usr/lib:/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.3.3/lib -s /usr/lib/secure


ここでは、sendmail 8.12.6 のコンパイルとインストールを行う（リスト 3-85）。

なお、サイトに固有の構成ファイルを編集する。構成ファイルの例を以下に示す。



Trusted Solaris 編


リスト 3-84 devtools/Site/site.config.m4

define(`confINCDIRS', `-I/usr/local/BerkeleyDB.3.3/include') define(`confLIBDIRS', `-L/usr/local/BerkeleyDB.3.3/lib') define(`confMANROOT', `/usr/local/man/man')

リスト 3-85 sendmail の Build（primaryadmin 役割）

# PATH=/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/local/bin # export PATH # cd /usr/local/sendmail-8.12.6 # ./Build # ./Build install

実際のインスとレーションで NOTE が出力されたため指示に従い以下を実施した # cd /usr/local/sendmail-8.12.6/obj.SunOS.5.8.sun4/mail.local # make force-install

実際のインスとレーションで NOTE が出力されたため指示に従い以下を実施した # cd /usr/local/sendmail-8.12.6/obj.SunOS.5.8.sun4/rmail # make force-install


ここでは、sendmail.cf ファイルの生成とインストールを行う（リスト 3-87）。

なお、サイトに固有の定義ファイルの編集する。定義ファイルの例を以下に示す。



Trusted Solaris 編


リスト 3-86 mc 定義ファイル

divert(-1) divert(0)dnl VERSIONID(`$Id: generic-solaris.mc,v 8.13 2001/06/27 21:46:30 gshapiro Exp $')OSTYPE(solaris2)dnl DOMAIN(generic)dnl FEATURE(àlways_add_domain')dnl MASQUERADE_AS(`tscorp.com')dnl MASQUERADE_DOMAIN(`tscorp.com')dnl FEATURE(`masquerade_entire_domain')dnl FEATURE(`masquerade_envelope')dnl FEATURE(àccess_db',`hash /etc/mail/access')dnl FEATURE(`blacklist_recipients')dnl FEATURE(`nouucp',`reject')dnl undefine(ÙUCP_RELAY')dnl undefine(`BITNET_RELAY')dnl define(`confCF_VERSION',`ts-single.mc-20030108')dnl define(`confMAX_MESSAGE_SIZE',`5242880')dnl define(`confPRIVACY_FLAGS',`goaway')dnl MAILER(local)dnl MAILER(smtp)dnl

リスト 3-87 sendmail.cf の Build（primaryadmin 役割）

# ./Build ts-single.cf Using M4=/usr/ccs/bin/m4 rm -f ts-single.cf /usr/ccs/bin/m4 ../m4/cf.m4 ts-single.mc > ts-single.cf || ( rm -f ts-single.cf && exit 1 ) *** WARNING: missing -T in argument of FEATURE(àccess_db', hash /etc/mail/access) chmod 444 ts-single.cf # cp -p ts-single.cf /etc/mail/sendmail.cf

次に sendmail の基本設定を行う。この作業も引き続き特権シェル環境にて行う。

なお、ここでは簡易に構築するため作業を特権シェル環境により行うが、運用時に

はこれらの作業が mailadmin 役割により可能となるようにする。

ここでは、定義ファイルの編集を行う。また、mailadmin 役割による編集が可能と

なるように、定義ファイルの所有者を mailadmin に変更する（リスト 3-88）。



Trusted Solaris 編


リスト 3-88 定義ファイルの編集（primaryadmin 役割）

# cd /etc/mail # chown mailadmin local-host-names access aliases # chmod 644 local-host-names access aliases

リスト 3-89 local-host-names

tscorp.com

リスト 3-90 access

Connect:localhost RELAY Connect:tscorp.com RELAY

リスト 3-91 access.db の生成（primaryadmin 役割）

# makemap -v hash access.db < access key=`connect:localhost', val=`RELAY' key=`connect:tscorp.com', val=`RELAY'

リスト 3-92 aliases

Postmaster: admin MAILER-DAEMON: postmaster nobody: /dev/null

リスト 3-93 aliases.db の生成（primaryadmin 役割）

# newaliases /etc/mail/aliases: 3 aliases, longest 10 bytes, 52 bytes total

最後に sendmail 起動スクリプトの編集を行う。この作業は admin 役割により行う。

標準でインストールされている sendmail の起動スクリプトを利用することとし、こ

れを編集する。admin 役割による編集が可能となるように、所有者を admin 役割に変

更する（リスト 3-94）。

インタープリターがシステムシェル（sysh）になっていることを確認し、以降のセ

キュリティ属性定義において設定する mailservice プロファイルがサービス起動時に

有効となるように、setprof コマンドによる定義を追加する。sendmail の起動スクリ

プトを確認する。なお、sendmail は BIND の後に起動しなければならない。



Trusted Solaris 編




リスト 3-95 sendmail スクリプト:インタープリター

#!/bin/sysh setprof mailservice

(2) ファイル



い。



1 /etc/mail/* N/A N/A N/A

2 /usr/local/man/* N/A N/A N/A

3 /usr/bin/newaliases -> /usr/lib/sendmail

4 /usr/bin/mailq -> /usr/lib/sendmail

5 /usr/bin/hoststat -> /usr/lib/sendmail

6 /usr/bin/purgestat -> /usr/lib/sendmail

7 /usr/bin/rmail -> ./mail

8 /usr/bin/mail -r-xr-xr-x bin bin

9 /usr/bin/vacation -r-xr-xr-x bin bin

10 /usr/sbin/editmap -r-xr-xr-x bin bin

11 /usr/sbin/mailstats -r-xr-xr-x bin bin

12 /usr/sbin/makemap -r-xr-xr-x bin bin

13 /usr/sbin/praliases -r-xr-xr-x bin bin

14 /usr/lib/smrsh -r-xr-xr-x bin bin

15 /usr/lib/mail.local -r-xr-xr-x bin bin

16 /usr/lib/sendmail -r-xr-sr-x root smmsp

17 /var/spool/clientmqueue drwxrwx--- smmsp smmsp

18 /var/spool/mqueue drwx------ root bin

19 /var/mail drwxdrwxrwt root mail





Trusted Solaris 編




対するアクセスを許可される。この場合、サービスに与える特権を少なくする最良の

方法は、サービスを形成するすべてのプロセスが同一のラベルで動作するようにする

ことである。つまり MTA の機能を果たす sendmail および MDA の機能を果たす

mail.local が共に、ネットワークからのアクセスを許可された同一のラベルで動作し

ている必要がある。



ADMIN_LOW

PUBLIC

ADMIN_HIGH

services

/var/spool

aliases etc.

syslog etc.

/var/mail

mail.localsendmail 全ての




sendmail および mail.local のプロセスの SL は[PUBLIC SERVICES]とする。


sendmail.cf および定義ファイルの SL は[ADMIN_LOW]とし、ネットワークアク

セスに関連するプロセス（sendmail、mail.local および派生するプロセス）

から読み込みのみが許可される。

ただし、最小特権を考慮し、キューディレクトリおよびスープールディレク

トリは[PUBLIC SERVICES]に変更する。




ところで、/var/spool/mqueue と/var/mail のディレクトリについて、標準のディ



Trusted Solaris 編


レクトリを変更する必要はがないが、標準では MLD になっているので、これを SLD

に変更する場合には、/var/spool/clientmqueue と同じ属性を適用する必要がある。



1 /usr/lib/mail.local ADMIN_LOW none all

2 /usr/lib/sendmail ADMIN_LOW none all

3 /var/spool/clientmqueue PUBLIC services N/A N/A

4 /var/spool/mqueue MLD（標準） N/A N/A

5 /var/mail MLD（標準） N/A N/A

次の管理に関わるファイルの属性をそれぞれのファイルに適用する。なお、実際

には初期設定から変更の必要はない。



1 /usr/bin/mail ADMIN_LOW none none

2 /usr/bin/vacation ADMIN_LOW none none

3 /usr/sbin/editmap ADMIN_LOW none none

4 /usr/sbin/mailstats ADMIN_LOW none none

5 /usr/sbin/makemap ADMIN_LOW none none

6 /usr/sbin/praliases ADMIN_LOW none none

7 /usr/lib/smrsh ADMIN_LOW none none

8 /etc/mail/* ADMIN_LOW N/A N/A




ところで、ここでは sendmail のみの定義を行い mail.local の定義を行わないが、

その理由はmail.localがsendmailから起動されるためsendmailのセキュリティ属

性を継承することが可能であるためである。



Trusted Solaris 編




1 /etc/init.d/sendmail root (euid)

sys (egid)

N/A N/A all

2 /usr/lib/sendmail root (uid)

smmsp (gid)

PUBLIC services

PUBLIC services

file_chown file_mac_read net_privaddr proc_setid sys_net_config sys_suser_compat

次の管理に関わる実行属性を管理用の mailcontrol プロファイルに追加する。

ところで、ここでは sendmail の定義を行っているが、これは、sendmail にシン

ボリックリンクをしている、newaliases、mailq、hoststats、purgestat を有効に

するためのものである。




N/A N/A N/A proc_setid sys_suser_compat

2 /usr/sbin/mailstats root (uid)

N/A N/A N/A N/A

3 /usr/sbin/makemap root (uid)

N/A N/A N/A N/A

4 /usr/sbin/praliases root (uid)

N/A N/A N/A N/A






Trusted Solaris 編





PUBLIC services

PUBLIC services




PUBLIC services

PUBLIC services

PUBLIC services




3.5.3.2. qmail

qmail については、2002 年 12 月において、http://www.qmail.org から入手が可能な

qmail-1.03 について実装と検証を行った。




最初に必要なパッケージの追加やソースの展開を行う。この作業は admin 役割に移

行し役割のワークスペースにて行うことが可能である。このときデフォルトのラベル

は[ADMIN_LOW]となる。


$ cd /usr/local $ gzcat qmail-1.03.tar.gz | tar xvf -

(A) ユーザとグループの追加

qmail では、root の権限で動作するプロセスを最小限に抑えるため、タスク毎に

ユーザが異なるプロセスが動作する。そのために必要なユーザおよびグループを作



Trusted Solaris 編


成する（リスト 3-97）。

なお、簡易に構築するため特権シェル環境により行うが、ユーザとグループの追

加は admin 役割にて SMC を利用することでも可能である。


# groupadd nofiles # groupadd qmail # useradd -s /bin/false -g nofiles -d /var/qmail/alias alias # useradd -s /bin/false -g nofiles -d /var/qmail qmaild # useradd -s /bin/false -g nofiles -d /var/qmail qmaill # useradd -s /bin/false -g nofiles -d /var/qmail qmailp # useradd -s /bin/false -g qmail -d /var/qmail qmailq # useradd -s /bin/false -g qmail -d /var/qmail qmailr # useradd -s /bin/false -g qmail -d /var/qmail qmails

(B) qmail のインストール

qmail のコンパイルとインストールを行う（リスト 3-99）。この作業も引き続き

特権シェル環境にて行う。

なお、コンパイルを gcc にて行うため conf-cc ファイルおよび conf-ld ファイル

を変更する。

また、コンパイル後インストールを行うと install および instcheck のコマンド

においてpermission denyというメッセージが出てインストールが停止してしまう。

これらは、make によって作成されたバイナリファイルである。そのため、許容特権

がなく特権シェルを利用しても特権を継承することができない。そこで、それらの

ファイルに許容特権を付与しインストールを行う。



Trusted Solaris 編


リスト 3-98 conf-cc,conf-ld

gcc -O2

リスト 3-99 qmail のインストール（primaryadmin 役割）

# PATH=/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/local/bin # export PATH # cd /usr/local/qmail-1.03 # make

実際のインストレーションで install および instcheck において permission denay でFatal error となるためこれらのコマンドの特権を有効にする。 # setfpriv -s -a all install instcheck

# make setup check

# ./config

(C) qmail の基本設定

qmail の基本設定を行う。この作業も引き続き特権シェル環境にて行う。

なお、こここでは簡易に構築するため作業を特権シェル環境により行うが、運用

時にはこれらの作業が mailadmin 役割により可能とするようにする。

ここでは、定義ファイルの編集を行う。また、mailadmin 役割による編集が可能

となるように、定義ファイルの所有者を mailadmin に変更する（リスト 3-100）。


# cd /var/qmail/control # chown mailadmin * # chmod 644 * # cd /var/qmail/alias # touch .qmail-root .qmail-postmaster .qmail-mailer-daemon # chown mailadmin .qmail-* # chmod 644 * .qmail-*

リスト 3-101 locals, rcpthosts

macaroni.tscorp.com tscorp.com localhost

リスト 3-102 .qmail-root, .qmail-postmaster, .qmail-mailer-daemon

&[email protected]



Trusted Solaris 編


(D) qmail の起動設定

qmail の起動の設定を行う。この作業も引き続き特権シェル環境にて行う。

まず、qmail の起動スクリプトを確認しコピーする（リスト 3-103）。

リスト 3-103 qmail 起動スクリプトのコピー

# cp /var/qmail/boot/home /var/qmail/rc

次に、既存の sendmail を無効として、その代わりに sendmail へのリクエストを

qmail に渡すラッパーである sendmail を有効にする（リスト 3-104）。

リスト 3-104 sendmail の保存

# mv /usr/lib/sendmail /usr/lib/sendmail.org # ln -s /var/qmail/bin/sendmail /usr/lib/sendmail

次に、ここでは、リモートホストからのメールの受信において inetd により起動

することとし、/etc/inetd.conf に smtp のエントリの追加修正を行う。

リスト 3-105 inetd.conf の変更

smtp stream tcp nowait,trusted,setaudit qmaild /var/qmail/bin/tcp-env tcp-env /var/qmail/bin/qmail-smtpd

最後に qmail の起動スクリプトの編集を行う。この作業は admin役割により行う。

標準でインストールされているsendmailの起動スクリプトを利用することとし、

これを編集する。admin 役割による編集が可能となるように、所有者を admin 役割

に変更する（リスト 3-106）。

インタープリターがシステムシェル（sysh）になっていることを確認し、以降の

セキュリティ属性定義において設定する mailservice プロファイルがサービス起動

時に有効となるように、setprof コマンドによる定義を追加する。sendmail の起動

スクリプトを確認する。また、既存の sendmail の起動スクリプトを qmail の起動ス

クリプトに置き換える。



Trusted Solaris 編






リスト 3-108 sendmail スクリプト：qmail 起動スクリプト

if [ -f /var/qmail/rc -a -f /var/qmail/control/me ]; then echo 'starting qmail server.' /var/qmail/rc & fi







とである。





Trusted Solaris 編


ADMIN_LOW

PUBLIC

ADMIN_HIGH

services

.qmail-* etc.

syslog etc.

全ての



qmail-lspwn

qmail-send

qmail-rspwn

splogger

qmail-clean

queue/* Mailbox


qmail のプロセスの SL は[PUBLIC SERVICES]とする。


定義ファイルの SL は[ADMIN_LOW]とし、ネットワークアクセスに関連するプ

ロセス（qmail のプロセスおよび派生するプロセス）から読み込みのみが許可

される。

ただし、最小特権を考慮し、キューディレクトリおよびスプールファイル

（mbox 形式）またはスープールディレクトリ（Maildir 形式）の SL は[PUBLIC

SERVICES]となるようにする。


サービス提供および管理に関わる実行可能ファイルについて、「強制特権を無し」、

「許容特権を全て」とする属性を適用する。なお、設定の手順については

3.4.4.1(1)(A)に記載している。


$ setfpriv -s -a all /etc/init.d/sendmail $ find /var/qmail -type f -exec setfpriv -s -a all {} ¥;

次に、キューディレクトリの SL をすべて[PUBLIC SERVICES]に変更する。なお、

設定の手順についてはに記載している。



Trusted Solaris 編



$ find /var/qmail/queue -exec setlabel -s “public services” {} ¥;

なお、スプールファイル（mbox 形式）またはスープールディレクトリ（Maildir

形式）はホームディレクトリ以下となるため、これは MLD となっているので、これ

を特に変更する必要はない。

(B) プロセス属性値

次のサービス提供に関わる実行属性をサービス用のmailserviceプロファイルお

よび inetd プロファイルに追加する。なお、設定の手順については 3.4.3.4(2)(A)

に記載している。

ところで、ここでは qmail の起動スクリプトのみの定義を行っており、スクリプ

ト内の qmail-start については定義を行わないが、その理由は qmail-start プログ

ラムに関係している。qmail-start では、fork(2)によってプロセスを作成後、

setuid(2)によってプロセスのユーザを変更しそれぞれのプロセスを exec(2)によ

り起動している。そのため qmail-start に特権を付与したとしても、それが無効と

なってしまうためである。




sys (egid)

N/A N/A all

2 /var/qmail/rc N/A N/A PUBLIC services

PUBLIC services

file_dac_sarch proc_setid

表 3-81 サービス用プロセス属性値（inetd プロファイル）


1 /var/qmial/bin/ tcp-env

N/A N/A PUBLIC services

PUBLIC services

N/A

次の管理に関わる実行属性を mailcontrol プロファイルに追加する。



Trusted Solaris 編


表 3-82 管理用プロセス属性値


1 /var/qmail/bin/ qmail-qstat

qmialq (euid)

N/A PUBLIC services

PUBLIC services

N/A

2 /var/qmail/bin/ qmail-qread

qmialq,qmail (euid)

N/A PUBLIC services

PUBLIC services

N/A

3 /var/qmial/bin/ qmail-crean


PUBLIC services

N/A

4 /var/qmail/bin/ qmail-newu

root (euid)

N/A N/A N/A N/A

5 /var/qmail/bin/ qmail-newmrh

root (euid)

N/A N/A N/A N/A







PUBLIC services

PUBLIC services




PUBLIC services

PUBLIC services

PUBLIC services




3.5.3.3. Postfix

Postfix については、2002 年 12 月において、http://www.postfix.org から入手が可能な

psotfix 2.0.0.2 について実装と検証を行った。



Trusted Solaris 編









$ cd /usr/local $ gzcat postfix-2.0.0.2.tar.gz | tar xvf -

(A) ユーザとグループの追加

Postfix は、root の権限で動作するプロセスを最小限に抑えるため、postfix ユー

ザのプロセスが動作する。そのために必要なユーザおよびグループを作成する（リ

スト 3-112）。

なお、簡易に構築するため特権シェル環境により行うが、ユーザとグループの追

加は admin 役割にて SMC を利用することでも可能である。


# groupadd postfix # groupadd postdrop # useradd -g postfix -d /dev/null -s /bin/false postfix

(B) sendmail 環境の保存

Postfix のインストールでは、sendmail 関連のファイルもインストールされる。

そのため、既存の sendmail の環境を保存しておく（リスト 3-113）。この作業も引

き続き特権シェル環境にて行う。



Trusted Solaris 編


リスト 3-113 既存の sendmail の保存

# mv /usr/lib/sendmail /usr/lib/sendmail.org # mv /usr/bin/newaliases /usr/bin/newaliases.org # mv /usr/bin/mailq /usr/bin/mailq.org

(C) postfix のインストール

Postfix のコンパイルとインストールを行う（リスト 3-114）。この作業も引き続

き特権シェル環境にて行う。

リスト 3-114 Postfix のコンパイル

# PATH=/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/local/bin # export PATH # cd /usr/local/postfix-2.0.0.2 # make

# make install …（省略）… Please specify the prefix for installed file names. This is useful if you are building ready-to-install packages for distribution to other machines. install_root: [/] tempdir: [/usr/local/postfix-2.0.0.2] config_directory: [/etc/postfix] daemon_directory: [/usr/libexec/postfix] command_directory: [/usr/sbin] queue_directory: [/var/spool/postfix] sendmail_path: [/usr/lib/sendmail] newaliases_path:[/usr/bin/newaliases] mailq_path: [/usr/bin/mailq] mail_owner: [postfix] setgid_group: [postdrop] manpage_directory: [/usr/local/man] sample_directory: [/etc/postfix] readme_directory: [no]

(D) Postfix の基本設定

Postfix の基本設定を行う。この作業も引き続き特権シェル環境にて行う。

なお、ここでは簡易に構築するために作業を特権シェル環境により行うが、運用



Trusted Solaris 編


時にはこれらの作業が mailadmin 役割により可能とするようにする。

ここでは、定義ファイルの編集を行う。また mailadmin 役割による編集が可能と

なるように、定義ファイルの所有者を maildadmin に変更する（リスト 3-115）。


# cd /etc/postfix # chown mailadmin main.cf

リスト 3-116 main.cf の主な設定項目

…（省略）… myhostname = macaroni.tscorp.com …（省略）… mydomain = tscorp.som …（省略）… myorigin = macaroni …（省略）… mydestination = $myhostname, localhost.$mydomain …（省略）… mynetworks_style = subnet

(E) Postfix の起動設定

最後に postfix の起動スクリプトの編集を行う。この作業は admin 役割により行

う。

標準でインストールされているsendmailの起動スクリプトを利用することとし、

これを編集する。admin 役割による編集が可能となるように、所有者を admin 役割

に変更する（リスト 3-117）。

インタープリターがシステムシェル（sysh）になっていることを確認し、以降の

セキュリティ属性定義において設定する mailservice プロファイルがサービス起動

時に有効となるように、setprof コマンドによる定義を追加する。sendmail の起動

スクリプトを確認する。また、既存の sendmail の起動スクリプトを postfix の起動

スクリプトに置き換える。



Trusted Solaris 編






リスト 3-119 sendmail スクリプト：postfix 起動スクリプト

if [ -f /usr/sbin/postfix -a -f /etc/postfix/main.cf ]; then echo 'starting postfix server.' /usr/sbin/postfix start & fi







とである。





Trusted Solaris 編


ADMIN_LOW

PUBLIC

ADMIN_HIGH

services

/var/spool

aliases etc.

syslog etc.

local postfix 全ての


に対する許可範囲 /var/mail

図 3-31 セキュリティポリシーのイメージ図

postfix および local のプロセスの SL は[PUBLIC SERVICES]とする。


main.cf および定義ファイルの SL は[ADMIN_LOW]とし、ネットワークアクセス

に関連するプロセス（postfix、local および派生するプロセス）から読み込

みのみが許可される。

ただし、最小特権を考慮し、キューディレクトリおよびスープールディレク

トリは[PUBLIC SERVICES]に変更する。


サービス提供および管理に関わる実行可能ファイルについて、「強制特権を無し」、

「許容特権を全て」とする属性を適用する。なお、設定の手順については

3.4.4.1(1)(A)に記載している。


$ setfpriv -s -a all /etc/init.d/sendmail $ setfpriv -s -a all /usr/sbin/post* $ setfpriv -s ‐a all /usr/lib/sendmail $ find /usr/libexec/postfix -type f -exec setfpriv -s -a all {} ¥;

次に、キューディレクトリの SL をすべて[PUBLIC SERVICES]に変更する。なお、

設定の手順についてはに記載している。



Trusted Solaris 編



$ find /var/spool/postfix -exec setlabel -s “public services” {} ¥;

なお、標準のスプールディレクトリ（/var/mail）については、標準では MLD に

なっているので、これを特に変更する必要はない。





# コマンド user group label clearance 特権


sys (egid)

N/A N/A all

2 /usr/local/postfix/ bin/postfix

root (uid)

N/A PUBLIC services

PUBLIC services

fil_dac_read file_dac_searchfile_mac_write net_privaddr proc_owner proc_setid

次の管理に関わる実行属性を mailcontrol プロファイルに追加する。

表 3-87 管理用プロセス属性値

# コマンド user group label clearance 特権

1 /usr/local/postfix/ bin/postalias

root (uid)

N/A N/A N/A N/A

2 /usr/local/postfix/ bin/postmap

root (euid)

N/A N/A N/A N/A

3 /usr/local/postfix/ bin/postqueue


N/A N/A






Trusted Solaris 編





PUBLIC services

PUBLIC services




PUBLIC services

PUBLIC services

PUBLIC services




3.5.4. FTP サーバー

3.5.4.1. WU-ftpd

ftp サーバーは、Trusted Solaris にも標準でインストールされているが、本書ではファ

イルを圧縮しながら転送する機能や IP アドレス単位のアクセス制限等、anonymous FTP と

して有効な多くの機能が携わっている wu-ftpd(Washington University FTP daemon)を利用し

て FTP サーバーを設定する手順を説明する。

(1) ディレクトリ構造

今回、wu-ftpd のインストールするにあたって、ディレクトリおよびファイルの保存先を

以下のように定義した。



Trusted Solaris 編


表 3-91 ディレクトリの作成

＃ディレクトリファイル備考

1 ftpaccess

2 ftpconversions

3 ftpgroups

4 ftphosts

5

/usr/local/wu-ftpd/etc

ftpusers

Wu-FTPD の設定ファイル

6 ftpcount

7

/usr/local/wu-ftpd/bin

ftpwho

8 ckconfig

9 ftprestart

10 ftpshut

11 privatepw

12

/usr/local/wu-ftpd/sbin

xferstats

管理コマンドプログラム

13 /var/ftp/ *

14 /var/ftp/bin/ *

15 /var/ftp/etc/ *

16 /var/ftp/lib/ *

17 /var/ftp/pub/ *

Anonymous 用のホームディレクトリ

(2) コンパイル

執筆時の wu-ftpd の最新ソースファイルは、wu-ftpd-2.6.2 となっている。これを

公式サイト(http://www.wu-ftpd.org)等からダウンロードし/usr/local/pkgに保存し

ているものとする。Trusted Solaris 標準の ftpd では、ユーザの SL 範囲のみログイ

ンを可能にしたり、役割でのログインは不可能になっている。wu-ftpd においてもこ

れらの制限を加えるため、configure を実行する際に PAM(Pluggable Authentication

Module)を有効にする必要がある。インストールは primaryadmin[admin_low]でおこ

なった。また、インストール後、設定ファイルを/usr/local/wu-ftpd/etc に用意する

必要があるが、サンプルが用意されているのでこれを利用することにする。



Trusted Solaris 編


リスト 3-122 コンパイル

$ sh # cd /usr/local/pkg # gzcat wu-ftpd-2.6.2.tar.gz | tar xvf - # cd wu-ftpd-2.6.2 # ./configure --prefix=/usr/local/wu-ftpd --with-etc-dir=/usr/local/wu-ftpd/etc --enable-pam # make # make install # cd doc/examples # cp ftpgroups ftphosts ftpusers /usr/local/wu-ftpd/etc

(3) ユーザおよびグループの追加

anonymous で利用するユーザを作成する必要がある。このユーザは、特にセキュリ

ティ属性等は必要はないので primaryadmin でコマンドラインで作成する。

リスト 3-123 ユーザおよびグループの追加(ftp)

# useradd -d /var/ftp -s /bin/false ‐g 60001 ftp

(4) anonymous 環境の設定

ここでは、anonymous における環境を設定する。wu-ftpd 自体の詳細な設定内容の説

明は割愛し、ls コマンドのみ利用できるようにする。Anonymous でログインした場合、

chroot を行い ftp ユーザのホームディレクトリ/var/ftp が/となる。そのため、ls 等

必要なコマンド、ライブラリは/var/ftp 以下にディレクトリを作成しファイルをコ

ピーする必要がある。今回作成したディレクトリは/var/ftp/usr/lib、/var/ftp/bin/

である。必要に応じて、/var/ftp/etc 等のディレクトリ等も作成して頂きたい。また、

コンテンツを保存するディレクトリ/var/ftp/pub も用意した。



Trusted Solaris 編


リスト 3-124 anonymous の設定

$ sh # mkdir /var/ftp # cd /var/ftp # mkdir bin pub # mkdir ‐p usr/lib # cp ‐p /usr/bin/ls bin/ls # chmod 111 bin/ls # cp ‐p /usr/lib/ld.so.1 /usr/lib/libc.so.1 /usr/lib/libdl.so.1 usr/lib/

(5) セキュリティポリシー

図に示すのは、その際のイメージ図である。ここでは、特に FTP のポリシーという

のは定義せず、他のサーバと同様のラベル情報を利用した。

ADMIN_LOW

PUBLIC

ADMIN_HIGH

services

contents conffile

in.ftpd

全ての



図 3-32 セキュリティポリシーのイメージ図

今回の FTP サーバーは、anonymous のみの利用を想定しファイルのアップロードは

禁止し、ダウンロードのみ許可する。そのため、外部からの応答は[PUBLIC Services]

で行い、コンテンツは[ADMIN_LOW]で保存する。また、表 3-92 に示すサービス用プ

ロセス属性値を inetd プロファイルに追加する。



Trusted Solaris 編



ファイル名 user group label clearance 特権

/usr/local/wu-ftpd/sbin/in.ftpd

N/A N/A N/A N/A net_privaddr proc_setid proc_chroot sys_config

(6) セキュリティ属性の設定

インストールしたすべてのファイルに許容特権を付与する。設定は、primaryadmin

でおこなう。

表 3-93 許容特権の設定(primaryadmin)

# find /usr/local/wu-ftpd -type f -exec setfpriv -s -a all {} ¥;

(A) inetd.conf の設定

ftpd は、inetd を利用して動作するため、/etc/inetd.conf を以下のように編集を

おこなう。

表 3-94 inetd.conf の設定

#ftp stream tcp6 nowait,trusted,setaudit root /usr/sbin/in.ftpd in.ftpd ftp stream tcp nowait,trusted,setaudit root /usr/local/wu-ftpd/sbin/in.ftpd in.ftpd -a

以上の inetd の設定が完了すると、inetd の再起動を行う。

表 3-95 inetd の再起動

# pkill ‐HUP inetd

(B) ネットワーク属性定義





Trusted Solaris 編





PUBLIC services

PUBLIC services




PUBLIC services

PUBLIC services

PUBLIC services






Trusted Solaris 編


3.5.5. セキュリティポリシーの妥当性確認

本節では、3.5.1.1 Apache の設定をおこなったセキュリティポリシーの妥当性を確認す

る。セキュリティポリシーを定義する前にサーバに対するあらゆるリスクを洗い出す必要

がある。これは、後述 4.3 節で述べる Trusted Solaris における保護対象及び保護非対象

に関連する。この、保護対象を踏まえたうえでポリシーを定義する必要がある。

3.5.5.1. セキュリティリスク

Trusted Solaris におけるメリットとして、サーバへの侵入防止ということがあげられる。

一般的に、主な侵入手法としてはサーバ上で動作しているソフトウェアの脆弱性をついた

ものが多い。また、サーバにバックドア等を仕掛け、それによって進入する方法も考えら

れる。バックドアに関しては、ソフトウェアをインストールする際に管理者が MD5 値等で

正規のものと比べることである程度防ぐことができる。しかし、ソフトウェアの脆弱性は、

ソフトウェアに依存しているため、管理者でもなくすことができない。また、進入後、バッ

クドアを仕掛けるといったパターンも考えられる。その為、ソフトウェアの脆弱性等をつ

いて進入されても、その後、侵入者に何もできないようにセキュリティポリシーを定義す

ることが懸命である。

3.5.5.2. セキュリティ属性の継承

通常、ソフトウェアの脆弱性をついてサーバ進入に成功した場合、セキュリティ属性は

継承される。これは、Trusted Solaris においても同様である。つまり、root ユーザです

べての継承可能特権を保持し動作しているソフトウェアを利用して進入し、進入後シェル

を実行した場合、このシェルは特権シェルと同等の振舞いをする。これらは、機密ラベル

や TP についても同様である。

そこで、上記を念頭にいれて 3.5.1 の Web サーバを例にとってセキュリティポリシーを

検証してみる。

(1) テストプロフィルの作成

Web サーバのプロセス属性値は、net_privaddr のみでファイル属性値が

file_dac_write、file_mac_write である。今回、Web サーバの脆弱性より進入し、進

入後シェルプロンプトが奪取されたと想定する。この場合、シェルに対して Web サー



Trusted Solaris 編


バと同様のセキュリティ属性値を付与することで同等の環境をつくることができる。

今回は、/bin/sh を/tmp/sh にコピー後、新規プロファイル testprofile を作成し、そ

れぞれ以下の特権を付与した。また、同時にテスト役割である testrole を作成しプロ

ファイル testprofile を割当てた。

表 3-99 ファイル属性値

ファイル名ラベル強制特権許容特権

/tmp/sh ADMIN_LOW file_dac_write file_mac_write

all

表 3-100 プロセス属性値

ファイル名 user group label clearance 特権

/tmp/sh www www public service

public service

net_privaddr

以上の設定が完了すると、testrole になり以下のコマンドを実行してみる。

リスト 3-125 id コマンドの実行

$ /tmp/sh $ id uid=80(www) gid=80(www) ←実行ユーザが www であることがわかる。

次に現在の機密ラベルを確認してみると、[PUBLIC Service]であることも確認できる。

リスト 3-126 plabel コマンドの実行

$ plabel 16300: [PUBLIC WEB] ← 現在の SL は[PUBLIC Service]

リストに示すのは、ppriv コマンドを実行した結果である。実行結果より、この sh は

net_privaddr 特権を持っていることがわかる。この特権は、プロセス属性値より継承可能

特権より継承されたものである。

リスト 3-127 ppriv コマンドの実行

$ ppriv 16301: net_privaddr ← 継承可能特権である net_privaddr を継承していることを確認できる。

次に、apache のログファイルを参照してみる。



Trusted Solaris 編


リスト 3-128 ディレクトリの参照

$ cd /usr/local/apache $ ls -l total 22 drwxr-xr-x 2 root other 512 1 月 7 16:08 bin drwxr-xr-x 2 root other 512 12 月 26 14:34 cgi-bin drwxr-xr-x 1 root other 0 1 月 1 1970 conf drwxr-xr-x 3 root other 1024 12 月 26 14:34 htdocs drwxr-xr-x 3 root other 3584 1 月 7 16:09 icons drwxr-xr-x 3 root other 1024 12 月 26 14:34 include drwxr-xr-x 2 root other 512 12 月 26 14:34 libexec drwxr-xr-x 1 root other 0 1 月 1 1970 logs drwxr-xr-x 4 root other 512 12 月 26 14:34 man drwxr-xr-x 2 root other 512 12 月 26 14:34 proxy

すべてのディレクトリ及びファイルは、機密ラベルが[ADMIN_LOW]であるため参照するこ

とが可能である。

3.5.5.3. まとめ

本節では、Web サーバに関してポリシーの検証をおこなった。Web サーバは、ユーザ www

で動作しているため DAC のアクセス制御も有効になっていた部分もある。しかし、root で

動作させても MAC に関するアクセス制御は同様に機能するため機密ラベルが[ADMIN_LOW]で

ある設定ファイル、ログファイルは参照することは可能だが書込みができないため保護さ

れている。本ポリシーは、Web サーバのみならず他のアプリケーションでも同様に定義する

ことができる。サーバが動作する、機密ラベルと設定ファイル、コンテンツ等を隔離する

ことが重要である。また、その際に必要になる、特権は極力最小限に抑える。どうしても

必要になる特権に関しては、特権の組み合わせを有効に活用し設定する必要があると考え

られる。

3.5.5.4. インターネットサーバーの要塞化

これまでは、外部からのアクセスを許可するサービスに対して、設定ファイルやコンテ

ンツファイルおよびログファイル等について、機密ラベルを分けることにより、それらの

保護を実現することを説明した。

ここでは、サーバの要塞化を実現する、より高度なセキュリティが要求される場合の、

内部からのアクセスと外部からのアクセスの隔離、およびサービスと他のプロセスまたは

ファイル等の隔離をすることによる、その実現方法について説明する。

なお、表 3-101 はここで解説するラベル定義の例である。また、リスト 3-21 はこれに

対応するラベル構成を定義した label_encodings ファイルの完全な例である。



Trusted Solaris 編


表 3-101 ラベル構成

# ラベル種別主な割り当て対象設定値

1 ADMIN_LOW 格付けシステムのアプリケーションおよび定義ファイル

標準

2 ADMIN_HIGH 格付けシステムのログファイルや監査ファイル標準

3 PUBLIC 格付け外部向けのサービスおよび定義ファイル 50

4 PRIVATE 格付け内部向けのサービスおよびデータファイル

70

5 services コンパートメントサービス全体を表す 51-80

6 web コンパートメント httpd プロセス用 51,56

7 script コンパートメント CGI プロセス用 61,56

8 mail コンパートメント SMTP および DNS サービス用 71,76

9 contents コンパートメント Web および FTP の定義ファイルやコンテンツ

56

10 mailconf コンパートメント SMTP および DNS の定義ファイルやデータベース

76

高度なラベル構成のネットワークでは、アクセスを許可するサービスは独立したコン

パートメントに隔離され、また各コンパートメント内では定義ファイルやコンテンツまた

データベースなどのサービスの提供に必要となるファイルに対して、サービスを提供する

プロセスが優位なラベルで実行されるものとする。

さらに、外部のアクセスに対して内部のアクセスが優位なラベルを取得できるようにし、

各サービスに対する外部からのアクセスによる派生プロセス対して、内部のアクセスによ

る派生プロセスが優位なラベルで実行されるものとする。

これにより、外部に公開しているサービスのセキュリティ上の問題により、仮に不正な

プロセスが派生することがあった場合において、そのようなプロセスは外部に公開してい

るサービスと同一のラベルとなることが考えられるが、内部のアクセスによる派生するプ

ロセスや内部のネットワークアクセス自体に対して直接的な参照を困難にすることが可能

となる。



Trusted Solaris 編


ADMIN_LOW

PUBLIC

ADMIN_HIGH

優位度

低

高

services

web script

PRIVATE

mail

mailconf contents

services

web mail

図 3-33 マルチラベルのラベル空間

参考として、apache、bind、sendmail については、このラベル構成における設定の例を

示す。

(1) apache

マルチラベルを考慮したネットワークを構成した際のポリシーを以下のように定義

する。



Trusted Solaris 編


ADMIN_LOW

PUBLIC

ADMIN_HIGH

services

PRIVATE

web script

contents

services web

logfile

httpd

html,CGI Files

外部からの



内部からの



suEXEC

conf Files

図 3-34 マルチラベル構成時のイメージ図

httpd の SL は[PUBLIC WEB]とし、CGI は Apache の機能である suEXEC を利用す

る。また、その際の SL は[PUBLIC SCIRPT]とし httpd の SL とは隔離する。

コンテンツファイルの SL は[PUBLIC CONTENTS]とし、CGI ファイルも同様とす

る。

apache に関する設定ファイルは、[ADMIN_LOW]としログファイルは[PUBLIC web]

として保存する。

(A) ファイル属性値

httpd プロセスの uid が www であるため、ログファイルに書き込むためには

file_dac_write および file_mac_write の特権が必要になる。そこで、ファイル及

びディレクトリのパーミッション、機密ラベルを変更し、これらの特権を不要とす

る。以下のコマンドは、secadmin によって実行する。

リスト 3-129 ファイル属性値設の定（secadmin 役割）

$ chown www /usr/local/apache/logs $ setlabel “public web” /usr/local/apache/logs



Trusted Solaris 編



次の属性をサービス用の webservice プロファイルに追加する。

表 3-102 プロセス属性


1 /usr/local/apache/ bin/apachectl

www www PUBLIC web

PUBLIC web script

net_privaddr

リスト 3-130 機密ラベルの設定（secadmin 役割）

$ setlabel -s “public contents” /export/contents /export/cgi-bin

次に、Apache のログファイルおよび設定ファイルのディレクトリとファイルの SL

を変更する。この作業も secadmin で行う。

リスト 3-131 機密ラベルの設定（secadmin 役割）

$ find /usr/local/apache/logs /usr/local/apache/conf ‐exec ¥n > setlabel -s “private web” {} ¥;

(C) プログラムの修正（suEXEC）

CGI スクリプトは、Apache の機能である suEXEC を利用してスクリプトの所有者

で実行するすることはできる。これにより、悪意のあるものや記述を間違ったスク

リプトによって他のユーザのファイルおよびディレクトリに影響を及ぼすことはな

い。しかし、Web サーバーと CGI が同じ SL で実行されているため、CGI スクリプト

の所有者のコンテンツは保護することはできない。そこで、suEXEC を httpd とは別

のコンパートメントで動作するように変更する。変更にあたっては、

src/support/suexec.c のソースファイルを編集し再コンパイルする必要がある。作

業は特権シェル環境でおこなう。編集する部分をリスト 3-132 および

リスト 3-133 に示す。



Trusted Solaris 編


リスト 3-132 suexec.c:header

#include "suexec.h" #ifndef TSOL #define TSOL #endif #ifdef TSOL #include <tsol/label.h> #include <tsol/priv.h> #endif /* TSOL */



Trusted Solaris 編


リスト 3-133 suexec.c:main()

/* * Error out if attempt is made to execute as root group * or as a GID less than GID_MIN. Tsk tsk. */ if ((gid == 0) || (gid < GID_MIN)) { log_err("crit: cannot run as forbidden gid (%d/%s)¥n", gid, cmd) exit(108); } /* * Change UID/GID here so that the following tests work over NFS. * * Initialize the group access list for the target user, * and setgid() to the target group. If unsuccessful, error out. */ #ifdef TSOL { bclabel_t label; int p; log_err("changing process label¥n"); getcmwplabel(&label); /* get current process label */ if (stobsl("- Services", bcltosl(&label), 0, &p) != 1) { log_err("unrecognized label at %d¥n", p); exit(109); } if (stobsl("+ CGI", bcltosl(&label), 0, &p) != 1) { log_err("unrecognized label at %d¥n", p); exit(109); } if (setcmwplabel(&label, SETCL_SL) != 0) { log_err("unable to set label¥n"); exit(109); } if (set_inheritable_priv(PRIV_SET, NULL) != 0) { log_err("unable to clear privilege set¥n"); exit(109); } } #endif /* TSOL */

変更の際に利用したシステムコールの説明は以下のとおりである。

getcmwplabel() 現在の CMW ラベルを取得する。

bcltosl() CMW ラベルのバイナリを SL にする。

stobsl() ASCII 表示の SL をバイナリに変換する。

setcmwplabel() プロセスの CMW ラベルをセットする。

set_inheritable_priv() 現在のプロセスの privilege をセットする。

また、これをコンパイルするために Makefile を修正する。次のオプションを修



Trusted Solaris 編


正する。

リスト 3-134 Makefile の変更

suexec: suexec.o $(CC) $(CFLAGS) -ltsol -o suexec $(LDFLAGS) suexec.o $(LIBS)

以上の変更が終わったら、configure を行った場所に移動し再コンパイルを行う。

リスト 3-135 再コンパイル

# cd ../.. # make # cp src/support/suexec /usr/local/apache/bin

また、変更した suexec を実行する際には、compartments を変更するため

proc_setsl と proc_tranquil の特権が必要になる。また、それぞれの uid で実行す

るので proc_setid も併せて必要になる。この作業は、secadmin によっておこなう。

表 3-103 ファイル属性値


1 /usr/local/apache/bin/suexec ADMIN_LOW proc_setsl proc_tranquil proc_setid

all

リスト 3-136 ファイル属性値の設定

$ setfpriv -s -f proc_setsl,proc_tranquil,proc_setid /usr/local/apache/bin/suexec

(2) BIND

この構成では、F/W 内に存在する内部 DNS の cache サーバとしても利用することが

できる。

ここでは、net_mac_read 特権と net_reply_equal 特権を利用する。これにより外部

と内部に対して異なるラベルを割り当てた高度なラベル構成のネットワークアクセス

対してプロセスが対応することが可能となる。



Trusted Solaris 編


ADMIN_LOW

PUBLIC

ADMIN_HIGH

services

PRIVATE

mail

mailconf

services mail

named

named.conf

syslog etc.

外部からの



内部からの



リスト 3-137 高度なラベル構成によるサービスのイメージ


サービス提供に関わる次のファイル属性をそれぞれのファイルに適用する。



1 /usr/local/sbin/named ADMIN_LOW none all

2 /usr/local/sbin/lwresd ADMIN_LOW none all

管理に関わる次のファイルの属性をそれぞれのファイルに適用する。



Trusted Solaris 編




1 /usr/local/bin/dig ADMIN_LOW none none

2 /usr/local/bin/host ADMIN_LOW none none

3 /usr/local/bin/isc-config.sh ADMIN_LOW none none

4 /usr/local/bin/nslookup ADMIN_LOW none none

5 /usr/local/bin/nsupdate ADMIN_LOW none none

6 /usr/local/sbin/dnssec-keygen ADMIN_LOW none none

7 /usr/local/sbin/dnssec-makekeyset ADMIN_LOW none none

8 /usr/local/sbin/dnssec-signkey ADMIN_LOW none none

9 /usr/local/sbin/dnssec-signzone ADMIN_LOW none none

10 /usr/local/sbin/named-checkconf ADMIN_LOW none none

11 /usr/local/sbin/named-checkzone ADMIN_LOW none none

12 /usr/local/sbin/rndc ADMIN_LOW none none

13 /usr/local/sbin/rndc-confgen ADMIN_LOW none none

14 /etc/named/* PUBLIC mailconf

N/A N/A


次の属性をサービス用の mailservice プロファイルに追加する。



1 /etc/init.d/sendmail

root (euid)

sys (egid)

N/A N/A all

2 /usr/local/sbin/named

root (uid)

N/A PUBLIC mail PRIVATE mail

file_mac_read net_privaddr sys_net_config sys_suser_compatnet_mac_read net_reply_equal

3 /usr/local/sbin/lwresd

root (uid)

N/A PUBLIC mail PRIVATE mail

file_mac_read net_privaddr sys_net_config sys_suser_compatnet_mac_read net_reply_equal

(3) sendmail

この構成では、外部のネットワークからのアクセスを許可する sendmail と内部の



Trusted Solaris 編


ネットワークからのアクセスのみを許可する/var/spoolが異なるラベルに設定される。

その場合、MTA 機能を果たす sendmail により/var/spool/clientmqueue に一時保存さ

れたデータを、MDA 機能を果たす mail.local が異なるラベルの/var/mail に保存する

ことが必要となる。この結果として実装されるサービスのイメージを示す。

ADMIN_LOW

PUBLIC

ADMIN_HIGH

services

PRIVATE

mail

mailconf

services mail

/var/mail mail.local

/var/spoolsendmail

aliases

syslog etc.

外部からの



内部からの



図 3-35 高度なラベル構成によるサービスのイメージ


サービス提供に関わる次のファイル属性をそれぞれのファイルに適用する。ここ

で/var/spool/mqueue と/var/mail のディレクトリについて、標準のディレクトリを

変更する必要はがないが、標準のでは MLD になっているので、これを SLD に変更す

る場合には、/var/slool/clientmqueue と同じ属性を適用する必要がある。

/var/spool/clientmqueue と/var/spool/mqueue ディレクトリに対しては、

sendmail がアクセスを行うため、sendmaail がプロセスとして動作するときのラベ

ルと同一であることが必要である。また/var/mail ディレクトリおよびその配下の

メールホルダは内部からアクセスされる（通常は POP や IMAP サービスのプロセスに

よりアクセスされる）ため、前者異なるラベルとなる。



Trusted Solaris 編




1 /usr/lib/mail.local ADMIN_LOW none all

2 /usr/lib/sendmail ADMIN_LOW none all

3 /var/spool/clientmqueue PUBLIC mail N/A N/A

4 /var/spool/mqueue MLD（標準） N/A N/A

5 /var/mail MLD（標準） N/A N/A

管理に関わる次のファイルの属性をそれぞれのファイルに適用する。



1 /usr/bin/mail ADMIN_LOW none none

2 /usr/bin/vacation ADMIN_LOW none none

3 /usr/sbin/editmap ADMIN_LOW none none

4 /usr/sbin/mailstats ADMIN_LOW none none

5 /usr/sbin/makemap ADMIN_LOW none none

6 /usr/sbin/praliases ADMIN_LOW none none

7 /usr/lib/smrsh ADMIN_LOW none none

8 /etc/mail/* PUBLIC mailconf N/A N/A


次の属性をサービス用の mailservice プロファイルに追加する。なお、ここでは

sendmailのみの定義を行いmail.localの定義を行わないが、その理由はmail.local

が sendmail から起動されるため sendmail のセキュリティ属性を継承することが可

能であるためである。



1 /etc/init.d/sendmail

root (euid)

sys (egid)

N/A N/A all


smmsp (gid)

PUBLIC mail PRIVATE mail

file_chown file_mac_read net_privaddr proc_setid sys_net_config sys_suser_compatnet_mac_read net_reply_equal

次の属性を管理用の mailcontrol プロファイルに追加する。



Trusted Solaris 編


ここで、sendmail の定義を行っているが、これは、sendmail にシンボリックリ

ンクをしている、newaliases、mailq、hoststats、purgestat を有効にするための

ものである。




N/A PUBLIC mailconf

PUBLIC mailconf

proc_setid sys_suser_compat

2 /usr/sbin/mailstats root (uid)

N/A PUBLIC mailconf

PUBLIC mailconf

N/A

3 /usr/sbin/makemap root (uid)

N/A PUBLIC mailconf

PUBLIC mailconf

N/A

4 /usr/sbin/praliases root (uid)

N/A PUBLIC mailconf

PUBLIC mailconf

N/A

(C) プログラムの修正（mail.local）

高度なラベル構成のネットワークを考慮したした場合、メールのスプールファイ

ルを内部のラベルとして保護するために、mail.local プログラムの修正が必要であ

る。

これは、通常では mail.local は sendmail からセキュリティ属性を継承するため、

そのラベルは[PUBLIC mail]と設定され、/var/mail へ書き込むメールボックスのラ

ベルが[PUBLIC mail]と設定されてしまう。これでは、内部からのアクセス（通常は

POP や IMAP を利用する）により実際にメールボックスの参照はできるが、削除がで

きなくなってしまう。

これを解決するため、mail.local 自信が[PRIVATE mail]で動作するようにプログ

ラムを修正する。つまり mail.local が起動されると同時に自分自信のラベルを

[PRIVATE mail]と設定できるように修正を行う。これにより/var/mail 以下に保存

されるメールボックスは[PRIVATE mail]となり、内部からの POP や IMAP によるメー

ルの参照および削除が可能となる。

なお、この作業は primaryadmin 役割になり、特権シェル環境において実行する

必要がある。

リスト 3-138 mail.local.c の編集

# cd obj.SunOS.5.8.sun4/mail.local # cp mail.local.c mail.local.c.single

mail.local.c の hedeer および mail()部分に次のコードを追加する。



Trusted Solaris 編


リスト 3-139 mail.local:header

#include <tsol/label.h>

リスト 3-140 mail.local：mail()

int tsol_retval, tsol_error, tlength = 0; bclabel_t pcmwlabel; bslabel_t psenslabel; char *tsol_string = "PRIVATE MAIL", *tstring = (char *)0; tsol_retval = stobsl(tsol_string, &psenslabel, NEW_LABEL, &tsol_error); setcsl(&pcmwlabel, &psenslabel); tsol_retval = setcmwplabel(&pcmwlabel, SETCL_SL); printf("setcmwplabel retern = %d¥n", tsol_retval);

変更の際に利用したシステムコールの説明は以下のとおりである。

stobsl() ASCII 表示の SL をバイナリに変換する。

setcsl() バイナリの CMW ラベルの SL を置き換える。

setcmwplabel() プロセスの CMW ラベルをセットする。

また、これをコンパイルするために Makefile を修正する。次のオプションを修

正する。

リスト 3-141 Makefile

LDOPTS= -ltsol

以上で、mail.local.c を構築する準備は完了である。mail.local の再構築を行

う。

リスト 3-142 mail.local.c の Build（primaryadmin 役割）

# cd obj.SunOS.5.8.sun4/mail.local # make # make force-install

再構築した mail.local は、自分自身のラベルを変更するための特権が必要とな

るので、次のファイル属性を mail.local ファイルに適用する。



Trusted Solaris 編


表 3-111 mail.local のセキュリティ属性


1 /usr/lib/mail.local ADMIN_LOW proc_setsl sys_trans_label

all



Trusted Solaris 編


4. 運用

4.1. 本章の目的

本章の目的は、Trusted Solaris 導入する際の留意点、ユーザの意識および OS 標準機能

の監査についてまとめる。また、保護範疇外であるが導入後の運用に関する点も記載する。

4.2. 導入計画

Trusted Solaris は、セキュアな OS である一方、考慮する点いくつか存在する。それら

について、導入におけるメリット・デメリットとして以下に示す。

4.2.1. Trusted Solaris 導入におけるメリット

4.2.1.1. セキュアな OS

Trusted Solaris は、強制アクセス制御、最小特権、Trusted Path 等の機能を持ち、セ

キュア OS としては唯一、Common Criteria の CAPP、RBACPP および LSPP のプロテクション

プロファイルについて EAL4 の認定を取得している。

4.2.1.2. Solaris 互換

Trusted Solaris は、Solaris をベースに開発されている。そのため、コマンド、設定ファ

イル等は非常に Solaris に類似している。また、audit(監査)や RBAC 等 Trusted Solaris

から Solaris に追加された機能も多くある。インストールできるソフトウェアも Solaris

と互換性があり Trusted Solaris 独自の特権や機密ラベルを設定することで利用できるソ

フトウェアも多い。

4.2.1.3. OS サポート

Trusted Solaris は、Sun Microsystems, Inc.が開発、提供している。そのため、購入後

サポート契約を締結すれば製品サポートを受けることができる。また、Trusted Solaris に



Trusted Solaris 編


関する、Discussion Forums 24が用意されており、多くのエンジニアが技術情報を提供して

いる。

4.2.1.4. X-Window

Trusted Solaris は、Solaris 同様 X-Window を利用した CDE 環境を利用できる。Trusted

Soalris の CDE は、機密ラベル、役割へのアサイン、デバイスの割当等いくつかのカスタマ

イズが行われている。しかし、標準の Dt アプリケーションや X-Window を利用するオープ

ンソース等も利用することができる。また、サン・マイクロシステムズ(株)が提供する Thin

Client の SunRay も利用することができる。

4.2.2. Trusted Solaris 導入におけるデメリット

4.2.2.1. 高度な設定技術の要求

Trusted Solaris 導入におけるメリットの 4.2.1.2 Solaris 互換をあげた。確かに、

Solaris にコマンドおよび設定ファイル等は類似している。しかし、Trusted Solaris 上で

単にアプリケーションを構築し動作させるだけでは、セキュアな OS としてあまり意味を持

たない。機密ラベル、最小特権および強制アクセス制御等を正確に理解し適切に設定する

ことではじめてセキュアな OS と呼べるだろう。そのため、セキュリティポリシーなど高度

な設定技術が要求される。

4.2.2.2. 日本語対応

現在、最新版の Trusted Solaris(4/01)は laguge CD が提供されていない。そのため、日

本語による表示、cs00 を利用した日本語入力のみ日本語をサポートしている。普段、Solaris

標準の ATOK や Wnn になれているユーザは、日本語入力に非常に苦労するだろう。また、マ

ニュアルはすべて英語のみ提供されている。

4.2.2.3. アプリケーションサポート

現状、Solaris をサポートしているアプリケーションでも Trusted Solaris になるとサ

ポート外となるケースが多い。そのため、障害が発生した際に原因を解析する作業はユー

ザ側に委ねられる。

24 Discussion Forums http://supportforum.sun.com/cgi-bin/WebX.cgi?/security.trustedsolaris



Trusted Solaris 編


4.3. 信頼性の確保

Trusted Solaris を導入することで信頼性が、ある程度確保することはできるがすべてを

完全に保護することはできない。本章では、Trusted Solaris 導入により保護できるもの、

できないものを明確にし、それらを踏まえた上での基本方針を示す。

4.3.1. 保護対象

Trusted Solaris は、強制アクセス制御、最小特権等の機能を利用している。そのため、

保護できる対象もそれに応じて多くなる。ここでは、保護できる対象を具体的にあげて説

明する。

4.3.1.1. 最小特権による保護

一般の OSでは、システム管理ユーザである rootや administratorが最大限の権限をもっ

ている。そのため、ユーザが任意に設定したファイルパーミッション等も root では変更が

可能である。しかし、Trusted Solaris においては、いくら root といえどもアクセス制御

を無視することはできない。これは、パーミッションを変更するために、特権が必要にな

るからである。この場合においては、特権 file_setdac が必要である。そのため、何らか

の方法で root の権限が奪取されても、root が実行するパーミッションを変更する chmod コ

マンドに file_setdac が付与されていなければ、ユーザが任意に設定したパーミッション

は保護されることになる。しかし、セキュリティ管理者の立場からしてユーザが間違った

パーミッションの設定をしている場合、これをすべてユーザ任せにするのは危険である。

そのため、セキュリティ管理者の chmod コマンドには file_setdac が付与されている。

強制アクセス制御により root ユーザ、一般ユーザ関係なくアクセス制御が実行されるこ

とが理解できたと思う。しかし、特権においてもシステムを乗っ取られる可能性がある。

それは、プロセスに継承可能特権が付与されている場合である。例えば、root で動作して

いるプロセスに継承可能特権として file_dac_write が与えられていたとする。そのプロセ

スのアプリケーションにセキュリティホールが存在し、root の/bin/sh が奪取された場合、

この/bin/sh には file_dac_write が継承される。この場合、このプロセスを乗っ取ること

で、任意アクセスの制御がおこなうことができるようになる。つまり、プロセスに対して

不要な特権は排除し、最小特権を実現する必要がある。また、特権の組み合わせを有効に

利用することでプロセス継承後の特権も最小にすることが可能になる。



Trusted Solaris 編


4.3.1.2. 強制アクセス制御による保護

次に、MAC 機能によって保護できるものを説明する。MAC の機能では、同一 SL のみ読み

込み・書込み可能である25。一方で異なる SL の場合は、優位な SL に対しては、読込み不可・

上書きのみ可、優位でない SL に対しては、読込み可、書込み不可という制限がある。イン

ターネットサーバーにおいて、この制限をすることで保護できるものがある。例えば、Web

サーバーでは、コンテンツや設定ファイル等である。3.5.1 の Web サーバーでも定義したが

Web サーバーのプロセスの SL をコンテンツの SL よりも優位にすることで、Web サーバーの

プロセスからは設定ファイルやコンテンツファイルを読み込むことは可能であるが、万一、

Web サーバーのプロセスを奪取されても設定ファイルやコンテンツファイルの改竄を防ぐ

ことができる26。ただし、一点よく誤解されることがある。それは、優位な SL に対しては

読込み・書込み不可と思われる点である。確かに、読込みは不可であるが、上書きが可能

なのである。つまり優位な SL に対して以下のコマンドは、MAC に関する権限は必要ない 1。

リスト 4-1 上書きの実行

# echo test > test.dat test.dat は、echo のプロセス SL よりも優位な SL

このため、MAC で機密ラベルを変更しているので安全であるというのは間違いである。そ

のままでは、ファイルが改竄される可能性がある。そのため、優位な SL のファイルは DAC

を併用する。ファイルのパーミッションをオーナにおいても読込み不可としておけばファ

イルが変更されることはない。また、バイナリファイル等は、改竄等防ぐためにすべて

SL[ADMIN_LOW]で保存すべきである。その場合もファイルオーナの書込み権は排除すべきで

ある。

4.3.2. 保護非対象

前章では、Trusted Solaris 導入によって保護できるものについて述べた。ここでは、保

護できないもについて検討する。

25 DAC については考慮していない。DAC のパーミッションがない場合は、この限りではない。 26 file_mac_read、file_mac_write は、考慮していない。今回の Web サーバーでは、継承可能特権として

file_mac_read、file_mac_write は付与していない。



Trusted Solaris 編


4.3.2.1. 暗号化

Trusted Solaris は、Solaris をベースにして OS 部分をセキュリティ強化したものであ

るが、アプリケーションレベルにおいては、更なるセキュリティ強化が必要である。まず、

暗号化について述べる。Trusted Solaris においてはネットワーク上を流れるパケットの暗

号化は考慮されていない。そのため、サーバーマシンから管理端末へ telnet、rlogin 等行

なった際、一般的なツールを利用してネットワーク上のパケットをキャプチャしたりする

ことが可能である。ネットワークパケットの暗号化については、Trusted Solaris には、IPsec

が含まれており、プロトコル単位、IP アドレス単位等でパケットを暗号化することができ

る。これは、Solaris とも互換性があるため、Trusted Solaris のみならず、Solaris との

暗号化も利用することができる。

4.3.2.2. ポートスキャン・DOS 攻撃

本ガイドラインに基づきアプリケーションを設定するわかると思うが、inetd 等の設定は

特に Solaris と変わらない。そのため、inetd で動作しているデーモン等は、ポートスキャ

ンの対象となり得る。また、外部のネットワークからの IP アドレスやポートに対する DOS

攻撃も可能である。これらの攻撃から、Trusted Solaris を導入しただけでは守ることはで

きない。もちろん、ポートスキャン等でセキュリティホールが見つかってもそのデーモン

が最小特権で動作していれば被害を最小限にとめることができることは、前章の保護対象

で述べたとおりである。しかし、さらにこれらの攻撃から守るには、従来とおり不要なサー

ビスを止め、必要なサービスに関しては、TCPWrapper や Firewall を導入することが望まし

い。Trusted Solaris 4/01 には、Firewall ソフトとして SunScreen3.2 が含まれている。

インストールマニュアルには、Trusted Solaris におけるインストール方法も明記されてい

るので、是非参考にして頂きたい。

4.3.2.3. パスワードの管理

Trusted Solaris は、RBAC を採用しているため、一般ユーザと管理者が存在する。管理

者が CDE のログイン画面からログインすることはできないが、デフォルトの設定では root

役割には、solaris.login.su 承認が割り当てられているため、Trusted Path が 0(off)でも

スイッチユーザが可能である。通常、Trusted Solaris が 0(off)では権限が付与されたコ

マンドは実行できない。しかし、システムファイルのほとんどが root の所有者になってい

る。そのため、もし一般ユーザルートのパスワードを取得すればシステムファイルを変更

される可能性がある。一般的に、root が持っているプロファイルは、システム設定後、す

べてなくしてしまうのが望ましい。また、不要な承認等も排除すべきである。しかし、原



Trusted Solaris 編


点に戻ると一般ユーザと管理者のパスワードは盗まれないようにするのが最善である。こ

れらは、Trusted Solaris でも保護することはできないので定期的にパスワードを変更する

ことが必要である。

4.3.3. 信頼性確保の基本方針

4.3.1、4.3.2 を踏まえて信頼性確保のための基本方針を以下にしめす。

表 4-1 信頼性確保の基本方針

＃項目内容

1 最小特権プロセスに必要な特権のみを与えて不要な特権は排除すべきである。そのためには、プロセスの振る舞いを正確に把握する必要がある。

2 強制アクセス制御動作するプロセスの機密ラベルと設定ファイル、コンテンツファイル等を隔離すべきである。

3 ファイルパーミッションバイナリファイルは書き込み権必要ないため廃除する

4 暗号化 Trusted Solaris は、デフォルトではネットワークパケットは暗号化しない。必要に応じて、SSL や IPsec 等の導入を検討する

5 パケットフィルタリング・ハードニング

DOS 攻撃の対象となる不要なポートやサービス等は停止すべきである。

6 セキュリティポリシーシステムのセキュリティポリシーを定義する場合は慎重におこなう必要がある。また、定期的なポリシーの見直しは必要である。

7 パスワードの管理 Trusted Solaris がセキュアな OS といえどもパスワードの管理は徹底すべきである。また、定期的なパスワードの変更も必要である。



Trusted Solaris 編


4.4. システム管理

4.4.1. 監査および診断

監査とは、あるイベント(システムコール)レベルでにログとして記録するもの機能である。

この機能を利用すると、ユーザのログイン失敗、パーミッション違反等多くの有効な監査

をおこなうことができる。Trusted Solaris では、標準で Audit(監査)が有効になっている。

ここでは、監査の設定方法、監査結果の解析および対策方法について説明する。

4.4.1.1. ファイル構成

監査で利用するファイル構成を表に示す。

表 4-2 監査のファイル構成

＃ディレクトリファイル備考

1 audit_class イベントをまとめたクラスファイル

2 audit_control システムの監査設定ファイル

3 audit_data 現在の監査ログへのポインタ

4 audit_event 監査イベントファイル

5 audit_statup /etc/init.d/audit から呼び出される監査ポリシーを設定するスクリプト

6 audit_user ユーザ単位で監査をおこなうための設定ファイル

7

/etc/security

audit_warn 警告メールをおくるスクリプト

8 /etc/security/audit * /var/audit へのシンボリックリンク

9 audit 監査デーモンの制御をおこなう

10 auditconfig 監査構成情報を取得したり監査ポリシーを設定するためのコマンド行インタフェース

11 auditreduce 監査ログの評価

12 auditd 監査デーモン

13 auditstat 監査状態を表示

14

/var/aduit

praudit 監査ログの評価

4.4.1.2. 監査クラスと監査イベント

監査クラスと監査イベントファイルは密接な関係で成り立っている。監査イベントファ

イル/etc/security/audit_event には、監査可能なすべてのイベント(システムコール)が記

述されている。以下に、その一部を示す。



Trusted Solaris 編


リスト 4-2 audit_event の一部

0:AUE_NULL:indir system call:no 1:AUE_EXIT:exit(2):pm 2:AUE_FORK:fork(2):ps 3:AUE_OPEN:open(2) - place holder:fa

エントリは以下のようになっている。

リスト 4-3 audit_event の内容

イベント番号：イベント名：イベント説明：イベントクラス

最初のエントリのイベント番号は、一般的に以下の表のようなカテゴリに分類される。

表 4-3 イベントクラスの分類

番号範囲イベントの種類

1-2047 カーネル (システムコール) が生成するイベント

2048-65535 ユーザレベルのイベント

2048-32767 Solaris および Trusted Solaris のユーザレベル用イベント

32768-65536 他社のアプリケーションで使用

次にイベントクラスについて説明する。下記に示すのはイベントクラス

/etc/security/audit_class ファイルからコメント行を除いたすべてである。



Trusted Solaris 編


リスト 4-4 audit_class ファイル

0x00000000:no:invalid class 0x00000001:fr:file read 0x00000002:fw:file write 0x00000004:fa:file attribute access 0x00000008:fm:file attribute modify 0x00000010:fc:file create 0x00000020:fd:file delete 0x00000040:cl:file close 0x00000100:nt:network 0x00000200:ip:ipc 0x00000400:na:non-attribute 0x00001000:lo:login or logout 0x00002000:ax:x server 0x00004000:ap:application 0x000f0000:ad:administrative 0x00010000:ss:change system state 0x00020000:as:system-wide administration 0x00040000:aa:audit administration 0x00080000:ao:other administration 0x00100000:ps:process start/stop 0x00200000:pm:process modify 0x00300000:pc:process 0x01000000:io:ioctl 0x02000000:fn:fcntl 0x04000000:ot:other 0x08000000:xl:X - client login/logout 0x10000000:xp:X - privileged/administrative operations 0x20000000:xc:X - object create/destroy 0x40000000:xa:X - other/allowed information flows 0x80000000:xs:X - operations that always silently fail, if bad 0xf8000000:xx:X - all events 0xffffffff:all:all classes

これらのファイルのフォーマットは以下のとおりである。

リスト 4-5 audit_class の内容

マスク値：クラス名：クラスの説明

マスク値は、符号なし整数として表され、利用できる最大クラス数は 32 である。また、

特別なクラスとして all、no が存在する。all は、監査する全クラスの集合であり、逆に

no は監査しないクラスの集合である。

また、イベントクラスとイベントはクラス名で紐付けされている。例えば、イベント番

号 2 の fork をみて頂きたい。この fork()のシステムコールには、ps のクラスが割り当て

られている。ここで、クラスファイルの ps を参照するとリスト 4-7 のように定義されてい

ることがわかる。



Trusted Solaris 編


リスト 4-6 fork()のイベント

2:AUE_FORK:fork(2):ps

リスト 4-7 ps クラス

0x00100000:ps:process start/stop

4.4.1.3. 監査基本設定

システムの監査設定は、/etc/security/audit_control を編集することでおこなうことが

できる。ここでは、audit_control ファイルの内容について説明する。以下に示すのは、ファ

イルで定義する変数である。

(1) 監査ログの保存場所

監査ログファイルは、デフォルトで/etc/security/audit/<hostname>以下に保存さ

れる。このディレクトリは、/var/audit にシンボリックリンクされている。保存場所

の指定は、以下のように行なう。

リスト 4-8 監査ログの指定

dir:/var/audit

ここで、ログをいくつかのディレクトリで保存する場合は、リスト 4-9 のようにお

こなう。これらは、ディレクトリに対するシンボリックリンクでも構わない。

リスト 4-9 複数の監査ログの指定

dir:/etc/security/<ホスト名>.1 dir:/etc/security/<ホスト名>.2

(2) 監査フラグ

監査フラグは、どのようなイベントを記録するかを定義。ここで定義するのは、イ

ベントクラスの組み合わせである。デフォルトでは、何も定義されていない。以下に

示すのは監査フラグの定義の記述例である。



Trusted Solaris 編


リスト 4-10 監査フラグの指定

flags: -fc,lo

監査フラグで使用する接頭辞には以下の３つがある。

リスト 4-11 監査フラグの説明

+ :成功イベントのみ監査をおこなう - :失敗イベントのみ監査をおこなうなし:イベントの成功、失敗にかかわらず監査をおこなう

また、インバース接頭辞も用意されている。

リスト 4-12 監査フラグ(インバース)の説明

^+ :成功イベントの監査を無効にする。 ^- :失敗イベントの監査を無効にする。 ^ :すべてのイベントの監査を無効にする

例えば、インバース接頭辞を利用すると以下のような条件を満たす監査をおこなう

ことができる。

リスト 4-13 監査フラグのサンプル例

flags:-all,^-fc

これは、-all ですべての失敗イベントを監査するが、̂-fc がセットされているため、

結果はすべての失敗イベントの中でクラス fc で定義される失敗イベントを除外した

ものを監査することになる。

Note: 監査フラグ all は、大量のログファイルを生成する。そのため、ディスクの許容容量を超えてしまうことがある。特別な理由で利用する以外 all フラグは使用しないことを推奨する。

監査フラグとして naflags というのがある。このフラグは、イベントを実行したユー

ザが特定できない場合に、どの監査をおこなうかを定義するものである。監査フラグ

のセットの方法は前述説明したものと同じである。



Trusted Solaris 編


(3) 監査閾値

監査の設定で監査閾値というものが存在する。これは、監査データを保存するディ

レクトリのファイルシステムの空き容量の閾値である。定義は以下のようにおこなう。

リスト 4-14 監査閾値の指定

minfree:20

単位は%である。つまり、監査データの存在するファイルシステムの許容容量が 80%

に閾値を定義していることになる。もし、この閾値を超えた場合、0で示す audit_warn

宛にメールが送られる。

(4) ユーザ別監査

同章の(1)～(3)までの内容は、システム単位の設定であった。つまり、

/etc/security/audit_control で定義される内容はシステムの全ユーザに同設定で有

効である。しかし、ユーザ単位で変更を行ないたい場合やあるユーザのみ個別の設定

を行いたい場合は、/etc/security/audit_user で設定する必要がある。ファイルの

フォーマットは以下のとおりである。

リスト 4-15 audit_user の内容

ユーザ名:ユーザの常時監査フラグ:ユーザの監査回避フラグ

システムの監査フラグとユーザの監査フラグには、以下の関係がある。

リスト 4-16 ユーザ監査フラグ指定時の監査内容

監査内容 = (システムの監査フラグ + ユーザの常時監査フラグ) ユーザの監査回避フラグ

(5) 警告メール

4.4.1.3(3)で説明した監査の閾値でファイルシステムの空き容量が閾値以下になっ

た場合に警告メールが送られる。この警告メールは、audit_warn 宛におくられる。通

常、audit_warn というユーザは存在しないので sendmail 等の alias で定義する必要



Trusted Solaris 編


がある。例えば警告メールを adminuser 宛に送信したい場合には/etc/aliases に以下

のように記述27する。

リスト 4-17 警告メール先の指定

audit_warn:adminuser

4.4.1.4. 監査設定手順

0 をもとに監査の設定手順方法について説明する。Trusted Solaris では、監査設定を行

なうために必要なコマンドを集めたプロファイル Audit Control が用意されている。この

Audit Control プロファイルは、標準では secadmin に割り当てられるため、監査の設定は

secadmin により行なう。

(1) 監査ポリシー

今回、監査を行なうにあたって以下のような監査ポリシーを定義した。

表 4-4 監査ポリシー

監査ポリシー設定内容

監査結果保存先 /etc/security/audit/gpan.128

監査対象ログイン・ログアウトの成功・失敗ファイル属性の変更

監査の閾値 20%

ユーザが分からない場合の監査対象ログイン・ログアウトの成功・失敗

ユーザレベルの監査 root: ファイルの書込み失敗プロセスの起動・停止失敗プロセスの変更失敗 admin、secadmin ファイル属性変更の監査は行なわない

警告メール送信先 admin

27 設定を有効にするためには newaliases を行なう必要がある。 28 通常保存先はホスト名になっている。



Trusted Solaris 編


(2) ポリシー設定

(A) ディレクトリの作成

監査結果を保存するディレクトリ/etc/security/audit/gpan.1 を作成する。作成

は、secadmin によっておこなう。

リスト 4-18 ディレクトリの作成

$ mkdir /etc/security/audit/gpan.1

また、監査結果はすべて[ADMIN_HIGH]の SL で作成されるのでディレクトリも併

せて[ADMIN_HIGH]に設定する。

リスト 4-19 機密ラベルの変更

$ setlabel –s “ADMIN_HIGH” /etc/security/audit/gpan.1

(B) audit_control

(1)の監査ポリシーをもとに secadmin によってポリシー設定を行なう。設定は、

役割 secadmin[admin_low]で行なう。その後、Workspace Menu の中にある

[Applications] – [Application Manager] – [System_Admin] – [Audit Control]をダブルクリックする。すると新規にウィンドウが起動し

/etc/audit/audit_control を vi で編集することができる。

今回行なった設定内容は以下のとおりである。

リスト 4-20 audit_control の内容

dir:/etc/security/audit/gpan.1 flags:lo,fm minfree:20 noflags:lo

Note: secadminでテキストエディタ等で/etc/audit/audit_controlファイルを編集することはできない。これは、secadmin に対してパーミッションがないからである。しかし、Audit Controlプロファイルには、CDE のアクションとして Audit Control が登録されているのでアクションを利用して編集することは可能。



Trusted Solaris 編


(C) audit_user

ユーザ単位の監査設定として/etc/audit/audit_user を編集する。編集は、

audit_control 同様、secadmin によっておこなう。Applications] – [Application Manager] – [System_Admin] – [Audit Users]をダブルクリックすると vi で編集を

することができる。今回設定した内容は以下のとおりである。

リスト 4-21 audit_user の内容

root:-fw,-ps,-pc admin:^fm: secadmin:^fm:

(D) audit_warn

警告メールの送信先を定義する必要がある。これは、/etc/alias を編集すること

で可能である。編集は役割 admin になり SMC を利用しておこなう。SMC にログイン

後[Trusted Solaris Configuration] – [users] – [Mailing Lists]をダブルクリッ

クする。すると、現在設定されている alias の一覧が表示される。そこで、ツール

バーの[Action] – [Add Mailing List]をクリックする。新規に表示されたウィンド

ウで以下のように入力する。

リスト 4-22 audit_warn の設定

Mailing List Name: audit_warn Mailing List Recipients: admin

(3) 監査の再起動

監査の設定ファイルを編集してもそのままでは有効にならない。そのため、変更し

た監査ポリシーを有効にする必要がある。secadmin[admin_high]によって以下のコマ

ンドを実行する。

リスト 4-23 監査の再起動

$ audit –s



Trusted Solaris 編


Note: audit コマンドは、auditd をコントロールするサブコマンドである。これらのオプションには、再起動のほかに以下の２つがある。いずれも secadmin[admin_high]でおこなう必要がある。

リスト 4-24 audit コマンド

監査起動の停止 $ audit -t 新ログファイルの作成 $ audit -n

4.4.1.5. 監査トレールと分析

監査結果(監査ログ)はバイナリフォーマットになっているため、テキストエディタ等で

参照することはできない。しかし、Trusted Solaris には、監査結果のトレールおよび分析

を行なうツールも含まれている。ここでは、その機能について説明する。説明するコマン

ドは、praudit と audittreduce である。これらのコマンドは、Audit Review プロファイル

29に含まれており admin 役割に割り当てられている。

(1) 監査結果(ログ)ファイル

監査結果(監査ログ)ファイルは、audit_control で設定したディレクトリに保存さ

れることは前述説明した。ここで、監査ログファイルについて説明する。まず、現在

書き込み中のログファイルを参照する場合は/etc/security/audit_dataに記述されて

いる。admin 役割になって確認する。

リスト 4-25 現在の監査ログファイル

$ cat /etc/security/audit_data

結果をみると、auditdのプロセスIDと監査結果の保存先を確認することができる。

29 Audit Review プロファイル内の praudit エントリは euid=0 から uid=0 に変更する必要がある。



Trusted Solaris 編


ここで、保存先のファイル名に注目して頂きたい。ファイル名のフォーマットは、以

下の形式になっている。

リスト 4-26 監査ログファイル名の命名規則

audit 開始時刻.audit 終了時刻.ホスト名

つまり、現在の監査結果ファイルは、まだ監査を継続しているため、audit 終了時

刻が not_terminated になっている。システムをリブートしたり、auditd を停止・再

起動したりするとファイルが作成される。

(2) praudit

監査ログを表示するツール praudit について説明する。praudit の使用方法は簡単

で以下のように引数に監査ログファイルを渡すのみである。

リスト 4-27 praudit コマンド

$ praudit /etc/security/audit/gpan.1/20030213102612.not_terminated.gpan

監査ログが存在する場合は、レコードが表示される。このレコードには、トークン

と呼ばれる項目があり、かならず header トークンから始まります。イベントによって、

表示されるトークンは異なる。リスト 4-28 に praudit の-s オプションを指定した際

の表示結果を示す。

リスト 4-28 praudit –s コマンド

file,Mon Feb 24 14:35:08 2003, + 811 msec, header,49,4,AUE_SYSTEMBOOT,na,Mon Feb 24 14:32:28 2003, + 0 msec text,booting kernel host,tsol-default

-s オプションを指定した際は、トークン単位に行で表示するため非常にみやすくな

る。この結果には、このイベントは、AUE_SYSTEMBOOT でシステムが起動した際に発生

したものと考えられる。イベントによって表示されるトークンは異なるが、すべての

レコードは header トークンから始まっていることがわかる。



Trusted Solaris 編


(3) auditreduce

praudit は、監査ログファイル内容をバイナリ形式から ASCII 形式に変換するのみ

だった。しかし、膨大な監査ログファイルの中からあるイベントのレコードを抽出す

るのは大変である。そこで、ここでは auditreduce について説明する。auditreduce

は、多くのオプション機能を持ち様々な監査ログを抽出することができる。このコマ

ンドは、praudit と組み合わせて利用する。基本的な使用法は、以下のとおりである。

リスト 4-29 auditreduce コマンド

$ auditreduce | praudit

このコマンドを実行すると、いままでの監査ログをすべて表示することになる。こ

れでは、大変確認することが困難だと思うので次に便利な利用方法をいくつか説明す

る。

(A) あるユーザのレコードを表示

全監査ログファイルから、あるユーザのレコードを表示する。-u オプションの後

にユーザ名を指定して実行する。

リスト 4-30 auditreduce によるユーザ名の抽出

$ auditreduce –u <uername> | praudit

(B) ある日のレコードのみを表示

全監査ログファイルから、あるユーザのレコードを表示する。-d オプションの後

に yyyymmdd の形式で日付を指定する。

リスト 4-31 auditreduce による日単位の抽出

$ auditreduce –d 20030203 | praudit



Trusted Solaris 編


(C) 日付の範囲を指定して表示

全監査ログファイルから、ある日付の範囲を指定して表示するには、-a と-b の

２つのオプションを組み合わせて利用する。-a オプションは、指定した日付以降の

レコードを表示し、-b オプションは指定した日付以前のレコードを表示する。

リスト 4-32 auditreduce による期間の抽出

$ auditreduce –a 20030203 –b 20030214 | praudit

この表示結果は、2003 年 2 月 3日以降から 2月 14 日以前のレコードを表示する。

(D) ある監査イベント(クラス)のみを表示

/etc/security/audit_event 内の監査イベントを指定して、そのイベントのみの

レコードを表示する場合は以下のようにおこなう。

リスト 4-33 auditreduce によるイベント名の抽出

$ auditreduce –m AUE_LOGIN | praudit

この例では、 AUE_LOGIN イベントのみを表示する。また、同様に

/etc/security/audit_class 内のクラスを指定することもできる。この場合は、-c

オプションを利用する。

リスト 4-34 auditreduce によるクラス名の抽出

$ auditreduce –c lo | praudit

デフォルトでは、クラス名 lo はログイン・ログアウトのイベントをまとめたも

とである。

(E) サマリファイルの作成

監査ログファイルは、監査内容にもよるが日々増大していく。そのため、日に応

じてまたは、ユーザ等に応じてサマリファイルを作成することを推奨する。しかし、

作成の前にサマリファイルを保存するディレクトリを作成する必要がある。作成は、

root 役割で行ないディレクトリの SL を[ADMIN_HIGH]に変更する。これは、



Trusted Solaris 編


auditreduce コマンドが[ADMIN_HIGH]で実行されるためディレクトリのパーミッ

ションがないとファイルを作成することができない。

リスト 4-35 サマリディレクトリの作成

root[ADMIN_LOW]で行なう。 $ mkdir /var/audit_summary secadmin[ADMIN_LOW]で行なう。 $setlabel –s “ADMIN_HIGH” /var/audit_summary

リスト 4-36 サマリファイルの作成

$ auditreduce –a 20030101 –O /var/audit_summary/summary0301

この例では、2003年1月1日から2003年1月31日までの監査ログファイルをファ

イル名/var/audit_summary/audit.20030101-20031031 として保存する。このファイ

ルは、バイナリファイルであるため、内容を参照する場合は praudit を利用する。

このようにサマリファイルを作成するとこの期間のデータは必要なくなる。よって

admin 役割で監査ファイルを削除してもよい。

リスト 4-37 監査ログファイルの削除

$ rm /etc/security/audit/gpan.1/200301*

但し、ファイルを削除した後、auditreduce を利用する場合は、サマリファイル

を指定する必要がある。例えば、2003年 1月 1日から2003年 1月 31日期間内のroot

のレコードを表示する場合は以下のようにおこなう。

リスト 4-38 サマリファイルの参照

$ auditreduce –u root /var/audit_summary/audit.20030101-20031031 | praudit

4.4.2. 保護範疇外の管理指針

Trusted Solaris は、セキュアな OS ではあるが、システムとしての基本的な管理もしっ

かりおこなう必要がある。本節では、保護の範疇外ではあるが、日常の Trusted Solaris



Trusted Solaris 編


における管理作業をあげて説明する。

4.4.2.1. アプリケーション・パッチの追加

Trusted Solais は最小特権の機能を持っており、アプリケーションにセキュリティホー

ルが存在して、問題が発生してもプロセスが保持している特権のみしか継承されないので

被害を最小限に抑えることができる。セキュリティホールが存在するアプリケーションを

動作させるものは気持ちいいものではない。また、管理者として常にセキュリティに気を

配り被害をなくすことが必要である。その他、アプリケーションに必要な機能の追加等が

あった場合、アプリケーションの追加・バージョンアップが必要になる。ここでは、追加・

バージョンアップに加えて OS のパッチ追加の際の管理指針を示す。

(1) アプリケーション

アプリケーションの追加は、基本的には 3.5 節で示したようにセキュリティポリ

シーの定義を行なう必要がある。プロセスに必要な特権を検索しそれらを適切に設定

する必要がある。また、バージョンアップに関しては、アプリケーションのインストー

ラに依存される。多くのオープンソフトは、install コマンドを利用している。この

install コマンドを利用すると所有者、グループおよびパーミッションを併せて設定

することができる。しかし、Trusted Solaris に必要な許容特権、強制特権等は設定

するころができない。そのため、インストール後 setfpriv コマンドで設定をおこなう

必要がある。

Note: ソフトウェアのバージョンアップで既存のファイルを上書きする場合、現在のファイルの特権を保存しておく必要がる。これらは getfpriv コマンドで取得することができる。

(2) パッチ

Trusted Solaris に標準で含まれるソフトウェアパッケージは、パッケージ名は同

じだが Solaris とは異なる。そのため、Solaris のパッチは当てることができない。

Trusted Solaris 専用30のパッチをあてる必要がある。パッチをあてる作業は、通常は

admin 役割によって patchadd コマンドによっておこなう。

30 SunSolve(http://sunsolve.sun.com/)でダウンロードするこができる。



Trusted Solaris 編


4.4.2.2. バックアップ

システムが、ミラーや RAID-5 等の構成になっていてもバックアップは必要である。

Trusted Solaris のバックアップコマンドとして ufsdump、tar、cpio 等が存在する。しか

しながら、Trusted Solaris のファイルシステムは、Solaris 標準の UFS を拡張されている

ため、セキュリティ属性を含めたファイル、ディレクトリおよびファイルシステムをバッ

クアップできるのは ufsdump、tar のみである。ufsdump については特にオプションを指定

することなく、Solaris 同様バックアップを取ることができる。tar に関しては、追加オプ

ションとして-T が用意されている。このオプションを指定して実行するとセキュリティ属

性も含めてバックアップすることが可能である。これらのコマンドは、標準では oper 役割

に割り当てられている。ufsdump で取得したリストアに関しては、ufsrestore によって復

元することができる。

4.4.2.3. OS のハードニング

0 において Trusted Solaris が、DOS 攻撃やポートスキャン等から保護対象外であること

は述べた。通常のインストールを行なっただけでは、利用しないポートが開いていたり、

不要なデーモンが起動していたりする。つまり、これらが DOS 攻撃や、ポートスキャンの

対象になりかねないのである。これらを対処するために Solaris 31Security Tool Kit(通称

JASS)がサン・マイクロシステムズ社から提供されている。サポート対象には、Trusted

Solaris は含まれていないが、適切に設定を行なえば利用することができる。このツールは、

OS インストール後に利用できるが、Jump Start インストール時にも利用することができる。

そのため、OS インストール直後から不要なサービス等は停止することができる。

31 Solaris Security Tool Kit (http://wwws.sun.com/software/security/jass/)



Trusted Solaris 編


5. コスト評価

これまでの章では Trusted Solaris に関する下記の解説を行ってきた。

Trusted Solaris の概念

Solaris との違い

セキュリティ強化されている機能に関する概念

マニュアルからだけではなかなか理解できないセキュリティの概念

構築

セキュリティ強化機能に関する詳細な解説

構築に必要となる知識と注意すべき点

基本的な概念から推奨するべき設定内容

UNIX や Solaris の経験が豊富なユーザにとっては、セキュリティ強化の概念や思想につ

いては、多少なりとも抵抗があったかもしれない。また構築については、特にスーパーユ

ーザが存在しないということが、構築の作業を複雑にするだけでなく、システム内部の動

作やアプリケーションの動作を理解するために、ある意味で厳格なセキュリティの概念や

思想を考えさせられることになったであろう。逆に、歴史的なセキュリティの概念を理解

しているユーザにとっては、Trusted Solaris の概念や思想については、抵抗もなく理解が

できたのではないだろうか。

具体的に、Trusted Solaris の導入、特にインターネットサーバーの構築を検討してい

る方々にとって、「実際にシステムを構築する場合にはどの程度の作業量が要求されるの

か。どのような箇所でつまずくのか。」といったことが定量的に示されていることが望ま

しいであろう。

ここでは、本ガイドラインを利用した場合の作業工数に関するデータを採取し、評価・

分析を行った。基本的に本ガイドラインは、Solaris の基礎知識を有しているユーザを前提

とするため、それぞれのシステム Solaris の未経験者がそれらの習得に要する作業工数に

関しては、本評価分析からは除外している。

5.1. 対象者のスキル

作業工数を評価・分析するにあたり、下記に示すようなユーザを作業対象者とした。



Trusted Solaris 編


Level-A

UNIX の利用者の経験がある

UNIX のインストール経験がある

UNIX のインターネットサーバーの構築経験がある

Level-B

UNIX の業務システムの構築または運用の経験がある

TCSEC など歴史的なセキュリティの概念を理解している

特に Solaris に限定せず、System V 系の UNIX のサーバーについて、運用または構築経験

があるユーザを対象とした。

5.2. 実施手順

作業工数を評価・分析するためのデータ採取は、上記に示した作業対象者に対して表 5-1

に示す手順にて実施した。

表 5-1 作業工数データ採取手順

# 項目説明

1 Trusted Solaris の勉強既存のマニュアル等を利用し作業対象 OS の勉強を行う。 (マニュアルは、http://docs.sun.com/にある Trusted Solaris 8 4/01 のドキュメントを利用した。)

2 システム構築・運用上記で習得した知識を基に作業を行う。インストールセキュリティポリシーの設定運用、監査、アプリの修正・追加

3 ガイドライン本ガイドラインを読み、再度設定等を行う。このとき#2 で行った作業と比較して以下の項目のデータを採取する。設定ミス、設定漏れの項目及び項目数上記ミス・漏れの再設定作業工数ガイドラインを読んでいた場合に短縮できた工数ガイドラインの理解度（A/B/C/D の四段階評価）

5.3. 結果

本節では、実施手順で示した手順に従って得られたデータをまとめる。

作業者のレベルと評価の期間は以下の通りである。



Trusted Solaris 編


Trusted Solaris の勉強：期間 5日（Level-A x 1, Level-B x 1）

Trusted Solaris のインストール

役割の作成

ユーザの作成

システム構築・運用：期間 5日（Level-A x 1, Level-B x 1）

ポリシーの作成

プロファイルの作成

セキュリティポリシーの設定（Apache, BIND-9, sendmail, WU-FTP の構築）

ガイドライン：期間：10 日（Level-A x 4, Level-B x 2）

Trusted Solaris のインストール

役割の作成

ユーザの作成

label_encodings の作成

セキュリティポリシーの理解

セキュリティポリシーの設定（Apache, BIND-9, sendmail, WU-FTP の構築）

5.3.1. 理解度

既存のマニュアルを基に Trusted Solaris を独習した場合と、本ガイドラインを参照し

た場合における Trusted Solaris の理解度はどの程度なのであろうか。理解度に関する調

査結果をに示す。

表 5-2 Trusted Solaris の理解度平均値（Level-A）

# 中項目小項目マニュアル参照 (100%)

ガイド参照 (100%)

1 概念 D( 25%) B( 75%)

2 インストール A(100%) A(100%)

3 カーネルパラメータ D( 25%) C( 50%)

4 プロファイル B( 75%) A(100%)

5 承認 C( 50%) B( 75%)

6 実効属性 D( 25%) B( 75%)

7 特権 D( 25%) C( 50%)

8 ラベル C( 50%) B( 75%)

9

セキュリティポリシー理解

ネットワーク C( 50%) B( 75%)



Trusted Solaris 編


表 5-3 Trusted Solaris の理解度平均値（Level-B）

# 中項目小項目マニュアル参照 (100%)

ガイド参照 (100%)

1 概念 B( 75%) A(100%)

2 インストール A(100%) A(100%)

3 カーネルパラメータ C( 50%) B( 75%)

4 プロファイル A(100%) A(100%)

5 承認 B( 75%) B( 75%)

6 実効属性 B( 75%) A(100%)

7 特権 C( 50%) B( 75%)

8 ラベル A(100%) A(100%)

9


ネットワーク B( 75%) A(100%)

5.3.2. 作業工数

既存のマニュアルを基に Trusted Solaris を独習した場合と、本ガイドラインを参照し

た場合における構築作業を実施した場合の工数はどの程度なのであろうか。作業工数に関

する調査結果をに示す。

表 5-4 構築の作業工数（Level-A）

# 中項目小項目マニュアル参照 (人日)

ガイド参照 (人日)

1 概念 2.0 0.5 2 インストール 0.5 0.5

3 カーネルパラメータ label_encodings 0.5 0.5

4 プロファイル 1.0 0.5

5 承認 1.0 0.5

6


実効属性 2.0 0.5

7 Apache 構築 3.0 1.0

8 BIND-9 構築 2.0 1.0

9 sendmail 構築 2.0 1.0

10

セキュリティポリシー設定

WU-FTP 構築 2.0 1.0

作業工数計 16.0 7.0



Trusted Solaris 編


表 5-5 構築の作業工数（Level-B）

# 中項目小項目マニュアル参照 (人日)

ガイド参照 (人日)

1 概念 0.5 0.5

2 インストール 0.5 0.5

3 カーネルパラメータ label_encodings 0.5 0.5

4 プロファイル 0.5 0.5

5 承認 0.5 0.5

6


実効属性 1.0 0.5

7 Apache 構築 2.0 1.0

8 BIND-9 構築 2.0 0.5

9 sendmail 構築 2.0 1.0

10

セキュリティポリシー設定

WU-FTP 構築 2.0 0.5

作業工数計 11.5 6.0

5.3.3. 設定ミス・設定漏れ

設定ミス・設定漏れについては、マニュアルのみを参照した場合と、ガイドを参照した

場合では、傾向が異なっていた。次にマニュアルのみを参照した場合の設定ミス・作業漏

れ、およびガイドを参照した場合でも共通して発生するミスを示す。

マニュアルのみを参照した場合

label_encodings ファイルを変更しない

Trusted Solarisの標準的なインストールにより有効となるlabel_encodingsファイ

ルはそのまま使うことが可能で、システム上特に問題となることはないため、特にガ

イドラインに示すようなインターネットサーバー専用のものを作成することは、基本

的には必要がないからである。

特権デバッグ後の確認が行えない

特にインターネットサーバーのようなboot時に起動されるプロセスやinetdにより

起動されるプロセスについては、特権デバッグや特権デバッグ後の動作確認には工夫

が必要である。通常の場合は、実行可能ファイル属性として許容特権セットと強制特

権セットを与えることで行おうとするが、これでは exec(2)システムコールなどで派生

する他のプロセスに特権を継承することができず、最終的にサービスが起動できない

場合がある。

共通して発生するミス

特権シェル環境と root 役割の使い分け

Trusted Solaris の緊急利用や開発利用のための primaryadmin 役割は、特権シェル



Trusted Solaris 編


環境を持っているが、これは Solaris でいうところのスーパーユーザと同様の環境を

提供する。しかし root 役割ではコマンドの利用についても SMC のようなツールの利用

についても制限がされている。

admin 役割と secadmin 役割の利用

UNIX の慣習として、全ての管理を root 役割で行いたくなるが、Trusted Solaris で

は管理の殆ど全てを admin 役割と secadmin 役割で行うことになっている。特にセキュ

リティに関する管理は secadmin 役割で行えるようになっているが、これにはある程度

の慣れが必要であるかもしれない。

特権を有効にする設定

特権を有効にするためには、許容特権セット、強制特権セット、継承可能セットの

何れか二つ以上が設定されている必要があるが、特に新たにアプリケーションをイン

ストールした場合では、プロファイルの設定を行ってファイル属性の設定を忘れる場

合がある。

ラベルを変更する設定

必要最小限の特権セットにて、インターネットサービスを通常の IP のクライアント

から利用できるようにする場合、サーバーのサービスおよびクライアントのアドレス

をユーザ許可範囲内の特定のラベルとして設定する必要があるが､何れかの設定が漏

れる場合がある。

管理端末を利用した設定

Trusted Solaris をある程度理解したユーザは、Solaris や Windows 等を利用してリ

モートから管理を考えるであろう。Trusted Solaris では、承認等を設定して Solaris

と同様に一般ユーザでログインし su コマンドで役割に変更することは可能である。し

かし、Trusted Solaris 以外の端末からログインした場合、Trusted Path はオフとな

る。そのため、トラステッドコマンドは実行できない。リモートから管理する場合は、

Trusted Solaris が動作している管理端末を用意する必要がある32。

5.4. 評価・分析

本節では、結果に示した各項目毎に、評価・分析した見解を述べる。

32 SMC(Solaris Management Console)の起動オプションを変更することで、Solaris から Trusted Path を

有効にしログインすることは可能である。



Trusted Solaris 編


5.4.1. 理解度

最初に、扱うユーザのレベルの観点から考察する。Level-A のユーザは UNIX やインター

ネットサーバーの知識があり、また、Level-B のユーザはクリティカルなシステムやセキュ

リティに関する造詣があると考えてよいであろう。

マニュアルの参照の段階では、Level-A のユーザが、「概念」「カーネルパラメータ」、「実

行属性」「特権」に関する理解が難しいことがわかる。それに比べて、Level-B のユーザは、

全体的に理解ができているが、「カーネルパラメータ」「特権」に関しては多少苦労してい

ることが伺える。これらが Trusted Solaris に固有の機能であり、新たな知識として理解

することが必要であったことが原因と考えられる。

ガイドラインを参照した場合には、特に Level-A のユーザが、「概念」「実行属性」につ

いての理解が進んでいる。それに比べて、Level-B のユーザは、ほぼ 100%理解する結果と

なった。これらについては、Level-A のユーザにとっては、新たな知識として理解する必要

があり、Level-B のユーザにとっては、基本的な概念として理解していており、ガイドライ

ンにより一層の理解が進んだことが考えられる。

また、Level-B のユーザにとって、「承認」についての理解が進んでいないが、これは、

「承認」の機能自体が、現在のところ Trusted Solaris の内部のアプケーションに利用さ

れているものであり、特に本調査のようなインターネットサーバーを構築するような一般

的のアプリケーションでは利用されることがなく、本ガイドラインでも簡単な説明程度に

留めているからであろう。

総合評価としては、本ガイドラインでは、Trusted Solaris に関する概念から、構築方法

および運用方法に関する基本的な要素、そしてマニュアルからでは理解が難しい指針や留

意点について解説を行っており、それらが着実に理解度を上げる結果となっていると言え

よう。

理解度が 100%に達しなかった、「カーネルパラメータ」「特権」について、具体的には、

以下が難解であることが原因となっている。

label_encodings の構文

特権の仕組み

label_encodings については、米国防情報局の定義に基づくものであるため、これを理解

することが必要であるが、インターネットサーバーの構築においては、本ガイドラインの

label_encodiings の例は参考になるであろう。また、特権の仕組みについては、複雑に感

じさせるものであるが、プロセスの実行時におけるクレデンシャルやファイル属性の本来

の意味を考察することや、経験によりある程度のパターンを考察することが、理解を進め

る最も良い方法であろう。



Trusted Solaris 編


5.4.2. 作業工数

理解度と同様に、扱うユーザのレベルの観点から考察する。机上での作業中心となる、

概念やセキュリティポリシーの理解、およびマシン上の作業中心となる、ポリシーの設定

に分けて解説する。

概念やセキュリティポリシーの理解

マニュアルの参照の段階では、Level-A のユーザが、「概念」「実行属性」に多くの工数が

とられている。それに比べて、Level-B のユーザは、一様に工数が少なくなっている。この

ことは理解度に応じてのことと考えられる。Level-A のユーザにとっては、新たな概念を理

解するために時間がかかり、Level-B のユーザにとっては、予備の知識があるため理解が早

かったことが考えられる。

ガイドラインを参照した場合には、Level-A および Level-B ともに、各セクションが約

0.5 人日に留まる結果となった。ここで注意すべきことは、マニュアルにおいても概念の解

説がある程度されていることである。マニュアルの参照において、ある程度の概念の理解

ができており、ガイドラインの参照においては、工数をかけずに簡単に読み進むことがで

きたことが考えられる。

セキュリティポリシーの設定

マニュアルの参照の段階では、Level-A のユーザは、Apache の構築に多くの工数がとら

れている。これは、アプリケーションのインストール後、最初に特権デバッグを行わなけ

ればならないが、この場合 Apache の特権デバッグが最初となったため、ここで実行方法や

実行環境を理解するのに工数を要したことが考えられる。

ガイドラインを参照した場合には、Level-B のユーザは、各アプリケーションによる工数

のばらつきがある。これは、アプリケーション自体に依存しているものでと考えられる。

また、セキュリティポリシーの設定において発生した設定ミス・設定漏れについては、

5.3.3 を参照して頂きたい。

総合評価として、本ガイドラインでは、インターネットサーバーの構築の解説として、

基本的で単純なセキュリティポリシーでありながら、Trusted Solaris の機能を十分に利用

する方法についての解説を行っており、概念とセキュリティポリシーの理解においてもセ

キュリティポリシーの設定においても、工数が削減する結果となっていると言えよう。

アプリケーションに依存して構築に要する工数が異なることは、アプリケーションの以

下のようなことを理解する必要があるためである。

ファイル（プログラム、データ、定義ファイル、など）の保存場所

各プログラムの依存（親子関係、兄弟関係、など）の関係

各プログラムの実行時（fork(2)、exec(2)、など）の状態

各プログラムのファイルアクセス時におけるクレデンシャルの状態



Trusted Solaris 編


これらについては、基本的には、特権デバッグによっても、確認することが可能である。

しかし、特にクレデンシャルの変化のタイミングとファイルアクセスのタイミングの前後

関係は、特権の付与の仕方に影響を与えるものであるが、アプリケーションのソースコー

ドがない場合は、ある程度の経験や試行錯誤によって判断せざるを得ない場合がある。

5.5. 結論

明らかにガイドラインによる効果があったと言えよう。ガイドラインにより必要な部分

の知識を効率よく学ぶことができ、また、設定に必要な事項についても効率よく取得する

ことができた。

label_encodings について、ガイドラインではインターネットサーバー用にファイルの作

成を行った。そのため、ファイルの編集に必要な事項に関する解説も行っている。しかし、

Trusted Solaris では標準で、label_encodings のサンプルを提供している。実際のところ、

サンプルをそのまま利用してもインターネットサーバーの構築は可能である。ただし、そ

の場合には、必要でない格付けやコンパートメントが存在し、アプリケーション毎にコン

パートメントを割り当て、それぞれを隔離する設定を行うことは不可能である。

特権の仕組みについて、ガイドラインでは理論的な解説を行っている。また、特権デバッ

グの方法の解説を行っている。実際のところ、特権について理解するにはある程度の経験

が必要であり、特権を有効にする方法についてはアプリケーションに依存するものであり、

これらの特質を理解する必要があるのも事実である。また、ガイドラインではあらかじめ

必要となる特権について特権デバッグにより検出しており、アプリケーション毎に特権検

出をする部分については省略している。

以上のことから、Trusted Solaris を利用して、インターネットサーバーとして理想的な

システム構築を行うには、本書に記載した程度のガイドラインは必要であり、設定の具体

例が示されていることが望ましい、ということが言える。

第Ⅰ編 trusted solaris編 - ipa...(iii) 変更履歴 変更日時 箇条番号 変更内容...

Documents

第Ⅰ編 trusted solaris編 - ipa...(iii) 変更履歴変更日時箇条番号変更内容...