第Ⅱ編 security-enhanced linux 編

第Ⅱ編 Security-Enhanced Linux 編

(i)

目次

1. 本書の概要 ................................................................. 1 1.1. 調査概要 ............................................................... 1 1.2. 調査期間 ............................................................... 1 1.3. 調査対象 ............................................................... 1 1.4. 調査方法 ............................................................... 2 1.5. 想定される読者.......................................................... 3

2. Security-Enhanced Linux の概要 .............................................. 4 2.1. SELinux のセキュリティアーキテクチャ .................................... 4

2.1.1. TE（Type Enforcement）.............................................. 5 2.1.2. RBAC（Role-Based Access Control）................................... 5

2.2. Linux と SELinux のアクセス制御機構の比較 ................................ 6 2.3. SELinux のセキュリティアーキテクチャによる効果 .......................... 8

3. 構築 ...................................................................... 10 3.1. 本章の目的 ............................................................ 10 3.2. インストール........................................................... 11 3.2.1. Red Hat Linux のインストール ....................................... 11 3.2.2. SELinux のインストール ............................................. 12 3.2.3. SELinux 設定の補足 ................................................. 29

3.3. カーネルパラメータ..................................................... 34 3.4. セキュリティポリシーのファイル構成..................................... 35 3.4.1. セキュリティポリシー定義ファイル................................... 35 3.4.2. アプリケーションコンフィギュレーションファイル................... 63 3.4.3. コマンド........................................................... 68

3.5. セキュリティポリシーの定義............................................. 72 3.5.1. Web サーバー ....................................................... 72 3.5.2. DNS サーバー ....................................................... 99 3.5.3. SMTP サーバー ..................................................... 121 3.5.4. FTP サーバー ...................................................... 206 3.5.5. セキュリティポリシーの検証・確認方法.............................. 228

4. 運用 ..................................................................... 243 4.1. 本章の目的 ........................................................... 243 4.2. 導入計画 ............................................................. 243

(ii)

4.2.1. SELinux 導入のメリット・デメリット ................................ 243 4.2.2. 導入システムの留意点.............................................. 245 4.2.3. ユーザの意識管理.................................................. 246

4.3. 信頼性の確保.......................................................... 247 4.3.1. 保護の対象........................................................ 247 4.3.2. 保護の対象外...................................................... 248 4.3.3. 信頼性確保のための方針............................................ 249

4.4. システム管理.......................................................... 250 4.4.1. 監査・診断方法.................................................... 250 4.4.2. アプリケーションの追加・更新...................................... 256 4.4.3. 保護範疇外の管理指針.............................................. 257

5. コスト評価 ............................................................... 262 5.1. 作業対象者のスキル.................................................... 262 5.2. 実施手順 ............................................................. 262 5.3. 結果 ................................................................. 263 5.3.1. 理解度 ........................................................... 263 5.3.2. 作業工数.......................................................... 264 5.3.3. 設定ミス・設定漏れ................................................ 265

5.4. 評価・分析 ........................................................... 267 5.4.1. 理解度 ........................................................... 267 5.4.2. 作業工数.......................................................... 268 5.4.3. 設定ミス・設定漏れ................................................ 269

5.5. 結論 ................................................................. 271

付録 A セキュリティポリシー定義ファイル................................... 272

付録 B 属性一覧 .......................................................... 315

付録 C グローバルマクロ一覧............................................... 318

付録 D その他のマクロ..................................................... 323

(iii)

変更履歴

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

2003/4/14 付録AのA-3　　　　smclient.fc と smclient.te のリストを追加

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

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

Security-Enhanced Linux 編

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

1. 本書の概要

1.1. 調査概要

本ガイドラインは、セキュア OS の１つである Security-Enhanced Linux（SELinux）を利

用してインターネットサーバーを構築する際の理想的な設定・運用指針をまとめたもので

ある。

セキュア OS である SELinux では、システムの運用を開始する前の段階におけるセキュリ

ティポリシーの定義が非常に重要な作業項目である。このセキュリティポリシーの定義に

おいて定義ミスや定義漏れがあったのでは、いくら SELinux といえども高いセキュリティ

を確保することは不可能である。しかし、SELinux に実装されているセキュリティアーキテ

クチャは非常に高度であり、それ故にセキュリティポリシーの定義は非常に複雑である。

加えて、セキュリティポリシーの定義を支援するツールに乏しく、なかなかに導入に踏み

切れないという問題がある。このような実情を踏まえて、SELinux をベースとしたインター

ネットサーバーを構築・運用する際の重要なポイントをまとめたのが本ガイドラインであ

る。また本ガイドラインには、SELinux の難易度・手間・負担といったものを読者に感じ取

らせるという目的も含まれている。

1.2. 調査期間

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

1.3. 調査対象

本ガイドラインは、表 1-1 に示すシステムとバージョンを対象として調査・分析を実施

し、その結果として作成されている。





表 1-1 調査・分析対象システム

システム名バージョン URL

Red Hat Linux バージョン 8.0 http://www.redhat.com/ http://www.jp.redhat.com/

SELinux 2.4 LSM-based Prototype カーネルバージョン 2.4.20 対応版（2003 年 1月 15 日リリース）

http://www.nsa.gov/ http://www.nsa.gov/selinux/

また、調査対象としたインターネットサービスとそのバージョンを表 1-2 に示す。

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

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

1 Web サーバー Apache 2.0.40-8

2 DNS サーバー BIND 9.2.1-9

3 djbdns

daemontools 1.05 0.76

4 SMTP サーバー sendmail 8.12.5-7

5 qmail 1.03-109

6 postfix 1.1.11-5

7 FTP サーバー WU-FTPD 2.6.2-8

1.4. 調査方法

本ガイドライン作成にあたっての調査では、標準、製品情報、およびインターネット上

で入手可能な公開情報による文献調査に加え、SELinux のセキュリティポリシー定義の解

析・修正・新規作成を実施することにより、以下の観点から調査を実施した。

構築面

• セキュリティポリシーを定義する際に必要な基礎知識を明らかとする。

• SELinux に標準で含まれるセキュリティポリシーを解析し、その留意点を明らかと

する。また、標準で含まれないセキュリティポリシーは新たに作成し、その留意

点を明らかとする。

• セキュリティポリシーを定義する際の手順・検証方法・確認方法を明らかとする。





運用面

• SELinux 導入にあたっての留意点を明らかとする。

• SELinux によって確保される信頼性の範囲を明らかとし、その留意点を明らかとす

る。

• SELinux 導入後のシステム管理に関する指針・留意点を明らかとする。

コスト面

• 一般的な Linux によるインターネットサーバー構築経験者が、SELinux を利用して

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

1.5. 想定される読者

本ガイドラインは、セキュアOSであるSELinuxを導入し、同システム上にてインターネッ

トサーバーを稼動させる際の指針をまとめたものである。従って、SELinux のベースとなる

Red Hat Linux あるいは各インターネットサービスのインストール・設定・運用に関しては

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

成されている。

Red Hat Linux を適切にインストールできる

Red Hat Linux や一般的な UNIX システムで利用される各種コマンドを知っている

Red Hat Linux の稼動するシステムにおいてインターネットサーバーを構築できる

Linux カーネルの再構築経験がある

つまり、一般的な Linux システムを利用したインターネットサーバーを構築・運用した

経験のあるシステム管理者レベルの読者を想定している。しかし、SELinux における各種設

定は非常に複雑で、構築対象とするインターネットサービスのプログラム構成、ディレク

トリ構成、あるいはアクセスするファイルとそのアクセス形式といった知識を要求される

ことはもちろんのこと、UNIX システムの構造・仕様に関する知識やプログラマレベルの知

識も要求されることがある。従って、上記に挙げたスキルを有する者であっても難しいと

感じる部分があるかも知れない。このような踏み込んだ部分に関しては、極力脚注等で解

説するように心掛けてはいるが、時には他の文献等を調べる必要が生じるかもしれない。





2. Security-Enhanced Linux の概要

Security-Enhanced Linux（SELinux）とは、一般的な Linux カーネルに対して、セキュ

リティ機能を強化する様々なアーキテクチャを追加するカーネルパッチのことで、米国家

安全保障局（The National Security Agency：NSA）にて開発されている。このように、厳

密にはカーネルパッチに過ぎないわけであるが、このカーネルパッチを適用した Linux シ

ステムを指す言葉として（まるで Linux ディストリビューションの 1つを指すかのように）

「SELinux」という名称が使われることが多い。

本章では、SELinux を導入することによってシステムに追加されるセキュリティアーキテ

クチャを解説する。

2.1. SELinux のセキュリティアーキテクチャ

Linux を含めて一般的な UNIX システムでは、任意アクセス制御（Discretionary Access

Control：DAC）と呼ばれるアクセス制御方式が採用されている。この任意アクセス制御で

は、システムの利用者の管理下にあるユーザ ID、パスワード、あるいはグループ ID といっ

た情報に基づいて、その利用者によるオブジェクトへのアクセスの正当性が判断される。

この任意アクセス制御による制御下において、オブジェクトに対するアクセス制御は、同

オブジェクトの所有者が自由に、つまり「任意」に設定することが許されている。たとえ

ばファイルに対するアクセス権の操作を想像すると分かりやすい。このような任意アクセ

ス制御方式を採用している一般的な UNIX システムでは、システム利用者のユーザ ID とパ

スワードが漏洩してしまった場合の被害は大きいことが容易に想像できる。特に root ユー

ザにはシステムの全権が与えられていることから、root ユーザのパスワードが攻撃者に知

られてしまえば、攻撃者はシステムに侵入してどんなことでもできてしまう。root ユーザ

として正当なユーザ ID とパスワードの組み合わせを提示されたならば、システムはその利

用者が正当であると判断せざるを得ないのである。これに対して、強制アクセス制御

（Mandatory Access Control：MAC）では、たとえば IP アドレスのようなシステム利用者

の管理下にない情報に基づいて、オブジェクトに対するアクセスの正当性を判断するアク

セス制御である。システムにおけるサブジェクトとオブジェクトとの間の関係をセキュリ

ティポリシー1としてあらかじめ定義しておき、システムレベルでそのアクセス制御方針を

強制的に執行するため、たとえ root ユーザであってもそのセキュリティポリシーに反する

1 判りやすく言えば、サブジェクトとオブジェクト間のアクセス許可／拒否を定義する「アクセスルール」

である。





アクセスを実現することは不可能となる。SELinux を導入することにより、この強制アクセ

ス制御機構が実装されるのである。では、強制アクセス制御機構はどのようなアーキテク

チャにより実装されているのか。具体的には以下に挙げるアーキテクチャにより実装され

ている。

TE（Type Enforcement）

RBAC（Role-Based Access Control）

MLS（Multi-Level Security）2

以下では上記の各セキュリティアーキテクチャを解説する。

2.1.1. TE（Type Enforcement）

TE とは、サブジェクトとオブジェクトとの間の関係を規制することによるアクセス制御

アーキテクチャである。システム上に存在し得るすべてのサブジェクトとオブジェクトに

はアクセス制御のためのラベルがアタッチされる。このラベルはセキュリティコンテキス

トと呼ばれ、ユーザ属性、role 属性、type 属性、および MLS に関する情報から構成される

言わばベクタ情報である。ちなみに SELinux では、サブジェクトに対してアタッチされた

セキュリティコンテキストの場合、その構成要素である type 属性は domain 属性と呼ばれ

る3。TE では、サブジェクトにアタッチされた domain とオブジェクトにアタッチされた type

との間の関係に基づいてアクセス制御方針を規定し、システムレベルにてその制御方針を

強制的に執行する。

2.1.2. RBAC（Role-Based Access Control）

RBAC とは、TE により強制的に執行されるサブジェクトとオブジェクトとの間のアクセス

制御に対して、更なる制限を加えるアクセス制御アーキテクチャである。RBAC では role と

いう概念が導入されており、これはその名のとおりシステム利用者の role（役割）を示す

概念として利用される。この role には、TE により許容されるアクセスの一部分をあらかじ

め関連付けておく。極端な言い方をすれば、role とは TE にて許容されるアクセスの部分集

合であると考えると分かりやすいだろう。つまり、TE により許容されたアクセスであって

も、role という視点から見た場合には必ずしも許容されるとは限らないのである。この RBAC

2 SELinux における MLS の実装はまだ試験段階であるため、本ガイドラインでは詳しくは言及しない。 3 SELinux の実装レベルでは、domain 属性と type 属性との間に区別はされていない。





が実装されたシステムの利用者は、常に何らかの role を背負った状態となる。従って、た

とえ TE で許可されているアクセスであっても、彼自身が背負っている役割の範疇外である

アクセスは決して彼に許可されることはない。

2.2. Linux と SELinux のアクセス制御機構の比較

前節では、TEやRBACといったSELinuxのセキュリティアーキテクチャの概要を解説した。

このような個々のアーキテクチャに関する解説を読んでもなかなか判りにくいだろう。そ

こでここでは、TEやRBACといった個々のセキュリティアーキテクチャに関する言及は避け、

通常の Linux のアクセス制御機構と SELinux のアクセス制御機構との比較という観点から

より判りやすく解説する。

ファイル

プロセス

パーミッション

チェック

Linux カーネル

アクセス要求

アクセス許可

実効ユーザID = pu

実効グループID = pg

ユーザID = fu

グループID = fg

-rwxr--r--

図 2.2-1 通常の Linux におけるアクセス制御機構

図 2.2-1 は、通常の Linux におけるアクセス制御機構を示した図である。この図は、あ

るプロセスがあるファイルに対してアクセスを試みている様子を示したものである。プロ

セスがファイルにアクセスを試みた場合、通常の Linux では当該ファイルのパーミッショ

ンがチェックされる。具体的には、当該ファイルの所有ユーザ ID、所有グループ ID、およ

びパーミッション情報に対して、アクセスを試みているプロセスの実効ユーザ ID と実効グ

ループ ID がアクセスを許可されているかどうかがチェックされる。そしてそれがすべてで

ある。このようなアクセス制御機構のため、たとえばプロセスが root 特権を獲得して稼動





している場合（つまりプロセスの実効ユーザ ID が 0、実効グループ ID が 0 の場合）、同プ

ロセスには、システム上のすべてのファイルに対するフルコントロールアクセスが無条

件に許可されていることになる。では、このようなプロセスがバッファオーバーフロー等

による攻撃対象となり、外部の攻撃者による悪意あるプログラムがプロセス内部から実行

されたならばどうなるだろうか。その悪意あるプログラムもまた root 特権を持って起動さ

れるのである。Linux をはじめとした一般的な UNIX システムでは、プロセスはその起動元

である親プロセスの特権を継承するという規則があることが原因である。極端な例かもし

れないが、この悪意あるプログラムがシェルプログラムであったならば、攻撃者は root 特

権のシェルプロセスを獲得できてしまうのである。問題点をまとめると以下のとおりであ

る。

• プロセスが余計な権限を持って稼動している。

• 子プロセスは親プロセスの持つ特権を無条件に継承する。

では、SELinux を導入したシステムはどのように変るのだろうか。図 2.2-2 は、SELinux

におけるアクセス制御機構を示したものである。

ファイル

プロセス

パーミッション

チェック

SELinux カーネル

セキュリティポリシー

チェック

セキュリティコンテキスト



許可されている

読み込み

アクセス要求

アクセス許可

SELinux

セキュリティ

アーキテクチャ

実効ユーザID = pu

実効グループID = pg

ユーザID = fu

グループID = fg

-rwxr--r--

図 2.2-2 SELinux におけるアクセス制御機構

図 2.2-2 を見て判るとおり、通常の Linux におけるパーミッションチェック機構はその

ままに、その手前にセキュリティポリシーによるアクセス制御機構が追加された形となっ

ている。このセキュリティポリシーによるアクセス制御機構では、あらかじめ定義された





アクセスルール（セキュリティポリシー）に従ってプロセスのファイルへのアクセス可否

をシステムが判断しており、この段階ではプロセスの実効ユーザ ID や実効グループ ID と

いった情報は一切関係のないものである。したがって、たとえプロセスの実効ユーザ ID と

実効グループ ID が 0 であったとしても、つまりプロセスが root 特権を持って稼動してい

たとしても、あらかじめ定義されたアクセスルールにおいて、このプロセスが当該ファイ

ルに対するアクセスを許可されていなければ、システムは単純にアクセスを拒否するので

ある。当然、この段階でアクセスが拒否されてしまえば、同アクセス要求はパーミッショ

ンチェックによるアクセス制御機構に降りていくことはない。また SELinux では、セキュ

リティポリシーにて特権の継承が明示的に許可されていない限り、子プロセスが親プロセ

スから特権を継承することはない。したがって、たとえプロセスが外部の攻撃者により乗っ

取られ、同プロセスから悪意あるプログラムが実行されたとしても、親プロセスの特権が

継承されないため、悪意あるプログラムはほとんど何の権限も持たないプロセスとしてし

か起動することができないのである。以上のような特長が、「SELinux では root 特権が廃止

されている」といわれる所以である。ただ厳密には、「root 特権が廃止されている」のでは

なく、セキュリティポリシーを適切に定義することで「パーミッションチェックによるア

クセス制御の手前でアクセスを拒否することが可能である」というのが正しい。この点は

勘違いしないでほしい。

2.3. SELinux のセキュリティアーキテクチャによる効果

TE と RBAC がシステムにもたらす効果は何か。それは権限の細分化である。Linux をはじ

めとした従来の UNIX システムでは、root ユーザにはシステムの全権（root 特権）が与え

られている。そして、管理者がシステムをメンテナンスする場合であっても、何らかのプ

ログラムが一般ユーザ以上の権限を必要とするオブジェクトにアクセスする場合であって

も、この root 特権を獲得するという非常に憂慮すべき状態となっている。システム管理者

やプログラムは、「システムに対する全権」を必要としているわけでない。システム管理者

が日常のメンテナンスの際にアクセスするオブジェクトはごく一部に限られているだろう

し、プログラムであればなおさらである。SELinux であれば、セキュリティポリシーを適切

に定義することにより、ユーザやプログラムのアクセス範囲（権限）を制限することが可

能である。結果として、そのユーザあるいはプログラムは、必要最低限な権限のみが付与

された形となる。プログラムに与えられた権限が必要最低限であれば、プログラムに潜在

する不良を攻撃することでシステムに侵入されたとしても、侵入者はごく限られた範囲で

しか活動できなくなる。このことにより、被害を大幅に減らすことが可能なのである。

現在、名の知れたアプリケーションプログラムのセキュリティホールが日々報告されて

いる。ある程度の規模に達したプログラムに、不良が皆無であることを期待することなど





到底できるものではない。開発者の努力により日々安定性が向上したとしても、バージョ

ンアップ等による大幅な改変時にその安定性は再び地に落とされる可能性もある。システ

ムのセキュリティを向上させる際のアプローチとして、「侵入させない」アプローチは重要

である。現に、これまでの主流はこの形態であった。しかし、「侵入させない」というアプ

ローチは、ウィルス駆除にしろ、IDS にしろ、既知の攻撃に関するデータベースを基準とし

たものであり、未知の攻撃手法には無力である。これからは「侵入されても何もさせない」

というアプローチも重要だろう。そしてこれこそがセキュア OS の導入意義である。





3. 構築

3.1. 本章の目的

本章では、SELinux を利用してインターネットサーバーを構築する場合の、システム設定

やセキュリティポリシー設定に関する留意点をガイドラインとしてまとめる。

本章は「インストール」、「カーネルパラメータ」、「セキュリティポリシーのファイル構

成」、「セキュリティポリシーの定義」、そして「セキュリティポリシーの検証・確認方法」

という項目で構成される。「インストール」では、代表的な Linux ディストリビューション

である Red Hat Linux と SELinux のインストールに関する留意点を記述する。「カーネルパ

ラメータ」では、SELinux カーネルを構築する場合のカーネルパラメータに関する留意点を

記述する。「セキュリティポリシーのファイル構成」では、SELinux のセキュリティポリシー

を設定する上で必要となる、また知っておかなければならない各ファイルの構成やその目

的を説明する。さらに、SELinux で追加・変更されたアプリケーションに関しても説明する。

「セキュリティパラメータの定義」では表 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/

最後に、「セキュリティポリシーの検証・確認方法」ではセキュリティポリシーをどのよ

うに設定し、どのように検証し、そしてどのように確認するかについて説明する。





3.2. インストール

3.2.1. Red Hat Linux のインストール

SELinux は Linux ディストリビューションに依存した構造になっておらず、基本的にファ

イルに設定するセキュリティコンテキストとセキュリティポリシーがあればどの Linux

ディストリビューションでも動作する。ただし、SELinux の開発ベースに Red Hat Linux を

使用していた経緯もあり、本ガイドラインでも Red Hat Linux をベースに説明を行う。現

在では、Debian GNU/Linux 用にもパッケージの作成を行っているプロジェクトも存在し、

SELinux の中心的人物 Russel Coker4氏も Debian GNU/Linux の愛用者である。このため、現

在SELinuxに含まれるセキュリティポリシーやセキュリティコンテキストの設定内容はRed

Hat Linux に合わない部分もあるので設定内容の修正が多少必要である。

Red Hat Linux インストール時に注意しなければならないのは、SELinux をコンパイルし

インストールするための開発環境が必要なことぐらいである。これ以外のハードウェア構

成やディスクのパーティション構成は通常のシステム構築と同じでよい。Red Hat Linux イ

ンストール時のパッケージ選択では「カスタム」を選択し、以下に示すパッケージをイン

ストールしなければならない。

表 3-2 必要なアプリケーション

# 分類パッケージ名内容

1 アプリケーション/パブリッシング texinfo info ファイル作成

2 開発/システム - カーネルヘッダ等

3 開発/ツール - make, autoconf 等

4 開発/ライブラリ - 各種ライブラリ

5 開発/言語 - コンパイラ、perl 等

上記以外のパッケージに関しては、構築するシステムに応じてインストールする必要が

ある。ちなみに、Red Hat Linux 8.0 のパッケージ一覧は Red Hat 社のホームページ5から

参照することができる。

4 http://www.coker.com.au/selinux/ 5 http://www.redhat.co.jp/





3.2.2. SELinux のインストール

3.2.2.1. インストールの概要

SELinux のソースコードは NSA の WEB サイト6からダウンロードする。現在は、安定バー

ジョンである Linux 2.4 系のソースコードと開発バージョンである Linux 2.5 系のソース

コードを取得することができる。SELinux 自身の開発は、常に新しいカーネルのバージョン

に追従しており、約 2ヶ月ごとに更新され、WEB サイトでアナウンス7がある。SELinux をイ

ンストールしようとしているマシンのハードウェアが新しすぎて 2.4 系カーネルでは動作

しないというような特別な理由がない限り、安定バージョンである Linux 2.4 系を選択し

た方がよい。

NSA の WEB サイトで公開されている SELinux のソースアーカイブは、表 3-3 に示すよう

な 5 つの配布形態がとられている。表中の“LSM”とは Linux Security Modules の略で、

Linux カーネルにアクセス制御を組み込むための一般的なフレームワークのことである。こ

の LSM は Linux Security Modules Project8により開発・公開されている。

表 3-3 SELinux のソースアーカイブの配布形態

# 配布形態内容

1 Everything in One Part SELinux を構成するファイルと LSM パッチ適応済みのLinux カーネルを１つのファイルアーカイブとした形式

2 Everything in Two Parts SELinux を構成するファイルと、LSM パッチ適応済みのLinux カーネルのそれぞれを別のファイルアーカイブとした形式

3 Everything but Kernel Source 標準の Linux カーネルに対する LSM パッチ(Linux カーネルのソースファイルは含まれない)と、SELinux を構成するファイルのそれぞれを別のファイルアーカイブとした形式

4 Patches and New Code Only Linux カーネルに対する LSM パッチ、LSM カーネルに対する SELinux のパッチ、ドキュメント類、SELinux のコマンドおよびセキュリティポリシーファイル群、関連コマンドに対するパッチファイル(13 ファイル)をそれぞれ１つずつのファイルアーカイブとした形式

5 All the Patches and New Code Together

#4 の各ファイルアーカイブをさらに一塊にし１つのファイルアーカイブにした形式

ここでいう“SELinux を構成するファイル”とは、LSM に対するカーネルパッチとセキュ

6 http://www.nsa.gov/selinux/ 7 http://www.sna.gov/seilnux/news.html 8 http://lsm.immunix.org/





リティポリシー設定ファイル群や新規に追加されたアプリケーションおよび SELinux 用に

改良した既存のコマンド類の集合を表す。

本章での説明は Red Hat Linux 等のディストリビューションが正しくインストールされ

ていることを前提として、Linux 2.4 系(LSM-2.4)の SELinux をインストールする場合を説

明している。SELinux のインストールや設定に関する説明は、ソースに同梱されている

README ファイルに説明が記述されている。本書はそれに従って説明を行い、付加的な情報

や解説を留意点として記載する。

SELinux のインストール形態には一連の作業を自動的に実行する“Quick Install”と、

個々の作業を１つずつ行う“STEP-BY-STEP BUILDING AND INSTALLING”がある。ここで、

LSM カーネル(SELinux カーネル部分)は/usr/src/lsm-2.4 ディレクトリ下に、セキュリティ

ポリシーや関連コマンドは/usr/src/selinux ディレクトリ下に展開されているものとして

説明を行う。また、以下の説明で記述されているディレクトリまたはファイルのパスは

/usr/src/selinux ディレクトリを起点とした相対パスである。

3.2.2.2. Quick Install

(1) ユーザ定義

Linux システム自身が認識するユーザ(/etc/passwd)以外に、SELinux が認識する

ユーザを定義しなければならない。特に、セキュリティ管理者は必ず設定しなければ

ならない。

設定するファイルは policy/users である。このファイルは標準でリスト 3-1 に示

すような定義がなされている。

リスト 3-1 users ファイルの内容

① user system_u roles system_r; ② user user_u roles user_r; ③ user root roles { user_r sysadm_r }; ④ user jadmin roles { user_r sysadm_r }; ⑤ user jdoe roles { user_r };

①の“system_u”はシステムプロセスおよびシステムオブジェクトの ID で、②の

“user_u”は Linux に定義されているが SELinux では未定義のユーザに対して付与さ

れるIDである。③から⑤の３行はSELinuxが認識するユーザの定義で、それぞれのユー

ザがどのロール(role)になれるかを意味する。“jadmin”と“jdoe”は例として定義さ

れているに過ぎないので削除し、必要なユーザを登録しなければならない。例えばリ





スト 3-2 に示すように変更し、少なくとも一人は管理者権限(sysadm_r)を付与した

ユーザを定義しなければならない(①)。

リスト 3-2 users ファイルの定義例

user system_u roles system_r; user user_u roles user_r; user root roles { user_r }; ① user admin roles { user_r sysadm_r};

(2) ファイルのセキュリティコンテキスト定義

policy/file_contexts/{types.fc,program/*.fc}には、ファイルシステム上の各

ファイルのセキュリティコンテキストが定義されている。types.fc ファイルにはシス

テム共通の定義が記述されており、program ディレクトリ下にはアプリケーションご

との定義が記述されている。これらの設定ファイルに記述されているパス名が、シス

テムを構築しようとしているサーバーの各ファイルのパスに合うように修正しなけれ

ばならない。Red Hat Linux であっても多少異なる部分があるので修正が必要である。

システムで稼動するプログラムとそのプログラムが使用するファイルがどのような種

類(読み込み専用、読み書き等)で、どのパスに位置するかを把握しておく必要がある。

例えば、syslogd に関連する定義は policy/file_contexts/program/syslogd.fc に

定義されている(リスト 3-3 参照)。実行ファイル/sbin/syslogd には syslogd_exec_t

という type が設定されているのが分かる(①)。

リスト 3-3 syslogd のセキュリティコンテキスト

# syslogd /sbin/syslogd system_u:object_r:syslogd_exec_t /sbin/minilogd system_u:object_r:syslogd_exec_t ① /usr/sbin/syslogd system_u:object_r:syslogd_exec_t /dev/log system_u:object_r:devlog_t /var/run/log system_u:object_r:devlog_t /var/run/klogd.pid system_u:object_r:klogd_var_run_t /var/run/syslogd.pid system_u:object_r:syslogd_var_run_t

存在しないプログラムやファイルパスに対する定義は削除してもかまわないが、特

にシステムに支障をきたすわけではないのでそのまま残しておいても問題はない。





(3) X Display Manager

X Display Manager (xdm、gdm、kdm)を使用するような設定(/etc/inittab の runlevel

が 5)になっている場合は、SELinux 用に修正されたディスプレイマネージャ[xdk]dm

が必要である。ただし、NSA からこの修正版は提供されておらず、sourceforge selinux

project9からそのパッチが提供されている。ログイン後 startx で X Windows System

は立ち上げることができるので、特に理由がない限りは起動時に X が立ち上がらない

ように runlevel 3 に設定することを推奨する。

(4) コンパイルとインストール

ここまでの設定が完了したら root ユーザになって“make quickinstall”を実行す

る。カーネルのコンパイルおよびインストール、各種ユーティリティおよび SELinux

用に修正されたプログラムのコンパイルとインストール、セキュリティポリシーのイ

ンストール、セキュリティコンテキストの設定が自動的に行われる。

カーネルのコンパイルにおいては、カーネルコンフィギュレーション(make

menuconfig)が表示されるので、ハードウェア構成等に応じてカーネルの設定を行う。

また、SELinux に関するコンフィギュレーションは最低でもリスト 3-4 に示すような

オプションを設定する必要がある。

リスト 3-4 SELinux に関するカーネルコンフィギュレーション

Networking Options - Network Packet Filtering Security Options - Enable different security models Capabilities Support NSA SELinux Support NSA SELinux Development Support

“make quickinstall”を実行すると以下に示す処理が自動的に実行される。

A) LSM カーネルソースに対する SELinux パッチの適用

B) カーネルのコンフィギュレーション(make menuconfig)

C) カーネルのコンパイル(make dep && make && make modules)

9 http://sourceforge.net/projects/selinux/





D) カーネルのインストール(make install; make modules_install)

E) module ディレクトリ下のコンパイルとインストール(checkpolicy)

F) tools ディレクトリ下でツールに必要なポリシーのインストール

G) policy ディレクトリ下のコンパイルとインストール(ポリシー関連)

H) libsecure ディレクトリ下のコンパイルとインストール(ライブラリ)

I) utils ディレクトリ下のコンパイルとインストール(関連コマンド)

J) selopt ディレクトリ下のコンパイルとインストール(ネットワーク系)

K) tools ディレクトリ下のコンパイルとインストール

L) utils/appconfig/*のインストール

M) setfiles コマンド(ラベル付けコマンド)のコンパイルとインストール

N) セキュリティコンテキスト設定の実行(cd policy && make reset)

ここで注意しなければならないのは D)の処理である。カーネルモジュールをインス

トールする前にカーネルのインストールを行っているため、使用しているディストリ

ビューションによってはエラーになってしまう場合がある。この場合は、再度“make

quickinstall”を実行するか、カーネルのみ手動でインストールしなければならない。

E)の checkpolicy のインストール処理にも問題がある。これは checkpolicy コマン

ドがインストールされると、checkpolicy のセキュリティコンテキストが書き変えら

れ、セキュリティポリシーファイル(/etc/security/selinux/policy.1210)のインス

トール処理でファイルへの書き込み権限がなくなってしまうからである。SELinux を

初めてインストールする場合やシステムを permissive モードで稼動してインストー

ルする場合は問題が発生しないが、enforcing モードでインストール11すると G)のセ

キュリティポリシーのインストール処理でインストール先のポリシーファイルに書き

込みできずにエラーとなり、インストール処理が異常終了してしまうのである。対策

としては、システムを permissive モードにしてインストールを行うか、リスト 3-5

のように checkpolicy インストール後に、セキュリティコンテキストを設定する必要

がある。

10 数字はポリシーDB のバージョン番号 11 既に SELinux が稼動しているので、実際は再インストール（バージョンアップ含む）になる





リスト 3-5 checkpolicy の relabel 処理

cd module/checkpolicy make relabel cd ../..

また、tools のコンパイルでエラーになる場合がある。コンパイルには X Windows

System や tcl/tk 等が必要になるので、詳細は selinux/tools/README を参照のこと。

本ツールが不要の場合は、selinux/Makefile の下記部分(リスト 3-6)を、行頭に“#”

を付けることでコメントアウトすればよい。

リスト 3-6 tools をコンパイルしない場合

# cd tools && make insert-policy # cd tools && make install

3.2.2.3. STEP-BY-STEP

“STEP-BY-STEP”は、“Quick Install”で自動的に処理されたそれぞれの作業を個別に

手作業で行うインストール形態である。

(1) パッチの適応

LSM カーネルに SELinux のパッチを適用する。これは最初に１回行えばよい。カー

ネルにパッチが当たっているかどうかを確認するには、/usr/src/lsm-2.4/Makefile

の EXTRAVERSION 変数を確認し、これが“-selinux”になっていれば適用済みである。

パッチが当たってない場合は“-lsm1”となっている。

パッチを当てる場合は、selinux ディレクトリ直下で“make insert”を実行する。

README ファイルには module ディレクトリに移動後“make insert”を実行と記述さ

れているが、selinux ディレクトリ直下の Makefile には二重実行を回避するための処

理が入っているので、再度パッチを適用しないようにするために selinux ディレクト

リ直下で実行することを推奨する。

パッチファイルは、Linux 2.4 系カーネル用として selinux-2.4.patch ファイルが、

Linux 2.5 系用として selinux-2.5.patch ファイルが module ディレクトリ下に格納さ

れている。





(2) カーネルのコンパイル

カーネルのコンパイルの手順としては、まず、カーネルのコンフィギュレーション

をシステムのハードウェア構成等に合わせる設定を行う。

リスト 3-7 カーネルのコンフィギュレーション

cd ../lsm-2.4 make menuconfig

SELinux 関連のコンフィギュレーションも“Quick Install”の場合同じようにリス

ト 3-8 のオプションを選択する。

リスト 3-8 SELinux に関するカーネルコンフィギュレーション

Networking Options - Network Packet Filtering Security Options - Enable different security models Capabilities Support NSA SELinux Support NSA SELinux Development Support

次にカーネルのコンパイルを行う。実行例を、リスト 3-9 に示す。

リスト 3-9 カーネルのコンパイル方法

make dep make make modules

(3) カーネルのインストール

これも通常の Linux カーネルのインストールと同じである。その実行例をリスト

3-10 に示す。





リスト 3-10 カーネルのインストール方法

su (root ユーザでない場合) cd ../lsm-2.4 ① make modules_install ② make install cd ../selinux

README ファイルには、①の処理(モジュールインストール)と②の処理(カーネルの

インストール)が逆に記述してあるが、ディストリビューションによってはエラーにな

る場合があるので、①を先に実行した方がよい。カーネルインストール後、必要に応

じてブートマネージャ LILO(/etc/lilo.conf)または GRUB(/boot/grub/menu.lst)の設

定を行う(詳細は(17)を参照のこと)。

(4) SELinux モジュールのコンパイルとインストール

次に、SELinux のビルドに必要なプログラムのコンパイルとインストールを行う。

現時点では、checkpolicy コマンド(セキュリティポリシー定義の文法的なチェックと

それをバイナリデータにコンパイルを行うコマンド)のみがこのディレクトリ下に組

み込まれている。リスト 3-11 はそのインストール方法である。

リスト 3-11 SELinux モジュールのインストール

su (root ユーザでない場合) cd modules make install ① make relabel cd ..

3.2.2.2 の Quick Install にも記述したが、SELinux を enforcing モードで再インス

トールする場合、checkpolicyコマンドのセキュリティコンテキストが書き変えられ、

これが原因でセキュリティポリシーファイルのインストール処理が失敗してしまう。

これを回避するために①のコマンドを実行して checkpolicy のセキュリティコンテキ

ストの設定を行う必要がある。

(5) ユーザ定義

Quick Install の 3.2.2.2(2)を参照のこと。





(6) X Display Manager


(7) ツール用のセキュリティポリシーのインストール

2003011510 版で、Tresys Technology 社が開発したセキュリティポリシー設定ツー

ルが SELinux のソースツリーにマージされた。ツールの詳細機能に関しては、

tools/README ファイルおよび tools/setools/README ファイルを参照のこと。本ツー

ルを使用する場合はこの段階でツール用のセキュリティポリシーをインストールする

必要があるが、使用しない場合はこのステップはスキップしてもよい。リスト 3-12

はその実行方法である。

リスト 3-12 ツール用セキュリティポリシーのインストール

cd tools make insert-policy cd ..

(8) セキュリティポリシーのインストール

セキュリティポリシーのビルドとインストールを行う。リスト 3-13 は、セキュリ

ティポリシーのインストール方法である。

リスト 3-13 セキュリティポリシーのインストール

cd policy su (root ユーザでない場合) make install-src install cd ..

セキュリティポリシー関連のソースファイルは/etc/security/selinux/src/policy

ディレクトリ下にコピーされる。インストール後、セキュリティポリシーやファイル

コンテキストの修正が必要な場合は、このディレクトリ下で作業を行うことになる。





(9) libsecure ライブラリのインストール

SELinux関連のシステムコールや関数群のライブラリとヘッダファイル(インクルー

ドファイル)のビルドとインストールを行う。このヘッダファイルとライブラリは、以

降で説明するアプリケーションと SELinux 用に修正されたコマンド類の中で使用され

ており、それらのコンパイル時に使用される。リスト 3-14 は libsecure 関連のビル

ドとインストールの実行例である。

リスト 3-14 libsecure 関連のインストール

cd libsecure make su (root ユーザでない場合) make install cd ..

(10) アプリケーションのインストール

ユーザ認証やセキュリティコンテキスト、セキュリティ ID を操作するために

SELinux用に修正・追加されたアプリケーションのビルドとインストールを行う。utils

ディレクトリ下には表 3-4 に示すようなアプリケーションがあり、リスト 3-15 に示

す実行例でこれらのアプリケーションがインストールされる。





表 3-4 アプリケーション一覧

# パッケージ名内容

1 fileutils-4.1 ls、cp、mv、rm 等のファイル操作コマンド群

2 findutils-4.1.7 find、locate、xargs コマンド

3 logrotate-3.6.5 logrotate コマンド

4 newrole newrole コマンド(SELinux 独自コマンド)

5 openssh-3.4p1 OpenSSH 関連

6 procps-2.0.7 ps、vmstat、top、kill、sysctl 等のプロセス関連コマンド群

7 psmisc-20.1 fuser、killall、pstree コマンド

8 run_init run_init コマンド(SELinux 独自コマンド)

9 sh-utils-2.0.11 basename、date、echo、env 等の一般コマンド

10 spasswd passwd や vipw のためのラッパーコマンド

11 stat-2.5 stat コマンド

12 strace-4.4 strace コマンド

13 tar-1.13.25 tar コマンド

14 util-linux-2.11f login コマンド

15 vixie-cron-3.0.1 cron 関連コマンド

これらのアプリケーションは、主に/usr/local/selinux ディレクトリ下にインス

トールされるが、login、SSH 関連、crontab、crond、logrotate コマンドは/bin、/usr/bin、

/usr/sbin 下にそれぞれインストールされる。

リスト 3-15 SELinux 関連アプリケーションのインストール

cd utils make su (root ユーザでない場合) make install cd ..

(11) ツール類のインストール

ツール類(現段階では、Tresys Technology 社のポリシー設定ツールのみ)を使用す

る場合は、ここでツールのビルドとインストールを行う。リスト 3-16 はその実行例

である。





リスト 3-16 ツールのインストール

cd tools make su (root ユーザでない場合) make install cd ..

ツールを使用しないのであればインストールする必要はない。

(12) Labeled Network

ネットワークのパケットにラベルを付加してセキュアなネットワークを構築する機

能が実装されている。しかし、本機能はまだ実験的な段階である。本機能に関するコ

マンド類のビルドとインストールを行う。リスト 3-17 にその実行例を示す。

リスト 3-17 ラベル付きネットワーク関連アプリケーションのインストール

cd selopt make su (root ユーザでない場合) make install cd ..

本機能を使用しないのであればインストールする必要はない。

(13) セキュリティ関連ファイル

以下に示す utils/appconfig ディレクトリ下のファイルを/etc/security ディレク

トリ下にコピーする。

1. default_contexts ・・・login、ssh、cron のデフォルトコンテキスト

2. default_type ・・・各ロールのデフォルトのタイプ

3. initrc_context ・・・init スクリプトのセキュリティコンテキスト

4. passwd_context ・・・/etc/passwd のセキュリティコンテキスト

5. shadow_context ・・・/etc/shadow のセキュリティコンテキスト





(14) ラベルマッピングファイルの削除

LSM バージョンでない SELinux(初期の SELinux は LSM をベースとしていなかった)

を立ち上げていた場合には、ファイルとセキュリティコンテキストのマッピング情報

が格納されているラベルマッピングファイルをファイルシステム上から削除しなけれ

ばならない。このファイルは、各ファイルシステムのルートディレクトリ下の

“...security”サブディレクトリに格納されている。ラベルマッピングファイルを削

除する例をリスト 3-18 に示す。

リスト 3-18 既存ラベルマッピングファイルを削除する例

rm -rf /...security /boot/...security /home/...security

(15) ファイルのセキュリティコンテキスト定義


(16) セキュリティコンテキストの設定

まず、各ファイルにセキュリティコンテキストを設定するプログラム setfiles のビ

ルドとインストールを行う。リスト 3-19 はその実行例である。

リスト 3-19 setfiles プログラムのインストール

cd setfiles make su (root ユーザでない場合) make install cd ..

setfiles プログラムのインストールが完了したら、リスト 3-20 に示すような方法

でセキュリティコンテキストの初期化と設定を行う。使用しているマシンやディスク

性能およびディスク上のファイル数にもよるが、全ファイルの設定を行うのに数分か

ら 20 数分程度かかる場合がある。





リスト 3-20 セキュリティコンテキストの初期化と設定

cd policy make reset cd ..

(17) ブートマネージャの設定

SELinux のカーネルは通常/boot ディレクトリ下に“vmlinuz-2.*.*-selinux”とい

うファイル名でインストールされるので、自システムのブートマネージャの環境に合

わせて設定を行う。

LILO を使用している場合は、/etc/lilo.conf にエントリを追加して lilo コマンド

を実行する。リスト 3-21 は lilo.conf ファイルに設定する場合の例である。ここで、

カーネルのファイル名は“vmlinuz-2.4.20-seilnux”、ルートデバイスは、IDE のプラ

イマリ・マスタに接続されたディスクのパーティション 2(/dev/hda2)としている。

リスト 3-21 LILO の設定例

image=/boot/vmlinuz-2.4.20-selinux label=2420-selinux read-only root=/dev/hda2 append="hdc=ide-scsi"

GRUB を使用している場合は、/sbin/new-kernel-pkg スクリプトや/sbin/grubby コ

マンドを使用して登録を行う。リスト 3-22 に GRUB による実行例を示す。

リスト 3-22 GRUB の設定方法の例

/sbin/new-kernel-pkg –install 2.4.20-selinux または /sbin/grubby --add-kernel=/boot/vmlinuz-2.4.20-selinux --copy-default ¥

--make-default --title "SELinux"

リスト 3-23 は、grub.conf(menu.lst)の設定例である。





リスト 3-23 grub.conf の設定例

title Red Hat Linux (2.4.20-selinux) root (hd0,0) kernel /vmlinuz-2.4.20-selinux ro root=/dev/hda2 initrd /initrd-2.4.20-selinux.img

(18) セキュリティコンテキストの再設定

システムをリブート後、ファイルのセキュリティコンテキストの再設定を行わなけ

ればならない。これは、セキュリティコンテキストの設定後システムをリブートする

間に変更や追加・削除されたファイルがあると、それらのファイルにセキュリティコ

ンテキストが正しく反映されないため、それらのファイルに対してセキュリティコン

テキストを正しく再設定する必要があるからだ。

まず、セキュリティ管理者(ロールが sysadm_r、ドメインが sysadm_t のユーザ)権

限でログインする。リモートからログイン(telnet、ssh)した場合は、newrole コマン

ドで管理者権限を取得することができる。次に、システム管理者が root でない場合は、

su コマンドで root ユーザになる。

policy ディレクトリ下に移動し、“make relabel”を実行することにより各ファイ

ルシステム下のファイルにセキュリティコンテキストを再設定することができる。リ

スト 3-24 はその実行方法である。

SELinux でない普通の Linux を立ち上げてしまった場合は、その間に作成・変更・

削除されたファイルのセキュリティコンテキストに不整合が発生している可能性があ

る。この場合も、再度 SELinux を立ち上げた後に“make relabel”を実行し、セキュ

リティコンテキストを再設定する必要がある。

リスト 3-24 セキュリティコンテキストの再設定

cd policy su (root ユーザでない場合) make relabel cd ..

ファイルのセキュリティコンテキストが正しく設定されていない場合に、システム

を enforcing モードで立ち上げると、マルチユーザモードに移行するときに実行され

るプログラムやデーモン類の起動が失敗し、システムが立ち上がらなくなる場合があ

るので注意が必要である。permissive モードでシステムを立ち上げて、セキュリティ





コンテキストの再設定を行ったほうがよい。

(19) PATH 環境変数の設定

SELinux 用に追加・修正されたアプリケーションは、/usr/local/selinux/bin と

/usr/local/selinux/sbinディレクトリ下にインストールされる。これらのアプリケー

ションを使用するために PATH 環境変数にこれらのディレクトリを追加する。

リスト 3-25 に示すように/bin や/usr/bin ディレクトリ下に置かれているコマンド

と同じ名称のプログラムもある。このため、PATH 環境変数にこれらのディレクトリを

設定する場合は、SELinux 用のパスを先に定義しなければならない。

リスト 3-25 SELinux 用のアプリケーションの一部

/usr/local/selinux/bin: avc_enforcing df lchsid newrules.pl sid_to_context svipw avc_toggle dir list_sids ps spasswd tar chcon dircolors load_policy pstree stat vdir checkpolicy find ls runas strace chsid flmon mkdir sadminpasswd strace-graph chsidfs id mkfifo schfn suseradd context_to_sid install mknod schsh suserdel cp killall newrole setfiles svigr /usr/local/selinux/sbin: ct pt qt run_init scmpd

(20) セキュリティポリシーの再設定

policy ディレクトリ下のセキュリティポリシー設定ファイルを変更し、システムに

その情報を反映するには、“make load”または“make reload”を実行する。両者に大

きな違いはないが、“make load”はセキュリティポリシーファイルに変更がない場合

にはポリシーの反映は実行されず、“make reload”の場合は設定ファイルの変更有無

にかかわらずポリシーが起動中のカーネルに再度反映される。

セキュリティコンテキストを変更した場合は、(18)に記述したように“make

relabel”を実行するか、chcon コマンドで個別に設定することができる。リスト 3-26

は/etc/crontab ファイルに対し“system_u:object_r:system_crond_script_t”とい

うセキュリティコンテキストを設定する例である。





リスト 3-26 chcon コマンドの実行例

chcon system_u:object_r:system_crond_script_t /etc/crontab

システムが enforcing(セキュリティ執行)モードで稼動しているときにセキュリ

ティポリシーの再設定やセキュリティコンテキストの再設定を行うには、セキュリ

ティ管理者(ロールが sysadm_r でドメインが sysadm_t)の権限が必要である。





3.2.3. SELinux 設定の補足

Red Hat Linux 8.0 に SELinux をインストールする場合、標準で添付されているセキュリ

ティポリシーやセキュリティコンテキストの設定内容だけでは問題が発生する。

本節では、問題となる事象を説明し、追加すべきセキュリティポリシーやセキュリティ

コンテキストをまとめる。

3.2.3.1. rc スクリプトのセキュリティコンテキスト

SELinux 付属の rc スクリプトに関連したセキュリティコンテキスト設定は、ファイル

file_contexts/program/initrc.fc においてリスト 3-27 のように定義されている。

リスト 3-27 rc スクリプトのセキュリティコンテキスト

/etc/rc.d/rc system_u:object_r:initrc_exec_t /etc/rc.d/rc.sysinit system_u:object_r:initrc_exec_t /etc/rc.d/rc.local system_u:object_r:initrc_exec_t /etc/init.d/rc.* system_u:object_r:initrc_exec_t

しかし、Red Hat Linux では/etc/rc.d/init.d ディレクトリ下に rc スクリプトファイル

の実体が配置され、/etc/rc.d/rc?.d ディレクトリ下にはそれら実体へのシンボリックリン

クが配置されている。このため、リスト 3-27 のファイルパス指定では、rc スクリプトに

設定されるべきセキュリティコンテキストである initrc_exec_t が設定されずに代りに

etc_t が設定されてしまう12。rc スクリプトは、この etc_t が設定された状態であってもシ

ステム起動時には正しく起動されるのだが、SELinux 独自コマンドの run_init では

enforcing モード時に etc_t タイプの実行権限がないため、スクリプトを起動できない。

対策として、ファイル file_contexts/program/initrc.fc にリスト 3-28 に示すような設

定が必要である。

12 ファイル file_contexts/types.fc において、ディレクトリ/etc 下のサブディレクトリとファイルには

一旦 etc_t が設定されるように定義されている。





リスト 3-28 rc スクリプト用の追加セキュリティコンテキスト

/etc/rc.d/(.*).d/.* system_u:object_r:initrc_exec_t

3.2.3.2. xinetd の rc スクリプト

xinetdの rcスクリプトにはリスト 3-29に示すようなコードが含まれている。ここでは、

コメントからも分かるように/etc/passwd ファイルに対して書き込み権限のチェックを行

い、root ユーザか否かのチェックを行っている。

リスト 3-29 xinetd の rc スクリプトの一部

# Check that we can write to it... so non-root users stop here [ -w /etc/passwd ] || exit 1

SELinux 環境下でこの部分が実行されるとリスト 3-30 に示すようなエラーが発生する。

当然であるが enforcing モードで実行した場合 xinetd が起動されない。

リスト 3-30 rc スクリプト実行時のエラー

avc: denied { write } for pid=15254 exe=/bin/bash path=/etc/passwd dev=09:00 ino=37046 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:etc_t tclass=file

この問題を解決するには/etc/passwd への書き込み権限を“initrc_t”ドメインに許可す

る必要があるが、その対象となるファイルの type は“etc_t”である。“etc_t”は/etc ディ

レクトリ下のほとんどのファイルに付与される type のため、この１行の処理のためだけに

initrc_t に権限を与えるのは危険であると判断する。解決策としては、/etc/passwd 以外

で initrc_t ドメインに書き込み権限があり一般ユーザからは書き込み権限のないファイル

に変更することである。リスト 3-31 にその変更例を示す。





リスト 3-31 rc スクリプトの変更例

# Check that we can write to it... so non-root users stop here [ -w /var/log/messages ] || exit 1

3.2.3.3. crontab のセキュリティコンテキスト

Red Hat Linux でのユーザの crontab ファイルは/var/spool/cron ディレクトリ直下に作

成される。しかし、SELinux 付属のセキュリティコンテキスト設定では、ファイル

file_contexts/program/crond.fc においてリスト 3-34 に示すようなファイルパス

(crontabs ディレクトリ下に作成)になっているため、セキュリティコンテキストが正しく

設定されない。

リスト 3-32 ユーザ crontab ファイルのセキュリティコンテキスト設定内容

/var/spool/cron system_u:object_r:cron_spool_t /var/spool/cron/crontabs system_u:object_r:cron_spool_t /var/spool/cron/crontabs/.* system_u:object_r:user_cron_spool_t /var/spool/cron/crontabs/root system_u:object_r:sysadm_cron_spool_t

解決方法は、ファイル file_contexts/program/crond.fc に対してリスト 3-33 に示すセ

キュリティコンテキストの設定を追加することである。

リスト 3-33 追加のセキュリティコンテキスト設定

/var/spool/cron/.* system_u:object_r:user_cron_spool_t /var/spool/cron/root system_u:object_r:sysadm_cron_spool_t

また、crontab 関連で問題になるのはシステムの crontab である“/etc/crontab”を編集

する場合である。エディタ(vi)で直接編集を行うとファイルのセキュリティコンテキスト

が変更されてしまい、cron ジョブが起動されなくなる。ファイル編集後、リスト 3-34 の

ように chcon コマンドでセキュリティコンテストを元に戻さなければならない。





リスト 3-34 /etc/crontab のセキュリティコンテキスト

chcon system_u:object_r:system_crond_script_t /etc/crontab

/etc/crontab だけに限らず、アプリケーションに固有な type が設定されているファイル

の場合は、そのセキュリティコンテキストが変更されたことで不適切な type が設定された

状態になるとシステムに支障をきたす恐れがある。

この問題を回避するために、リスト 3-35 に示すようなシェルスクリプトを用意しておく

と便利である。①、②で対象ファイルのセキュリティコンテキストをセーブする。③で vi

コマンドを起動してファイルを編集する。vi が終了すると、④で chcon コマンドを使用し、

セーブしておいたセキュリティコンテキストを設定する。同時に１つのファイルしか編集

できないが有用である。

リスト 3-35 コンテキストを元に戻すシェルスクリプト

#!/bin/sh if [ $# != 1 ] then echo Usage : $0 file exit 1 fi FILE=$1 if [ ! -w ${FILE} ] then echo No write permission exit 1 fi ① set -- `/usr/local/selinux/bin/ls --context $1` ② SID=$4 ③ vi $FILE ④ chcon $SID $FILE

3.2.3.4. コンソールでの make relabel の注意点

コンソールからセキュリティコンテキストの再設定“make relabel”を実行すると、tty

デバイス(/dev/tty?)のセキュリティコンテキストがリセットされ、種々のコマンドでメッ

セージの出力が表示されなくなる。このような状態になった場合は、ログアウトし再度ロ

グインすればよい。





3.2.3.5. ntp.conf

NTPの時間誤差値を格納するファイル(/etc/ntp.confの driftfileパラメタ)のデフォル

トは/etc/ntp/drift となっている。また、このファイルには書き込み権限も必要である。

SELinux に標準で提供されている NTP 関連のセキュリティコンテキストファイル

(file_contexts/program/ntp.fc)は、リスト 3-36 のようになっており、var_lib_ntp_t に

対して書き込み権限を許可している。

リスト 3-36 ntp のセキュリティコンテキスト設定の一部

/var/lib/ntp(/.*)? system_u:object_r:var_lib_ntp_t

リスト 3-36 のファイルパスを“/etc/ntp(/.*)?”に変更する方法もあるが、一般的に/etc

下のファイルに書き込み権限を与えるような設定は望ましくない。対策としては、

/etc/ntp.conf の設定をリスト 3-37 のように変えるべきであろう。

リスト 3-37 /etc/ntp.conf の設定例

# ntp.conf server www.xxx.yyy.zzz driftfile /var/lib/ntp/drift





3.3. カーネルパラメータ

SELinux に関連したカーネルパラメータのトップカテゴリは“Security Options”で、こ

のオプションを選択するとセキュリティに関するパラメータを設定することができる。

表 3-5 に SELinux 固有のカーネルパラメータを示す。まず、#1 の“Enable different

security models”を有効にすることにより全体のパラメータを表示することができる。

表 3-5 SELinux 固有のカーネルパラメータ

# カーネルパラメータ説明

1 Enable different security models デフォルトで Linux に組み込まれているセキュリティ機能以外のセキュリティモデルを有効にする

2 Capabilities Support Linux カーネルで提供されている Linux Capability 機能を有効にする

3 NSA SELinux Support SELinux の機能を有効にする

4 NSA SELinux Development Support SELinux を開発モードで構築する。このオプションを有効にすると、システムはセキュリティポリシーが執行されない「許可モード(permissive)」で起動され、コマンドを使用して「執行モード(enforcing)」に切り替えることができる。

5 NSA SELinux MLS policy MLS(Multi-Level Security)機能を有効にする

6 NSA SELinux extended socket calls 拡張 socket 関数を有効にする

7 Labeled IP Networking Support ラベル付きネットワーク機能を有効にする。

8 CIPSO/FIPS-188 IP Options #6 のサブオプションとして CIPSO13/FIPS-18814を有効にする。

表 3-5 のオプション以外には、Openwall プロジェクト15が提供しているセキュリティ関

連の機能、Domain And Type Enforcement For Linux16および LIDS17の機能を有効にすること

ができる。

システムを構築する上で必須のオプションは、#1、#2、#3、#4 である。これ以外の機能

は、まだ実験的な段階であり、当該機能に関するドキュメントやセキュリティポリシーの

設定例に関する情報が少ない。また、これらの機能は「セキュアなインターネットサーバー

の構築」には必須な機能ではないので、本ガイドラインでは言及はしない。

13 COMMERCIAL IP SECURITY OPTION 14 Federal Information Processing Standards Publication 188 15 http://www.openwall.com/ 16 http://www.cs.wm.edu/~hallyn/dte/ 17 Linux Intrusion Detection System http://www.lids.org/





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

本章では、SELinux におけるセキュリティポリシー定義ファイルの配置位置とそのディレ

クトリ構造を解説し、その後、各セキュリティポリシー定義ファイルにおける定義内容の

概要とセキュリティポリシー定義書式を解説する。また後半では、セキュリティポリシー

を操作する上で重要となる各種のコマンドに関しても解説を行う。

3.4.1. セキュリティポリシー定義ファイル

SELinux には標準のセキュリティポリシー定義が含まれている。これらは一般的な Linux

システムで通常インストールされているプログラムや、Apache、sendmail といった多くの

ユーザによって利用されているプログラムのためのセキュリティポリシー定義から構成さ

れている。SELinux を通常とおりインストールした場合、標準のセキュリティポリシー定義

ファイルはディレクトリ/etc/security/selinux/src/policy 下にインストールされる。

SELinux インストール後のセキュリティポリシーの変更は、このディレクトリ下にインス

トールされた各種ファイルを操作してシステムに適用することになる。表 3-6 にディレク

トリ/etc/security/selinux/src/policy 下の様子を示す。





表 3-6 /etc/security/selinux/src/policy 下の様子

＃ファイル/ディレクトリ説明

1 Makefile セキュリティポリシーをコンパイル・インストール・反映するための Makefile

2 README ディレクトリ/etc/security/selinux/policy 下の各設定ファイルの説明が記述されているドキュメントファイル

3 assert.te アクセスベクタアサーションを定義するファイル

4 attrib.te 属性を定義するファイル

5 constraints constraint を定義するファイル

6 domains/ domain を定義するファイルが格納されているディレクトリ

7 file_contexts/ ファイルにアタッチするセキュリティコンテキストを定義するファイルが格納されているディレクトリ

8 fs_use オブジェクトにアタッチするセキュリティコンテキストの決定方法をファイルシステムごとに指定するファイル

9 genfs_contexts fs_use ファイルで定義可能なセキュリティコンテキスト決定方法ではサポートできないファイルシステムに関するセキュリティコンテキスト決定方法を指定するファイル

10 initial_sid_contexts 初期 SID コンテキストを定義するファイル

11 macros/ マクロを定義するファイルが格納されているディレクトリ

12 mls MLS に関する設定が記述されているファイル

13 net_contexts ネットワーク関連オブジェクトにアタッチするセキュリティコンテキストを定義するファイル

14 policy.conf セキュリティポリシーのコンパイル時に生成されるファイル。定義されている全てのセキュリティポリシーが本ファイルに集約される。

15 rbac role の遷移許可ルールを定義するファイル

16 tmp/ セキュリティポリシーのコンパイル時に生成されるテンポラリファイルが格納されるディレクトリ

17 types/ 特定の domain と関連性のない一般的な type を定義するファイルが格納されているディレクトリ

18 users ユーザを登録するファイル

以下では、SELinux における各種セキュリティポリシー定義の説明および定義方法を解説

する。また、それらのセキュリティポリシー定義とセキュリティポリシー定義ファイルと

の関連性を解説する。なお、以後セキュリティポリシー定義ファイルを本文にて指し示す

際には、ディレクトリ/etc/security/selinux/src/policy に対する相対ディレクトリとし

て表現する。また、定義書式の解説では BNF 記法を用いるが、共通で登場する BNF 記法は

あらかじめここで示しておくことにする。





identifier ::= 識別文字列 identifier_list ::= identifier | identifier_list identifier set ::= '*' | identifier | '{' identifier_list '}' | '~' identifier | '~' '{' identifier_list '}'

3.4.1.1. マクロの定義

SELinux におけるセキュリティポリシー定義では、GNU m4 マクロプロセッサ18によるマク

ロがサポートされている。マクロにはセキュリティポリシー定義ファイルを簡潔化するこ

とができるという利点がある。実際、SELinux に標準で用意されているセキュリティポリ

シー定義では非常に多くのマクロが定義されて利用されている。しかし、マクロ化されて

いることにより見通しが悪くなっている部分があるのも事実である。標準で用意されてい

るセキュリティポリシー定義を適切に理解するためには、また、自身で新たにセキュリティ

ポリシーを定義する場合にも、マクロの種類とその定義内容をはじめに十分に理解してお

く必要がある。

マクロを定義する際の書式に関しては、GNU m4 マクロプロセッサのドキュメント19等を参

照してほしい。

関連ファイル

domains/admin_macros.te 管理者ユーザ domain を定義するためのマクロが定義されているファイル

domains/global_macros.te クラスの集合、パーミッションの集合、および domain の遷移や type の遷移等の汎用的なマクロが定義されているファイル。本ファイルで定義されているマクロの概要は付録の表C-1 と表 C-2 を参照してほしい。

domains/program/*.te 各アプリケーションプログラム固有のマクロを定義しているファイル

domains/user_macros.te ユーザ domain を定義するためのマクロが定義されているファイル

3.4.1.2. 属性の定義

SELinux のセキュリティポリシー定義には属性と呼ばれる概念が存在する。属性とは具体

的には type に付与するものであり、属性を付与することによって type にその属性の持つ

18 http://www.gnu.org/software/m4/m4.html 19 http://www.gnu.org/manual/m4/index.html





性質を与えることができるというものである。書式をリスト 3-38 に示す。

リスト 3-38 属性の定義書式

‘attribute’ attr_name ‘;’ attr_name ::= identifier

このように定義することで、「attr_name」で示される属性名を定義することができる。

ちなみに、属性には以下に挙げる大きく 2つの用途が存在している。

• type に汎用的なアクセスベクタルールを関連付ける

• type をグルーピングする

1 つめの用途に該当する属性には、セキュリティポリシー定義ファイルにおいて定義され

ている何らかのアクセスベクタルールが関連付けされている。そして、この属性を付与さ

れた type にもその属性に関連付けされているアクセスベクタルールが適用されることにな

る。つまり、多くの type が必要とするような汎用的なアクセスベクタルールを一箇所で定

義・管理するための用途である。

2 つめの用途に該当する属性は、単にその属性名を定義されているに過ぎない。この用途

の属性は付与した type を括る目的で利用されるものである。SELinux のセキュリティポリ

シー定義では type を指定する箇所で代わりに属性名を指定することが許されている。属性

名が指定されると、セキュリティポリシーコンパイラはその属性が付与されたすべての

type に展開してコンパイルを実行する。つまり、type 定義時に同一の性質を有する type

をグルーピングするラベルとして属性を付与しておくことで、ある性質を有する type に対

するアクセスベクタルールを簡単に定義できるわけである。属性のこの用法は非常に多く

利用されているので重要である。

デフォルトで定義されている属性の一覧は付録の表 B-1 を参照してほしい。

関連ファイル

attrib.te 属性名を定義するファイル

3.4.1.3. TE の定義

このセクションでは、TE に関連するセキュリティポリシー定義を解説する。





(1) domain と type の定義

TE では、サブジェクトにアタッチされている domain とオブジェクトにアタッチさ

れている type を基準にアクセス制御が行われる。そこでまずは、アタッチする type

と domain を定義しなければならない。書式をリスト 3-39 に示す。

リスト 3-39 domain および type の定義書式

‘type’ type_name opt_alias_def opt_attr_list ‘;’ type_name ::= identifier opt_alias_def ::= ‘alias’ aliases | empty aliases ::= identifier | ‘{‘ identifier_list ‘}’ opt_attr_list ::= ‘,’ attr_list | empty attr_list ::= identifier | attr_list ‘,’ identifier

このように定義することで、「type_name」で示される名称の type を定義することが

できる。またこの際、「opt_alias_def」で示される別名を付与することや、

「opt_attr_list」で示される属性を付与することが可能である。属性に関しては

3.4.1.2 を参照してほしい。

SELinux ではサブジェクトにアタッチする type を domain と呼んでいるが、実装レ

ベルではこの domain と type を区別して扱っているわけではなく、domain は「サブジェ

クトにアタッチされた場合に必要となる各種アクセス権限を有した type」という扱い

に過ぎない。プロセスやユーザにアタッチされる domain には、ファイル等のオブジェ

クトにアタッチされる type と比較して余計な幾つかのアクセス権限が必要となるこ

とは想像に難しくないだろう。domain として必要となるアクセス権限は属性「domain」

として定義されており、domain を定義する場合には上記書式にて属性「domain」を付

与する形で定義すればよいのである。

type には、特定の domain と関連のある type、つまり特定のプロセスによってのみ

アクセスされるファイル等のオブジェクトにアタッチする type と、特定の domain と

は関連のない type、つまり様々なサブジェクトによってアクセスされ得るオブジェク

トにアタッチする type の 2 通りが存在し、これらは定義場所が異なっているので注意

が必要である。





Note：「ユーザ domain を追加する場合は」

ユーザ domain を追加する場合には、通常マクロ「user_domain」20あるいは「admin_domain」21を利用する。

マクロ「user_domain」は一般ユーザ用の domain を、マクロ「admin_domain」は管理者ユーザ用の domain を

定義するマクロである。ユーザ domain を新たに定義する場合、login プログラムが shell プログラムを実行

した際に開始される shell プロセスに対して同ユーザ domain をアタッチするための domain 遷移ルールや、

この domain 遷移を許可するために、login プログラムにアタッチされる role である「system_r」に対して

同ユーザ domain を割り当てる必要がある（3.4.1.4(1)を参照）。上記のマクロでは、ユーザ domain として不

可欠なこれらのセキュリティポリシーを一括して定義してくれる。

関連ファイル

domains/下の*.te ファイル特定の domain と関連付けられる type の定義

types/*.te 特定の domain と関連付けられない type の定義

macros/下の*.te ファイルマクロの中で定義されている場合もある

(2) domain 遷移ルールおよび type 遷移ルールの定義

3.4.1.3(1)では domain と type の定義方法を説明した。しかし、これはあくまで定

義に過ぎない。定義した domain と type は各々、サブジェクトとオブジェクトにアタッ

チしなければならない。これを定義するのが domain 遷移ルールと type 遷移ルールで

ある。

domain 遷移ルールは新たに開始されるプロセスに対してアタッチする domain を定

義するものである。Linux ではその起動時にシステムによって「init プロセス」と呼

ばれるプロセスが開始される。この init プロセスはシステムで最もはじめに開始され

るプロセスで、その後システム上で開始されるあらゆるプロセスの先祖となるプロセ

スである。つまり、システム上で開始されるプロセスにはすべて親プロセスが存在す

ることを意味している22。domain 遷移ルールではこの起動元プロセス（親プロセス）

にアタッチされている domain と起動されるプロセスの実行ファイルにアタッチされ

ている type を基準として、新たに開始されるプロセスにアタッチする domain を指定

する。

type 遷移ルールは新たに作成されるオブジェクトに対してアタッチする type を定

義するものである。この type 遷移ルールは実態のない抽象的なオブジェクトや、実態

のあるオブジェクトであっても常に存在するとは限らないオブジェクトに対してtype

をアタッチするためのものである。たとえば、プログラムが稼動時に一時的に作成す

20 マクロファイル macros/user_macros.te にて定義されている。 21 マクロファイル macros/admin_macros.te にて定義されている。 22 init プロセスは唯一親プロセスの存在しない特別なプロセスである。





るテンポラリファイルを考えてみる。ファイルというオブジェクトはファイルシステ

ム上で実態のある存在ではあるが、テンポラリファイルの場合、常にファイルシステ

ム上に存在しているとは限らないため、あらかじめ type をアタッチしておくことがで

きない23。このようなオブジェクトの場合、そのオブジェクトの作成元であるサブジェ

クトにアタッチされている domain やその他の関連のあるオブジェクトにアタッチさ

れている type を基準として、新たに作成されるオブジェクトに対してアタッチする

type を定義しなければならない。

書式をリスト 3-40 に示す。

リスト 3-40 domain 遷移ルールおよび type 遷移ルールでの定義書式

‘type_transition’ source_types target_types ‘:’ classes new_type ‘;’ source_types ::= set target_types ::= set classes ::= set new_type ::= identifier

この書式の意味は以下のとおりである。

23 ファイルシステム上に常に存在しているファイルに関しては、あらかじめ type をアタッチしておくこと

が可能である。恒久的なファイルに対する type のアタッチに関しては 3.4.1.7 にて解説している。





「source_types」で示される domain がアタッチされているサブジェクトが、

「target_types」で示される type のアタッチされた、「classes」で示されるサブ

ジェクトあるいはオブジェクトを生成した場合、生成されるサブジェクトあるいは

オブジェクトに対して「new_type」で示される domain あるいは type をアタッチす

る。

- 補足 -

domain 遷移ルールの場合、「source_types」には起動元プロセスにアタッチされている domain を、

「target_types」には新たに開始するプログラムの実行ファイルにアタッチされている type を、

「classes」にはプロセスを示す class である”process”を指定する。

type 遷移ルールの場合、「source_types」には作成元プロセスにアタッチされている domain を、

「target_types」には新たに作成されるオブジェクトに関連のあるオブジェクトにアタッチされ

ている type を、「classes」にはその関連オブジェクトの種類を示す class を指定する。

上記に示した type_transition 宣言は domain あるいは type の遷移を許可するだけ

であり、実際に遷移を実現するために必要となる幾つかのアクセス権限は与えられな

いため、この宣言に加えてそれらのアクセス権限を与えるセキュリティポリシー定義

が必要となることに注意しなければならない。これらのアクセス権限は多岐にわたる

ため、遷移ルールを定義するためのマクロ24が用意されており、通常はこのマクロを使

用するべきである。

domain 遷移ルールを定義しない場合、新たに開始されるプロセスには開始元である

親プロセスの domain が引き継がれてアタッチされる。同様に、type 遷移ルールを定

義しない場合、新たに作成されるオブジェクトには同オブジェクトと関連を持つオブ

ジェクトの type が引き継がれてアタッチされる。

なお、domain遷移ルールはRBACにより更に制限を受ける。domain遷移ルールとrole

との関係は 3.4.1.4(1)にて解説する。

24 domain 遷移ルールを定義するためのマクロ「domain_auto_trans」、ファイルにアタッチする type を定

義するためのマクロ「file_type_auto_trans」等が定義されている。





関連ファイル

domains/下の*.te ファイル domain と type の遷移は必ず domain がその発端となるものである。従って、通常は domain が定義される場所で定義される。


(3) type 変更ルールの定義

3.4.1.3(2)で解説した type 遷移ルールは新たに作成されるオブジェクトに対して

アタッチする type を定義するものである。これに対して、既に何らかの type がアタッ

チされているオブジェクトの type を変更することを許可するのがこの type 変更ルー

ルである。書式をリスト 3-41 に示す。

リスト 3-41 type 変更ルールの定義書式

‘type_change’ source_types target_types ‘:’ classes new_type ‘;’ source_types ::= set target_types ::= set classes ::= set new_type ::= identifier


ドメイン「source_types」がアタッチされているサブジェクトが、タイプ

「target_types」のアタッチされている、「classes」で示されるオブジェクトの type

を「new_type」で示される type に変更することを許可する。

この type 変更ルール定義は type の変更を許可するだけである点に注意が必要であ

る。3.4.1.3(2)にて解説した type 遷移ルールは必要なアクセス権限を定義してやるこ

とで、定義された遷移ルールはカーネルによって適宜執行される。しかし、この type

変更ルールを執行するのはカーネルではなくプログラムである。SELinux ではセキュ

リティコンテキストを変更するための独自のシステムコールが実装されており、この

システムコールを利用するアプリケーションに対して、その type 変更を許可するのが

この type 変更ルール定義である。つまり、この定義ルールは SELinux 向けに改良され





た、あるいは SELinux 向けに作成されたプログラムとの組み合わせで意味を持つもの

である。

関連ファイル

domains/下の*.te ファイル type の変更は必ず domain がその発端となるものである。従って、通常は domain が定義される場所で同時に定義される。


(4) アクセスベクタルールの定義

SELinux では独自の各種パーミッションが定義されており、オブジェクトのクラス

ごとにこれらのパーミッションの部分集合が定義されている。このクラスごとに定義

されたパーミッションの集合はアクセスベクタと呼ばれる。アクセスベクタルールは

特定の domain がアタッチされたサブジェクトと特定の type がアタッチされたオブ

ジェクトとの間で許可するパーミッションの集合を定義するもので、このパーミッ

ションの集合はそのオブジェクトのアクセスベクタの部分集合となる。書式をリスト

3-42 に示す。

リスト 3-42 アクセスベクタルールの定義書式

avc_kind source_types target_types ‘:’ classes permissions ‘;’ avc_kind ::= ‘allow’ | ‘auditallow’ | ‘dontaudit’ source_types ::= set target_types ::= set classes ::= set permissions ::= set

avc_kind が’allow’の場合、上記書式の意味は以下のとおりである。

ドメイン「source_types」がアタッチされたサブジェクトに、タイプ「target_types」

のアタッチされた、「classes」で示されるオブジェクトに対する、「permissions」

で示されるパーミッションを許可する。

SELinux ではこのアクセスベクタルールにて明示的にアクセスを許可しない限り、





いかなるアクセスもシステムによって拒否される。逆に言えば、許可するアクセスは

すべてこのアクセスベクタルールで定義しなければならないということである。

アクセスベクタルールで明示的に許可されていないアクセスが発生した場合、シス

テムはそのアクセスに関する情報をログとしてファイル/var/log/messages に出力す

る。つまり、システムによって拒否されたアクセスがあった場合にログが出力される

わけだが、逆にシステムによってアクセスが許可された場合にログを出力したい場合

がある。この場合には、上記の書式の avc_kind にて’auditallow’を利用すればよい。

また、システムによってアクセスが拒否された場合のログ出力を行わせたくない場合

には、’dontaudit’を利用して該当するアクセスを指定すればよい。

Note：「dontaudit の使い方」

アクセスが拒否された場合のログを出力したくないケースなど果たしてあるのだろうか。標準のセキュリ

ティポリシーを眺めていると、この dontaudit 宣言が利用されている箇所を時々目にする。実は、アプリケー

ションの中にはバグや実装上の問題等により、その動作に不要と思われる余計な権限を要求するようなオペ

レーションを起こすものが存在する。アプリケーションが正常に稼動するのであれば、SELinux としては当

該権限を与えるべきではないが、この場合常にアクセス拒否のログが出力されることになる。このような承

知済みのログは出力させたくないだろう。このような場合に、dontaudit 宣言は有用である。

関連ファイル

domains/下の*.te ファイル domain あるいは type が定義されている箇所で定義される場合

macros/下の*.te ファイルマクロの中で定義されている場合

types/*.te type が定義されている箇所で定義される場合

(5) アクセスベクタアサーションの定義

決してアクセスを許可してはいけないアクセスルールを明示的に定義しておくこと

ができる。これがアクセスベクタアサーションの定義である。このアクセスベクタア

サーション定義にて明示的に定義されたアクセスルールがセキュリティポリシー定義

ファイルにてアクセスを許可する形で定義された場合、セキュリティポリシーコンパ

イラによってエラーが出力される。プログラムのためのセキュリティポリシーを新た

に定義する場合などは、誤ったセキュリティポリシー定義をしてしまわないためにも、

まずアクセスベクタアサーションの定義からはじめるように心掛けるのも良いことで

ある。書式をリスト 3-43 に示す。





リスト 3-43 ファイル assert.te での書式

‘neverallow’ source_types target_types ’:’ classes permissions ‘;’ source_types ::= set target_types ::= set classes ::= set permissions ::= set


ドメイン「source_types」がアタッチされたプロセスには、タイプ「target_types」

のアタッチされたオブジェクト「classes」に対するパーミッション「permissions」

を決して許可してはいけない。

関連ファイル

assert.te アクセスベクタアサーションを定義するファイル

3.4.1.4. RBAC の定義

このセクションでは RBAC に関連するセキュリティポリシー定義を解説する。

(1) role の定義

RBAC によるアクセス制御アーキテクチャにおいてユーザに割り当てる role を定義

する。書式をリスト 3-44 に示す。

リスト 3-44 role の定義書式

‘role’ identifier ‘types’ types ‘;’ types ::= set






「identifier」で示される role が未定義であれば定義し、同 role に対して「types」

で示される domain への domain 遷移を許可する。

この role 宣言では先の定義内容を後の定義内容が上書きすることはない。リスト

3-45 とリスト 3-46 に示す定義はどちらも同じセキュリティポリシー定義を意味する。

リスト 3-45 role 定義形態その 1

role system_r types { ftpd_t getty_t };

リスト 3-46 role 定義形態その 2

role system_r types ftpd_t; role system_r types getty_t;

「role を定義する」と捉えるよりも、「role に、遷移を許可する domain を割り当て

る」と捉える方が分かりやすいだろう。そして、「その際はじめて登場した role であ

れば定義も行われる」のである。重要なのは、「許可する遷移先 domain を割り当てる」

ことなのである。3.4.1.3(2)で domain 遷移ルールの定義を解説したが、domain 遷移

ルールが定義されていたとしても、その遷移先の domain が role に対して許可されて

いない限り、この role を割り当てられたユーザがその domain 遷移を実現することは

許されない。

role に対する遷移先 domain の割り当ては domain と domain 遷移ルールを定義した

箇所で随時行われているため、role 定義文はセキュリティポリシー定義の各所で目に

することになる。





Note：「新たな role を定義する場合は」

新たに role を定義して同 role でログインするユーザを用意する場合には、login プログラムにアタッチさ

れている role である「system_r」が、新たに定義した role に遷移することを許可する必要がある。role 遷

移許可の定義に関しては 3.4.1.4(2)を参照してほしい。

関連ファイル

domains/下の*.te ファイル role の定義あるいは遷移先 domain の割り当て

macros/下の*.te ファイル同上

types/下の*.te ファイル同上

(2) role 遷移許可の定義

role 属性は domain や type と同様に遷移ルールをサポートしている。role の遷移を

許可する際の書式をリスト 3-47 に示す。

リスト 3-47 role 遷移許可の定義書式

‘allow’ current_roles new_roles ‘;’ current_roles ::= set newroles ::= set


「current_roles」で示される role が、「new_roles」で示される role へ遷移する

ことを許可する。

domain 遷移ルールは 3.4.1.4(1)で説明したとおり RBAC により制限を受けるが、こ

の role 遷移ルールは RBAC による制限を受けることはない。代わりに 3.4.1.5 で説明

する constraint による制限を受ける。SELinux の標準セキュリティポリシー定義にお

いて role 遷移ルールが定義されている箇所はごく僅かである。

関連ファイル

rbac role 遷移許可の定義





(3) role 遷移ルールの定義

role 遷移ルールはあるプログラムの実行時に、新たに開始されるプロセスにアタッ

チする role を定義するものである。書式をリスト 3-48 に示す。

リスト 3-48 role 遷移ルールの定義書式

‘role_transition’ current_roles types new_role ‘;’ current_roles ::= set types ::= set new_role ::= identifier


「current_roles」で示される role が、「types」で示される type がアタッチされ

ている実行ファイルを実行して開始されたプロセスには「new_role」で示される

role をアタッチする。

上記書式の遷移先 role として指定可能な role は、3.4.1.4(2)における role 遷移許

可定義にて許可されている role に限られる。role 遷移ルールを明示的に定義しない

場合、新たに開始されたプロセスには開始元プロセスにアタッチされている role が引

き継がれてアタッチされる。

なお、開始されたプロセスにおいてアクセス権限を自動的に変更させる方法として

は、role はそのままに domain のみを遷移させる形式が適切であるため、この role 遷

移ルールは将来サポートから外されることになっている。

関連ファイル

SELinux の標準セキュリティポリシー定義では利用されていない。

3.4.1.5. constraint の定義

constraint とは TE と RBAC によるアクセス制御に加えて更に詳細なレベルでのアクセス

制御を定義することが可能なアクセス制御アーキテクチャである。TE ではサブジェクトと





オブジェクトにアタッチされているセキュリティコンテキストの構成要素である type 属性

（サブジェクトの場合は domain 属性）を基準としたアクセス制御である。これに対して

constraint では、セキュリティコンテキストを構成する type 以外の属性、つまりユーザ属

性や role 属性もアクセス制御の基準として利用することが可能である。書式をリスト 3-49

に示す。

リスト 3-49 ファイル constraints での書式

‘constrain’ classes permissions expression ‘;’ expression ::= ‘(‘ expression ‘)’ | not expression | expression and expression | expression or expression | U1 op U2 | U1 op users | U2 op users | R1 role_op R2 | R1 op roles | R2 op roles | T1 op T2 | T1 op types | T2 op types U1：サブジェクトにアタッチされているセキュリティコンテキストのユーザ属性 R1：サブジェクトにアタッチされているセキュリティコンテキストのロール属性 T1：サブジェクトにアタッチされているセキュリティコンテキストのタイプ属性 U2：オブジェクトにアタッチされているセキュリティコンテキストのユーザ属性 R2：オブジェクトにアタッチされているセキュリティコンテキストのロール属性 T2：オブジェクトにアタッチされているセキュリティコンテキストのタイプ属性 not ::= ‘!’ | ‘not’ and ::= ‘&&’ | ‘and’ or ::= ‘||’ | ‘or’ op ::= ‘==’ | ‘!=’ role_op ::= op | ‘eq’ | ‘dom’ | ‘domby’ | ‘incomp’ users ::= set roles ::= set types ::= set role_op：ロール属性に対してのみ利用可能なオペレータ






「expression」で示す条件が成立する場合に限り、「classes」で示すサブジェクトある

いはオブジェクトに対して「permissions」で示すパーミッションを許可する。

role に対するオペレータは以下の意味を持っている。

• a_r == b_r a_r と b_r が同一の role である場合に真

• a_r eq b_r 同上

• a_r != b_r a_r と b_r が異なる role である場合に真

• a_r dom b_r a_r が b_r に遷移可能である場合に真

• a_r domby b_r b_r が a_r に遷移可能である場合に真

• a_r incomp b_r a_r と b_r が双方向で遷移不可能である場合に真

関連ファイル

constraints constraint を定義するファイル

3.4.1.6. ユーザの登録

SELinux はシステムのユーザアカウントとは別に独自のユーザ識別情報を管理している。

そのため、login プログラムによりシステムにログインして作業を行う必要のあるユーザア

カウントは SELinux の管理するユーザ識別情報としても登録しておかなければならない。


リスト 3-50 ユーザへの role 割り当ての書式

'user' identifier 'roles' roles ';' roles ::= set






「identifier」で示されるユーザを登録し、同ユーザに対して「roles」で示される role

を割り当てる。

RBAC によるアクセス制御アーキテクチャを実装した SELinux では、いかなるユーザも何

かしらの role が割り当てられていなければならない。したがって、必ず１つ以上の role

を割り当てる必要がある。なお、上記書式における「identifier」に指定するユーザは、

システムのユーザアカウントとして登録されている必要がある。

ここで割り当てた role は同アカウントでログインの際に選択することが可能である。ま

た、ログイン後であれば 3.4.3.1 で説明する newrole コマンドにより role の変更を行うこ

とが可能である。

Note：「SELinux のユーザ識別情報はどのように扱われるのか」

SELinux に登録されたユーザ識別情報はそのユーザが login プログラムによりシステムにログインした際に、login

プログラムにより開始される shell プロセスにアタッチされる。以後、shell プロセスにより開始されるプロセスに

引き継がれ、同プロセスが作成するオブジェクトに対しても引き継がれてアタッチされる。SELinux のユーザ識別情

報として登録されていないユーザアカウントでシステムにログインした場合、login プログラムにより開始される

shell プロセスにはどんなユーザ識別情報がアタッチされるのか。この場合、SELinux の標準セキュリティポリシー

定義では、ユーザ識別情報「user_u」がアタッチされることになっている。このユーザには role として「user_r」

のみが割り当てられている。

関連ファイル

users ユーザを登録するファイル

3.4.1.7. セキュリティコンテキストのアタッチ

3.4.1.3(2)では type 遷移ルールによるオブジェクトへの type のアタッチを説明した。

type 遷移ルールは抽象的なオブジェクトあるいは常に存在しているとは限らないオブジェ

クトに対して動的に type をアタッチするための定義である。これは、あらかじめ type を

アタッチしておくことができないオブジェクトに対しても、そのオブジェクトが作成され

た際に適切な type をアタッチする必要があるためである。これに対して、ファイルシステ

ム上に恒久的に存在しているファイルといったオブジェクトにはあらかじめ静的に type を

アタッチしておかなければならない。

本節では、オブジェクトに対するセキュリティコンテキストのアタッチについて説明す

る。





(1) 初期 SID コンテキストの定義

SELinux には「セキュリティサーバー」と呼ばれるカーネル内コンポーネントが実

装されている。このコンポーネントはあらかじめ定義されたセキュリティポリシーを

システム起動時にメモリに読み込んで管理する役割を担っている。このセキュリティ

サーバーがセキュリティポリシー定義からセキュリティコンテキストを読み込む際に

は、随時「セキュリティ ID（SID）」と呼ばれる ID を算出しており、カーネル内での

セキュリティコンテキストの管理はこの SID により行われている。しかし、システム

起動時で、セキュリティサーバーがまだ起動していない段階で必要となるセキュリ

ティコンテキストが幾つか存在する。当然これらの SID はセキュリティサーバーに算

出させることができない。そこで、これらのセキュリティコンテキストに割り当てる

SID はあらかじめ予約されており、この特別な SID は「初期 SID」と呼ばれている。ファ

イル initial_sid_contexts では、初期 SID のセキュリティコンテキストが定義されて

いる。書式をリスト 3-51 に示す。

リスト 3-51 初期 SID のセキュリティコンテキストを定義する書式

'sid' identifier security_context security_context ::= user ':' role ':' type user ::= identifier role ::= identifier type ::= identifier


「identifier」で示される初期 SID に、「security_context」で示されるセキュリ

ティコンテキストを対応付ける。

上記書式の「identifier」に指定できるのは、SELinux にて定義済みの初期 SID 識

別子25のみである。

通常、初期 SID に対応付けられたセキュリティコンテキストを編集する必要性はな

25 SELinux を標準構成でインストールしている場合、定義済みの初期 SID 識別子はファイル

/usr/local/selinux/flask/initial_sids で確認できる。





い。

関連ファイル

initial_sid_contexts 初期SIDに対応付けるセキュリティコンテキストを定義するファイル

(2) ファイルシステム

SELinux はファイルシステム自身とファイルシステム上の inode に対するセキュリ

ティコンテキストのアタッチを、ファイルシステムごとに異なる手順で実施すること

が可能である。ここでは、特定のファイルシステムに対してセキュリティコンテキス

トのアタッチ手順を定義する方法を説明する。なお、下記のいずれの方法でも定義さ

れていないファイルシステムがマウントされた場合には、初期 SID として定義されて

いるセキュリティコンテキスト「unlabeled」がアタッチされる（初期 SID に関しては

3.4.1.7(1)を参照してほしい）。

(A) 恒久的なマップ情報によるアタッチ

ファイルシステム上の inode において、その inode 番号が常に保持されることが

保証されるファイルシステムの場合、ファイルシステム自身とファイルシステム上

のファイルにアタッチするセキュリティコンテキストは inode 番号とセキュリティ

コンテキストのペアによる恒久的なマップ情報をファイルシステム上に保存してお

くことができる。恒久的なマップ情報によるアタッチ手順はリスト 3-52 に示す書

式にて定義することが可能である。

リスト 3-52 恒久的なマッピング情報によるアタッチ手順の定義書式

'fs_use' fstype ';' fstype ::= ファイルシステムタイプ名






「fstype」で示されるファイルシステムでは、恒久的なマップ情報によるセキュ

リティコンテキストのアタッチ手順を採用する。

関連ファイル

fs_use ファイルシステムに対するセキュリティコンテキストのアタッチ手順を定義するファイル

(B) 作成元プロセスによるアタッチ

仮想ファイルシステムの場合、セキュリティコンテキストのアタッチ手順として

恒久的なマップ情報を利用できない。この場合、ファイルシステムの作成元である

プロセスにアタッチされたセキュリティコンテキストを引き継いでファイルシステ

ム内の inode にアタッチする手順を定義することが可能である。書式をリスト 3-53

に示す。

リスト 3-53 作成元プロセスによるアタッチ手順の定義書式

'fs_use_task' fstype security_context ';' fstype ::= ファイルシステムタイプ名 security_context ::= user ':' role ':' type user ::= identifier role ::= identifier type ::= identifier


「fstype」で示されるファイルシステムでは、ファイルシステム自身に対しては

「security_context」で示されるセキュリティコンテキストをアタッチし、ファ

イルシステム内のinodeに対してはファイルシステム作成元であるプロセスのセ

キュリティコンテキストをアタッチする。

これは、パイプファイルシステムやソケットファイルシステムに適した定義であ





る。

関連ファイル


(C) type 遷移ルールによるアタッチ

仮想ファイルシステムの場合には、ファイルシステムの作成元であるプロセスと

そのファイルシステムにアタッチされた双方のセキュリティコンテキストを基準に

して、inode にアタッチするセキュリティコンテキストを決定するアタッチ手順を

定義することも可能である。書式をリスト 3-54 に示す。

リスト 3-54 type 遷移ルールによるアタッチ手順の定義書式

'fs_use_trans' fstype security_context ';' fstype ::= ファイルシステムタイプ名 security_context ::= user ':' role ':' type user ::= identifier role ::= identifier type ::= identifier


「fstype」で示されるファイルシステムでは、ファイルシステム自身に対しては

「security_context」で示されるセキュリティコンテキストをアタッチし、ファ

イルシステム内の inode に対しては、ファイルシステム作成元であるプロセスと

ファイルシステムのセキュリティコンテキストを基準に定義されている type 遷

移ルールに基づいて遷移先の type をアタッチする。

これは、devpts ファイルシステムや仮想記憶ファイルシステムに適した定義であ

る。





関連ファイル


(D) 変則的なアタッチ

恒久的なマップ情報が利用できず、上記で説明した特定の規則に従った手順も利

用できないファイルシステムの場合には、リスト 3-55 に示す書式を利用してセ

キュリティコンテキストを定義する。

リスト 3-55 変則的なアタッチ手順の定義書式

'genfscon' fstype pathprefix security_context | 'genfscon' fstype pathprefix '-' file_type security_context fstype ::= ファイルシステムタイプ名 pathprefix ::= ディレクトリパス | ファイルパス security_context ::= user ':' role ':' type user ::= identifier role ::= identifier type ::= identifier file_type ::= 'b' | 'c' | 'd' | 'p' | 'l' | 's' | '-' 'b'：ブロック型スペシャルファイル 'c'：キャラクタ型スペシャルファイル 'd'：ディレクトリ 'p'：名前付きパイプ 'l'：シンボリックリンク 's'：ソケット '-'：通常のファイル


「fstype」で示されるファイルシステムでは、同ファイルシステム上において

「pathprefix」と「file_type」で示されるファイルあるいはディレクトリに対

して「security_context」で示されるセキュリティコンテキストをアタッチする。

上記書式における「pathprefix」はファイルシステムの root ディレクトリを起

点としたパスを指定しなければならない点に注意が必要である。また、この





「pathprefix」で明示的に定義されないファイルとディレクトリは、同ファイルあ

るいはディレクトリのパスと最も長く一致したパスに対する定義が適用される。

Note：「ネットワークファイルシステム」

LSM ベースとなる前の SELinux では、ネットワークファイルシステムに対してセキュリティコンテキスト

をアタッチするための固有の機構が存在していたが、現状の LSM ベースの SELinux ではサポートされてい

ない。現状の SELinux でネットワークファイルシステムに対するセキュリティコンテキストをアタッチす

るためには、"genfscon"ステートメントにより定義する必要がある。

関連ファイル

genfs_contexts ファイルシステムに対してアタッチするセキュリティコンテキストを定義するファイル

(3) 一般のファイル

3.4.1.7(2)(A)で説明した手順によりセキュリティコンテキストをアタッチできる

ファイルシステムでは、あらかじめセキュリティコンテキストのマップ情報を作成し

ておかなければならない。書式をリスト 3-56 に示す。

リスト 3-56 一般のファイルに対するセキュリティコンテキスト割り当て書式

pathname_regexp opt_security_context | pathname_regexp '-' file_type opt_security_context pathname_regexp：ディレクトリあるいはファイルパス（正規表現可能） file_type ::= 'b' | 'c' | 'd' | 'p' | 'l' | 's' | '-' 'b'：ブロック型スペシャルファイル 'c'：キャラクタ型スペシャルファイル 'd'：ディレクトリ 'p'：名前付きパイプ 'l'：シンボリックリンク 's'：ソケット '-'：通常のファイル opt_security_context ::= '<<none>>' | user ':' role ':' type user ::= identifier role ::= identifier type ::= identifier






「pathname_regexp」と「file_type」で示されるファイルあるいはディレクトリに

対して「opt_security_context」で示されるセキュリティコンテキストをアタッチ

する。

ファイルパスの指定では一般的な正規表現による指定が可能である。またこの際

ファイルタイプを指定することで、対象とするファイルあるいはディレクトリを更に

絞り込んだ指定が可能となる。一般ファイルに対するセキュリティコンテキストのア

タッチは他のセキュリティポリシー定義とは異なり、3.4.3.1 で説明する setfiles コ

マンドによってシステムに反映させる。 setfiles コマンドはファイル

file_contexts/file_contexts26を先頭行より走査してシステムに反映する。そのため、

同一のファイルあるいはディレクトリに対して複数のセキュリティコンテキストが定

義されていた場合には、最後に登場した定義が優先されるので注意が必要である。

セキュリティコンテキストとして"<<none>>"を指定すると、そのファイルあるいは

ディレクトリに対するセキュリティコンテキストのアタッチをスキップさせることが

できる。たとえばファイル file_contexts/types.fc には以下の定義が見られる。

# # /var/run # ① /var/run(/.*)? system_u:object_r:var_run_t ② /var/run/.*¥.*pid <<none>>

これはディレクトリ/var/run 下の全てのファイルとディレクトリに対してセキュ

リティコンテキスト「system_u:object_r:var_run_t」をアタッチするように定義した

後（①）、同ディレクトリ下の PID ファイルに対してのみ"<<none>>"を定義している

（②）。setfiles コマンドを実行すると、ディレクトリ/var/run 下の PID ファイル以

外に対してはセキュリティコンテキストのアタッチが実施されるが、"<<none>>"が指

定されている PID ファイルのセキュリティコンテキストが操作されることはない。何

故このような指定が必要なのか。PID ファイルはプロセスが開始された際に動的に作

成されるファイルで、且つセキュリティ上重要なファイルであるため、通常は同プロ

セスに固有の type がアタッチされるように type 遷移ルールが定義されている。もし

26 このファイルには、setfiles コマンド実行時に、ファイルに対するセキュリティコンテキスト定義のす

べてが集約される。





仮に、setfiles コマンド実行時に同ファイルがファイルシステム上に存在しており、

setfiles コマンドによってプロセスに固有な type ではない type がアタッチされてし

まったら、このプロセスは自身が作成した PID ファイルに対してアクセスできなく

なってしまうだろう。setfiles コマンドによってこのようなファイルのセキュリティ

コンテキストが操作されてはまずいのである。

Note：「オブジェクトにアタッチする role」

セキュリティコンテキストはユーザ識別情報、role、type、および MLS 関連情報から構成される複合情報で

ある。セキュリティコンテキストの構成要素である role は本来ユーザに割り当てるための概念である。ファ

イル等のオブジェクトに対してセキュリティコンテキストをアタッチする際、この role には何を指定するの

か。それは「object_r」である。なお、プロセスにアタッチされる role は、そのプロセスを起動したユーザ

の role である。

関連ファイル

file_contexts/types.fc 特定のプログラムに関連しないファイルに対するセキュリティコンテキストを定義するファイル

file_contexts/program/*.fc 特定のプログラムに関連するファイルに対するセキュリティコンテキストを定義するファイル

file_contexts 「setfiles」コマンドが生成するファイルで、上記ファイルにおけるセキュリティコンテキストのすべての定義がこのファイルに集約される。

(4) ネットワーク

セキュリティコンテキストをアタッチすることのできるネットワークオブジェクト

はポート、ネットワークインタフェース、およびノード（ホスト）である。

(A) ポート

ポートにセキュリティコンテキストをアタッチする際の書式をリスト 3-57 に示

す。





リスト 3-57 ポートに対するアタッチ

'portcon' protocol_type port_number security_context | 'portcon' protocol_type port_range security_context protocol_type ::= 'tcp' | 'udp' port_number ::= 整数値 port_range ::= port_number '-' port_number security_context ::= user ':' role ':' type user ::= identifier role ::= identifier type ::= identifier


「protocol_type」で示されるネットワークプロトコルで、「port_number」で示

されるポートあるいは「port_range」で示される範囲のポートに対して

「security_context」で示されるセキュリティコンテキストをアタッチする。

なお、上記の定義書式にて明示的にセキュリティコンテキストが定義されていな

いポートには、初期 SID として定義されているセキュリティコンテキスト「port」

がアタッチされる（初期 SID に関しては 3.4.1.7(1)を参照してほしい）。

(B) ネットワークインタフェース

ネットワークインタフェースには2つのセキュリティコンテキストを定義しなけ

ればならない。1 つはネットワークインタフェース自体にアタッチするセキュリ

ティコンテキストであり、もう 1 つはそのネットワークインタフェースで受信した

パケットにアタッチするセキュリティコンテキストである。






リスト 3-58 ネットワークインタフェースに対するアタッチ

'netifcon' interface device_context packet_context interface ::= ネットワークインタフェース名 device_context ::= security_context packet_context ::= security_context security_context ::= user ':' role ':' type user ::= identifier role ::= identifier type ::= identifier


「 interface 」で示されるネットワークインタフェースに対して

「device_context」で示されるセキュリティコンテキストをアタッチし、この

ネットワークインタフェースで受信したパケットに対して「packet_context」で

示されるセキュリティコンテキストをアタッチする。

上記の書式における「packet_context」はネットワークインタフェースより送出

されるパケットにアタッチするセキュリティコンテキストではなく、受信したパ

ケットに対してアタッチするセキュリティコンテキストである点を勘違いしないで

欲しい27。

上記の定義書式にて明示的にセキュリティコンテキストを定義しない場合、ネッ

トワークインタフェースには初期 SID として定義されているセキュリティコンテキ

スト「netif」がアタッチされ、受信したパケットには同じく初期 SID の「netmsg」

がアタッチされる（初期 SID に関しては 3.4.1.7(1)を参照してほしい）。

(C) ノード

ノード情報にアタッチするセキュリティコンテキストの定義書式をリスト 3-59

に示す。

27 カーネルパラメータにおける「Labeled IP Networking Support」を有効にすることで、セキュリティコ

ンテキストのアタッチされたパケットをサポートできるが、本ガイドライン作成時点では試験的な位置付

けである。





リスト 3-59 ノードに対するアタッチ

'nodecon' ipv4_address ipv4_mask security_context ipv4_address ::= ネットワークアドレス ipv4_mask ::= ネットマスク security_context ::= user ':' role ':' type user ::= identifier role ::= identifier type ::= identifier


「ipv4_address」と「ipv4_mask」で示されるネットワークアドレスを持ったノー

ドのノード情報に対して「security_context」で示されるセキュリティコンテキ

ストをアタッチする。

上記の定義書式にて明示的にセキュリティコンテキストを定義しない場合、初期

SID として定義されているセキュリティコンテキスト「node」がアタッチされる（初

期 SID に関しては 3.4.1.7(1)を参照してほしい）。

3.4.2. アプリケーションコンフィギュレーションファイル

Linux システムに既存のアプリケーションの中には、その性質上 SELinux により導入され

るセキュリティアーキテクチャを自身で意識して稼動しなければならないものが存在する。

代表的なものは、login、SSH 関連、crontab、crond、および logrotate コマンドといった

ものである。SELinux には上記アプリケーションを SELinux 用に改良したものが含まれてお

り、インストールの際に既存のアプリケーションはこれらによって置き換えられる。アプ

リケーションコンフィギュレーションファイルとは、上記のような SELinux 用に改良・

追加28されたアプリケーションのための各種設定ファイルのことである。

28 SELinux 独自のコマンド等、新規に追加されるプログラムも存在する。





(1) デフォルトセキュリティコンテキストの定義

ファイル/etc/security/default_contexts では、login プログラム、SSH セッショ

ンおよび cron ジョブにアタッチするデフォルトのセキュリティコンテキストを定義


リスト 3-60 デフォルトコンテキストの定義書式

system_process_partial_context default_partial_contexts system_process_partial_context ::= partial_context default_partial_contexts ::= partial_context | default_partial_contexts partial_context partial_context ::= role ':' type role ::= identifier type ::= identifier


「system_process_partial_context」で示されるシステムプロセスのデフォルトセ

キュリティコンテキストを「default_partial_contexts」で示されるセキュリティ

コンテキストとする。

上記の書式における「default_partial_contexts」がシステムプロセスによってど

のように扱われるかはそのプロセスに依るため、以下で具体例を挙げて説明する。ファ

イル/etc/security/default_contexts の内容をリスト 3-61 に示す。

リスト 3-61 /etc/security/default_contexts

① system_r:local_login_t user_r:user_t ② system_r:sshd_t user_r:user_t ③ system_r:crond_t user_r:user_crond_t system_r:system_crond_t

①は login プログラムに対するデフォルトセキュリティコンテキストの定義である。

login プログラムはログインしようとしているユーザのデフォルトセキュリティコン

テキストを決定するために上記のファイルを参照している。この際、書式における





「default_partial_contexts」に該当する部分を先頭より走査し、いちばん最初に登

場した正当なセキュリティコンテキストをデフォルトとして採用する。

②は SSH セッションにおけるデフォルトセキュリティコンテキストの定義である。

「default_partial_contexts」部分の扱われ方は login プログラムと同様である。

③は cron ジョブにアタッチするセキュリティコンテキストの定義である。

「default_partial_contexts」部分には、システム cron ジョブにアタッチするセキュ

リティコンテキストはもちろん、各ユーザの cron ジョブにアタッチするセキュリティ

コンテキストとして必要なものはすべて指定しなければならない。

関連ファイル

/etc/security/default_contexts デフォルトセキュリティコンテキストを定義するファイル

(2) デフォルト type の定義

ファイル/etc/security/default_typeでは、各roleにおけるそのペアとするデフォ

ルト type を定義する。書式をリスト 3-62 に示す。

リスト 3-62 デフォルト type の定義書式

role ':' default_type role ::= identifier default_type ::= identifier


「role」で示される role のデフォルト type を「default_type」で示される type

とする。

この定義は 3.4.3.1 で説明する newrole コマンド等で参照されており、newrole コ

マンドにて role のみを指定した場合には、このファイルにて定義されているデフォル

ト type が遷移先の type として決定される。当然、デフォルト type として指定する

type は role に割り当てられている type でなければならない。





関連ファイル

/etc/security/default_type デフォルト type を定義するファイル

(3) init スクリプトにアタッチするセキュリティコンテキストの定義

ファイル/etc/security/default_type では、3.4.3.2 で説明する run_init コマンド

により開始される init スクリプトにアタッチするセキュリティコンテキストを定義


リスト 3-63 init スクリプトにアタッチするセキュリティコンテキストの定義書式

user ':' role ':' type user ::= identifier role ::= identifier type ::= identifier

この書式の意味を以下に示す。

run_init コマンドにより開始される init スクリプトに対して、「user」、「role」、

および「type」で示されるセキュリティコンテキストをアタッチする29。

システム起動時の init プロセスから開始される initrc スクリプトにアタッチされ

るセキュリティコンテキストはここでの定義の影響を受けることはない。

関連ファイル

/etc/security/initrc_context run_init コマンドにより開始される init プロセスにアタッチするセキュリティコンテキストを定義するファイル

29 init スクリプトから起動されるプロセスにアタッチされるセキュリティコンテキストは、セキュリティ

ポリシー定義にて定義された遷移ルールに従って決定される。





(4) passwd ファイルにアタッチするセキュリティコンテキストの定義

ファイル/etc/security/passwd_context では、3.4.3.1 で説明する spasswd あるい

は svipw 等のコマンドにより編集されたファイル/etc/passwd にアタッチするセキュ

リティコンテキストを定義する。書式をリスト 3-64 に示す。

リスト 3-64 passwd ファイルにアタッチするセキュリティコンテキスト定義書式

user ':' role ':' type user ::= identifier role ::= identifier type ::= identifier

この書式の意味を以下に示す。

spasswd あるいは svipw 等のコマンドにより編集されたファイル/etc/passwd に対

して、「user」、「role」、および「type」で示されるセキュリティコンテキストをア

タッチする。

spasswd あるいは svipw 等のコマンドは自身が編集するファイル/etc/passwd のセ

キュリティコンテキストを適切なものに維持するために、編集後の同ファイルに対し

て、本定義により指定されているセキュリティコンテキストをアタッチする。

関連ファイル

/etc/security/passwd_context spasswd あるいは svipw 等のコマンドにより編集されたファイル/etc/passwd にアタッチするセキュリティコンテキストを定義するファイル

(5) shadow passwd ファイルにアタッチするセキュリティコンテキストの定義

ファイル/etc/security/shadow_context では、3.4.2(4)と同様の理由でファイル

/etc/shadow にアタッチするセキュリティコンテキストを定義する。定義書式は

3.4.2(4)と同様である。





関連ファイル

/etc/security/shadow_context spasswd あるいは svipw 等のコマンドにより編集されたファイル/etc/shadow にアタッチするセキュリティコンテキストを定義するファイル

3.4.3. コマンド

SELinux をインストールすると、新たに幾つかのコマンドがインストールされる。これら

のコマンドのデフォルトインストール先はディレクトリ/usr/local/selinux/bin/あるい

は/usr/local/selinux/sbin/である。本節では、これらのコマンドの中でも利用頻度の高

いコマンドを抜粋して説明する。なお、本節での解説は概説に留めているため、コマンド

の書式をはじめとした詳細な情報が必要な場合には、各コマンドのマニュアルページを参

照のこと。

3.4.3.1. ディレクトリ/usr/local/selinux/bin/下のコマンド

(1) avc_enforcing

SELinux のカーネルを構築した際に、カーネルパラメータとして「NSA SELinux

Development Support」を指定すると、SELinux の動作モードとして「permissive」モー

ドと「enforcing」モードを適宜切り替えることが可能となる。本コマンドを実行する

と、現在の稼動モードが表示される。

(2) avc_toggle

システムの稼動モードを切り替えるコマンド。現在「permissive」モードで稼動し

ていれば「enforcing」モードに、「enforcing」モードで稼動しているのであれば

「permissive」モードに切り替えることができる。なお、本コマンドが有効なのはカー

ネルパラメータとして「NSA SELinux Development Support」が指定されたカーネルで

起動している場合に限られる。

(3) chcon

ファイルあるいはディレクトリのセキュリティコンテキストを変更するコマンド。

特定のプログラムからのみアクセスされるファイルの場合、同ファイルにはプログラ





ム固有に定義された type がアタッチされていることが多い。このようなファイルを、

たとえば管理上の理由によりエディタ等の別プログラムで編集した際に、アタッチさ

れていた type が変更されてしまう。このような場合に、適切なセキュリティコンテキ

ストをアタッチし直すためのコマンドとして有用である。

(4) id

ユーザ情報を表示するコマンド。3.4.3.1(5)にて説明する newrole コマンドを利用

していると、自身に割り当てられている role と type が判らなくなることが多い。こ

のような場合に、自身に割り当てられている role と type を確認するためのコマンド

として有用である。

(5) newrole

複数の role を割り当てられているユーザでシステムにログインしている場合に、

role を切り替えるコマンド。厳密には、引数で指定された role で新たな shell を開

始するコマンド。

本コマンドは 3.4.2(2)のアプリケーションコンフィギュレーションファイルを

参照している。

(6) runas

引数で指定されたセキュリティコンテキストでプログラムを実行するコマンド。

(7) setfiles

ファイルシステム上のファイルに対してセキュリティコンテキストを一括してア

タッチするコマンド。SELinux のインストール過程にて、セキュリティコンテキスト

のマップ情報を初期化する目的で利用されている。SELinux インストール後であって

も、ファイルにアタッチされた誤ったセキュリティコンテキストを正す目的や、新た

に作成したセキュリティポリシーのための新たなセキュリティコンテキストをファイ

ルにアタッチする目的で利用することも可能である。

(8) spasswd

passwd コマンドのラップコマンドで、passwd ファイルと shadow passwd ファイルの





セキュリティコンテキストを適切なものに維持した状態でユーザパスワードの変更を

実現する。ただしこのコマンドは引数を取らないため、コマンドを実行したユーザ自

身のパスワード以外は変更できない。このコマンドはファイル/etc/passwd と

/etc/shadow にアタッチされているセキュリティコンテキストを適切なものに維持す

るため、同ファイル編集後に特定のセキュリティコンテキストをアタッチする。この

セキュリティコンテキストは 3.4.2(4)と 3.4.2(5)のアプリケーションコンフィギュ

レーションファイルにより決定される。

(9) sadminpasswd

spasswd との違いは本コマンドがユーザアカウント名を引数として受け付けること

である。管理者ユーザであれば、本コマンドを用いてシステム上の一般ユーザのパス

ワードを変更することが可能である。一般ユーザであっても本コマンドを利用するこ

とはできるが、他のユーザのパスワードを変更することは許可されていないため、自

身のパスワードを変更できるに過ぎない。

(10) svipw

vipw コマンドのラップコマンドで、passwd ファイルと shadow passwd ファイルのセ

キュリティコンテキストを適切なものに維持した状態で同ファイルの編集を実現する。

本コマンドは spasswd コマンドと同様の理由により、3.4.2(4)と 3.4.2(5)のアプリ

ケーションコンフィギュレーションファイルを参照している。

3.4.3.2. ディレクトリ/usr/local/selinux/sbin/下のコマンド

(1) run_init

initrc スクリプトを実行するコマンド。本コマンドで実行された initrc スクリプ

トには 3.4.2(3)で定義されているセキュリティコンテキストがアタッチされる。通常

Linux システムでは、initrc スクリプトをコマンドラインから実行してデーモンの起

動・停止・再起動が可能であるが、SELinux では initrc スクリプトは init プロセス

からのみ起動されることを前提としてセキュリティポリシーが定義されている。した

がって、initrc スクリプトをコマンドラインから実行した場合に適切なセキュリティ

コンテキストがアタッチされず、その後 initrc スクリプトから起動されるプログラム

は正常に稼動しない。デーモンプログラムをコマンドラインより起動・停止・再起動

させたい場合には、本コマンドを利用する必要がある。なお、本コマンドの引数にお





ける initrc スクリプトの指定は絶対パスでなければならないことに注意が必要であ

る。

3.4.3.3. スクリプト

スクリプトは SELinux のソースアーカイバに含まれている。上記の各種コマンドとは違

い、SELinux のインストールの際に同時にインストールされないため気付きにくいが、非常

に便利なスクリプトがあるので紹介する。

(1) newroles.pl

このスクリプトはログ情報からセキュリティポリシー定義文（allow 文に限られる）

を作成して出力してくれるスクリプトである。SELinux はそのセキュリティポリシー

定義において拒否しているアクセスが発生した際にログを出力する。このスクリプト

はそのログ情報を入力として、拒否されたアクセスを許可するためのセキュリティポ

リシー定義文を出力してくれるのである。アプリケーションのために新たなセキュリ

ティポリシーを定義する場合などに以下のような用法が考えられる。

① 必要な domain と type を定義する（アクセスベクタルールは一切定義しない）。

② ①をシステムのセキュリティポリシーに反映させる。

③ SELinux の稼動モードを「permissive」モードに変更する。

④ 当該アプリケーションを一通り稼動させる。

⑤ 本スクリプトを利用してログ情報からアクセスベクタルールを作成する。

⑥ ⑤で得たアクセスベクタルールを厳密に吟味する。

⑦ ⑥の結果必要なアクセスベクタルールはセキュリティポリシーに反映する。

このような手順を採れば、新たなセキュリティポリシーを定義する際に効率よく作

業できる。しかし、⑥は非常に重要であることを忘れないで欲しい。この作業を怠っ

てしまっては SELinux を導入する意味がまったくなくなってしまうからである。





3.5. セキュリティポリシーの定義

本章では、表 3-1 に示した 4 種のインターネットサービス(Web/DNS/SMTP/FTP)、7 種の

プログラムのセキュリティポリシーの設定内容を提示し、その設定内容について解説を行

う。本ガイドラインで解説するセキュリティポリシーの設定内容は、SELinux に標準で付属

されているものだが、djbdns および Wu-FTPD に関するセキュリティポリシーは筆者らが実

際に作成し、その動作確認および検証を行ったものである。

本章では、セキュリティポリシーやファイルのセキュリティコンテキストに関する設定

の注意点および留意点を記述し、本ガイドラインの読者が実際にシステムを構築する際に

役立ててほしい。

3.5.1. Web サーバー

3.5.1.1. Apache

(1) Apache の概要

WEB サーバーの定番と言えば Apache で、世界で使用されている WEB サーバーの 80%

以上のシェアを誇るといわれている。Red Hat 7.3 では Apache のバージョンは 1.3 が

採用されていたが、Red Hat Linux 8.0 はバージョン 2.0 が採用されている。

(A) ディレクトリ構造

Red Hat Linux の RPM によるパッケージでも、Red Hat Linux 7.3 と 8.0 では異

なる。また、ソースからコンパイルしてインストールする場合でも、configure ス

クリプトに何も指定しない場合は、Apache 1.3 では/usr/local/apache ディレクト

リにインストールされ、Apache 2.0 では/usr/local/apache2 ディレクトリとなる。

また、httpd.conf の記述次第で DocumentRoot 等を変更可能である。これらの説明

は網羅できないので、Red Hat Linux 7.3 と 8.0 で RPM によるパッケージで Apache

をインストールした場合のディレクトリ構造の違いのみを述べることにする。これ

らのディレクトリ構造は、後で述べるファイルのセキュリティコンテキストの設定

で重要になるので注意しなければならない。





表 3-7 Apache のディレクトリ構造

# Red Hat 7.3 Red Hat 8.0 内容

1 /etc/httpd 同左 HTTPD_ROOT

2 /etc/httpd/conf 同左 conf ディレクトリ

3 /usr/lib/apache /usr/lib/httpd/modules モジュール用ディレクトリ

4 /var/cache/httpd /etc/httpd/proxy cache 用ディレクトリ (但しコメントになっている)

5 /var/log/httpd 同左ログ用ディレクトリ

6 /var/www/cgi-bin 同左 CGI 用ディレクトリ

7 /var/www/html 同左ドキュメントルート

8 /var/www/icons 同左 ICON 用ディレクトリ

9 なし /var/www/error エラー応答用ページ

(2) セキュリティポリシー設定ファイル

Apache のセキュリティポリシー設定ファイル一覧を表 3-8 に示す。これらのファイ

ルは、SELinux に標準で組み込まれているファイルである。

表 3-8 Apache のポリシー設定ファイル一覧

# ファイルパス内容

1 policy/file_contexts/program/apache.fc ファイルのセキュリティコンテキスト

2 policy/domains/program/apache.te セキュリティポリシー

3 policy/domains/httpadm.te httpd_admin domain マクロ

(3) ファイルのセキュリティコンテキスト

標準で提供されている Apache に関連したファイルのセキュリティコンテキストに

関して説明を行う。Apache のインストール先ディレクトリや HTML/CGI を格納するディ

レクトリパスが本書に記述されている内容と異なる場合は、当該セキュリティコンテ

キスト設定ファイルを編集し、適切なセキュリティコンテキストを設定しなければな

らない。

(A) 実行ファイル

リスト 3-65 は、Apache の実行ファイルに対するセキュリティコンテキストであ

る。Red Hat Linux の RPM を使用せず、Apache をソースからビルドする場合、デフォ

ルトのインストール先が /usr/local/apache (version 1.x) または

/usr/local/apache2 (version 2.x)になるので、ビルド時にインストール先のディ

レクトリを変更するか、セキュリティコンテキストファイルに記述されているパス





名を変更する必要がある。

リスト 3-65 実行ファイルのセキュリティコンテキスト

/usr/sbin/apache(2)? system_u:object_r:httpd_exec_t /usr/sbin/httpd system_u:object_r:httpd_exec_t

(B) コンフィギュレーション

リスト 3-66 は、Apache が使用するコンフィギュレーションファイル関連のセ

キュリティコンテキストである。

リスト 3-66 コンフィギュレーション関連ファイルのセキュリティコンテキスト

/etc/apache(2)?(/.*)? system_u:object_r:httpd_config_t /etc/httpd system_u:object_r:httpd_config_t /etc/httpd/conf(/.*)? system_u:object_r:httpd_config_t ① /etc/vhosts system_u:object_r:httpd_config_t

①に示した/etc/vhostsファイルはSELinuxのメーリングリストでも話題となり、

このセキュリティポリシー作成者自身もよく分からないと言っている。実害はない

ということでこのまま残されているのではないだろう。

(C) HTML コンテンツ

リスト 3-67 は、HTML ファイル等のコンテンツに関連したファイルのセキュリ

ティコンテキストである。Red Hat Linux 8.0 では、/var/www/error がエラー応答

用のページとして追加されているので、①のような定義を追加しなければならない。

また、/var/www/manual のディレクトリも存在するので、必要であれば②のような

定義を追加する。





リスト 3-67 HTML コンテンツ関連のセキュリティコンテキスト

/var/www/html(/.*)? system_u:object_r:httpd_sys_content_t /var/www/icons(/.*)? system_u:object_r:httpd_sys_content_t /var/www/mrtg(/.*)? system_u:object_r:httpd_sys_content_t ① /var/www/error(/.*)? system_u:object_r:httpd_sys_content_t ② /var/www/manual(/.*)? system_u:object_r:httpd_sys_content_t

HTML コンテンツの置き場所は、システム管理者の好みにもより色々なディレクト

リ下に置かれる場合があるので、必ず確認すること。

(D) Proxy 用キャッシュ

リスト 3-68 は、Apache を Proxy として使用する場合のディレクトリパスおよび

ファイルに対するセキュリティコンテキストである。当該パスは httpd.conf の

“CacheRoot”パラメタで指定される。

リスト 3-68 キャッシュ関連のセキュリティコンテキスト

/var/cache/httpd(/.*)? system_u:object_r:httpd_cache_t /var/cache/ssl.*¥.sem system_u:object_r:httpd_cache_t

(E) ログファイル

リスト 3-69 は、ログ関連ファイルのセキュリティコンテキストである。

リスト 3-69 ログ関連ファイルのセキュリティコンテキスト

/etc/httpd/logs system_u:object_r:httpd_log_files_t /var/log/apache(2)?(/.*)? system_u:object_r:httpd_log_files_t /var/log/cgiwrap.log.* system_u:object_r:httpd_log_files_t /var/log/httpd(/.*)? system_u:object_r:httpd_log_files_t

(F) モジュール

リスト 3-70 は、モジュール関連のセキュリティコンテキストである。Red Hat

Linux 8.0 で RPM を使用して Apache をインストールした場合モジュール関連のファ





イルは/usr/lib/httpd/modules ディレクトリ下にインストールされる。このため、

①の行に示したような定義が必要となる。

リスト 3-70 モジュール関連のセキュリティコンテキスト

/etc/httpd/modules system_u:object_r:httpd_modules_t /usr/lib/apache(/.*)? system_u:object_r:httpd_modules_t /usr/lib/apache2/modules(/.*)? system_u:object_r:httpd_modules_t ① /usr/lib/httpd/modules(/.*)? system_u:object_r:httpd_modules_t

(G) suexec 関連

リスト 3-71 は、suexec 関連の実行プログラムに関するセキュリティコンテキス

トである。このセキュリティコンテキストがラベル付けされたプログラムは、httpd

に割り当てられる domain“httpd_t”とは別の domain“httpd_suexec_process_t”

が割り当てられる。

リスト 3-71 suexec 関連のセキュリティコンテキスト

/usr/lib/apache(2)?/suexec(2)? system_u:object_r:httpd_suexec_exec_t /usr/lib/cgi-bin/(nph-)?cgiwrap(d)? system_u:object_r:httpd_suexec_exec_t /usr/sbin/suexec system_u:object_r:httpd_suexec_exec_t

(H) CGI 関連

リスト 3-72 は、CGI プログラムに対するセキュリティコンテキストである。こ

れらのプログラムの suexec プログラムと同様に、httpd_sys_script_process_t と

いう domain を割り当てられて実行される。





リスト 3-72 CGI 関連のセキュリティコンテキスト

/usr/lib/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_t /var/www/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_t /var/www/perl(/.*)? system_u:object_r:httpd_sys_script_t

(I) PID 用ファイル

リスト 3-73 は、httpd プログラム実行時のプロセス ID を格納するファイルに対

するセキュリティコンテキストである。これは、httpd.confの PidFileディレクティ

ブで指定されたファイルである。Red Hat Linux 8.0 の RPM では、/var/run/httpd.pid

ファイルが作成される。

リスト 3-73 PID 用ファイルのセキュリティコンテキスト

/var/run/apache(2)?.pid.* system_u:object_r:httpd_var_run_t

後述するセキュリティポリシーの「ファイルの自動遷移機能」を使用して、

/var/run ディレクトリ下に作成されたファイルは“httpd_var_run_t”に自動的に

遷移するような設定を行っているため、リスト 3-73 に示したようなファイルコン

テキストの設定は不要に思われるが、システム稼動中にセキュリティコンテキスト

の再割り当て(make relabel)を実行したときに、別の type に割り当てられるのを防

ぐためにもこの定義は必要である。

(J) その他

ユーザの CGI スクリプトを実行するには、“httpd_user_script_t”という type

をファイルに設定しておかなければならない。この設定は、SELinux 標準では提供

されていないので、管理者またはユーザ自身が chcon コマンドで適切なセキュリ

ティコンテキストを設定する必要がある。なお、本説明は Apache のセキュリティポ

リシー定義ファイル(apache.te)の先頭に“NOTES”として記述されている。リスト

3-74 は、ユーザの CGI スクリプトファイル user_cgi.pl に対して、セキュリティコ

ンテキスト“system_u:object_r:httpd_user_script_t”を設定する chcon コマンド

の実行例である。





リスト 3-74 ユーザ CGI の type 設定例

chcon system_u:object_r:httpd_user_script_t user_cgi.pl

(4) セキュリティポリシー

SELinux の標準で提供されている Apache のセキュリティポリシーは、186 行(コメン

トおよび空行を含めると 480 行)と他のプログラムに比べて非常に大きな設定内容と

なっている。

(A) ポート type

リスト 3-75 は、Apache が使用するポートの type 定義である。一般的に、①は

80 番ポート、②は 8080 番ポートに設定されることが多い。

リスト 3-75 ポートの type 定義

① type http_port_t, port_type; ② type http_cache_port_t, port_type;

ここで定義したポート type とポート番号の実際に対応させる設定は、

selinux/policy/net_contexts ファイルに記述されている。

(B) type 宣言

リスト 3-76 に示したのは、ファイルのセキュリティコンテキストの設定で使用

する type の宣言である。それぞれの type には属性として、ファイルを意味する

“file_type”および管理者ファイルを表す“sysadmfile”が付与されている。①に

関しては、実行ファイルを意味する“exec_type”が、②にはログファイルを意味す

る“logfile”、③にはプロセス ID 格納ファイルを意味する“pidfile”という属性

が設定されている。④はマクロ定義で、“httpd_tmp_t”type の宣言(file_type、

sysadmfile、tmpfile)の type を付与し、/tmp ディレクトリ下にファイルを作成し

たときに、自動的にこの type に遷移する定義である。





リスト 3-76 ファイルの type 宣言

① type httpd_exec_t, file_type, sysadmfile, exec_type; ② type httpd_log_files_t, file_type, sysadmfile, logfile; ③ type httpd_var_run_t, file_type, sysadmfile, pidfile; type httpd_config_t, file_type, sysadmfile; type httpd_modules_t, file_type, sysadmfile; type httpd_cache_t, file_type, sysadmfile; type httpd_tmpfs_t, file_type, sysadmfile; type httpd_sys_content_t, file_type, sysadmfile; type httpd_user_content_t, file_type, sysadmfile; type httpd_sys_htaccess_t, file_type, sysadmfile; type httpd_user_htaccess_t, file_type, sysadmfile; ④ tmp_domain(httpd)

(C) domain 定義

リスト 3-77 は、Apache の実行プログラムである httpd の起動時に割り当てられ

る domain とそれに関連した定義である。①で“httpd_t”がプロセスを意味する

“domain”属性とログの出力権限を意味する“privlog”属性が付与されている。②

では、“system_r”の role に対して“httpd_t”に遷移する許可を与えている。③は、

マクロ定義で“httpd_t”に共通操作の権限(システムファイルの読み込み権限や/tmp

への書き込み権限等)を与える。④でメッセージを出力するために、コンソールデバ

イスへの読み書き権限を与えている。⑤はマクロ定義で init スクリプトから起動さ

れたときに自動的に“httpd_t”に遷移する定義である。⑥も同様に、“init_t”が

httpd を実行したときに“httpd_t”に遷移する定義である。

リスト 3-77 httpd_t domain 関連の定義

① type httpd_t, domain, privlog; ② role system_r types httpd_t; ③ every_domain(httpd_t) ④ allow httpd_t console_device_t:chr_file { read write }; ⑤ domain_auto_trans(initrc_t, httpd_exec_t, httpd_t) ⑥ type_transition init_t httpd_exec_t:process httpd_t;

特に、⑤の domain 遷移の定義は重要である。通常“initrc_t”という domain は

種々のデーモンを起動するために多くの権限が設定されている。この domain の権限

を維持したまま httpd を起動した場合、httpd 自身に不要なそして危険な権限まで

与えてしまうことになる。この危険性をなくすのが domain 遷移であり、この場合





“httpd_t”という domain に遷移をさせて、その domain に必要最低限の権限を与え

てで httpd デーモンを起動させるのである。

(D) CGI スクリプト

リスト 3-78 は、システム用とユーザ用の CGI スクリプトに関する設定である。

domain の宣言や role の定義等は、“httpd_t”と同じであり、それぞれのファイル

に設定されるセキュリティコンテキストの type もシステム用とユーザ用に分けて

定義する。ただ異なるのは①の設定である“in_user_role”はマクロ定義で、ユー

ザ domain からこのユーザの CGI スクリプトが実行されたときに、自動的に

“httpd_user_script_process_t”に domain を遷移する権限を許可している。

リスト 3-78 CGI スクリプトのセキュリティポリシー

# システム CGI スクリプト type httpd_sys_script_process_t, domain; role system_r types httpd_sys_script_process_t; every_domain(httpd_sys_script_process_t) # ユーザ CGI スクリプト type httpd_user_script_process_t, domain; role system_r types httpd_user_script_process_t; ① in_user_role(httpd_user_script_process_t) every_domain(httpd_user_script_process_t) # システム CGI スクリプトの type type httpd_sys_script_t, file_type, sysadmfile; # ユーザ CGI スクリプトの type type httpd_user_script_t, file_type, sysadmfile;

リスト 3-79 は、システムおよびユーザのスクリプトが扱うファイルへの権限を

明確に区別するためのものである。ここでの定義は、type の定義のみであるが後述

する allow 文にてその設定を明確にしている。type 名からその役割を想像できるよ

うにするために、サフィックス“r_t”は読み込み専用、“rw_t”は読み書き、“a_t”

は読み込みおよび追加書きを意味するそれぞれの文字列が付加されている。また、

“file_type_auto_trans”で tmp_t(/tmp ディレクトリ等に付与される type)を持つ

ディレクトリ下に作成されたファイルに対しては、自動的に

“httpd_user_script_rw_t”の type が付与されるような設定になっている(①、②)。





リスト 3-79 その他のスクリプト用 type

type httpd_sys_script_r_t, file_type, sysadmfile; type httpd_sys_script_rw_t, file_type, sysadmfile; ① file_type_auto_trans(httpd_sys_script_process_t, tmp_t, httpd_sys_script_rw_t) type httpd_sys_script_a_t, file_type, sysadmfile; type httpd_user_script_r_t, file_type, sysadmfile; type httpd_user_script_rw_t, file_type, sysadmfile; ② file_type_auto_trans(httpd_user_script_process_t, tmp_t, httpd_user_script_rw_t) type httpd_user_script_a_t, file_type, sysadmfile;

リスト 3-80 は、ユーザの CGI スクリプトやシステムの CGI スクリプトを実行し

たときに、適切な domain に遷移させるためのポリシー定義である。①、②は

Apache(httpd)自身がスクリプトを実行したときの domain 遷移定義である。③は

ユーザが直接手動で CGI スクリプトを実行したとき、④、⑤は Web 管理者

(httpd_admin権限を持ったユーザ)が CGIスクリプトを実行したときのdomain遷移

の定義である。これらは、作成した CGI スクリプトをデバッグ等の目的により手動

で実行させたときでも、適切な domain に遷移させることができるようにするための

ものである。

リスト 3-80 CGI スクリプトの domain 遷移

① domain_auto_trans(httpd_t, httpd_user_script_t, httpd_user_script_process_t)② domain_auto_trans(httpd_t, httpd_sys_script_t, httpd_sys_script_process_t) ③ domain_auto_trans(user_t, httpd_user_script_t, httpd_user_script_process_t)④ domain_auto_trans(httpd_admin_t, httpd_sys_script_t, httpd_sys_script_process_t) ⑤ domain_auto_trans(httpd_admin_t, httpd_user_script_t, httpd_user_script_process_t)

前述の(C)で説明したようにdomain遷移は不要な権限を継承させないためのもの

で、この設定を忘れるとセキュリティホールを作りかねない。





(E) SUEXEC 関連の定義

リスト 3-81 は、ユーザスクリプトと当該ユーザの ID で実行するためのプログラ

ムである suexec 用の domain 定義である。①で httpd_suexec_process_t という

domain を定義している。②ではこの domain に遷移できる role の定義である。③で

はシステムで標準的なアクセス権限をこの domain に許可している。④は SUEXEC 用

の実行プログラムに付与する type の定義である。

リスト 3-81 SUEXEC 用 domain 定義

# The following are types for SUEXEC,which runs user scripts as their # own user ID ① type httpd_suexec_process_t, domain; ② role system_r types httpd_suexec_process_t; ③ every_domain(httpd_suexec_process_t) ④ type httpd_suexec_exec_t, file_type, exec_type, sysadmfile;

リスト 3-82は SUEXECで起動されるプロセスのためのdomain遷移の定義である。

まず、①で httpd(httpd_t)デーモンから suexec(httpd_suexec_exec_t)プログラム

が実行されたときに domain を“httpd_suexec_process_t”に遷移させ、②で suexec

がユーザのスクリプト(httpd_user_script_t)を起動したときに、その domain を

“httpd_user_script_process_t”に遷移させる。

ユーザのスクリプトを安全に実行させるためには、スクリプトファイルに設定す

るセキュリティコンテキストを正しく設定しなければならない。

リスト 3-82 SUEXEC domain 遷移の定義

① domain_auto_trans(httpd_t, httpd_suexec_exec_t, httpd_suexec_process_t) domain_auto_trans(httpd_suexec_process_t, httpd_user_script_t, httpd_user_script_process_t)

リスト 3-83 は、suexec domain (httpd_suexec_process_t)に与えられる権限の

定義である。①は setuid(2)/setgid(2)システムコール発行する権限の付与である。

②、③はユーザ CGI スクリプトが存在するディレクトリの検索権限とそのファイル

を実行するための権限である。④、⑤はシステムのコマンド(/bin、/usr/bin 等)や

ライブラリの実行権限である。⑥、⑦、⑦’はログ出力の権限である。⑦’は追加のセ

キュリティポリシーで Red Hat Linux では、/etc/httpd/logs が/var/log/httpd へ





のシンボリックリンクになっているため、このセキュリティポリシーが必要になる。

⑧は domain 遷移の定義である。⑨から⑫は httpd が使用するファイル(パイプ、pid

ファイル、キャッシュ)に対する権限を与えている。

リスト 3-83 SUEXEC への権限の付与

① allow httpd_suexec_process_t httpd_suexec_process_t:capability { setuid setgid };② allow httpd_suexec_process_t httpd_user_script_t:dir { search getattr };③ allow httpd_suexec_process_t httpd_user_script_t:file { execute entrypoint }; ④ allow httpd_suexec_process_t bin_t:file rx_file_perms; ⑤ allow httpd_suexec_process_t lib_t:file { execute }; ⑥ allow httpd_suexec_process_t httpd_log_files_t:dir { search }; ⑦ allow httpd_suexec_process_t httpd_log_files_t:file { append getattr }; ⑦’ allow httpd_suexec_process_t httpd_log_files_t:lnk_file { read }; ⑧ allow httpd_suexec_process_t httpd_user_script_process_t:process { transition }; ⑨ allow httpd_suexec_process_t httpd_t:fifo_file {getattr} ; ⑩ allow httpd_user_script_process_t httpd_t:fifo_file {getattr} ; ⑪ allow httpd_suexec_process_t httpd_var_run_t:file rw_file_perms; ⑫ allow httpd_suexec_process_t httpd_cache_t:file rw_file_perms;

(F) dontaudit の設定

リスト 3-84 は、httpd が保持する UNIX ストリームソケットに対して、SUEXEC プ

ロセスや mail/MTA が読み書きを行ってもログを採取しないという設定である。

リスト 3-84 dontaudit の設定

dontaudit httpd_suexec_process_t httpd_t:unix_stream_socket { read write }; dontaudit { system_mail_t mta_user_agent } httpd_t:unix_stream_socket { read write };

基本的に、Apache は close-on-exec(プログラムの exec(2)時にファイルをクロー

ズする指定)を設定しているので、これに違反することはない。





(G) コマンド類の実行許可

リスト 3-85 は、Web 管理者(①)、ユーザ CGI スクリプト(②、④)、システム CGI

スクリプト(③、⑤)に、type が bin_t のコマンド(/bin や/usr/bin ディレクトリ下

のプログラム)やライブラリの実行権限を与える定義である。perl スクリプトや

シェルスクリプトで CGI を作成しているときはこれらの設定は必ず必要である。

リスト 3-85 コマンド類の実行許可

① can_exec(httpd_admin_t, bin_t) ② can_exec(httpd_user_script_process_t, lib_t) ③ can_exec(httpd_sys_script_process_t, lib_t) ④ can_exec(httpd_user_script_process_t, bin_t) ⑤ can_exec(httpd_sys_script_process_t, bin_t)

(H) シグナル、FD、パイプ

リスト 3-86 は、ユーザおよびシステムの CGI スクリプトに対して、シグナル

SIGCHLD を httpd に送信する許可、httpd/initrc/init からのファイルディスクリプ

タ(FD)の継承、および FIFO ファイル(パイプ)への書き込み許可を与える定義である。

リスト 3-86 シグナル、FD、パイプの許可

allow httpd_user_script_process_t httpd_t:process {sigchld}; allow httpd_user_script_process_t httpd_t:fd use; allow httpd_user_script_process_t initrc_t:fd {use}; allow httpd_user_script_process_t init_t:fd {use}; allow httpd_user_script_process_t httpd_t:fifo_file { write }; allow httpd_sys_script_process_t httpd_t:process {sigchld}; allow httpd_sys_script_process_t httpd_t:fd use; allow httpd_sys_script_process_t initrc_t:fd {use}; allow httpd_sys_script_process_t init_t:fd {use}; allow httpd_sys_script_process_t httpd_t:fifo_file {getattr write};

(I) CGI スクリプトのアクセス権限

リスト 3-87 は、ユーザおよびシステムの CGI スクリプトが必要とする書き込み

権限を与えている。①は/var/run ディレクトリ下のファイル(主にプロセス ID を格





納)、②は/dev/null デバイス、③は/dev/random デバイス、④は httpd を Proxy と

して使用した場合のキャッシュのディレクトリおよびファイルである。

リスト 3-87 CGI スクリプトの書き込み権限

① allow httpd_user_script_process_t httpd_var_run_t: file rw_file_perms; ② allow httpd_user_script_process_t null_device_t: chr_file rw_file_perms;③ allow httpd_user_script_process_t random_device_t:chr_file r_file_perms;④ allow httpd_user_script_process_t httpd_cache_t: file rw_file_perms; allow httpd_sys_script_process_t httpd_var_run_t: file rw_file_perms; allow httpd_sys_script_process_t null_device_t: chr_file rw_file_perms; allow httpd_sys_script_process_t random_device_t:chr_file r_file_perms; allow httpd_sys_script_process_t httpd_cache_t: file rw_file_perms;

リスト 3-88 は、ユーザおよびシステムの CGI スクリプトに対し、ユーザのディ

レクトリやスクリプト自身がおかれているディレクトリのサーチ権限を与えている。

この権限がないと、CGI スクリプトから目的とするファイルを探すことができない。

リスト 3-88 CGI スクリプトのサーチ権限

allow httpd_user_script_process_t httpd_user_script_t:dir {search add_name};

allow httpd_user_script_process_t home_root_t:dir { getattr search };

allow httpd_user_script_process_t user_home_dir_type:dir {getattr search};

allow httpd_user_script_process_t httpd_user_content_t:dir {search};

allow httpd_user_script_process_t httpd_sys_script_t:dir {search};

allow httpd_sys_script_process_t httpd_sys_script_t:dir {search add_name};

allow httpd_sys_script_process_t httpd_sys_content_t:dir {search};

リスト 3-89 は、リスト 3-79 で定義した type に対する許可を実際に定義してい

る。サフィックスとして“r_t”が付いた type のディレクトリおよびファイルに対

しては読み込み権限のみを、“rw_t”には読み込みと書き込み権限を、“a_t”に対し

ては読み込みと追加書き権限を設定している。システム用 CGI スクリプトに対して

はユーザ用と多少異なり、サフィックス“rw_t”の type に対しては読み書き権限に

加えてファイルの作成権限を与えている。





リスト 3-89 読み込み・読み書き・追加書き権限

allow httpd_user_script_process_t httpd_user_script_r_t:file r_file_perms;

allow httpd_user_script_process_t httpd_user_script_r_t:dir r_dir_perms;

allow httpd_user_script_process_t httpd_user_script_rw_t:file rw_file_perms;

allow httpd_user_script_process_t httpd_user_script_rw_t:dir rw_dir_perms;

allow httpd_user_script_process_t httpd_user_script_a_t:file ra_file_perms;

allow httpd_user_script_process_t httpd_user_script_a_t:dir ra_dir_perms;

allow httpd_sys_script_process_t httpd_sys_script_r_t:file r_file_perms;

allow httpd_sys_script_process_t httpd_sys_script_r_t:dir r_dir_perms;

allow httpd_sys_script_process_t httpd_sys_script_rw_t:file

create_file_perms;

allow httpd_sys_script_process_t httpd_sys_script_rw_t:dir create_dir_perms;

allow httpd_sys_script_process_t httpd_sys_script_a_t:file ra_file_perms;

allow httpd_sys_script_process_t httpd_sys_script_a_t:dir ra_dir_perms;

(J) 一般ユーザからのアクセス権限

一般ユーザが自身の HTML コンテンツや CGI スクリプトに対してアクセスする権

限の設定を行う。一般ユーザには、“user_t”という domain が割り当てられるため、

この domain からオブジェクト(ファイルやディレクトリ)にアクセスできるような

設定を与えなければならない。

リスト 3-90 は、一般ユーザが“httpd_user_content_t”（WEB コンテキスト）、

“httpd_user_script_t”(CGI スクリプト)、および“httpd_user_htaccess_t”

(htaccess ファイル)のそれぞれの type に対してのアクセス制限を設定している。

ここでは、ファイルの作成・削除等を自由にできる権限を与える設定である。





リスト 3-90 ユーザコンテキスト・CGI への権限設定

allow user_t httpd_user_content_t:file create_file_perms; allow user_t httpd_user_content_t:dir create_dir_perms; allow user_t httpd_user_content_t:lnk_file {create}; allow user_t httpd_user_script_t:file create_file_perms; allow user_t httpd_user_script_t:file {relabelto}; allow user_t httpd_user_script_t:dir create_dir_perms; allow user_t httpd_user_script_t:lnk_file {create}; allow user_t httpd_user_htaccess_t:file create_file_perms; allow user_t httpd_user_htaccess_t:lnk_file {create};

リスト 3-91 は、リスト 3-89 とは異なり CGI スクリプトからのアクセス権限で

はなく一般ユーザからのアクセス権限の設定である。つまり、ユーザが手動でファ

イルを作成したり編集したりするための権限であるため、それぞれの type に対して

“create”権限を与えている。また、ファイルのセキュリティコンテキストも変更

できるように“relabelto”と“relabelfrom”の権限を付与されている。

リスト 3-91 ユーザからのアクセス権限

allow user_t httpd_user_script_r_t:file create_file_perms; allow user_t httpd_user_script_r_t:lnk_file {create}; allow user_t httpd_user_script_r_t:dir create_dir_perms; allow user_t httpd_user_script_rw_t:file rw_file_perms; allow user_t httpd_user_script_rw_t:lnk_file {create}; allow user_t httpd_user_script_rw_t:dir rw_dir_perms; allow user_t httpd_user_script_a_t:file ra_file_perms; allow user_t httpd_user_script_a_t:lnk_file {create}; allow user_t httpd_user_script_a_t:dir ra_dir_perms; allow user_t httpd_user_content_t:dir {relabelto relabelfrom}; allow user_t httpd_user_content_t:file {relabelto}; allow user_t httpd_user_htaccess_t:file {relabelto};

(K) associate 設定

リスト 3-92 は、システムおよびユーザのファイル type に対してファイルシステ

ムへの関連を定義しているものである。つまり、この設定で fs_t という type ファ

イルシステムにこれらのファイルを作成可能になるわけであるが、

“policy/types/file.te”で“file_type”に既に設定されているため、この定義自

身冗長な定義と言える。





リスト 3-92 associate 設定

allow httpd_sys_script_a_t fs_t:filesystem {associate}; allow httpd_sys_script_r_t fs_t:filesystem {associate}; allow httpd_sys_script_rw_t fs_t:filesystem {associate}; allow httpd_user_script_t fs_t:filesystem {associate}; allow httpd_user_script_a_t fs_t:filesystem {associate}; allow httpd_user_script_r_t fs_t:filesystem {associate}; allow httpd_user_script_rw_t fs_t:filesystem {associate}; allow httpd_sys_content_t fs_t:filesystem {associate}; allow httpd_sys_htaccess_t fs_t:filesystem {associate}; allow httpd_user_content_t fs_t:filesystem {associate}; allow httpd_user_htaccess_t fs_t:filesystem {associate};

(L) httpd のアクセス権限

ここで設定する権限は httpd デーモン自身に対する権限である。httpd に割り当

てられた httpd_t という domain に対して不必要な権限を与えてしまうと、将来

Apacheni にセキュリティ上の脆弱性が発見されプロセスが外部からの攻撃者に

乗っ取られた場合に、その権限を利用してシステムの重要なファイルが破壊される

可能性がある。よって、httpd_t に対す権限設定は注意が必要である。

リスト 3-93 は、HTML コンテンツに対する権限設定である。①②はシステムの WEB

コンテンツのファイルおよびそのディレクトリに対し読み込み権限を与える設定で

ある。③は htaccess ファイルの読み込み権限である。④は一般的なコマンドの実行

権限を与えている。⑤⑥⑦は同様に、ユーザの WEB コンテンツのファイルおよびディ

レクトリ、htaccess ファイルの読み込み権限の設定を行っている。ここで注意しな

ければならないのは、書き込み権限を与えてはいけないことである。

リスト 3-93 httpd への権限設定(1)

① allow httpd_t httpd_sys_content_t:file r_file_perms; ② allow httpd_t httpd_sys_content_t:dir r_dir_perms; ③ allow httpd_t httpd_sys_htaccess_t: file r_file_perms; ④ allow httpd_t bin_t:file { read execute }; ⑤ allow httpd_t httpd_user_content_t:file r_file_perms; ⑥ allow httpd_t httpd_user_content_t:dir r_dir_perms; ⑦ allow httpd_t httpd_user_htaccess_t: file r_file_perms;

リスト 3-94 は、同様に httpd に対するシステムおよびユーザの CGI スクリプト





に対する権限の設定である。実行権限やスクリプトプロセスに対するシグナル送

信・プロセス遷移、およびディレクト・ファイルの読み込み権限を与えている。こ

こでもファイル type に対するアクセス権限は、いずれも読み込みのみである。

リスト 3-94 httpd への権限設定(2)

allow httpd_t httpd_sys_script_t:file {execute getattr read}; allow httpd_t httpd_sys_script_process_t:process {signal sigkill sigstop}; allow httpd_t httpd_sys_script_process_t:process {transition}; allow httpd_t httpd_sys_script_t:dir r_dir_perms; allow httpd_t httpd_sys_script_rw_t:dir r_dir_perms; allow httpd_t httpd_sys_script_rw_t:file r_file_perms; allow httpd_t httpd_user_script_t:file {execute getattr read}; allow httpd_t httpd_user_script_process_t:process {signal sigkill sigstop}; allow httpd_t httpd_user_script_process_t:process {transition}; allow httpd_t httpd_user_script_t:dir r_dir_perms; allow httpd_t httpd_user_script_rw_t:file r_file_perms; allow httpd_t httpd_user_script_rw_t:dir r_dir_perms;

リスト 3-95 は、httpd_t(httpd デーモン)に対し、一般ユーザのディレクトリお

よびファイルに対する参照権限を与える設定である。“home_root_t”は、/home ディ

レクトリに付与される type で、“user_home_dir_type”は一般ユーザのホームディ

レクトリに、“user_home_type”はホームディレクトリ下のすべてのファイルに付与

される属性である。①は PHP3 用に ioctl を発行するためにファイルおよびリンク

ファイルに対してその権限を与えている。②はシステム管理者のホームディレクト

リ(デフォルトでは/root)を参照しても、ログを出力しない設定である。

リスト 3-95 ホームディレクトリへのアクセス許可

allow httpd_t home_root_t:dir { getattr search }; allow httpd_t user_home_dir_type:dir { getattr search }; allow httpd_t user_home_type:dir { getattr search read }; ① allow httpd_t user_home_type:{ file lnk_file } { getattr read ioctl }; ② dontaudit httpd_t sysadm_home_dir_t:dir { getattr search };

リスト 3-96は、httpd_t(httpdデーモン)に対するケイパビリティの設定である。

ここで与えられているケイパビリティは、それぞれ chown(ファイルのオーナーおよ

びグループの変更)、ソケットの bind、setgid(GID の設定)、setuid(UID の設定)、

kill(シグナル SIGKILL の送信)、dac_override (DAC の無効化。任意アクセス制御





の制限を無効化する)、dac_read_search (読み込み制限の解除)を設定している。

リスト 3-96 httpd_t のケイパビリティの設定

allow httpd_t httpd_t:capability {chown net_bind_service setgid setuid kill dac_override dac_read_search };

リスト 3-97は、httpd_config_t の typeを設定したコンフィギュレーションファ

イル(httpd.conf 等)の読み込み権限を設定している。ここで使用している

“r_dir_file”は、ディレクトリ、ファイルおよびリンクファイル対する読み込み

権限を設定するマクロである。また、“initrc_t”に対しても読み込み権限の設定を

しているのは、rc スクリプトからも参照できるようにするためである。

リスト 3-97 config ファイルの読み込み権限

r_dir_file(httpd_t, httpd_config_t) r_dir_file(initrc_t, httpd_config_t)

リスト 3-98 は、httpd_t(httpd デーモン)に対し、ログファイルの作成・読み・

書きの権限を設定している(①、②)。③、④はシステムの CGI スクリプトとユーザ

の CGI スクリプトに対して、ログファイルへの追加書きのみを許可している。これ

は、CGI スクリプトの不具合によりログファイルを消失するのを防ぐためである。

Red Hat Linux では、/etc/httpd/logs は/var/log/httpd へのシンボリックリンク

になっている。このため、⑤の設定が必要である。

リスト 3-98 ログファイルの作成・読み・書き権限

① allow httpd_t httpd_log_files_t:dir rw_dir_perms; ② allow httpd_t httpd_log_files_t:file create_file_perms; ③ allow httpd_sys_script_process_t httpd_log_files_t:file {append}; ④ allow httpd_user_script_process_t httpd_log_files_t:file {append}; ⑤ allow httpd_t httpd_log_files_t:lnk_file r_file_perms;

リスト 3-99 は、init から継承したのファイルディスクリプタ(stdin、stdout、

stderr)を使用するための設定である。





リスト 3-99 init との関連

allow httpd_t init_t:fd use;

リスト 3-100 は、httpd_t(httpd デーモン)に対して、lib_t という type に設定

されたファイルに実行権限を設定している。

リスト 3-100 ライブラリの実行権限

can_exec(httpd_t, lib_t)

リスト 3-101 は、httpd_t(httpd デーモン)が、http_port_t(www のポート)と

http_cache_port_t(Proxy 用のポート)に対し、bind(ポートへの対応付け)できるよ

うにする設定である。

リスト 3-101 bind の権限設定

allow httpd_t { http_port_t http_cache_port_t }:tcp_socket name_bind;

リスト 3-102 は、httpd_t(httpd デーモン)が var_run_t(/var/run)の type を持

つディレクトリ下にファイルを作成した場合にそのファイルの type を遷移する設

定である(①)。プロセス ID を格納するファイル(/var/run/httpd.pid)がその対象で

ある。同様に②も Apache を Proxy として使用した場合のキャッシュがおかれるディ

レクトリおよびファイルを httpd_cache_t に遷移させる。③はメモリファイルシス

テム下に作成されたファイルの type を“httpd_tmpfs_t”に遷移させる設定である。

通常は、親ディレクトリのセキュリティコンテキストが引き継がれるが、ファイル

type の自動遷移を設定することにより、より安全にファイルを扱うことができる。

リスト 3-102 ファイル type の遷移

① file_type_auto_trans(httpd_t, var_run_t, httpd_var_run_t) ② file_type_auto_trans(httpd_t, var_t, httpd_cache_t) ③ file_type_auto_trans(httpd_t, tmpfs_t, httpd_tmpfs_t)

リスト 3-103は、httpdから動的にローディングされるモジュール(DSO : Dynamic





Shared Object)を実行するための設定である。①はモジュールに付与された type

のファイルを httpd_t(httpd デーモン)が実行できるようにする can_exec マクロを

使用している。②can_exec マクロだけでは一部権限が不足するので、モジュールが

置かれているディレクトリの読み込み権限やリンクファイルの読み込み権限の設定

も行う必要がある(②、③)。

リスト 3-103 モジュールの実行権限

① can_exec(httpd_t, httpd_modules_t) ② allow httpd_t httpd_modules_t:dir r_dir_perms; ③ allow httpd_t httpd_modules_t:lnk_file r_file_perms;

(M) その他の権限

リスト 3-104 の①②は initrc_t(rc スクリプト)からモジュールのディレクトリ

およびユーザスクリプトのディレクトリの読み込み権限の設定である。③は、/etc

ディレクトリ下のファイル(たとえば、nisswitch.conf)の読み込み権限が必要な場

合設定を行う。③は/dev/null デバイスに対しての読み書き権限である。

リスト 3-104 その他の権限

① allow initrc_t httpd_modules_t:dir r_dir_perms; ② allow initrc_t httpd_user_script_rw_t:dir r_dir_perms; ③ allow httpd_t etc_t:file { read getattr }; ④ allow httpd_t null_device_t:chr_file rw_file_perms;

リスト 3-105 は、シェルの実行権限に関する設定であるが SELinux 付属のデフォ

ルトの設定ではコメントになっており、コメントをはずさない限りシェル(シェルス

クリプト ) を実行することができない。シェルを実行し、

httpd_sys_script_process_t に domain を遷移させたい場合は①を有効にし、

httpd_t のままの domain を維持したいのであれば②を有効にする。通常の CGI でも

同じことが言えるが、セキュリティホールを作りやすいので十分な注意が必要で、

安全な(システムに悪影響を与えない)domain で実行するようにすべきである。





リスト 3-105 シェルの実行権限

① #domain_auto_trans(httpd_t, shell_exec_t, httpd_sys_script_process_t) ② #can_exec(httpd_t, shell_exec_t)

(5) httpd_admin domain マクロ

WEB 管理者用のユーザ domain を定義するマクロが提供されている。ファイルは

“selinux/policy/domain/httpadm.te”で、その中身は“httpd_admin_domain”とい

うマクロ定義がされ、そのファイルの最後で当該マクロを使用している。

WEB 管理者用の domain には、WEB コンテンツ(システムおよびユーザ)、CGI スクリ

プト、コンフィギュレーションファイルのファイルにアクセスするためのすべての権

限が与えられる。

(A) httpd_adint_t domain の定義

順序は逆になるが httpadm.te ファイルの最後にリスト 3-106 に示すような定義

がある。これは、httpd_admin_t という domain の定義である(①)。httpd_admin_r

という role がこの domain に遷移することができ(②)、システムで標準的なアクセ

ス権限を every_domain マクロで与えている(③)。最後に、このファイル自身に定義

されている httpd_admin_domain マクロを使用して、WEB 管理者として必要なセキュ

リティポリシーの設定を行う(④)。httpd_admin_r は、selinux/policy/rbac ファイ

ルに定義されており、user_r(一般ユーザの role)および sysadm_r(システム管理者

の role)を持ったユーザから遷移できるように定義されている。

リスト 3-106 httpd_admin_t domain の定義

① type httpd_admin_t, domain; ② role httpd_admin_r types httpd_admin_t; ③ every_domain(httpd_admin_t) ④ httpd_admin_domain(httpd_admin)

本節以降は、上記リスト 3-106 の④で使用している httpd_admin_domain マクロ

の説明を行う。マクロ内で使用している“$1”は、マクロの第１引数、つまり

“httpd_admin”に置換される。





(B) ユーザ domain

リスト 3-107 は、user_domain マクロを使用して httpd_admin_t に一般ユーザと

同等の権利を与えるため設定である。たとえば、ホームディレクトリへのアクセス

権限や tty/pty デバイスへのアクセス権限等と一般ユーザがシステムにログイン後、

必要最低限の権限をこのマクロで付与している。

リスト 3-107 ユーザ domain の権限

user_domain($1)

(C) ファイルへのアクセス権限

httpd_admin_tの domainを与えられたWEB管理者に対して、システムのHTMLファ

イルや CGI スクリプト等の WEB コンテンツの作成・編集権限や Apache のコンフィ

ギュレーション関連ファイルの編集権限を設定する。

リスト内に記述されている“$1_t”というのは、httpd_admin_domain マクロの第

１引数である“httpd_admin”が$1 に置換され、その結果として“httpd_admin_t”

という文字列が生成され、“httpd_admin_t”という domain に対する権限の設定を行

うことを意味している。

リスト 3-108 は、Apache のコンフィギュレーションファイルを編集できるよう

にするための権限である。ファイルの作成権限やリンクファイルの作成権限等を付

与している。

リスト 3-108 コンフィギュレーションファイルへのアクセス権限

allow $1_t httpd_config_t:file create_file_perms; allow $1_t httpd_config_t:dir rw_dir_perms; allow $1_t httpd_config_t:lnk_file link_file_perms;

リスト 3-109 は、ログファイルは httpd のログファイルを参照および編集できる

ようにするための権限である。





リスト 3-109 ログファイルへのアクセス権限

allow $1_t httpd_log_files_t:file create_file_perms; allow $1_t httpd_log_files_t:dir rw_dir_perms ; allow $1_t httpd_log_files_t:lnk_file link_file_perms;

リスト 3-110 は、モジュール(/etc/httpd/modules)へのアクセス権限で、ファイ

ル・ディレクトリに対しては読み込み権限しか与えていない。つまり、プログラム

のインストール相当の権限は WEB 管理者には与えていないということである。

リスト 3-110 モジュールへのアクセス権限

allow $1_t httpd_modules_t:dir r_dir_perms; allow $1_t httpd_modules_t:file r_file_perms;

(D) プログラムの実行権限

リスト 3-111は、httpdプログラムの実行権限やシグナル等の送信権限であるが、

デフォルトではリストのようにコメントアウトされている。基本的に、httpd デー

モンの起動停止は、SELinux が提供している run_init コマンドを使用すべきで、WEB

管理者の domain から直接起動すべきではない。もし、この設定を有効にする場合は、

httpd_admin_tというdomainからhttpd_tにdomain遷移できるようなセキュリティ

ポリシーを apache.te 内に定義すべきである。

リスト 3-111 プログラムの実行権限

#allow $1_t httpd_exec_t:file rx_file_perms; #allow $1_t httpd_t:process{ sigkill sigstop signal transition};

リスト 3-112 およびリスト 3-113 は、type からわかるように WEB コンテンツ、

CGI スクリプトおよび htaccess ファイルの参照・編集権限である。

システムのコンテンツばかりでなく、ユーザのコンテンツに対してもその権限を

与えている。一般ユーザの WEB コンテンツにまで管理者がアクセスできるかどうか

は、そのシステムの運用をどのようにするかの問題であり、セキュリティポリシー

の設定とは別問題である。運用方針として、WEB 管理者にはアクセス許可を与えな

いと決定した場合は、“httpd_user_*_t”に対する定義文は削除するかコメントアウ





トしなければならない。

リスト 3-112 コンテンツ・スクリプトへのアクセス権限（１）

allow $1_t httpd_sys_content_t:file create_file_perms; allow $1_t httpd_user_content_t:file create_file_perms; allow $1_t httpd_sys_content_t:dir rw_dir_perms; allow $1_t httpd_user_content_t:dir rw_dir_perms; allow $1_t httpd_sys_content_t:lnk_file {create}; allow $1_t httpd_user_content_t:lnk_file {create}; allow $1_t httpd_sys_script_t:file create_file_perms; allow $1_t httpd_sys_script_t:dir create_dir_perms; allow $1_t httpd_sys_script_t:lnk_file {create}; allow $1_t httpd_sys_htaccess_t:file create_file_perms; allow $1_t httpd_sys_htaccess_t:lnk_file {create};

リスト 3-113 コンテンツ・スクリプトへのアクセス権限（２）

allow $1_t httpd_sys_script_r_t:file create_file_perms; allow $1_t httpd_sys_script_r_t:lnk_file {create}; allow $1_t httpd_sys_script_r_t:dir create_dir_perms; allow $1_t httpd_user_script_r_t:file create_file_perms; allow $1_t httpd_user_script_r_t:lnk_file {create}; allow $1_t httpd_user_script_r_t:dir create_dir_perms; allow $1_t httpd_sys_script_rw_t:file rw_file_perms; allow $1_t httpd_sys_script_rw_t:lnk_file {create}; allow $1_t httpd_sys_script_rw_t:dir rw_dir_perms; allow $1_t httpd_user_script_rw_t:file rw_file_perms; allow $1_t httpd_user_script_rw_t:lnk_file {create}; allow $1_t httpd_user_script_rw_t:dir rw_dir_perms; allow $1_t httpd_sys_script_a_t:file ra_file_perms; allow $1_t httpd_sys_script_a_t:lnk_file {create}; allow $1_t httpd_sys_script_a_t:dir ra_dir_perms; allow $1_t httpd_user_script_a_t:file ra_file_perms; allow $1_t httpd_user_script_a_t:lnk_file {create}; allow $1_t httpd_user_script_a_t:dir ra_dir_perms;

(E) domain の変更

リスト 3-114 は、newrole コマンドを使用して WEB 管理者の role になるための

設定である。①は newrole_t が使用していたファイルディスクリプタの使用権限、

②は WEB管理者を終了(起動シェルを exit)するときに newroleに対して SIGCHLDシ





グナルを送信する権限、③でシェルを起動する権限、④はログイン状態に入るため

の権限、⑤でプロセスの domain を httpd_admin_t に遷移させるための権限をそれぞ

れ与えている。システムのログインユーザとして“webadmin”を定義し、このユー

ザがログインしたときは通常のユーザ権限を与えておく。ログイン後、SELinux で

新規に提供されている newrole コマンドを使用して、“httpd_admin_r”の role に遷

移するような運用を考える必要がある。

リスト 3-114 domain の変更

① allow $1_t newrole_t:fd use; ② allow $1_t newrole_t:process {sigchld}; ③ can_exec($1_t, shell_exec_t) ④ allow $1_t shell_exec_t:file {entrypoint}; ⑤ allow newrole_t $1_t:process {transition};

(F) セキュリティコンテキスト設定権限

リスト 3-115 は、ファイルのセキュリティコンテキストを設定する権限を与えて

いる。CGI スクリプト、WEB コンテンツ、htaccess ファイルに対してのセキュリティ

コンテキスト設定権限が付与されている。





リスト 3-115 セキュリティコンテキスト設定権限

allow $1_t httpd_sys_script_t:dir {relabelto}; allow $1_t httpd_sys_script_a_t:dir {relabelto}; allow $1_t httpd_sys_script_r_t:dir {relabelto}; allow $1_t httpd_sys_script_rw_t:dir {relabelto}; allow $1_t httpd_user_script_t:dir {relabelto}; allow $1_t httpd_user_script_a_t:dir {relabelto}; allow $1_t httpd_user_script_r_t:dir {relabelto}; allow $1_t httpd_user_script_rw_t:dir {relabelto}; allow $1_t httpd_sys_script_a_t:file {relabelto}; allow $1_t httpd_sys_script_r_t:file {relabelto}; allow $1_t httpd_sys_script_rw_t:file {relabelto}; allow $1_t httpd_user_script_r_t:file {relabelto}; allow $1_t httpd_user_script_rw_t:file {relabelto}; allow $1_t httpd_user_script_a_t:file {relabelto}; allow $1_t httpd_sys_content_t:dir {relabelto}; allow $1_t httpd_user_content_t:dir {relabelto}; allow $1_t httpd_sys_content_t:file {relabelto}; allow $1_t httpd_sys_htaccess_t:file {relabelto}; allow $1_t httpd_user_content_t:file {relabelto}; allow $1_t httpd_user_htaccess_t:file {relabelto};





3.5.2. DNS サーバー

本節ではドメインネームシステム(DNS)を実装した２つのプログラムを取り上げて解説

を行う。１つは DNS を実装した代表的なソフトウェアパッケージである BIND、もう 1 つは

qmail で有名な D. J. Bernstein 氏が開発した djbdns である。

3.5.2.1. BIND 9

(1) BIND の概要

もっとも普及している DNS の実装は BIND(Berkeley Internet Name Domain)で、も

ともとは 4.3BSD 用に開発されたプログラムである。現在は、Internet Software

Consortium (ISC)30が開発を行っており無償で入手することができる。

Red Hat Linux では、バージョン 7.1 から BIND 9 を採用しており、Red Hat Linux 8.0

には BIND 9.2.1 が RPM パッケージとして組み込まれている。

表 3-9 に BIND 9 のディレクトリ構造を示す。当然であるが named.conf の記述次第

でゾーンファイルを格納するディレクトリパスや、named プログラムへのオプション

として“-t”を指定することにより named.conf 自身のパスも変更できる。

表 3-9 BIND 9 のディレクトリ構造


1 /etc/named.conf コンフィギュレーションファイル

2 /etc/rndc.* rndc 関連(conf、key)

3 /var/named/ ゾーンファイル用のディレクトリ

4 /usr/sbin/ named 等の実行プログラム

5 /var/run/named/ PID 用のファイル

SELinux が標準で提供しているセキュリティポリシーおよびファイルに付与するセ

キュリティコンテキストが想定しているディレクトリ構造は、表 3-9とは多少異なる。


BIND 用のファイル用のセキュリティコンテキストおよびセキュリティポリシーの

設定ファイルは表 3-10 に示すように SELinux に標準で組み込まれている。

30 http://www.isc.org/products/BIND/





表 3-10 BIND のポリシー設定ファイル一覧


1 policy/file_contexts/program/named.fc ファイルのセキュリティコンテキスト

2 policy/domains/program/named.te セキュリティポリシー


(A) 実行ファイル

リスト 3-116 は、BIND の実行ファイルのセキュリティコンテキストである。こ

れらのファイルが/usr/local 等の別の場所にインストールされている場合は、この

定義ファイルを変更しなければならない。

リスト 3-116 実行ファイルのセキュリティコンテキスト

/usr/sbin/lwresd system_u:object_r:named_exec_t /usr/sbin/named.* system_u:object_r:named_exec_t /usr/sbin/r?ndc system_u:object_r:ndc_exec_t

(B) コンフィギュレーションファイル

リスト 3-117 は、named プログラムおよび rndc コマンド用のコンフィギュレー

ションファイルに対するセキュリティコンテキストである。“named.conf”の設定に

よりゾーンファイルの格納ディレクトリを定義できるので、自システムの環境に合

わせて正確に設定しなければならない。

SELinux 標準の設定ファイルでは、①のように/var/named ディレクトリ以下に

“named_conf_t”type を付与している。通常、このディレクトリ下にはゾーンファ

イルが置かれるので、この設定には疑問が残る。3.5.2.1(3)(C)で記述するように

“named_zone_t”を付与すべきである。

まは、②に示すように rndc コマンド関連のコンフィギュレーションは、Red Hat

Linux では/etc ディレクトリ直下にインストールされるので、このような定義が必

要である。





リスト 3-117 conf ファイルのセキュリティコンテキスト

/etc/bind/named.conf system_u:object_r:named_conf_t /etc/named.conf system_u:object_r:named_conf_t ① /var/named(/.*)? system_u:object_r:named_conf_t /etc/bind/rndc.key system_u:object_r:rndc_conf_t ② /etc/rndc.* system_u:object_r:rndc_conf_t

(C) プライマリサーバー用ゾーンファイル

リスト 3-118 は、ゾーンファイルのセキュリティコンテキストである。通常

“named_zone_t”に対しては読み込み専用の設定をするが、ダイナミック DNS を使

用する場合は、書き込み権限を与える必要がある。3.5.2.1(4)(F)で述べるファイル

のアクセス権限でデフォルトでは読み込み専用で設定されている(r_dir_file マク

ロ使用)。これを、rw_dir_file マクロを使用して書き込みも許可する。

前節で述べたが、①に示すように/var/named ディレクトリ下は一般にゾーンファ

イル用に使用されるので、この行を追加して“named_zone_t”を付与すべきである。

リスト 3-118 ゾーンファイルのセキュリティコンテキスト

/etc/bind(/.*)? system_u:object_r:named_zone_t ① /var/named(/.*)? system_u:object_r:named_zone_t

(D) セカンダリサーバー用ゾーンファイル

リスト 3-119 は、BIND をセカンダリサーバーとして運用している場合の設定で

ある。つまり、プライマリサーバーからゾーンファイルを転送するため、ゾーンファ

イルに対する書き込み権限が必要になる。前節(C)の named_zone_t とは type を区別

しておいた方がより安全である。

プライマリサーバーと同じディレクトリ構造をとりたい場合は、①に示したよう

に/var/namedディレクトリ下にnamed_cache_tとう typeを設定することもできる。

もしくは、②のように“named_zone_t”type を設定し、セキュリティポリシー設定

時に“named_zone_t”type の読み書き権限を設定するという方法もある。





リスト 3-119 cache ファイルのセキュリティコンテキスト

/var/cache/bind(/.*)? system_u:object_r:named_cache_t ① /var/named(/.*)? system_u:object_r:named_cache_t ② /var/named(/.*)? system_u:object_r:named_zone_t

(E) PID 用ファイル

リスト 3-120は、namedおよびrndc用のプロセスIDを格納するファイルのセキュ

リティコンテキストである。Red Hat Linux 8.0 では、/var/run/named ディレクト

リ下に PID 用ファイルが作成されるので、①の設定が必要である。

リスト 3-120 PID 用ファイルのセキュリティコンテキスト

/var/run/bind(/.*)? system_u:object_r:var_run_named_t /var/run/ndc system_u:object_r:var_run_named_t ① /var/run/named(/.*)? system_u:object_r:var_run_named_t


(A) ポート type

リスト 3-121 は、named または rndc が使用するポートの type 定義である。一般

的に、①は 53 番ポート、②は 953 番ポートに設定されている。

リスト 3-121 ポートの type 定義

① type named_port_t, port_type; ② type rndc_port_t, port_type;

(B) domain 定義

リスト 3-122は、namedとndc/rndcのdomain定義である。namedはdaemon_domain

マクロを使用してデーモンとしての一般的な domain 定義マクロにより定義されて

いる(①)。このマクロを使用することによりnamed_tというdomainや named_exec_t

という実行ファイルに付与される type、initrc_t からの domain 遷移等の宣言が展





開される。②は ndc/rndc の domain 定義で、③はシステム管理者(sysadm_r)の role

に対してのみ ndc_t に遷移できることを許可している。④は ndc/rndc コマンドの実

行ファイル自身に付与される type の宣言である。⑤はその実行ファイルをシステム

管理者(sysadm_t)が実行したときに自動的にdomainをndc_tに遷移させる宣言であ

る。⑥は ndc/rndc コマンド実行時に必要なライブラリの実行権限の設定である。

リスト 3-122 named・ndc の domain 定義

① daemon_domain(named) ② type ndc_t, domain, privlog; ③ role sysadm_r types ndc_t; ④ type ndc_exec_t, file_type,sysadmfile, exec_type; ⑤ domain_auto_trans(sysadm_t, ndc_exec_t, ndc_t) ⑥ uses_shlib(ndc_t)

(C) named_t domain への権限設定

リスト 3-123 は、named_t(domain)に対して named_exec_t(type)を持つファイル

を実行できるようにするための定義で、can_exec マクロを使用してその権限設定を

行っている(①)。②は、sbin_t(type)を持つディレクトリ(/sbin、/usr/sbin)の検

索権限である。

リスト 3-123 named の実行許可

① can_exec(named_t, named_exec_t) ② allow named_t sbin_t:dir search;

リスト 3-124 は、named_t domain に対して sched_setscheduler や nice システ

ムコールを発行し、自身のプロセススケジューリングポリシーを変更できるように

する定義である。





リスト 3-124 sched_setscheduler の許可

allow named_t self:process setsched;

(D) ファイル type 宣言

リスト 3-125 は、BIND が使用するファイルに設定するセキュリティコンテキス

トの type 宣言である。①は named.conf、②は rndc.conf、③はプライマリサーバー

用ゾーンファイル、④はセカンダリサーバー用のゾーンファイルに設定する type

である。③、④を分ける理由は、named からプライマリサーバー用のゾーンファイ

ルは読み込み専用にし、セカンダリサーバー用のゾーンファイルはプライマリサー

バーから転送したゾーンデータを書き込める用にするために、type を分ける必要が

あるからである。

リスト 3-125 ファイルの type 宣言

① type named_conf_t, file_type, sysadmfile; ② type rndc_conf_t, file_type, sysadmfile; ③ type named_zone_t, file_type, sysadmfile; ④ type named_cache_t, file_type, sysadmfile;

(E) ケイパビリティ

リスト 3-126 は、named_t(named デーモン)自身がケイパビリティの設定をでき

るようにするための権限である。

リスト 3-126 ケイパビリティの設定権限

allow named_t self:process setcap;

リスト 3-127 は、named_t/ndc_t domain に対するケイパビリティの設定である。

①では named_t domain に対し、setuid(UID の設定)、setgid(GID の設定)、ソケッ

トの bind、chown/fowner(ファイルのオーナー、グループの変更)、dac_override (DAC

の無効化。任意アクセス制御の制限を無効化する)、nice(nice 値の変更)のそれぞ

れの権限を与える。②では ndc_t domain に対し、dac_override の権限を与えてい





る。

リスト 3-127 ケイパビリティの設定

① allow named_t named_t:capability { setuid setgid net_bind_service chown fowner dac_override sys_nice };② allow ndc_t self:capability dac_override;

(F) ファイルのアクセス権限

namedデーモンやndc/rndcコマンドに関連したファイルのアクセス権限を設定す

る。読み込み専用にしなければならないファイルや書き込みも必要ファイル等を考

えて設定する必要がある。

リスト 3-128 は、/etc ディレクトリ下のファイルに対する読み込み権限の設定

である。①、②は/etc ディレクトリ下の一般的なファイルおよびリンクファイル、

③はシステム実行時に作成されるファイルおよびリンクファイル、④は

/etc/resolv.con ファイルである。

リスト 3-128 /etc 下の読み込み権限

① allow named_t etc_t:{ file lnk_file } { getattr read }; ② allow ndc_t etc_t:dir r_dir_perms; ③ allow named_t etc_runtime_t:{ file lnk_file } { getattr read }; ④ allow named_t resolv_conf_t:file { getattr read };

リスト 3-129 は、リスト 3-125 で設定したファイルへのアクセス権限である。

①は named.conf に対する読み込み権限である。r_dir_file はマクロで、第 2 引数

に設定したディレクトリおよびファイルに読み込み権限を与える。②は、ゾーンファ

イルに対する読み込み権限で、③はセカンダリサーバー用のゾーンファイルに対す

る読み書き権限である。④は ndc/rndc 用のコンフィギュレーションファイルに対す

る読み込み権限で、named_t、ndc_t、initrc_t のそれぞれに対して許可を行ってい

る。ダイナミック DNS を利用してゾーンファイルを自動的に更新する場合は

named_zone_t に対して書き込み権限を与える必要があるので、②の r_dir_file マ

クロを rw_dir_file マクロに変更する必要がある。





リスト 3-129 ファイルのアクセス権限

① r_dir_file(named_t, named_conf_t) ② r_dir_file(named_t, named_zone_t) ③ rw_dir_create_file(named_t, named_cache_t) ④ allow { named_t ndc_t initrc_t } rndc_conf_t:file { getattr read };

(G) ネットワーク関連の権限

リスト 3-130 は、ネットワーク関連の設定である。①は UDP/TCP のソケットの作

成や使用を許可するマクロで、named_t domain にその許可を与えている。②、③、

④は、named_t(named デーモン)以外からの domain(プログラム)からの UDP パケット

の送受信、TCP の接続および送受信の許可を設定している。⑤、⑥では、named_port_t

および rndc_port_t のそれぞれのポートに対する udp/tcp の bind の許可である。

リスト 3-130 ネットワーク関連の権限

① can_network(named_t) ② can_udp_send(domain, named_t) ③ can_udp_send(named_t, domain) ④ can_tcp_connect(domain, named_t) ⑤ allow named_t named_port_t:udp_socket name_bind; ⑥ allow named_t { named_port_t rndc_port_t }:tcp_socket name_bind;

リスト 3-131 は、UNIX(LOCAL)ドメインプロトコルを利用した STREAM 型と DGRAM

型のソケットを作成および使用する許可である。

リスト 3-131 UNIX ドメインプロトコル用ソケットの権限

allow named_t self:unix_stream_socket create_stream_socket_perms; allow named_t self:unix_dgram_socket create_socket_perms;

リスト 3-132は、ndc_tに対してネットワーク関連の権限を付与する設定である。

①は、can_network マクロによりソケットの作成、パケットの送受信を許可する設

定である。②の can_tcp_connect マクロにより ndc_t が named_t(named デーモン)

に対して、TCP によるソケットの接続、パケットの送受信を許可している。③、④

は ndc_t 自身に対し、⑤は named_t に対して UNIX(LOCAL)ドメインプロトコルを利





用したい STREAM 型のソケットの作成および接続権限の設定である。⑥は

var_run_named_t type のソケットファイルに対しての読み書き権限の設定である。

リスト 3-132 ndc_t のネットワーク関連の権限

① can_network(ndc_t) ② can_tcp_connect(ndc_t, named_t) ③ allow ndc_t self:unix_stream_socket create_stream_socket_perms; ④ allow ndc_t self:unix_stream_socket connect; ⑤ allow ndc_t named_t:unix_stream_socket connectto; ⑥ allow ndc_t var_run_named_t:sock_file rw_file_perms;

(H) システム情報の読み込み権限

リスト 3-133 は、/proc/sys ディレクトリ下のファイル、つまりカーネルのコン

フィギュレーションパラメータを読み込むための権限設定である。①は/proc/sys

ディレクトリ、②、③は/proc/sys/kernel ディレクトリおよびそのファイルに相当

する。同様に、①’②’③’は ndc_t(ndc/rndc コマンド)に対する読み込み権限の設定

である。④、⑤も同様に/proc ディレクトリ下のディレクトリおよびファイルに対

する読み込み権限の設定である。目的としては/proc/cpuinfo ファイルからの情報

取得である。

リスト 3-133 カーネルパラメータの読み込み権限

① allow named_t sysctl_t:dir r_dir_perms; ② allow named_t sysctl_kernel_t:dir r_dir_perms; ③ allow named_t sysctl_kernel_t:file r_file_perms; ①’ allow ndc_t sysctl_t:dir r_dir_perms; ②’ allow ndc_t sysctl_kernel_t:dir r_dir_perms; ③’ allow ndc_t sysctl_kernel_t:file r_file_perms; ④ allow named_t proc_t:dir r_dir_perms; ⑤ allow named_t proc_t:file r_file_perms;

(I) その他のアクセス権限

リスト 3-134 は、/dev/random デバイスに対する読み込み権限の設定である。①

の設定で、/dev ディレクトリの読み込み権限を与え、②で/dev/random デバイスに

対する読み込み権限を与えている。





リスト 3-134 random デバイスの読み込み権限

① allow named_t device_t:dir r_dir_perms; ② allow named_t random_device_t:chr_file r_file_perms;

リスト 3-135 は、named_t(named デーモン)自身が作成する FIFO ファイル(パイ

プファイル)への読み書き権限の設定である。

リスト 3-135 FIFO ファイルの読み込み権限

allow named_t self:fifo_file rw_file_perms;

リスト 3-136 は、前述以外で ndc_t に必要な権限をまとめたものである。①は、

ndc コマンドが端末(tty)に対してメッセージを出力したり、ユーザからの入力を求

めたりするために、tty デバイスに対する読み書きの権限設定である。②は、ndc_t

自身が fork システムコールを発行したり、シグナルを送信したりする権限の設定で

ある。③は、FIFO ファイル(パイプ)に対する読み書き権限で、④はゾーンファイル

が置かれているディレクトリのサーチ権限の設定である。⑤は、login、sshd、newrole

から継承したファイルディスクリプタを使用する権限の設定である。

リスト 3-136 その他の ndc_t への権限

① allow ndc_t admin_tty_type:chr_file { getattr read write }; ② allow ndc_t self:process { fork signal_perms }; ③ allow ndc_t self:fifo_file { read write getattr ioctl }; ④ allow ndc_t named_zone_t:dir search; ⑤ allow ndc_t privfd:fd use;





3.5.2.2. djbdns

(1) djbdns の概要

djbdns は、qmail で有名な D. J. Bernstein 氏の作品で、「安全、確実、高速、簡潔、

設定も簡単な DNS サービスとツール群」として紹介31されている。

djbdns および関連プログラム(daemontools、ucspi-tcp)は Red Hat Linux では標準

パッケージとして用意されておらず、また SELinux でもそれらのセキュリティポリ

シーは準備されていない。また、後述するように djbdns は SELinux と相性が悪いため

多少トリッキーな方法をとらなければならないのが難点である。

djbdns は、補助プログラムとして daemontools や ucspi-tcp が必要であり、djbdns

も含めて事前にインストールされているものとして説明を行う。プログラムのインス

トールディレクトリパスはソースパッケージからビルドするときの標準的なまたは習

慣的に使用されるパスを使用する。

表 3-11 djbdns 関連プログラムのインストールパス一覧


1 /package daemontools のソースのインストール先ディレクトリ

2 /package/admin/(次行に続く)daemontools-x.xx/command

このディレクトリに実行プログラムの実体がインストールされる。x.xx はバージョン番号で、現在は“0.76”である。

3 /command daemontools の実行プログラムの

4 /service svscan プログラムの監視対象ディレクトリ

5 /usr/local/bin djbdns 関連の実行プログラムのインストール先ディレクトリ

6 /var/dnscache ローカルキャッシュサーバー用管理ディレクトリ

7 /var/dnscachex 外部キャッシュサーバー用管理ディレクトリ

8 /var/tinydns ゾーン DNS サーバー用管理ディレクトリ

9 /var/axfrdns ゾーン転送用管理ディレクトリ

djbdns を起動する場合は、#6 から#9 に示すようなディレクトリを/service ディレ

クトリにシンボリックリンクを張ることにより daemontools が自動的に目的のプログ

ラムを起動してくれる。daemontools は管理ディレクトリ内の log ディレクトリにロ

グを出力するほか、run スクリプトも生成する。また、SELinux のコンセプトとしては、

「ログファイル」と「実行ファイル」には別々のセキュリティコンテキストをラベル

付けして、読み書きのアクセス権限やプログラム実行時の domain 遷移を設定しなけれ

31 http://djbdns.qmail.jp/ 日本語関連のページ





ばならない。ファイルの type を自動的に遷移する file_type_auto_trans マクロが用

意されているが、複数の type(ログファイル用と実行ファイル用)に遷移させることは

できないので、djbdns および daemontools を SELinux 上で使用する場合は工夫が必要

である。1つは、daemontools を修正して run スクリプトを log ディレクトリ下に作成

しないようにすることだが、これは現実的ではない。もう 1つは、permissive モード

で djbdns を実行させた後、つまり実行時に作成されるファイルがすべて作成された後

に、ファイルのセキュリティコンテキストを設定する方法である。run スクリプトは

一旦作成されると変更されないため、この方法でも問題ない。実行後作成されるファ

イルとしては、“supervise”もある。

selinux/policy ディレクトリ下で“make relabel”を実行する方法もあるが、ファ

イルひとつを変更する場合は、chcon コマンドを使用してリスト 3-137 のように設定

する方法もある(①)。また、②のように setfiles コマンドを使用して、djbdns に関

連してファイルのセキュリティコンテキストをすべて設定しなおす方法もある。この

例は、管理ディレクトリが“/var/dnscache”を想定している。

リスト 3-137 ファイルコンテキストの設定例

① chcon system_u:object_r:djbdns_exec_t /var/dnscache/log/run ② setfiles /usr/src/selinux/policy/file_contexts/program/djbdns.fc /var


djbdnsおよびdaemontoolsのセキュリティポリシーおよびファイルのセキュリティ

コンテキスト定義ファイルは標準で組み込まれていない。表 3-12 に djbdns の、表

3-13 に daemontools の設定ファイルの名称を例として記載する。次節に説明するセ

キュリティポリシーとセキュリティコンテキストをそれぞれのファイルに記述してシ

ステムに組み込む必要がある。

表 3-12 djbdns のポリシー設定ファイル一覧


1 policy/file_contexts/program/djbdns.fc ファイルのセキュリティコンテキスト

2 policy/domains/program/djbdns.te セキュリティポリシー





表 3-13 daemontools のポリシー設定ファイル一覧


1 policy/file_contexts/program/daemontools.fc ファイルのセキュリティコンテキスト

2 policy/domains/program/daemontools.te セキュリティポリシー


(A) daemontools 関連のセキュリティコンテキスト

リスト 3-138 は、daemontools 関連のファイルのセキュリティコンテキスト一覧

である。①は daemontools のコマンドのシンボリックリンクがインストールされる

ディレクトリである。②はコマンドのシンボリックリンクだがこのファイルには実

行ファイルと同じ“daemontools_exec_t”の type を付与する。③は各種デーモンの

管理ディレクトリをシンボリックリンクするための監視用ディレクトリで、

“daemontools_serv_t”という type を付与する。④は daemontools のトップディレ

クトリで、この下にソースファイルやコマンドの実体が置かれる。ソースファイル

等には新規 type を付与する必要はないので“src_t”とし、⑤でコマンド類には

“daemontools_exec_t”という実行プログラムであることを識別できるような名称

の type を付与する。

リスト 3-138 daemontools のセキュリティコンテキスト

① /command system_u:object_r:bin_t ② /command/(.*)? system_u:object_r:daemontools_exec_t③ /service(/.*)? system_u:object_r:daemontools_serv_t④ /package(/.*)? system_u:object_r:src_t ⑤ /package/admin/daemontools.*/command(/.*)? system_u:object_r:daemontools_exec_t

(B) djbdns 関連のセキュリティコンテキスト

リスト 3-139 は、root サーバーの IP アドレスを格納するファイルである。BIND

でいうこところの“named.root”や“named.ca”ファイルに相当する。





リスト 3-139 dnsroots.global 用セキュリティコンテキスト

/etc/dnsroots.global system_u:object_r:djbdns_etc_t

リスト 3-140 は、djbdns の実行プログラムに付与するセキュリティコンテキス

トである。デフォルトのインストール先は/usr/local/bin ディレクトリである。

リスト 3-140 djbdns の実行ファイルのセキュリティコンテキスト

/usr/local/bin/axfr-get system_u:object_r:djbdns_exec_t /usr/local/bin/axfrdns.* system_u:object_r:djbdns_exec_t /usr/local/bin/dnscache.* system_u:object_r:djbdns_exec_t /usr/local/bin/dnsfilter system_u:object_r:djbdns_exec_t /usr/local/bin/dnsip system_u:object_r:djbdns_exec_t /usr/local/bin/dnsipq system_u:object_r:djbdns_exec_t /usr/local/bin/dnsmx system_u:object_r:djbdns_exec_t /usr/local/bin/dnsname system_u:object_r:djbdns_exec_t /usr/local/bin/dnsq system_u:object_r:djbdns_exec_t /usr/local/bin/dnsqr system_u:object_r:djbdns_exec_t /usr/local/bin/dnstrace system_u:object_r:djbdns_exec_t /usr/local/bin/dnstracesort system_u:object_r:djbdns_exec_t /usr/local/bin/dnstxt system_u:object_r:djbdns_exec_t /usr/local/bin/pickdns.* system_u:object_r:djbdns_exec_t /usr/local/bin/random-ip system_u:object_r:djbdns_exec_t /usr/local/bin/rbldns.* system_u:object_r:djbdns_exec_t /usr/local/bin/tinydns.* system_u:object_r:djbdns_exec_t /usr/local/bin/walldns.* system_u:object_r:djbdns_exec_t

リスト 3-141(ローカルキャッシュサーバー)、リスト 3-142(外部キャッシュ

サーバー、リスト 3-143(ゾーン DNS サーバー)、リスト 3-144(ゾーン転送用サー

バー)は、DNS サーバーを構築する際の目的別の管理ディレクトリである。それぞれ

の管理ディレクトリは、dnscache-conf、tinydns-conf、axfrdns-conf コマンドで

作成される。管理ディレクトリの構造を簡単に表 3-14 に説明する。





表 3-14 管理ディレクトリの構造

# ディレクトリ・ファイル内容

1 env ディレクトリプログラムの動作パラメタで、ファイル名が環境変数名、ファイル内容がその値となる

2 log ディレクトリログ格納ディレクトリ。run スクリプトも含まれる

3 root ディレクトリクライアントのIPアドレス、rootサーバー、DNSサーバーを登録するディレクトリ、tinydns の data ファイル等が置かれる。

4 supervise ディレクトリ supervise コマンドがデーモンを監視する作業ディレクトリ

5 run スクリプトデーモンを起動するスクリプト

管理ディレクトリを作成する権限の設定は行っていないため、必ず permissive

モードで作成しなければならない。また、log ディレクトリ下の run スクリプトや

supervise ディレクトリはプログラムが起動された後に作成されるので、セキュリ

ティコンテキストの再設定が必要である。

また、それぞれの管理ディレクトリの構成は使用目的により多少異なるが、ほぼ

同じ構成をとっている。ファイルのセキュリティコンテキストを定義する場合に注

意しなければならないのは、リスト 3-141 のリストの例で説明すると、①の log お

よびそのディレクトリ下のファイルに対するセキュリティコンテキストの定義と、

②の log/run ファイルに対するセキュリティコンテキストの定義の順序である。こ

の順序を逆にすると、log/run ファイルにログファイルの type“djbdns_ver_log_t”

が付与されてしまい、run スクリプトを実行できなくなる。

リスト 3-141 は、ローカルキャッシュサーバー用のファイル構成とそのファイル

群に付与するセキュリティコンテキストである。ローカルキャッシュサーバーとは、

単独で稼動しているマシンで、外部 DNS を参照するキャッシュサーバーである。自

システム内からのみの名前解決要求が出されるサーバーである。

リスト 3-141 ローカルキャッシュサーバー用管理ディレクトリ

/var/dnscache system_u:object_r:djbdns_var_t /var/dnscache/env(/.*)? system_u:object_r:djbdns_var_env_t ① /var/dnscache/log(/.*)? system_u:object_r:djbdns_var_log_t /var/dnscache/root(/.*)? system_u:object_r:djbdns_var_root_t /var/dnscache/seed system_u:object_r:djbdns_var_seed_t /var/dnscache/supervise(/.*)? system_u:object_r:djbdns_var_supervise_t /var/dnscache/run system_u:object_r:djbdns_exec_t ② /var/dnscache/log/run system_u:object_r:djbdns_exec_t

リスト 3-142 は、外部キャッシュサーバー用のファイル構成とそのファイル群に





付与するセキュリティコンテキストである。外部キャッシュサーバーとは

localhost 以外のマシンから利用可能なサーバーで、構造的にはローカルキャッ

シュサーバーとほぼ同じである。

リスト 3-142 外部キャッシュサーバー用管理ディレクトリ

/var/dnscachex system_u:object_r:djbdns_var_t /var/dnscachex/env(/.*)? system_u:object_r:djbdns_var_env_t /var/dnscachex/log(/.*)? system_u:object_r:djbdns_var_log_t /var/dnscachex/root(/.*)? system_u:object_r:djbdns_var_root_t /var/dnscachex/seed system_u:object_r:djbdns_var_seed_t /var/dnscachex/supervise(/.*)? system_u:object_r:djbdns_var_supervise_t /var/dnscachex/run system_u:object_r:djbdns_exec_t /var/dnscachex/log/run system_u:object_r:djbdns_exec_t

リスト 3-143 は、ゾーン DNS サーバー用のファイル構成とそのファイル群に付与

するセキュリティコンテキストである。ゾーン DNS サーバーとは特定ホストのホス

ト名情報を受け持つ DNS サーバーである。

リスト 3-143 ゾーン DNS サーバー用管理ディレクトリ

/var/tinydns system_u:object_r:djbdns_var_t /var/tinydns/env(/.*)? system_u:object_r:djbdns_var_env_t /var/tinydns/log(/.*)? system_u:object_r:djbdns_var_log_t /var/tinydns/root(/.*)? system_u:object_r:djbdns_var_root_t /var/tinydns/root/add-alias system_u:object_r:djbdns_exec_t /var/tinydns/root/add-childns system_u:object_r:djbdns_exec_t /var/tinydns/root/add-host system_u:object_r:djbdns_exec_t /var/tinydns/root/add-mx system_u:object_r:djbdns_exec_t /var/tinydns/root/add-ns system_u:object_r:djbdns_exec_t /var/tinydns/seed system_u:object_r:djbdns_var_seed_t /var/tinydns/supervise(/.*)? system_u:object_r:djbdns_var_supervise_t /var/tinydns/run system_u:object_r:djbdns_exec_t /var/tinydns/log/run system_u:object_r:djbdns_exec_t

リスト 3-144 は、djbdns からセカンダリサーバーとして運用している BIND に

ゾーンを転送する場合の、管理ディレクトリのファイル構成とそのファイル群に付

与するセキュリティコンテキストである。





リスト 3-144 ゾーン転送用管理ディレクトリ

/var/axfrdns system_u:object_r:djbdns_var_t /var/axfrdns/Makefile system_u:object_r:djbdns_var_t /var/axfrdns/env(/.*)? system_u:object_r:djbdns_var_env_t /var/axfrdns/log(/.*)? system_u:object_r:djbdns_var_log_t /var/axfrdns/tcp.* system_u:object_r:djbdns_var_tcp_t /var/axfrdns/supervise(/.*)? system_u:object_r:djbdns_var_supervise_t /var/axfrdns/run system_u:object_r:djbdns_exec_t /var/axfrdns/log/run system_u:object_r:djbdns_exec_t


(A) daemontools の domain 定義

リスト 3-145 は、daemontools の domain 定義である(①)。②は system_r role

から daemontools_t domain への遷移を許可する設定である。③はマクロ定義で

“daemontools_t”に共通操作の権限(システムファイルの読み込み権限や/tmp への

書き込み権限等)を与える。

リスト 3-145 daemontools の domain 定義

① type daemontools_t, domain, privlog; ② role system_r types daemontools_t; ③ every_domain(daemontools_t)

(B) daemontools のファイル type 宣言

リスト 3-146は、daemontoolsで使用するディレクトリ・ファイルに付与するtype

である。実行プログラムには“daemontools_exec_t”を、/service ディレクトリお

よびその配下のファイル ( 一般的にはシンボリックリンク ) には

“daemontools_serv_t”の type を付与する。





リスト 3-146 daemontools の type 宣言

type daemontools_exec_t, file_type, sysadmfile, exec_type; type daemontools_serv_t, file_type, sysadmfile;

(C) daemontools の domain 遷移

リスト 3-147 は、daemontools の domain 遷移の定義である。Linux システムで

daemontools をインストールすると、起動スクリプト/command/svscanboot が

/etc/inittab に追加され、システムが立ち上がると自動的に daemontools も起動さ

れる。通常のデーモンはrcスクリプトを経由して起動されるが、daemontoolsはinit

プロセスから直接起動されるので、①に記述したような domain 遷移が必要である。

②は、daemontools 関連コマンドの実体がおかれているディレクトリの検索権限

を init プロセスに与える設定である。

リスト 3-147 daemontools の domain 遷移

① domain_auto_trans(init_t, daemontools_exec_t, daemontools_t) ② allow init_t daemontools_exec_t:dir { search };

(D) daemontools のプログラム実行権限

リスト 3-148 は、daemontools_t domain に付与するプログラムの実行権限であ

る。can_exec マクロを使用し、daemontools 関連のコマンド、/usr/bin/や/bin 関

連のコマンド、シェル(シェルスクリプト)の実行権限を与えている。

リスト 3-148 daemontools_t domain によるプログラムの実行権限

can_exec(daemontools_t, { daemontools_exec_t bin_t shell_exec_t })

(E) daemontools のファイルアクセス権限

リスト 3-149 は、daemontools_t domain に対して daemontools 関連のコマンド

がおかれているディレクトリの読み込み権限(①)、/service ディレクトリおよびそ

の下に作成されたリンクファイルの読み込み権限(②、③)の設定である。





リスト 3-149 ディレクトリ・ファイルの読み込み許可

① allow daemontools_t daemontools_exec_t:dir r_dir_perms; ② allow daemontools_t daemontools_serv_t:dir r_dir_perms; ③ allow daemontools_t daemontools_serv_t:lnk_file r_file_perms;

(F) 管理ディレクトリのアクセス権限

リスト 3-150 は、daemontools が djbdns の管理ディレクトリにアクセスする際

に必要な権限の設定である。①、②、③は log ディレクトリおよびその配下のファ

イル・FIFO ファイル(パイプファイル)の作成・読み書き権限である。④、⑤、⑥は

supervise ディレクトリおよびその配下のファイル・FIFO ファイルの作成・読み書

き権限である。⑦は管理ディレクトリ自身に対する読み込み権限である。

リスト 3-150 daemontools の管理ディレクトリに対する権限

① allow daemontools_t djbdns_var_log_t:dir create_dir_perms; ② allow daemontools_t djbdns_var_log_t:file create_file_perms; ③ allow daemontools_t djbdns_var_log_t:fifo_file rw_file_perms; ④ allow daemontools_t djbdns_var_supervise_t:dir create_dir_perms; ⑤ allow daemontools_t djbdns_var_supervise_t:fifo_file create_file_perms; ⑥ allow daemontools_t djbdns_var_supervise_t:file create_file_perms; ⑦ allow daemontools_t djbdns_var_t:dir r_dir_perms;

(G) ポート type 設定

リスト 3-151 は、named_port_t type の定義であるが、m4 マクロプロセッサの

ifdef 文で囲まれている。これは 3.5.2.1BIND 9 のリスト 3-121 の定義と重複しな

いようにするためで、“named.te”があれば(定義されていれば)何も展開されないし、

なければ①の文が展開され“named_port_t”の port_type として定義される。

リスト 3-151 ポートの type の定義

ifdef(`named.te',`',` ① type named_port_t, port_type; ')





(H) djbdns の domain 定義

リスト 3-152 は、djbdns の domain(①)とそれに付随した定義である。②、③は

system_r role と sysadm_r role から djbdns_t domain への遷移許可を与えるもの

である。④は、djbdns_t に共通操作の権限(システムファイルの読み込み権限や/tmp

への書き込み権限等)を与える。

リスト 3-152 djbdns の domain 定義

① type djbdns_t, domain, privlog; ② role system_r types djbdns_t; ③ role sysadm_r types djbdns_t; ④ every_domain(djbdns_t)

(I) djbdns のファイル type

リスト 3-153 は、djbdnsに関連したディレクトリやファイルの type宣言である。

①は/etc/dnsroots.global ファイルである。②は djbdns の実行プログラムに割り

当てる type の宣言である。③から⑨は表 3-14 に示した管理ディレクトリに対する

type である。それぞれ識別しやすいような名称をつけている。⑩はゾーン転送時に

必要な tcpserver(ucspi-tcp)が使用するアクセス制御用ファイルに付与する type

である。

リスト 3-153 djbdns 関連ファイルの type 宣言

① type djbdns_etc_t, file_type, sysadmfile; ② type djbdns_exec_t, file_type, sysadmfile, exec_type; ③ type djbdns_var_env_t, file_type, sysadmfile; ④ type djbdns_var_log_t, file_type, sysadmfile; ⑤ type djbdns_var_root_t, file_type, sysadmfile; ⑥ type djbdns_var_run_t, file_type, sysadmfile; ⑦ type djbdns_var_seed_t, file_type, sysadmfile; ⑧ type djbdns_var_t, file_type, sysadmfile; ⑨ type djbdns_var_supervise_t, file_type, sysadmfile; ⑩ type djbdns_var_tcp_t, file_type, sysadmfile;

(J) djbdns の domain 遷移

リスト 3-154 は djbdns domain への遷移を定義している。①はシステム管理者が





djbdns 関連コマンドを実行したときの domain 遷移である。これはシステム管理者

(sysadm_r role を割り当てられたユーザ)が、djbdns の管理ディレクトリを作成す

るために dnscache-conf コマンドや tinydns-conf コマンドを実行するが、このとき

に正しく domain の遷移を行うためである。②は djbdns 関連のプログラムが

daemontools から起動されたときの domain 遷移である。

リスト 3-154 djbdns の domain 遷移

① domain_auto_trans(sysadm_t, djbdns_exec_t, djbdns_t) ② domain_auto_trans(daemontools_t, djbdns_exec_t, djbdns_t)

(K) プログラムの実行権限

リスト 3-155 は、djbdns_t domain によるプログラムの実行権限である。一般コ

マンド(/bin、/usr/bin 等)、daemontools 関連、シェルスクリプト、djbdns 自身の

それぞれのプログラム実行権限を与えている。

リスト 3-155 djbdns_t domain によるプログラムの実行権限

can_exec(djbdns_t, { bin_t daemontools_exec_t shell_exec_t djbdns_exec_t } )

(L) djbdns のケイパビリティ

リスト 3-156 は、djbdns_t domain に設定するケイパビリティである。root ユー

ザから起動されるので、より安全にするために一般ユーザに変わる必要がある。そ

のために、setuid(UID の設定)、getgid(GID の設定)を行う権限である。また、ソケッ

トの bind、chroot(管理ディレクトリの root に chroot する)のそれぞれのケイパビ

リティが必要である。

リスト 3-156 ケイパビリティの設定

allow djbdns_t djbdns_t:capability { setuid setgid net_bind_service sys_chroot };





(M) bind の設定

リスト 3-157 は、djbdns_t domain が、named_port_t の TCP および UDP ポートに

対する bind の権限を与えている。

リスト 3-157 bind の設定

allow djbdns_t named_port_t:udp_socket { name_bind }; allow djbdns_t named_port_t:tcp_socket { name_bind };

(N) ファイルアクセス権限

リスト 3-158 は、djbdns_t domain に対するディレクトリやファイルのアクセス

許可である。①は daemontools のコマンド類が格納されているディレクトリの検索

権限である。②から⑪は管理ディレクトリ下のディレクトリおよびファイルに対す

るアクセス権限である。④から⑦は、ログファイルやデータファイルを作成する必

要があるので作成・読み書き権限が付与されている。

リスト 3-158 ファイルのアクセス許可

① allow djbdns_t daemontools_exec_t:dir { search }; ② allow djbdns_t djbdns_var_env_t:dir r_dir_perms; ③ allow djbdns_t djbdns_var_env_t:file r_file_perms; ④ allow djbdns_t djbdns_var_log_t:dir create_dir_perms; ⑤ allow djbdns_t djbdns_var_log_t:file create_file_perms; ⑥ allow djbdns_t djbdns_var_root_t:dir create_dir_perms; ⑦ allow djbdns_t djbdns_var_root_t:file create_file_perms; ⑧ allow djbdns_t djbdns_var_seed_t:file r_file_perms; ⑨ allow djbdns_t djbdns_var_t:dir r_dir_perms; ⑩ allow djbdns_t null_device_t:chr_file { read }; ⑪ allow djbdns_t djbdns_var_tcp_t:file r_file_perms;





3.5.3. SMTP サーバー

本節では、SMTP サーバーを構築する際の設定指針を解説する。SELinux には sendmail、

qmail、および postfix のためのセキュリティポリシー定義が標準で用意されている。ここ

では、これらの標準セキュリティポリシーを解説し、その留意点を明らかにする。

SMTP サーバーに関連するセキュリティポリシー定義ファイルは sendmail、qmail、およ

び postfix の各々に固有な定義ファイルと、MTA として共通なセキュリティポリシーを定義

した共通定義ファイルから構成されている。個々の SMTP サーバーに関するセキュリティポ

リシー定義を理解するためには、SMTP サーバーに共通なセキュリティポリシー定義をあら

かじめ十分に把握しておく必要があるだろう。SMTP サーバーに共通のセキュリティポリ

シー定義は 3.5.3.4 にて解説している。

3.5.3.1. sendmail

本節では、sendmail を利用した SMTP サーバー構築の際の設定指針として、SELinux に標

準で用意されているセキュリティポリシー定義を解説し、その留意点を明らかにする。

本ガイドラインで利用を想定しているsendmailのバージョンは8.12.5である。これは、

Red Hat Linux 8.0 のインストール CD に含まれている sendmail のバージョンに等しい。バー

ジョン 8.12 では、セキュリティ関連の見直しの結果としてその仕様が大きく変更されてい

るのはご存知だろうか。sendmail は MTA としての機能と MSA としての機能の双方を有する

プログラムであるが、従来は MSA として機能する場合にも root 特権を獲得して稼動してい

た。これは単純に、MTA として機能する際に root 特権が必要であるからだと思われる。し

かし MSA として機能する限りは root 特権ほどの権限は必要ないためセキュリティ上好まし

くない。この点が考慮され、バージョン 8.12 からは MTA として機能するプロセスと MSA と

して機能するプロセスとが分離されたのである。本ガイドラインで利用を想定している

バージョンの SELinux に含まれている標準セキュリティポリシー定義では、この仕様変更

が考慮されていないため、ローカルからメールを発信する際に問題が発生する。この点に

関しては 3.5.3.1(6)にて解説しているので参考にしてほしい。

(1) ディレクトリ構造

Red Hat Linux 8.0 のインストール CD に含まれる RPM パッケージから sendmail を

インストールした際のディレクトリ構造を表 3-15 に示す。以降ではこのディレクト





リ構造に則してセキュリティポリシー定義を解説する。なお同表ではドキュメント

ファイルあるいは man ページ等のインストール先は記載していないので注意してほし

い。

表 3-15 sendmail のディレクトリ構造

＃ファイルパス内容

1 /etc/ エイリアスファイルの配置先

2 /etc/mail/ エイリアスファイル以外のコンフィギュレーションファイルの配置先

3 /etc/pam.d/ PAM32における SMTP 用のコンフィギュレーションファイルの配置先

4 /etc/rc.d/init.d/ initrc スクリプトの配置先

5 /etc/smrsh/ smrsh シェルから起動を許可するプログラム配置先

6 /etc/sysconfig/ sendmail の initrc スクリプトより参照される各種定数が定義されたファイルの配置先

7 /usr/bin/ sendmail本体へのリンクファイルと管理用コマンドへのリンクファイルの配置先

8 /usr/lib/ sendmail 本体へのリンクファイルの配置先

9 /usr/lib/sasl/ Cyrus SASL ライブラリが SMTP サーバーから利用される際に読み込むコンフィギュレーションファイルの配置先

10 /usr/sbin/ sendmail 本体をはじめ、幾つかの管理用コマンドの配置先

11 /var/log/ ログファイルの出力先

12 /var/mail/ /var/spool/mail へのシンボリックリンク

13 /var/run/ PID ファイルの作成先

14 /var/spool/clientmqueue/ クライアントキューディレクトリ

15 /var/spool/mail/ スプールディレクトリ

16 /var/spool/mqueue/ キューディレクトリ

17 /var/tmp/ デッドレターの出力先


sendmail に関連するセキュリティポリシー定義ファイルを表 3-16 に示す。

32 PAM（Pluggable Authentication Modules）は、汎用的なユーザ認証メカニズムを提供するモジュールで

ある。Red Hat Linux では、Linux-PAM と呼ばれる実装モジュールが利用されている。

http://www.kernel.org/pub/linux/libs/pam/





表 3-16 sendmail のセキュリティポリシー定義ファイル一覧

＃ファイルパス説明

1 file_contexts/program/sendmail.fc sendmail に関連するファイルに対してアタッチするセキュリティコンテキストを定義したファイル

2 macros/program/sendmail_macros.te sendmail に関連したマクロを定義したファイル

3 domains/program/sendmail.te sendmail のセキュリティポリシーを定義したファイル

なお、SMTP サーバー共通のセキュリティポリシー定義ファイルに関しては

3.5.3.4(1)を参照してほしい。

(3) オブジェクトのセキュリティコンテキスト

sendmail に関連した各種オブジェクトに対してアタッチされるセキュリティコン

テキストを解説する。

(A) ファイルのセキュリティコンテキスト

sendmail に関連するファイルとディレクトリにアタッチするセキュリティコン

テキストはファイル file_contexts/program/sendmail.fc にて定義されており、

3.5.3.1 のディレクトリ構造に基いて設計されている。ファイル sendmail.fc の内

容をリスト 3-159 に示す。

リスト 3-159 file_contexts/program/sendmail.fc

① /etc/mail(/.*)? system_u:object_r:etc_mail_t ② /var/spool/mqueue(/.*)? system_u:object_r:mqueue_spool_t ③ /var/log/sendmail.st system_u:object_r:sendmail_var_log_t

①は、ディレクトリ/etc/mail と同ディレクトリ下に配置されている、sendmail

が使用するコンフィギュレーションファイルに対してアタッチするセキュリティコ

ンテキストの定義である。

②は、キューディレクトリと同ディレクトリ下のファイルに対してアタッチする

セキュリティコンテキストの定義である。

③は、sendmail の出力する統計情報ファイルに対してアタッチするセキュリティ

コンテキストの定義である。ただし、RPM より sendmail をインストールした場合、





統計情報の出力先ファイルは/etc/mail/statistics となっており、ここでの定義は

意味のないものとなっている。

sendmail のインストール先等、ディレクトリ構造に相違がある場合には、セキュ

リティコンテキストが適切にアタッチされるように同ファイルを編集する必要があ

る。

(B) ポートのセキュリティコンテキスト

ポートに対するセキュリティコンテキストはファイル net_contexts にて定義さ

れており、この際アタッチされる type 「 smtp_port_t 」はファイル

domains/program/mta.te にて定義されている。ファイル mta.te に関しては、


(4) マクロ

sendmail 固有のマクロ「sendmail_user_domain」を定義したマクロファイル

macros/program/sendmail_macros.te が存在する。同マクロはユーザ domain から起動

されたsendmailプロセスにアタッチするためのdomainを定義するものである。なお、

同マクロにて定義される domain はデーモンとして起動される sendmail プロセスにア

タッチする domain とは区別されている点に注意が必要である。

マクロ「sendmail_user_domain」はマクロファイル macros/user_macros.te にて定

義されているマクロ「user_domain」から呼び出されている。つまり、マクロ

「user_domain」を用いて、あるユーザ domain「"domain_prefix"_t」を定義すること

で、同時に本マクロにて domain「"domain_prefix"_mail_t」が定義される。そして、

ユーザ domain「"domain_prefix"_t」から起動される sendmail プロセスには、domain

「"domain_prefix"_mail_t」がアタッチされるようになるのである。

マクロファイル macros/program/sendmail_macros.te の全容は付録のリスト A-12

を参照してほしい。

(A) ケイパビリティ

リスト 3-160 は、ユーザ domain から起動された sendmail プロセスがケイパビリ

ティを獲得することを許可するセキュリティポリシー定義である。





リスト 3-160 ケイパビリティ

allow $1_mail_t self:capability net_bind_service;

ここでは、ケイパビリティ CAP_NET_BIND_SERVICE（ソケットの bind）を獲得す

ることを許可している。

(B) テンポラリファイルの保護

ユーザ domain から起動された sendmail プロセスによって、その稼動中にテンポ

ラリ領域下に作成されるテンポラリファイルを保護するべきである。

リスト 3-161 テンポラリファイルの保護

type $1_mail_tmp_t, file_type, sysadmfile, tmpfile; file_type_auto_trans($1_mail_t, tmp_t, $1_mail_tmp_t)

テンポラリファイルを保護するには、sendmail プロセスがテンポラリ領域下に

ファイルを作成した際に、同ファイルに対して作成者である sendmail プロセス固有

の type をアタッチすれば良い。sendmail プロセスにはその起動元であるユーザ

domain 固有の domain がアタッチされているため、テンポラリファイルにアタッチ

する type もまたユーザ domain 固有の type をアタッチするのが望ましい。リスト

3-161 では、ユーザ domain「"domain_prefix"_t」固有の、つまり、sendmail プロ

セスにアタッチされている domain「"domain_prefix"_mail_t」に固有の type とし

て、「"domain_prefix"_mail_tmp_t」を宣言している。そして、この domain

「"domain_prefix"_mail_t」が、type「tmp_t」のアタッチされたディレクトリ（テ

ンポラリ領域）下にファイルを作成した際に、同ファイルに対して domain

「"domain_prefix"_mail_tmp_t」をアタッチするべくファイル type 遷移ルールを定

義している。

(C) 統計情報ファイルに対するアクセス制御

sendmailは MDAプログラムによって発信あるいは送信されたメールの総数とその

総容量を統計情報として追跡する機能を有している。これらの情報は統計情報ファ





イル /etc/mail/statistics 33 に出力される。従って、 domain

「"domain_prefix"_mail_t」には、統計情報ファイルに対する書き込み権限を与え

る必要がある。

リスト 3-162 統計情報ファイルに対するアクセス制御

allow $1_mail_t etc_mail_t:file rw_file_perms;

統計情報ファイルには、セキュリティコンテキストとして type「etc_mail_t」が

アタッチされている。リスト 3-162 では、type「etc_mail_t」のアタッチされたファ

イルに対する書き込み権限を与えている。

(D) スプールディレクトリに対するアクセス制御

sendmail におけるローカルメール配送形式は mbox 形式34である。mbox 形式のロー

カルメール配送では、全ユーザ共通のスプールディレクトリ/var/spool/mail 下に

各ユーザのメールボックスファイルを作成するため、同ディレクトリに対するファ

イル作成権限が必要である。

リスト 3-163 スプールディレクトリに対するアクセス制御

allow $1_mail_t mail_spool_t:dir rw_dir_perms; allow $1_mail_t mail_spool_t:file create_file_perms;

実際のローカルメール配送は、sendmail から起動されるプログラム

/usr/sbin/procmail が行う。従ってリスト 3-163 では、スプールディレクトリに対

するファイル作成権限を、procmail プロセスにアタッチされる domain

「"domain_prefix"_mail_t」（3.5.3.4(3)(B)を参照）に対して与えている。

33 バージョン 5.1 よりも前のバージョンの sendmail では、統計情報ファイルは/var/tmp/sendmail.st で

あった。 34 全ユーザの受信メールを共通ディレクトリ（一般的には/var/spool/mail）下にユーザ毎に別ファイルと

して保存する形式のこと。mbox 形式の場合、同一ユーザ宛のメールメッセージはすべて 1つの mbox ファ

イルに追記・管理される。





(E) キューディレクトリに対するアクセス制御

キューディレクトリに対してファイルを作成する権限が必要である。

リスト 3-164 キューディレクトリに対するサクセス制御

allow $1_mail_t mqueue_spool_t:dir rw_dir_perms; allow $1_mail_t mqueue_spool_t:file create_file_perms;

キューディレクトリに対するメールメッセージの保存は sendmail プロセス自身

が行う。従ってリスト 3-164 では、sendmail プロセスにアタッチされる domain

「"domain_prefix"_mail_t」（3.5.3.4(3)(A)を参照）に対してファイル作成権限を

与えている。

Note：「キューディレクトリを保護しないと･･･」

キューディレクトリを保護することは非常に重要である。もしも sendmail プロセス以外の存在が、キュー

ディレクトリ下に不正に偽造したメールメッセージを置いたとしたら、sendmail プロセスは何の疑いも無

くそのメールメッセージファイルを処理してしまうだろう。キューディレクトリに対するアクセス制御を

適切に制限することは重要である。

(F) ログファイルの保護

sendmail プロセスが出力するログファイルに対して sendmail 固有の type をア

タッチすることにより、他のプロセスによるアクセスからログファイルを保護する

べきである。

リスト 3-165 ログファイルの保護

file_type_auto_trans($1_mail_t, var_log_t, sendmail_var_log_t)

リスト 3-165 では、sendmail プロセスがディレクトリ/var/log 下にファイルを

作成した際に、同ファイルに対して sendmail 固有の type である

「sendmail_var_log_t」をアタッチするべくファイルタイプ遷移ルールを定義して

いる。

ログファイルへの書き込み権限をsendmailプロセスに制限しておくことにより、





ログファイルの改竄を防ぐことが可能である。

(5) セキュリティポリシー定義

sendmail固有のセキュリティポリシーはファイルdomains/program/sendmail.teに

て定義される。またこのファイルでは、デーモンとして稼動する sendmail プロセスに

アタッチする domain の宣言も行われている。

ファイル domains/program/sendmail.te の全容は付録のリスト A-13 を参照してほ

しい。

(A) domain の定義

デーモンとして稼動する sendmail プロセスにアタッチする domainを定義してい

る。この domain はユーザ domain により起動された sendmail プロセスにアタッチす

る domain とは異なるものである。

リスト 3-166 sendmail デーモンプロセスにアタッチする domain の定義

① type sendmail_t, domain, privlog, mta_delivery_agent; ② role system_r types sendmail_t; ③ every_domain(sendmail_t)

リスト 3-166 では、デーモンとして稼動する sendmail プロセスにアタッチする

domain として「sendmail_t」を定義しており（①）、domain に共通して必要となる

各種権限をマクロ「every_domain」により与えている（③）。また、デーモンプロセ

スとして稼動する sendmail の起動元は initrc スクリプトであるため、同スクリプ

トの role である「system_r」に対して domain「sendmail_t」を許可している（②）。

initrc スクリプトに対する sendmail プログラムの起動権限と、その際の domain 遷

移ルールは 3.5.3.4(4)(B)で定義済みであるが、この②の定義がなければ domain の

遷移は許可されないので注意が必要である。

(B) type の定義

デーモンとして稼動している sendmail プロセスがその稼動中に出力するログ

ファイル等は常にファイルシステム上に存在しているとは限らないため、あらかじ

めセキュリティコンテキストをアタッチしておくことができない。そこで、それら





のファイルが作成された際に適切な type がアタッチされるように、ファイル type

遷移ルールを定義すべきである。リスト 3-167 では、これらのファイル type 遷移

ルールを定義している。

リスト 3-167 ファイル type 遷移ルールの定義

① type sendmail_tmp_t, file_type, sysadmfile, tmpfile; ② file_type_auto_trans(sendmail_t, tmp_t, sendmail_tmp_t) ③ type sendmail_var_log_t, file_type, sysadmfile, logfile; ④ file_type_auto_trans(sendmail_t, var_log_t, sendmail_var_log_t) ⑤ type sendmail_var_run_t, file_type, sysadmfile, pidfile; ⑥ file_type_auto_trans(sendmail_t, var_run_t, sendmail_var_run_t)

①と②では、sendmail プログラムが稼動中に出力するテンポラリファイルにア

タッチする type として「sendmail_tmp_t」を宣言し、デーモンとして稼動している

sendmail プロセスがシステムのテンポラリ領域にファイルを作成した際に、同ファ

イルに対して type「sendmail_tmp_t」をアタッチするように定義している。同様に

③と④では、デーモンとして稼動している sendmail プロセスが出力するログファイ

ルにアタッチする type とそのファイル type 遷移ルールを、⑤と⑥では、PID ファ

イルに対してアタッチする type とそのファイル type 遷移ルールを定義している。

(C) ケイパビリティ

リスト 3-168 は、デーモンとして稼動する sendmail プロセスがケイパビリティ

を獲得することを許可するセキュリティポリシー定義である。


allow sendmail_t sendmail_t:capability { setuid setgid net_bind_service sys_nice chown };

ここでは、ケイパビリティ CAP_SETUID（UID の変更）、CAP_SETGID（GID の変更）、

CAP_NET_BIND_SERVICE（ソケットの bind）、CAP_SYS_NICE（nice 値の変更）、および

CAP_CHOWN（ファイルの所有者の変更）を獲得することを許可している。





(D) ファイルディスクリプタとパイプの継承

デーモンとして稼動する sendmail プロセスは initプロセスによりオープンされ

た標準入力、標準出力、および標準エラー出力のためのファイルディスクリプタを

引き継いで使用するため、これを許可しなければならない。

リスト 3-169 init プロセスからのファイルディスクリプタの継承

allow sendmail_t init_t:fd use;

リスト 3-169 は、デーモンとして稼動する sendmail プロセスが init プロセスか

らファイルディスクリプタを引き継ぐことを許可する定義である。また、システム

プロセスから起動される非デーモン稼動の sendmail プロセスは initrc スクリプト

により作成されたファイルディスクリプタの引き継ぎを許可される必要がある。

リスト 3-170 initrc スクリプトからのファイルディスクリプタの継承

allow system_mail_t initrc_t:fd use; allow system_mail_t initrc_t:fifo_file { getattr read write };

リスト 3-170 は、システムプロセスから起動された非デーモン稼動の sendmail

プロセスが initrc スクリプトからファイルディスクリプタを引き継ぐことを許可

する定義である。また、同スクリプトにて作成された名前付きパイプへのアクセス

も許可している。

(E) ネットワーク

sendmail プログラムはネットワークアクセスを必要とするプログラムであるか

ら、当然それらに必要となる権限を与えなければならない。

リスト 3-171 ネットワークアクセスに必要な権限の付与

can_network(sendmail_t)

リスト 3-171 では、ネットワークアクセスに必要となる権限を一括して与えるマ





クロ「can_network」を利用して、デーモンとして稼動する sendmail プロセスにア

タッチされる domain「sendmail_t」に対して必要な権限を与えている。

リスト 3-172 TCP ソケットに対するバインドの許可

allow sendmail_t smtp_port_t:tcp_socket name_bind;

リスト 3-172 では、デーモンとして稼動する sendmail プロセスが TCP ソケット

に対してバインドすることを許可する定義である。type「smtp_port_t」は MTA プロ

グラムが使用するソケットオブジェクトにアタッチするための type として

3.5.3.4(4)(A)にて定義されているものである。

(F) 設定ファイルに対するアクセス制御

sendmail には様々な設定ファイルが存在している。デーモンとして稼動する

sendmail プロセスに対して、これらの設定ファイルに対するアクセス権限を与えな

ければならない。リスト 3-173 は、これらのアクセス権限を与えるための定義であ

る。

リスト 3-173 設定ファイルに対するアクセス制御（デーモンプロセス）

① allow sendmail_t etc_aliases_t:file { setattr rw_file_perms }; ② allow sendmail_t etc_mail_t:dir rw_dir_perms; ③ allow sendmail_t etc_mail_t:file create_file_perms;

①は、デーモンとして稼動するsendmailプロセスに対してエイリアスデータベー

スファイル/etc/aliases.db の読み取り権限を与える定義である。②と③はエイリ

アスデータベースファイル以外の設定ファイルが配置されているディレクトリ

/etc/mail と同ディレクトリ下のファイルに対するアクセス制御である。同ディレ

クトリ下には各種の設定データベースファイルが配置されているだけでなく、発信

あるいは送信されたメールの総数とその総容量を追跡した結果をリストアする統計

情報ファイルも配置されているため、ファイルに対する読み取り権限だけではなく、

ファイルを作成する権限と書き込み権限も与えている。

エイリアスデータベースファイル以外に関しては、ユーザ domain から起動され

た sendmail プロセスにおいても同様のアクセスを許可する必要がある。この定義が

リスト 3-174 である。





リスト 3-174 設定ファイルに対するアクセス制御（非デーモンプロセス）

allow user_mail_domain etc_mail_t:file rw_file_perms;

属性「user_mail_domain」はユーザ domain から起動された sendmail プロセスを

括る属性である。

(G) スプールとキューディレクトリに対するアクセス制御

デーモンとして稼動する sendmail プロセスにスプールディレクトリとキュー

ディレクトリに対するアクセス権限を与えなければならない。リスト 3-175 は、こ

れらのアクセス権限を与えるための定義である。

リスト 3-175 スプールとキューディレクトリに対するアクセス制御

① allow sendmail_t mail_spool_t:dir rw_dir_perms; ② allow sendmail_t mail_spool_t:file create_file_perms; ③ allow sendmail_t mqueue_spool_t:dir rw_dir_perms; ④ allow sendmail_t mqueue_spool_t:file create_file_perms; ⑤ allow system_mail_t mqueue_spool_t:dir rw_dir_perms; ⑥ allow system_mail_t mqueue_spool_t:file create_file_perms;

①と②はスプールディレクトリに対するアクセス制御の定義であるが、通常

sendmail におけるローカルメールの配信処理は sendmail により起動される MDA プ

ログラムによって行われる。このMDAプログラムとは一般的にはprocmailで、スプー

ルディレクトリに対するアクセスベクタルールは procmail にアタッチされる

domain に対して定義されるべきである。3.5.3.1(5)(J)で解説するが、procmail プ

ロセスにアタッチされる domain は「procmail_t」であり、この domain「procmail_t」

にはファイル/domains/program/procmail.te にて①および②と同等のアクセス権

限が与えられている。①と②の定義は不要である。

③と④はキューディレクトリに対するアクセス制御である。sendmail は直ちに送

信処理を開始できないメールが存在する場合、一旦キューディレクトリに保存する。

このことから、sendmail はキューディレクトリに対してファイルを作成する権限が

必要であり、キューディレクトリに保存されたメールを送信する際には同保存ファ

イルに対する読み取り権限が必要となる。また、送信を終了したメールはキューディ

レクトリから削除しなければならず、削除権限も必要である。





環境によっては、外部ホスト宛のメールを自動配送しない設定で sendmail を運

用している場合があるだろう。恐らくこのような環境では以下に示すようなコマン

ドを cron から実行することでキューディレクトリに保存されたメールメッセージ

を定期的に配送しているのではないだろうか。

/usr/sbin/sendmail -q

この場合、sendmail プロセスはシステム domain「system_t」から起動されるこ

とになるため、domain「system_mail_t」に対してもキューディレクトリへのアクセ

ス権限を与える必要がある。⑤と⑥はこのための定義である。

(H) UTMP ファイルへのアクセス

現在ログインしているユーザの情報はファイル/var/run/utmp35に記録される。

sendmail がこのファイルに対してアクセスする必要性は一切ないのだが、現状の

sendmail プログラムはこのファイルに対して読み込みあるいは書き込みを要求す

ることがある。しかし決して読み取り権限や書き込み権限を与えてはならない。

リスト 3-176 UTMP ファイルに対するアクセス制御

dontaudit sendmail_t initrc_var_run_t:file { read write };

リスト 3-176 では、sendmail のデーモンプロセスが utmp ファイルに対する読み

取りあるいは書き込みアクセスを要求した際に（当然アクセスは拒否される）アク

セス拒否を示すログを出力しないように設定している。

(I) ディレクトリ/root へのアクセス

リスト 3-177 は、sendmail プロセスがディレクトリ/root にアクセスしようとし

た際にそれを許可せず、且つアクセス拒否のログを出力しないようにするセキュリ

ティポリシー定義である。

35 who、w、finger、users といったコマンドが参照するファイル





リスト 3-177 sendmail プロセスの/root へのアクセスを許可しない

dontaudit sendmail_t sysadm_home_dir_t:dir { getattr search }; dontaudit system_mail_t sysadm_home_dir_t:dir { getattr search };

(J) プログラム procmail の実行

sendmailでは通常、ロカールメールの配送時にプログラムprocmailを起動する。

そこで、起動された procmail プロセスに対して適切な domain がアタッチされるよ

うに domain 遷移ルールを定義する必要がある。

リスト 3-178 procmail 実行時の domain 遷移ルール

ifdef(`procmail.te',` domain_auto_trans(sendmail_t, procmail_exec_t, procmail_t) domain_auto_trans(system_mail_t, procmail_exec_t, procmail_t) ')

リスト 3-178 では、デーモン稼動する sendmail プロセスとシステム domain

「system_t」から起動された sendmail プロセスがプログラム procmail を起動した

際に、開始された procmail プロセスに対して domain「procmail_t」をアタッチす

るように domain 遷移ルールを定義している。ただし、domain「procmail_t」はファ

イル domains/program/procmail.te にて定義されているため、同ファイルが存在し

ない場合には上記の domain 遷移ルールは無効となるように定義されている。

(6) ローカルからメールを発信する

sendmail のバージョン 8.12 では、MTA として機能するプロセスと MSA として機能す

るプロセスとが分離された関係でキューディレクトリが分割されている。従来の

キューディレクトリが/var/spool/mqueueのみであったのに対して、クライアントメー

ルを格納するためのキューディレクトリとして/var/spool/clientmqueue が用意され

ている。SELinux に標準で用意されているセキュリティポリシー定義ではこの点が考

慮されていないため、ローカルからのメール発信の際にアクセス拒否されてしまう。

ここでは、クライアントキューディレクトリに対するセキュリティポリシーを新た

に定義する際の留意点を述べる。






クライアントキューディレクトリである/var/spool/clientmqueue にアタッチ

する。

リスト 3-179 /var/spool/clientmqueue のセキュリティコンテキスト

/var/spool/clientmqueue(/.*)? system_u:object_r:clientmqueue_spool_t

リスト 3-179 では、新たな type「clientmqueue_spool_t」をアタッチしている。

同 type の定義に関しては 3.5.3.1(6)(B)にて解説する。

(B) セキュリティポリシー定義

MTA として機能するプロセスと MSA として機能するプロセスとが分離されたとは

言っても、相変わらずそれらのプログラムは同一であり、sendmail の本体自身に過

ぎない。sendmail プログラムの実行時パラメータとしてそのオペレーションモード

を切り替えているに過ぎないのである。従って、MSA として起動した sendmail プロ

セスには MTA として起動した sendmail プロセスと同一の domain が同一のルールで

アタッチされることになる。

以下では、MSA として稼動する sendmail に必要なセキュリティポリシー定義を解

説する。

リスト 3-180 type の定義

type clientmqueue_spool_t, file_type, sysadmfile;

リスト 3-180 は、クライアントキューディレクトリにアタッチする type

「clientmqueue_spool_t」の定義である。sendmail 以外の他のプロセスからのアク

セスを制限するためにも、クライアントキューディレクトリに対して sendmail

固有の type をアタッチするべきである。





リスト 3-181 /var/spool/clientmqueue に対するアクセス制御

① allow user_mail_domain clientmqueue_spool_t:dir create_dir_perms; ② allow user_mail_domain clientmqueue_spool_t:file create_file_perms; ③ allow sendmail_t clientmqueue_spool_t:dir rw_dir_perms; ④ allow sendmail_t clientmqueue_spool_t:file create_file_perms;

リスト 3-181 では、MSA として起動した sendmail プロセスに対してクライアン

トキューディレクトリにファイルを作成する権限を与えている。ここでの

「user_mail_domain」と「sendmail_t」は、MSA として起動している sendmail プロ

セスにアタッチされた domain を意味していることに注意してほしい。ここで、

domain「sendmail_t」にアクセス権限を与えていることに疑問を持たれる方もいる

かもしれない。デーモンとして稼動するsendmailプロセスにアタッチされるdomain

が「sendmail_t」であることを考えれば、疑問を持たれたとしても仕方のないこと

である。実は、MTA として機能するプロセスと MSA として機能するプロセスとが分

離されたことで、システム上にデーモンとして稼動する 2つの sendmail プロセスが

存在している可能性があるのである。キューディレクトリが 1 つであった以前の

バージョンでは、たとえば以下のような起動パラメータで sendmail をデーモンとし

て起動していただろう。

/usr/sbin/sendmail –bd –q1h

つまり、キュー内に格納されたメールメッセージの再配送指定パラメータ「-q」

を指定することで、キューディレクトリ内のメールメッセージを定期的に処理させ

ていたわけである。ところが、バージョン8.12よりキューディレクトリが2つとなっ

たことで、新たに追加されたクライアントキューディレクトリ内のメールメッ

セージも定期的に処理する必要がでてきた。そこでバージョン8.12以降のsendmail

では、cron ジョブにより定期的に sendmail を MSA として起動させてクライアント

キューディレクトリを処理させるか、あるいはクライアントキューディレクトリ

を処理するためだけのデーモンプロセスとして sendmail を常に起動させておくこ

とが推奨されている。Red Hat Linux 8.0 では、インストール CD に含まれる RPM パッ

ケージを利用して sendmail をインストールした場合、デフォルトでは後者の処理方

式が採用されており、③と④はこの sendmail デーモンプロセスによるキューの処理

を考慮したものである。なお前者の方式で処理を行う場合、cron ジョブから起動さ





れる sendmail プロセスの domain は「system_mail_t」となるため、①と②のセキュ

リティポリシー定義でクライアントキューディレクトリに対するアクセス権限が

与えられていることになる36。つまり、cron ジョブによりクライアントキューディ

レクトリを処理するのであれば、③と④は不要となる。

リスト 3-182 sendmail プロセス間の通信制御ルール

① allow sendmail_t user_mail_domain:tcp_socket { recvfrom acceptfrom }; ② allow user_mail_domain sendmail_t:tcp_socket { connectto recvfrom }; ③ allow sendmail_t self:tcp_socket { connectto recvfrom acceptfrom };

リスト 3-182 は、MSA としてユーザ domain から起動された sendmail プロセスと

デーモンとして稼動している sendmail プロセスとの間の、あるいはデーモンとして

稼動している sendmail プロセス同士の通信制御設定を定義するものである。①と②

は、MSA として稼動する sendmail プロセス（ユーザ domain から起動される）が、

そのメールメッセージ送信の際に、MTA としてデーモン稼動している sendmail プロ

セスと SMTP 通信を行うことを許可する定義である。③は、MSA としてデーモン稼動

している sendmail プロセスが、クライアントキューディレクトリ内のメールメッ

セージ送信の際に、MTA としてデーモン稼動している sendmail プロセスと SMTP 通

信を行うことを許可する定義である。

(C) 問題点

クライアントキューディレクトリを考慮したセキュリティポリシー定義に関し

て 3.5.3.1(6)(B)にて解説したが、理想としては、MSA として稼動する sendmail プ

ロセスにアタッチする domain は MTA として稼動する sendmail プロセスにアタッチ

する domain とは区別するべきである。しかし、その実行ファイルが同一である以上、

異なる domain をアタッチすることができないというのが現状である37。sendmail は

その起動時パラメータで様々な動きを取り得る仕様であるため、残念ながら機能別

に domain を切り分けにくいと言わざるを得ない。

36 なお「user_mail_domain」は、システムdomain「system_t」あるいはユーザdomainより起動されたsendmail

プロセスにアタッチされる domain を括る属性である。 37 sendmail の実行プログラムをシェルスクリプトでラップすれば不可能ではないが、実行時パラメータで

様々な動きを取り得る sendmail をラップするのは理想的ではないと思われる。





3.5.3.2. qmail

本節では、qmail を利用した SMTP サーバー構築の際の設定指針として、SELinux に標準

で用意されているセキュリティポリシー定義を解説し、その留意点を明らかにする。

qmail の RPM パッケージを入手することは難しい。qmail の本家サイトにて配布されてい

るパッケージは SRPM であり、ビルド済みである RPM パッケージは配布されていないようで

ある。そこで本ガイドラインでは、qmail をソースより標準設定にてコンパイルしてインス

トールした環境を想定することにする。

qmail ではその運用形態として様々な形態が選択可能となっているが、本ガイドラインで

は以下の運用形態を想定するものとする。

• qmail の運用ディレクトリは/var/qmail とする。

• プログラム qmail-smtpd はスーパーサーバーxinetd より起動する。

• ローカルメールの配送形態は、各ユーザのホームディレクトリ下に mbox 形式にて

配送する。


qmail を標準構成にてコンパイル・インストールした際のディレクトリ構造を表

3-17 に示す。以降ではこのディレクトリ構造に則してセキュリティポリシー定義を解

説する。なお同表では、ドキュメントファイルあるいは man ページ等のインストール

先は記載していないので注意してほしい。





表 3-17 qmail のディレクトリ構造



2 /var/qmail/ qmail の運用ディレクトリ

3 /var/qmail/alias/ エイリアスファイルの配置先

4 /var/qmail/bin/ qmail を構成する各種プログラムの配置先

5 /var/qmail/boot/ qmail 起動サンプルスクリプトの配置先

6 /var/qmail/control/ コンフィギュレーションファイルの配置先

7 /var/qmail/queue/ キューディレクトリ

8 /var/qmail/users/ メールアドレスとローカルホストのユーザアカウントとの対応付けを定義したデータベースファイルの配置先

9 /var/spool/mail/ スプールディレクトリ。本ディレクトリ下の各ユーザのメールボックスファイルは、各々ユーザのホームディレクトリ下に作成したメールボックスファイルへのシンボリックリンクであるとする。


qmail に関連するセキュリティポリシー定義ファイルを表 3-18 に示す。

表 3-18 qmail のセキュリティポリシー定義ファイル一覧


1 file_contexts/program/qmail.fc qmail に関連するファイルに対してアタッチするセキュリティコンテキストを定義したファイル

2 domains/program/qmail.te qmail に関連するセキュリティポリシーを定義したファイル




qmail に関連した各種オブジェクトに対してアタッチするセキュリティコンテキス

トを解説する。


qmail に関連するファイルとディレクトリにアタッチするセキュリティコンテキ





ストはファイル file_contexts/program/qmail.fc にて定義される。

ファイルfile_contexts/program/qmail.fcの全容は付録のリスト A-15を参照し

てほしい。

コンフィギュレーションファイル

リスト 3-183 は、qmail のコンフィギュレーションファイルにアタッチするセ

キュリティコンテキストの定義である。

リスト 3-183 コンフィギュレーションファイルのセキュリティコンテキスト

① /etc/qmail(/.*)? system_u:object_r:etc_qmail_t /var/qmail(/.*)? system_u:object_r:etc_qmail_t

なお、qmail をソースより標準設定にてコンパイル・インストールした環境では、

qmail を構成するすべてのプログラムはディレクトリ/var/qmail 下にインストール

されるため、①は必要のない定義である。

キューディレクトリ

リスト 3-184 は、qmail のキューディレクトリと同ディレクトリ下のファイルに

アタッチするセキュリティコンテキストの定義である。

リスト 3-184 /var/spool/qmail のセキュリティコンテキスト

/var/spool/qmail(/.*)? system_u:object_r:qmail_spool_t

リスト 3-184 より判るとおり、SELinux に標準で含まれているファイルコンテキ

ストの定義は qmail をソースより標準構成にてインストールした場合と異なってい

る。そこで、リスト 3-185 に示すように修正しなければならない。

リスト 3-185 /var/qmail/queue のセキュリティコンテキスト定義を追加

/var/qmail/queue(/.*)? system_u:object_r:qmail_spool_t





qmail を構成するプログラムの実行ファイル

リスト 3-186 は、qmail を構成する各種プログラムの実行ファイルにアタッチす

るセキュリティコンテキストの定義である。

リスト 3-186 実行ファイルのセキュリティコンテキスト（修正前）

/usr/sbin/qmail-start system_u:object_r:qmail_start_exec_t /usr/sbin/qmail-lspawn system_u:object_r:qmail_lspawn_exec_t /usr/bin/tcp-env system_u:object_r:qmail_tcp_env_exec_t /usr/sbin/qmail-inject system_u:object_r:qmail_inject_exec_t /usr/sbin/qmail-smtpd system_u:object_r:qmail_smtpd_exec_t /usr/sbin/qmail-queue system_u:object_r:qmail_queue_exec_t /usr/sbin/qmail-local system_u:object_r:qmail_local_exec_t /usr/sbin/qmail-clean system_u:object_r:qmail_clean_exec_t /usr/sbin/qmail-send system_u:object_r:qmail_send_exec_t /usr/sbin/qmail-rspawn system_u:object_r:qmail_rspawn_exec_t /usr/sbin/qmail-remote system_u:object_r:qmail_remote_exec_t /usr/sbin/qmail-qread system_u:object_r:qmail_qread_exec_t /usr/sbin/splogger system_u:object_r:qmail_splogger_exec_t /usr/sbin/qmail-getpw system_u:object_r:qmail_exec_t /usr/local/bin/serialmail/.* system_u:object_r:qmail_serialmail_exec_t

3.5.3.2(1)にて示したとおり、qmail をソースより標準構成にてコンパイル・イ

ンストールした場合、qmail を構成するすべての実行ファイルはディレクトリ

/var/qmail/bin にインストールされる。そこで、上記のセキュリティポリシーをリ

スト 3-187 に示すように修正しなければならない。





リスト 3-187 実行ファイルのセキュリティコンテキスト（修正後）

① /var/qmail/bin(/.*)? system_u:object_r:bin_t /var/qmail/bin/qmail-start system_u:object_r:qmail_start_exec_t /var/qmail/bin/qmail-lspawn system_u:object_r:qmail_lspawn_exec_t /var/qmail/bin/tcp-env system_u:object_r:qmail_tcp_env_exec_t /var/qmail/bin/qmail-inject system_u:object_r:qmail_inject_exec_t /var/qmail/bin/qmail-smtpd system_u:object_r:qmail_smtpd_exec_t /var/qmail/bin/qmail-queue system_u:object_r:qmail_queue_exec_t /var/qmail/bin/qmail-local system_u:object_r:qmail_local_exec_t /var/qmail/bin/qmail-clean system_u:object_r:qmail_clean_exec_t /var/qmail/bin/qmail-send system_u:object_r:qmail_send_exec_t /var/qmail/bin/qmail-rspawn system_u:object_r:qmail_rspawn_exec_t /var/qmail/bin/qmail-remote system_u:object_r:qmail_remote_exec_t /var/qmail/bin/qmail-qread system_u:object_r:qmail_qread_exec_t /var/qmail/bin/splogger system_u:object_r:qmail_splogger_exec_t /var/qmail/bin/qmail-getpw system_u:object_r:qmail_exec_t /usr/local/bin/serialmail/.* system_u:object_r:qmail_serialmail_exec_t② /var/qmail/bin/sendmail system_u:object_r:sendmail_exec_t

ディレクトリ/var/qmail/bin 下には、上記のプログラム以外にも幾つものプログ

ラムがインストールされている。固有の domain をアタッチしないプログラムの実行

ファイルには汎用的な実行ファイルを示す type「bin_t」をアタッチしておいた方

が良いだろう38（①）。

qmail には、sendmail との互換性を考慮して、プログラム qmail-inject をラッ

プしたプログラム/var/qmail/bin/sendmail が用意されている。このプログラムに

は忘れずに type「sendmail_exec_t」をアタッチしなければならない（②）。




domains/program/mta.te にて定義されている。ファイル mta.te に関しては、


(4) マクロ

ファイル domains/program/qmail.te では幾つかのマクロが定義されている。これら

38 これらのプログラムの中には、適切に稼動させるために固有の domain を定義し、適切なセキュリティポ

リシーを定義しなければならないものも存在することに注意してほしい。





のマクロはいずれもpostfixのデーモンプロセスにアタッチするdomainを定義するた

めのものである。ここでは、これらのマクロに関して解説する。

(A) qmaild_sub_domain

リスト 3-188 に示すマクロ「qmaild_sub_domain」は、同マクロ呼び出し時の第

1引数に指定された domain 修飾子を持つ domain を親 domain として、第 2引数に指

定された domain 修飾子を持つ domain を定義するマクロである。3.5.3.2(4)(B)で解

説するマクロ「qmail_daemon_domain」が、プログラム qmail-start から起動される

プログラム qmail-lspawn、qmail-send、splogger、qmail-rspawn、および qmail-clean

の domain を定義するために用いられるのに対して、本マクロはこれら以外のプログ

ラムの domain を定義するために用いられる。

リスト 3-188 マクロ「qmaild_sub_domain」

define(`qmaild_sub_domain', ` ① daemon_sub_domain($1, $2, `$3') ② allow $2_t etc_qmail_t:dir { getattr search }; ③ allow $2_t etc_qmail_t:{ lnk_file file } { getattr read }; ④ allow $2_t var_spool_t:dir search; ⑤ allow $2_t var_t:dir search; ')

①で利用されているマクロ「daemon_sub_domain」は、第1引数で指定されるdomain

修飾子を持つ domain に対して、第 2引数で指定される domain 修飾子を持つ domain

の実行ファイルの実行権限を与え、同ファイル実行時に起動されるプロセスに対し

て、第 2引数で指定された domain 修飾子を持つ domain をアタッチする domain 遷移

ルールを定義するマクロである。より具体的に説明すれば、このマクロにて domain

「$2_t」とその domain をアタッチするプログラムの実行ファイルにアタッチするた

めの type「$2_exec_t」が定義され、domain「$1_t」が type「$2_exec_t」のアタッ

チされたファイルを実行した際に起動するプロセスに対して domain「$2_t」をア

タッチする domain 遷移ルールが定義される。

②～④では、①で定義された domain に対して、qmail 固有の type がアタッチさ

れたディレクトリやファイルといったオブジェクトに対する読み取り権限を与えて

いる。

マクロ「qmaild_sub_domain」により固有な domain を定義されているプログラム

の中には、ディレクトリ/var 下の情報を取得しようとするものが存在する。これら

のプログラムを考慮し、⑤に示すセキュリティポリシー定義が必要となる。





(B) qmail_daemon_domain

リスト 3-189 に示すマクロ「qmail_daemon_domain」は qmail の構成プログラム

である qmail-start から起動されるプログラムの domain を定義するマクロである。

リスト 3-189 マクロ「qmail_daemon_domain」

define(`qmail_daemon_domain', ` ① qmaild_sub_domain(qmail_start_t, qmail_$1, `$2') allow qmail_$1_t qmail_start_t:fifo_file { read write }; allow qmail_start_t qmail_$1_exec_t:file read; ')dnl

マクロ「qmaild_sub_domain」を利用することで、domain「qmail_start_t」のア

タッチされたプロセス、つまり qmail_start プロセスを親プロセスとする子プロセ

スにアタッチする domain が定義される（①）。


ここでは、ファイル domains/program/qmail.te にて定義されるセキュリティポリ

シー定義に関して解説する。


qmail は役割分担された数多くのプログラムより構成されている。従って、各プ

ログラムのプロセスにアタッチするための domain も数多く定義されている。これら

の domain の多くは 3.5.3.2(4)で解説したマクロ「qmaild_sub_domain」あるいは

「qmail_daemon_domain」によって定義される。

プログラム qmail-start

プログラム qmail-start にアタッチする domain はリスト 3-190 に示す箇所にて

定義される。





リスト 3-190 domain「qmail_start_t」の定義

① daemon_base_domain(qmail_start) allow qmail_start_t self:capability { setgid setuid }; ② allow qmail_start_t { bin_t sbin_t }:dir search;

マクロ「daemon_base_domain」により domain「qmail_start_t」が定義される（①）。

マクロ「daemon_base_domain」は新たな domain を定義すると同時に、デーモンとし

て稼動するプロセスに共通して必要となる type の宣言や、権限を一括して付与して

くれるマクロである39。また、マクロ「daemon_base_domain」では、定義する domain

の実行ファイルにアタッチする type も同時に定義されるため、ここでは type

「qmail_start_exec_t」が同時に定義されていることになる。このあたりは非常に

見通しが悪いので注意してほしい。

プログラム qmail_start はディレクトリ/var 下の情報を取得しようとするため、

リスト 3-190 の②はリスト 3-191 に示すように修正する必要がある。

リスト 3-191 ディレクトリ/var に対する探索権限を与える

allow qmail_start_t { bin_t sbin_t var_t }:dir search;

同様に、ディレクトリ/var/qmail に対する探索権限も必要である。そこで、リス

ト 3-192 に示すセキュリティポリシー定義を追加する必要がある。

リスト 3-192 ディレクトリ/var/qmail に対する探索権限を与える

allow qmail_start_t etc_qmail_t:dir search;

プログラム qmail-send

プログラムqmail-sendにアタッチするdomainはリスト 3-193に示す箇所にて定

義される。

39 macros/global_macros.te にて定義されている。





リスト 3-193 domain「qmail_send_t」の定義

① qmail_daemon_domain(send) rw_dir_create_file(qmail_send_t, qmail_spool_t) allow qmail_send_t qmail_spool_t:fifo_file read; allow qmail_send_t self:process { fork signal_perms }; allow qmail_send_t self:fifo_file write; ② domain_auto_trans_read(qmail_send_t, qmail_queue_exec_t, qmail_queue_t) ③ allow qmail_send_t sbin_t:dir search;

プログラム qmail-send はキューディレクトリに登録されたメールメッセージを

処理するプログラムである。qmail-send は qmail-start により起動されるため、プ

ロセスにアタッチする domain はマクロ「qmail_daemon_domain」により定義されて

いる（①）。

②と③では、プログラム qmail-queue の起動を許可している。プログラム

qmail-send がプログラム qmail-queue を起動することがあるのか、と思うかもしれ

ない。これは、永続的に配送に失敗したメールメッセージ（バウンスメッセージ）

は配送失敗の旨を示す情報が付加されたメールメッセージとして送信者に返送され

ることになるのだが、プログラム qmail-send はこのメールメッセージを新規メール

メッセージとして扱うべくプログラム qmail-queue を起動してキューディレクトリ

に格納させるため、②と③の権限が必要となるのである。なお、本ガイドラインで

は、プログラム qmail-queue のインストール先をディレクトリ/var/qmail/bin とし

ており、同ディレクトリにアタッチされる type は 3.5.3.2(3)(A)にて示したとおり

「bin_t」である。従って③はリスト 3-194 に示すように変更する必要がある。

リスト 3-194 プログラム qmail-queue のインストール先を考慮した修正

allow qmail_send_t bin_t:dir search;

プログラム qmail-lspawn

プログラムqmail-lspawnにアタッチするdomainはリスト 3-195に示す箇所にて

定義される。





リスト 3-195 domain「qmail_lspawn_t」の定義

① qmail_daemon_domain(lspawn, `, mta_delivery_agent') allow qmail_lspawn_t self:fifo_file { read write }; allow qmail_lspawn_t self:capability { setuid setgid }; allow qmail_lspawn_t self:process { fork signal_perms }; ② allow qmail_lspawn_t sbin_t:dir search; ③ can_exec(qmail_lspawn_t, qmail_exec_t) allow qmail_lspawn_t self:unix_stream_socket create_socket_perms; allow qmail_lspawn_t qmail_spool_t:dir search; allow qmail_lspawn_t qmail_spool_t:file { read getattr }; allow qmail_lspawn_t etc_t:file { getattr read }; allow qmail_lspawn_t tmp_t:dir getattr; dontaudit qmail_lspawn_t user_home_dir_type:dir { getattr search };

プログラム qmail-lspawnはプログラム qmail-send により処理されたメールメッ

セージがローカル宛のメールメッセージであった場合に処理を委譲されるプログラ

ムで、プログラム qmail-start により起動されるプログラムである。従って、

qmail-lspawn のプロセスにアタッチする domain はマクロ「qmail_daemon_domain」

により定義されている（①）。

プログラム qmail-lspawn はローカル宛メールメッセージの受信者を解決するた

めに qmail-users 機構40を利用するが、これにより解決できない場合、ユーティリ

ティプログラム qmail-getpw を呼び出す。②と③はこの qmail-getpw の起動を許可

するための定義である。なお、「qmail_exec_t」はプログラム qmail-getpw の実行ファ

イルにアタッチされている type である（3.5.3.2(3)(A)）。また、起動されたプログ

ラム qmail-getpw はディレクトリ/var/run 下の情報を取得しようとするため、リス

ト 3-196 に示すセキュリティポリシーを追加定義しなければならない。

リスト 3-196 プログラム qmail-getpw に/var/run の探索権限を与える

allow qmail_lspawn_t var_run_t:dir search;

リスト 3-195 における③のセキュリティポリシー定義により、プログラム

qmail-lspawn から起動されるプログラム qmail-getpw のプロセスには domain

「qmail_lspawn_t」がアタッチされることになる。そこで、同 domain に対してディ

レクトリ/var/run の探索権限を与えているのである。

40 メールアドレスとローカルホストユーザの対応付けを定義する機構のこと。通常、この対応付けはファ

イル/var/qmail/users/assign にて定義されている。





プログラム qmail-rspawn

プログラムqmail-rspawnにアタッチするdomainはリスト 3-197に示す箇所にて

定義される。

リスト 3-197 domain「qmail_rspawn_t」の定義

① qmail_daemon_domain(rspawn) allow qmail_rspawn_t qmail_spool_t:dir search; allow qmail_rspawn_t qmail_spool_t:file rw_file_perms; allow qmail_rspawn_t self:process { fork signal_perms }; allow qmail_rspawn_t self:fifo_file read; allow qmail_rspawn_t { bin_t sbin_t }:dir search;

プログラム qmail-rspawnはプログラム qmail-send により処理されたメールメッ

セージがリモートホスト宛のメールメッセージであった場合に、そのメールメッ

セージの配信をスケジューリングする役割を持ったプログラムで、プログラム

qmail-start により起動されるプログラムである。従って、qmail-rspawn のプロセ

スにアタッチする domain はマクロ「qmail_daemon_domain」により定義されている

（①）。

プログラム qmail-clean

プログラム qmail-clean にアタッチする domain はリスト 3-198 に示す箇所にて

定義される。

リスト 3-198 domain「qmail_clean_t」の定義

① qmail_daemon_domain(clean) allow qmail_clean_t qmail_spool_t:dir rw_dir_perms; allow qmail_clean_t qmail_spool_t:file { unlink read getattr };

プログラムqmail-cleanは配信できずにキューディレクトリに残留しているメー

ルメッセージを削除する役割を持ったプログラムで、プログラム qmail-start によ

り起動されるプログラムである。従って、qmail-clean のプロセスにアタッチする

domain はマクロ「qmail_daemon_domain」により定義されている（①）。





プログラム splogger

プログラムsploggerにアタッチするdomainはリスト 3-199に示す箇所にて定義

される。

リスト 3-199 domain「qmail_splogger_t」の定義

① qmail_daemon_domain(splogger) allow qmail_splogger_t self:unix_dgram_socket create_socket_perms; allow qmail_splogger_t etc_t:lnk_file read; dontaudit qmail_splogger_t initrc_t:fd use;

プログラム splogger は qmail より syslog にログ情報を出力するためのプログラ

ムで、プログラム qmail-start により起動されるプログラムである。従って、

splogger のプロセスにアタッチする domain はマクロ「qmail_daemon_domain」によ

り定義されている（①）。

プログラム splogger はタイムゾーン情報を取得するために、ファイル

/etc/localtime を読み取る必要があるため、リスト 3-200 に示すセキュリティポリ

シーを追加定義した方が良いだろう。

リスト 3-200 プログラム splogger にタイムゾーン情報の参照を許可する

allow qmail_splogger_t etc_t:file { getattr read };

プログラム qmail-remote

プログラムqmail-remoteにアタッチするdomainはリスト 3-201に示す箇所にて

定義される。





リスト 3-201 domain「qmail_remote_t」の定義

① qmaild_sub_domain(qmail_rspawn_t, qmail_remote) allow qmail_rspawn_t qmail_remote_exec_t:file read; can_network(qmail_remote_t) allow qmail_remote_t qmail_spool_t:dir search; allow qmail_remote_t qmail_spool_t:file rw_file_perms; allow qmail_remote_t resolv_conf_t:file { getattr read }; allow qmail_remote_t self:tcp_socket create_socket_perms; allow qmail_remote_t self:udp_socket create_socket_perms;

プログラム qmail-remote はリモートホスト宛のメールメッセージを SMTP 接続に

よりリモート SMTP サーバーに配送する役割を持ったプログラムで、プログラム

qmail-rspawn により起動されるプログラムである。従って、qmail-remote のプロセ

スにアタッチする domain はマクロ「qmaild_sub_domain」により domain

「qmail_rspawn_t」を起動元とする domain として定義されている（①）。

プログラム qmail-local

プログラム qmail-local にアタッチする domain はリスト 3-202 に示す箇所にて

定義される。





リスト 3-202 domain「qmail_local_t」の定義

① qmaild_sub_domain(qmail_lspawn_t, qmail_local, `, privhome, mta_delivery_agent') allow qmail_lspawn_t qmail_local_exec_t:file read; allow qmail_local_t self:process { fork signal_perms }; ② domain_auto_trans(qmail_local_t, qmail_queue_exec_t, qmail_queue_t) ③ allow qmail_local_t qmail_queue_exec_t:file read; allow qmail_local_t qmail_spool_t:file { ioctl read }; allow qmail_local_t self:fifo_file write; allow qmail_local_t sbin_t:dir search; allow qmail_local_t self:unix_stream_socket create_stream_socket_perms; allow qmail_local_t etc_t:file { getattr read }; # for piping mail to a command ④ can_exec(qmail_local_t, shell_exec_t) ⑤ allow qmail_local_t bin_t:dir search; ⑥ allow qmail_local_t bin_t:lnk_file read; ⑦ allow qmail_local_t devtty_t:chr_file rw_file_perms; ⑧ allow qmail_local_t { etc_runtime_t proc_t }:file { getattr read };

プログラムqmail-localはローカルホスト宛のメールメッセージをローカルシス

テム上の然るべきユーザに配信する役割を持ったプログラムで、qmail-lspawn によ

り起動されるプログラムである。従って①のように、qmail-local のプロセスにア

タッチする domain は domain「qmail_lspawn_t」を起動元とする domain としてマク

ロ「qmaild_sub_domain」により定義されている（①）。

②と③では、プログラム qmail-queue の実行を許可している。これは、ローカル

ホスト宛のメールメッセージの配送に失敗した場合に当該メールメッセージは配送

失敗の旨を示す情報が付加されたメールメッセージとして送信者に返送されること

になるのだが、プログラム qmail-local はこのメールメッセージを新規メールメッ

セージとして扱うべくプログラム qmail-queue を起動してキューディレクトリに格

納させるため、②と③の権限が必要となるのである。

④～⑧は、qmail-local からコマンドを起動し、同コマンドに対してメールメッ

セージを渡すことを許可するためのセキュリティポリシー定義である。

本ガイドラインでは、qmail におけるローカル配送形式として、各ユーザのホー

ムディレクトリ下の mbox 形式にて配送する形式を想定している。プログラム

qmail-local がこのメールボックスファイルに対してメールメッセージを追記でき

るようにリスト 3-203 に示すセキュリティポリシーを追加定義しなければならな

い。





リスト 3-203 メールボックスファイルへの配送を許可する

allow qmail_local_t mail_spool_t:file { lock append };

ユーザのホームディレクトリ下に作成したメールボックスファイルには type

「mail_spool_t」がアタッチされている必要があるので注意してほしい。

プログラム tcp-env

プログラム tcp-env にアタッチする domain はリスト 3-204 に示す箇所にて定義

される。

リスト 3-204 domain「qmail_tcp_env」の定義

① qmaild_sub_domain(tcpd_t, qmail_tcp_env) ② allow qmail_tcp_env_t inetd_t:fd use; ③ allow qmail_tcp_env_t inetd_t:tcp_socket { read write getattr }; allow qmail_tcp_env_t inetd_t:process sigchld; allow qmail_tcp_env_t resolv_conf_t:file { read getattr }; ④ allow qmail_tcp_env_t sbin_t:dir search; can_network(qmail_tcp_env_t)

qmail においてリモートホストからの SMTP 接続を受けるプログラムは

qmail-smtpd である。プログラム qmail-smtpd はデーモンプロセスとして常時起動

している必要はなく、スーパーサーバーxinetd から必要に応じて起動される形で稼

動させるのが一般的である。スーパーサーバーxinetd は qmail-smtpd に代って SMTP

ポートを監視し、リクエストを受け付けるとプログラム tcpd を起動する。プログラ

ム tcpd は受け付けたリクエストをログに出力し、然るべきチェック等を行うプログ

ラムである。受け付けたリクエストに問題がない場合、プログラム tcpd は

qmail-smtpd を起動するのだが、実は直接プログラム qmail-smtpd が起動されるの

ではない。プログラム qmail-smtpd はスーパーサーバーxinetd から必要な情報を取

得するためにプログラム tcp-env 経由にて起動されるのである。ここでは、このプ

ログラム tcp-env のプロセスにアタッチする domain「qmail_tcp_env」が定義され

ている。上述の通り①において、プログラム tcpd41より起動されるプロセスにアタッ

チする domain として「qmail_tcp_env」が定義されている。

41 プログラム tcpd にアタッチされる domain は「tcpd_t」である。同 domain は、domains/program/tcpd.te

にて定義されている。





②と③では、スーパーサーバーxinetd から tcpd プロセスが引き継いだ各種のオ

ブジェクトを更に tcp-env プロセスが引き継ぐことを許可している。

④は、tcp-env プロセスがプログラム sendmail-smtpd を実行するに当たり、同プ

ログラムの配置されるディレクトリ/usr/sbin 下を探索する権限を与えるための定

義である。なお、本ガイドラインではプログラム sendmail-smtpd のインストール先

をディレクトリ/var/qmail/bin としており、同ディレクトリにアタッチされる type

は 3.5.3.2(3)(A)にて示したとおり「bin_t」である。従って④はリスト 3-205 に示

すように変更する必要がある。

リスト 3-205 プログラム sendmail-smtpd のインストール先を考慮した修正

allow qmail_tcp_env_t bin_t:dir search;

また、上述のプログラム tcpd はプログラム tcp-env を実行する際にディレクトリ

/var/qmail を探索するため、リスト 3-206 に示すセキュリティポリシーを追加定義

する必要がある42。

リスト 3-206 プログラム tcp-env 実行に必要な権限を domain「tcpd_t」に追加

allow tcpd_t etc_qmail_t:dir search;

プログラム qmail-smtpd

プログラム qmail-smtpd にアタッチする domain はリスト 3-207 に示す箇所にて

定義される。

42 domain「tcpd_t」にはファイル domains/program/tcpd.te においてマクロ「every_domain」が適用され

ているため、同マクロにより type「bin_t」のアタッチされたディレクトリに対する探索権限が与えられ

ている。従って、type「bin_t」のアタッチされているディレクトリ/var/qmail/bin の探索権限を改めて

ここで定義する必要はない。





リスト 3-207 domain「qmail_smtpd_t」の定義

① qmaild_sub_domain(qmail_tcp_env_t, qmail_smtpd) allow qmail_tcp_env_t qmail_smtpd_exec_t:file read; can_network(qmail_smtpd_t) ② allow qmail_smtpd_t inetd_t:fd use; ③ allow qmail_smtpd_t inetd_t:tcp_socket { read write }; allow qmail_smtpd_t inetd_t:process sigchld; allow qmail_smtpd_t self:process { fork signal_perms }; allow qmail_smtpd_t self:fifo_file write; allow qmail_smtpd_t self:tcp_socket create_socket_perms; ④ allow qmail_smtpd_t sbin_t:dir search; ⑤ domain_auto_trans(qmail_smtpd_t, qmail_queue_exec_t, qmail_queue_t) ⑥ allow qmail_smtpd_t qmail_queue_exec_t:file read;

上述のように、プログラム qmail-smtpd はプログラム tcp-env により起動される。

従って、プログラム qmail-smtpd にアタッチする domain「qmail_smtpd_t」は①に

おいてマクロ「qmaild_sub_domain」により定義されている。

②と③では、スーパーサーバーxinetd が作成した各種オブジェクトを更に

qmail-smtpd プロセスが引き継ぐことを許可している。

④～⑥は、受信したメールメッセージをプログラム qmail-queue に渡すべくプロ

グラム qmail-smtpd がプログラム qmail-queue を起動することを許可する定義であ

る。なお、本ガイドラインではプログラム qmail-queue のインストール先をディレ

クトリ/var/qmail/bin としており、同ディレクトリにアタッチされる type は

3.5.3.2(3)(A)にて示したとおり「bin_t」である。従って④は、リスト 3-208 に示

すように変更する必要がある。

リスト 3-208 プログラム qmail-queue のインストール先を考慮した修正

allow qmail_smtpd_t bin_t:dir search;

プログラム qmail-inject

プログラムqmail-injectにアタッチするdomainはリスト 3-209に示す箇所にて

定義される。





リスト 3-209 domain「qmail_inject_t」の定義

① qmaild_sub_domain({ system_mail_t sysadm_mail_t user_mail_t }, qmail_inject, `, mta_user_agent') allow qmail_inject_t self:process { fork signal_perms }; allow qmail_inject_t self:fifo_file { write }; allow qmail_inject_t sbin_t:dir search; role sysadm_r types qmail_inject_t; in_user_role(qmail_inject_t)

プログラム qmail-inject はローカルから発信されるメールを受け付けるプログ

ラムである。qmail では、sendmail との互換性を考慮し、qmail-inject のラッププ

ログラム sendmail が用意されている。プログラム mail をはじめとした外部プログ

ラムはこのラッププログラムを呼び出すため、qmail-inject はラッププログラム経

由で呼び出されることになる。ラッププログラムの実行ファイルには type

「sendmail_exec_t」がアタッチされており、システム domain「system_t」やユー

ザ domain により起動された際のプロセスには「system_mail_t」、「sysadm_mail_t」、

あるいは「usermail_t」がアタッチされていることになる。従って①のように、プ

ログラムqmail-injectのプロセスにアタッチするdomainはユーザdomainから起動

された MTA プロセスを起動元とする domain として、マクロ「qmaild_sub_domain」

により定義されている。

プログラム qmail-qread

プログラム qmail-qread にアタッチする domain はリスト 3-210 に示す箇所にて

定義される。

リスト 3-210 domain「qmail_qread_t」の定義

① qmaild_sub_domain(userdomain, qmail_qread, `, mta_user_agent') in_user_role(qmail_qread_t) role sysadm_r types qmail_qread_t; ② r_dir_file(qmail_qread_t, qmail_spool_t) allow qmail_qread_t self:capability dac_override; allow qmail_qread_t privfd:fd use;

プログラムqmail-qreadはキューディレクトリに格納されているメールメッセー

ジに関する情報を出力するユーティリティプログラムである。ユーザによってコマ

ンドラインより起動されるプログラムであるため、プログラム qmail-qread のプロ





セスにアタッチする domain は、①のようにユーザ domain を起動元とする domain

としてマクロ「qmaild_sub_domain」により定義されている。

②では、domain「qmail_qread_t」に対してキューディレクトリ下に存在するファ

イルの読み取り権限を与えている。

プログラム qmail-queue

プログラム qmail-queue にアタッチする domain はリスト 3-211 に示す箇所にて

定義される。

リスト 3-211 domain「qmail_queue_t」の定義

① qmaild_sub_domain(qmail_inject_t, qmail_queue, `, mta_user_agent') role sysadm_r types qmail_queue_t; in_user_role(qmail_queue_t) allow qmail_inject_t qmail_queue_exec_t:file read; ② rw_dir_create_file(qmail_queue_t, qmail_spool_t) allow qmail_queue_t qmail_spool_t:fifo_file { read write }; allow qmail_queue_t { qmail_start_t qmail_lspawn_t }:fd use; allow qmail_queue_t qmail_lspawn_t:fifo_file write; allow qmail_queue_t qmail_start_t:fifo_file { read write }; allow qmail_queue_t privfd:fd use; allow qmail_queue_t crond_t:fifo_file { read write }; allow qmail_queue_t inetd_t:fd use; allow qmail_queue_t inetd_t:tcp_socket { read write }; allow qmail_queue_t sysadm_t:fd use; allow qmail_queue_t sysadm_t:fifo_file write;

メールメッセージをキューディレクトリに格納するプログラムである

qmail-queue はプログラム qmail-inject より起動される。従って①のように、

qmail-queue のプロセスにアタッチする domain は qmail_inject を起動元とする

domain としてマクロ「qmaild_sub_domain」により定義されている。

②では、domain「qmail_queue_t」に対してキューディレクトリ下にファイルを

作成する権限を与えている。

プログラム serialmail

プログラムserialmailにアタッチするdomainはリスト 3-212に示す箇所にて定

義される。





リスト 3-212 domain「qmail_serialmail_t」の定義

① qmaild_sub_domain(user_crond_t, qmail_serialmail) in_user_role(qmail_serialmail_t) can_network(qmail_serialmail_t) can_exec(qmail_serialmail_t, qmail_serialmail_exec_t) allow qmail_serialmail_t self:process { fork signal_perms }; allow qmail_serialmail_t proc_t:file { getattr read }; allow qmail_serialmail_t { resolv_conf_t etc_runtime_t }:file { getattr read }; allow qmail_serialmail_t home_root_t:dir search; allow qmail_serialmail_t user_home_dir_type:dir { search read getattr }; rw_dir_create_file(qmail_serialmail_t, user_home_type) allow qmail_serialmail_t self:fifo_file { read write }; allow qmail_serialmail_t self:udp_socket create_socket_perms; allow qmail_serialmail_t self:tcp_socket create_socket_perms; allow qmail_serialmail_t privfd:fd use; allow qmail_serialmail_t crond_t:fifo_file { read write ioctl }; allow qmail_serialmail_t devtty_t:chr_file { read write }; ② can_exec(qmail_serialmail_t, bin_t) ③ allow qmail_serialmail_t bin_t:dir search;

D.J.Bernstein 氏43により開発されたプログラム serialmail はダイヤルアップ環

境でメールメッセージを転送する機能を提供するプログラムである44。定期的に起

動される必要のあるserialmailは通常cronプログラムを利用するため、serialmail

プロセスにアタッチする domain「qmail_serialmail_t」はユーザ cron ジョブから

起動されるプロセスにアタッチする domain としてマクロ「qmaild_sub_domain」に

より定義されている（①）。

②と③は、プログラム serialmail がプログラム tcpclient を起動することを許可

するための定義である。qmail は inetd や xinetd といったスーパーサーバーと連携

して稼動することが可能となっているが、これらのスーパーサーバーには幾つかの

問題点が従来より指摘されている。qmail の開発者である D.J.Bernstein 氏はこれ

らの問題点を解消したプログラムパッケージ ucspi-tcp45も開発しており、スーパー

サーバーに代ってこの ucspi-tcp を利用することを推奨している。プログラム

tcpclientはこのucspi-tcpを構成するプログラムの1つで、プログラムserialmail

を構成するプログラムである maildirsmtp がこの tcpclient を起動する必要がある

43 qmail の開発者で qmail 以外にも数多くのプログラムパッケージを開発している。本ガイドラインでも

取り上げている DNS サーバーdjbdns も彼が開発したプログラムである。http://cr.yp.to/djb.html 44 serialmail はシリアル・リンクによりメールを転送するためのツールの集まりである。

http://cr.yp.to/serialmail.html 45 http://cr.yp.to/ucspi-tcp.html





ため、②と③の定義が必要となる。

(B) type の定義

qmail に固有な type はリスト 3-213 に示す箇所にて定義される。

リスト 3-213 qmail 固有の type の定義

① type qmail_var_run_t, file_type, sysadmfile, pidfile; ② type etc_qmail_t, file_type, sysadmfile; ③ type qmail_exec_t, file_type, sysadmfile, exec_type; ④ type qmail_spool_t, file_type, sysadmfile; type var_qmail_t, file_type, sysadmfile;

①は、qmail がその稼動中に作成する PID ファイルにアタッチする type の定義で

ある。このため、属性「pidfile」が付与されている。

②は、ディレクトリ/etc/qmail と/var/qmail 下のサブディレクトリ・ファイル

にアタッチする type の定義である。

③は、qmail のユーティリティプログラムである qmail-getpw の実行ファイルに

アタッチする type の定義である。

④は、qmail のスプールディレクトリ/var/spool/qmail と同ディレクトリ下のサ

ブディレクトリ・ファイルにアタッチする type の定義である。

(C) SMTP ポートへのバインド

qmail をスーパーサーバーと連携させて稼動させる場合には、スーパーサーバー

が SMTP ポートに対してバインドすることを許可する必要がある。

リスト 3-214 SMTP ポートへのバインド許可

ifdef(`inetd.te', ` allow inetd_t smtp_port_t:tcp_socket name_bind; ')

リスト 3-214 は、スーパーサーバーが SMTP ポートに対してバインドすることを

許可するセキュリティポリシー定義である。





(D) cron ジョブからの起動

リスト 3-215 は、cron ジョブから qmail の構成プログラムを実行する際に必要

となるセキュリティポリシー定義である。

リスト 3-215 cron ジョブからの起動

allow user_crond_t etc_qmail_t:dir search; allow user_crond_t etc_qmail_t:file read;

マクロ「crond_domain」46にて定義される domain「user_crond_t」には、一般的

な（type「bin_t」がアタッチされた）実行ファイルの実行権限が与えられており、

この時起動されるプロセスには domain「user_crond_t」がアタッチされる。ここで

は、cron ジョブから起動されたこれらのプロセスがディレクトリ/var/qmail 下の

ファイルにアクセスする権限を与えている。なお、固有の domain がアタッチされた

プログラムを cron ジョブから実行させる場合には、そのためのセキュリティポリ

シーを定義しなければならない。

3.5.3.3. postfix

本節では、postfix を利用した SMTP サーバー構築の際の設定指針として、SELinux に標

準で用意されているセキュリティポリシー定義を解説し、その留意点を明らかにする。


Red Hat Linux 8.0 のインストール CD に含まれる RPM パッケージから、postfix を

インストールした際のディレクトリ構造を表 3-19 に示す。以降ではこのディレクト

リ構造に則してセキュリティポリシー定義を解説する。なお、同表ではドキュメント

ファイルあるいは man ページ等のインストール先は記載していないので注意してほし

い。

46 ファイル domains/program/crond_macros.te にて定義されている。





表 3-19 postfix のディレクトリ構造


1 /etc/postfix/ コンフィギュレーションファイルの配置先


3 /usr/bin/ sendmail との互換性を保つためのプログラムsendmail.postfix、mailq.postfix、およびrmail.postfix プログラムの配置先

4 /usr/lib/sasl/ Cyrus SASLライブラリがSMTPサーバーから利用される際に読み込むコンフィギュレーションファイルの配置先

5 /usr/libexec/postfix/ デーモンプログラムの配置先

6 /usr/sbin/ post*という名称のユーティリティプログラムの配置先

7 /var/spool/postfix/ キューディレクトリ

8 /var/spool/postfix/usr/lib/ zoneinfo ファイルの配置先


postfix に関連するセキュリティポリシー定義ファイルを表 3-20 に示す。

表 3-20 postfix のセキュリティポリシー定義ファイル一覧


1 file_contexts/program/postfix.fc postfix に関連するファイルに対してアタッチするセキュリティコンテキストを定義したファイル

2 domains/program/ postfix.te postfix に関連するセキュリティポリシーを定義したファイル




postfix に関連した各種オブジェクトに対してアタッチするセキュリティコンテキ

ストを解説する。


postfix に関連するファイルとディレクトリにアタッチするセキュリティコンテ

キストはファイル file_contexts/program/postfix.fc にて定義される。SELinux に





おいて標準で用意されているpostfix用のセキュリティポリシー定義はDebianでの

環境に基づいて定義されているようである。従って、Red Hat Linux 8.0 において、

インストールCDに含まれるRPMパッケージからpostfixをインストールした環境と

比較すると、セキュリティコンテキストのアタッチ先であるファイルパスが異なっ

ている箇所が見られる。このような部分はカスタマイズする必要があるので注意し

てほしい。

ファイルfile_contexts/program/postfix.fcの全容は付録のリスト A-17を参照

してほしい。

コンフィギュレーションファイル

リスト 3-216 は、postfix のコンフィギュレーションファイルにアタッチするセ


リスト 3-216 コンフィギュレーションファイルのセキュリティコンテキスト

① /etc/postfix(/.*)? system_u:object_r:etc_postfix_t ② /etc/postfix/postfix-script.* system_u:object_r:postfix_exec_t /etc/postfix/prng_exch system_u:object_r:postfix_prng_t

ここで注意が必要なのはエイリアスファイルの扱いである。3.5.3.4(2)(A)にて

解説するが、標準のセキュリティポリシー定義ではエイリアスファイルの配置位置

が/etc/aliases と/etc/aliases.db に想定されている。しかし、Red Hat Linux 8.0

における postfix でのエイリアスファイルの配置位置のデフォルトは

/etc/postfix/aliases と/etc/postfix/aliases.db となっているため、これらの

ファイルに対して適切にセキュリティコンテキストをアタッチしてやるために、リ

スト 3-216 の②の位置にリスト 3-217 に示す定義を追加しなければならない。

リスト 3-217 /etc/postfix/aliases ファイルのセキュリティコンテキスト定義

/etc/postfix/aliases(.db)? system_u:object_r:etc_aliases_t

もちろん、上記を追加定義せずに、postfix のコンフィギュレーションファイル

main.cf にてエイリアスファイルの配置位置を/etc/aliases に変更しても構わない

だろう。





デーモンプログラムの実行ファイル

リスト 3-218はpostfixのデーモンプログラムの実行ファイルにアタッチするセ


リスト 3-218 デーモンプログラムのセキュリティコンテキスト

/usr/lib/postfix/.* system_u:object_r:postfix_exec_t /usr/lib/postfix/cleanup system_u:object_r:postfix_cleanup_exec_t /usr/lib/postfix/local system_u:object_r:postfix_local_exec_t /usr/lib/postfix/master system_u:object_r:postfix_master_exec_t /usr/lib/postfix/pickup system_u:object_r:postfix_pickup_exec_t /usr/lib/postfix/(n)?qmgr system_u:object_r:postfix_qmgr_exec_t /usr/lib/postfix/showq system_u:object_r:postfix_showq_exec_t /usr/lib/postfix/smtp system_u:object_r:postfix_smtp_exec_t /usr/lib/postfix/smtpd system_u:object_r:postfix_smtpd_exec_t /usr/lib/postfix/bounce system_u:object_r:postfix_bounce_exec_t

Red Hat Linux 8.0 の環境では表 3-19 に示したように、これらの実行ファイル

のインストール先ディレクトリは/usr/libexec/postfix である。そこで上記をリス

ト 3-219 に示すように修正しなければならない。

リスト 3-219 デーモンプログラムのセキュリティコンテキスト（修正後）

/usr/lib(exec)?/postfix/.* system_u:object_r:postfix_exec_t

/usr/lib(exec)?/postfix/cleanup system_u:object_r:postfix_cleanup_exec_t

/usr/lib(exec)?/postfix/local system_u:object_r:postfix_local_exec_t

/usr/lib(exec)?/postfix/master system_u:object_r:postfix_master_exec_t

/usr/lib(exec)?/postfix/pickup system_u:object_r:postfix_pickup_exec_t

/usr/lib(exec)?/postfix/(n)?qmgr system_u:object_r:postfix_qmgr_exec_t

/usr/lib(exec)?/postfix/showq system_u:object_r:postfix_showq_exec_t

/usr/lib(exec)?/postfix/smtp system_u:object_r:postfix_smtp_exec_t

/usr/lib(exec)?/postfix/smtpd system_u:object_r:postfix_smtpd_exec_t

/usr/lib(exec)?/postfix/bounce system_u:object_r:postfix_bounce_exec_t

このように修正することで、ディレクトリ/usr/lib/postfix に加えてディレクト

リ/usr/libexec/postfix 下に対しても適切にセキュリティコンテキストがアタッ

チされる。なお、Red Hat Linux 8.0 の環境ではディレクトリ/usr/lib/postfix が

存在しない。従って、修正前のセキュリティコンテキストアタッチルールが何ら

かの悪影響を及ぼすことはないためそのまま残す形としている。





ユーティリティプログラム

リスト 3-220 は postfix のユーティリティプログラムにアタッチするセキュリ

ティコンテキストの定義である。

リスト 3-220 ユーティリティプログラムのセキュリティコンテキスト

/usr/sbin/postalias system_u:object_r:postfix_master_exec_t /usr/sbin/postcat system_u:object_r:postfix_master_exec_t /usr/sbin/postconf system_u:object_r:postfix_master_exec_t /usr/sbin/postdrop system_u:object_r:postfix_postdrop_exec_t /usr/sbin/postfix system_u:object_r:postfix_master_exec_t /usr/sbin/postkick system_u:object_r:postfix_master_exec_t /usr/sbin/postlock system_u:object_r:postfix_master_exec_t /usr/sbin/postlog system_u:object_r:postfix_master_exec_t /usr/sbin/postmap system_u:object_r:postfix_master_exec_t /usr/sbin/postqueue system_u:object_r:postfix_postqueue_exec_t /usr/sbin/postsuper system_u:object_r:postfix_master_exec_t /usr/sbin/rmail system_u:object_r:postfix_master_exec_t

Red Hat Linux 8.0 の環境では表 3-19 に示すようにプログラム rmail のインス

トールパスが/usr/bin/rmail.postfix となっている。そこで、リスト 3-221 に示す

定義文を追加しなければならない。

リスト 3-221 /usr/bin/rmail のセキュリティコンテキスト

/usr/bin/rmail system_u:object_r:postfix_master_exec_t /usr/bin/rmail.postfix system_u:object_r:postfix_master_exec_t

プログラムrmailの実行ファイルは実際には/usr/bin/rmail.postfixとなってお

り、/usr/bin/rmail はその/usr/bin/rmail.postfix へのシンボリックリンクとなっ

ているため、これら 2 つのファイルに対してセキュリティコンテキストを適切にア

タッチする必要がある。

キューディレクトリ

リスト 3-222はpostfixのキューディレクトリにアタッチするセキュリティコン

テキストの定義である。





リスト 3-222 キューディレクトリのセキュリティコンテキスト

/var/spool/postfix/active(/.*)? system_u:object_r:postfix_spool_t

/var/spool/postfix/incoming(/.*)? system_u:object_r:postfix_spool_t

/var/spool/postfix/maildrop(/.*)? system_u:object_r:postfix_spool_maildrop_t

/var/spool/postfix/defer(red)?(/.*)? system_u:object_r:postfix_spool_t

/var/spool/postfix/bounce(/.*)? system_u:object_r:postfix_spool_bounce_t

/var/spool/postfix/flush(/.*)? system_u:object_r:postfix_spool_flush_t

chroot 環境で利用する場合のシステムファイル

リスト 3-223 は postfix を chroot 環境で実行する際に必要となるシステムファ

イルにアタッチするセキュリティコンテキストの定義である。

リスト 3-223 システムファイルのセキュリティコンテキスト

/var/spool/postfix/lib(/.*)? system_u:object_r:lib_t /var/spool/postfix/lib/ld.*¥.so.* system_u:object_r:ld_so_t /var/spool/postfix/lib/lib.*¥.so.* system_u:object_r:shlib_t /var/spool/postfix/lib/[^/]*/lib.*¥.so.* system_u:object_r:shlib_t /var/spool/postfix/lib/devfsd/.*¥.so.* system_u:object_r:shlib_t /var/spool/postfix/etc/services system_u:object_r:etc_t

postfix を chroot 環境で実行する場合、ディレクトリ/var/spool/postfix に

chroot されるため、postfix の稼動に必要となるシステムファイルをそのシステム

の流儀（ファイルパス）に従って同ディレクトリ下にコピーしておく必要がある。

リスト 3-223 はそれらのシステムファイルにアタッチするセキュリティコンテキ

ストの定義である。また、Red Hat Linux 8.0 の環境では表 3-19 に示したようにタ

イムゾーン情報を配置するディレクトリ/var/spool/postfix/usr/lib/zoneinfo が

用意されている。SELinux に標準で含まれる postfix 用のセキュリティポリシー定

義ファイルではこの点を考慮されていないので、リスト 3-223 をリスト 3-223 に示

すように修正するのが良いだろう。





リスト 3-224 システムファイルのセキュリティコンテキスト（修正後）

/var/spool/postfix/usr(/.*)? system_u:object_r:usr_t

/var/spool/postfix(/usr)?/lib(/.*)? system_u:object_r:lib_t

/var/spool/postfix(/usr)?/lib/ld.*¥.so.* system_u:object_r:ld_so_t

/var/spool/postfix(/usr)?/lib/lib.*¥.so.* system_u:object_r:shlib_t

/var/spool/postfix(/usr)?/lib/[^/]*/lib.*¥.so.* system_u:object_r:shlib_t

/var/spool/postfix(/usr)?/lib/devfsd/.*¥.so.* system_u:object_r:shlib_t

/var/spool/postfix/etc/services system_u:object_r:etc_t

このようにしておけば、システムのディレクトリ/usr/lib/下に含まれるシステ

ムファイルをコピーすることになった場合にも対応できるだろう。

デーモンプロセスのアクセスポイント

postfix はそのメールシステムを実現するために数多くのデーモンプロセスに

よって構成されている。これらのデーモンプロセスは自身の提供するサービスを別

プロセスに提供するために、ソケットや名前付きパイプといったオブジェクトを作

成する。そして、これらのオブジェクトを公開とする（postfix とは無関係な外部

プロセスからのアクセスを認める）か、非公開とする（postfix 内のデーモンプロ

セスにのみアクセスを認める）か、をデーモンプロセス毎に設定できるようになっ

ており、公開するオブジェクトはディレクトリ/var/spool/postfix/public の下に、

非公開のオブジェクトはディレクトリ/var/spool/postfix/private の下に作成さ

れるようになっている。リスト 3-225 はこれらのディレクトリとその中に配置され

るオブジェクトにアタッチするセキュリティコンテキストの定義である。なお、本

ガイドラインでは上記オブジェクトを「アクセスポイント」と呼ぶことにする。

リスト 3-225 アクセスポイントのセキュリティコンテキスト

/var/spool/postfix/private(/.*)? system_u:object_r:postfix_private_t /var/spool/postfix/public(/.*)? system_u:object_r:postfix_public_t

PID ファイル

リスト 3-226は postfixの各デーモンプロセスが作成するPIDファイルにアタッ

チするセキュリティコンテキストの定義である。





リスト 3-226 PID ファイルのセキュリティコンテキスト

/var/spool/postfix/pid system_u:object_r:var_run_t /var/spool/postfix/pid/.* system_u:object_r:postfix_var_run_t




domains/program/mta.te にて定義されている。ファイル mta.te に関しては


(4) マクロ

ファイル domains/program/postfix.te では幾つかのマクロが定義される。これらの

マクロはいずれもpostfixのデーモンプロセスにアタッチするdomainを定義するため

のものである。ここでは、これらのマクロに関して解説する。

(A) postfix_domain

マクロ「postfix_domain」は postfix におけるデーモンプログラムのプロセスに

アタッチする domain を定義するマクロである。プログラム master にアタッチする

domain はこのマクロを利用して定義される。それでは、マクロ「postfix_domain」

の全容をご覧いただこう。リスト 3-227 がマクロ「postfix_domain」の定義内容で

ある。





リスト 3-227 マクロ「postfix_domain」

define(`postfix_domain', `

daemon_base_domain(postfix_$1, `$2')

allow postfix_$1_t self:process setpgid;

allow postfix_$1_t postfix_master_t:process sigchld;

allow postfix_master_t postfix_$1_t:process signal;

allow postfix_$1_t { etc_t etc_postfix_t }:dir r_dir_perms;

allow postfix_$1_t { etc_t etc_postfix_t }:{ file lnk_file } r_file_perms;

allow postfix_$1_t self:unix_dgram_socket create_socket_perms;

allow postfix_$1_t self:unix_stream_socket create_stream_socket_perms;

allow postfix_$1_t self:unix_stream_socket connectto;

allow postfix_$1_t { sbin_t bin_t }:dir r_dir_perms;

allow postfix_$1_t bin_t:lnk_file r_file_perms;

allow postfix_$1_t shell_exec_t:file rx_file_perms;

allow postfix_$1_t var_spool_t:dir r_dir_perms;

allow postfix_$1_t postfix_exec_t:file rx_file_perms;

allow postfix_$1_t devtty_t:chr_file rw_file_perms;

allow postfix_$1_t etc_runtime_t:file r_file_perms;

allow postfix_$1_t proc_t:dir r_dir_perms;

allow postfix_$1_t proc_t:file r_file_perms;

allow postfix_$1_t postfix_exec_t:dir r_dir_perms;

allow postfix_$1_t fs_t:filesystem getattr;

can_exec(postfix_$1_t, postfix_$1_exec_t)

allow postfix_$1_t resolv_conf_t:file { read getattr };

allow postfix_$1_t var_t:dir { search getattr };

allow postfix_$1_t tmp_t:dir getattr;

file_type_auto_trans(postfix_$1_t, var_run_t, postfix_var_run_t)

')dnl

このマクロは、第 1引数として domain 修飾子を、第 2引数として domain に付与

する属性リストを受け付ける仕様となっており、domain「postfix_"domain 修飾子

"_t」が定義される。以下では、このマクロ「postfix_domain」にて定義されるセキュ

リティポリシーを部分的に抜粋しながら解説していくことにする。

domain の定義

リスト 3-228 はマクロ「postfix_domain」における domain の定義箇所である。

"$1"と"$2"は各々、マクロ「postfix_domain」の第 1引数と第 2引数を示している。





リスト 3-228 postfix デーモンプロセス domain の定義

daemon_base_domain(postfix_$1, `$2')

ここではマクロ「daemon_base_domain」が利用されている。このマクロにより

domain「postfix_$1_t」が定義され、マクロ「postfix_domain」の第 2 引数に指定

された属性が同 domain に付与される。また、同 domain の実行ファイルにアタッチ

するための type「postfix_$1_exec_t」もこのマクロにより同時に定義されている

ことに注意してほしい。

master プログラムとの間のシグナル送信

リスト 3-229 はマクロ「postfix_domain」において、master プログラムとデー

モンプログラムとの間でのシグナルの送信を許可するセキュリティポリシーを定義

している箇所である。

リスト 3-229 master プログラムとの間のシグナル送信を許可

allow postfix_$1_t self:process setpgid;

allow postfix_$1_t postfix_master_t:process sigchld;

allow postfix_master_t postfix_$1_t:process signal;

postfix では、プログラム master 以外のデーモンプログラムはすべてプログラム

master から起動される。従って、master プロセスの子プロセスとなるこれらのデー

モンプロセスは親プロセスである master プロセスに対してその終了時に SIGCHLD

シグナルを送信する。また逆に、親プロセスである master プロセスから子プロセス

であるデーモンプロセスに対して各種のシグナルが送信されることがある。これら

は適切に許可される必要がある。

コンフィギュレーションファイルへのアクセス

postfix のデーモンプロセスが各種コンフィギュレーションファイルを参照する

ことを許可しなければならない。リスト 3-230 は、マクロ「postfix_domain」にお

いて、postfix のコンフィギュレーションファイルが配置されるディレクトリ

/etc/postfix と同ディレクトリ下のファイルとリンクファイルに対する読み取り

権限を与えるセキュリティポリシーを定義している箇所である。





リスト 3-230 コンフィギュレーションファイルへのアクセスを許可

allow postfix_$1_t { etc_t etc_postfix_t }:dir r_dir_perms; allow postfix_$1_t { etc_t etc_postfix_t }:{ file lnk_file } r_file_perms;

ディレクトリ/etc/postfix を参照するためには親ディレクトリである/etc に対

しても読み取り権限が必要であることに注意してほしい。

ソケット通信

postfix のデーモンプロセスはそのプロセス間でソケット通信を行うため、ソ

ケットを作成・利用する権限が必要である。リスト 3-231 はリスト 3-228 において

定義された domain に対してソケットの作成・利用を許可するためのセキュリティポ

リシーを定義している箇所である。

リスト 3-231 デーモンプロセスに対してソケットの作成・利用を許可

① allow postfix_$1_t self:unix_dgram_socket create_socket_perms;

② allow postfix_$1_t self:unix_stream_socket create_stream_socket_perms;

③ allow postfix_$1_t self:unix_stream_socket connectto;

リスト 3-231 における①は、自身と同一の domain（type）がアタッチされた UDP

ソケットの作成とその利用を許可するためのセキュリティポリシー定義である。同

様に②は、TCP ソケットの作成とその利用を許可するためのセキュリティポリシー

定義である。なお TCP ソケットはコネクション型であるため、③のように TCP ソケッ

トに対するコネクションを許可するセキュリティポリシー定義が必要となる。

PID ファイルの作成

postfix のデーモンプロセスが PID ファイルを作成することを許可する必要があ

る。リスト 3-232 は、マクロ「postfix_domain」において、PID ファイルの作成を

許可するためのセキュリティポリシーを定義している箇所である。





リスト 3-232 PID ファイルの作成を許可

file_type_auto_trans(postfix_$1_t, var_run_t, postfix_var_run_t)

このファイル type 遷移ルールにより、postfix のデーモンプロセスが作成する

PID ファイルには type「postfix_var_run_t」がアタッチされる。

その他

マクロ「postfix_domain」にて定義される domain には様々な権限が与えられて

いる。

リスト 3-233 その他の権限

allow postfix_$1_t { sbin_t bin_t }:dir r_dir_perms; allow postfix_$1_t bin_t:lnk_file r_file_perms; allow postfix_$1_t shell_exec_t:file rx_file_perms; allow postfix_$1_t var_spool_t:dir r_dir_perms; allow postfix_$1_t postfix_exec_t:file rx_file_perms; allow postfix_$1_t devtty_t:chr_file rw_file_perms; allow postfix_$1_t etc_runtime_t:file r_file_perms; allow postfix_$1_t proc_t:dir r_dir_perms; allow postfix_$1_t proc_t:file r_file_perms; allow postfix_$1_t postfix_exec_t:dir r_dir_perms; allow postfix_$1_t fs_t:filesystem getattr; can_exec(postfix_$1_t, postfix_$1_exec_t) allow postfix_$1_t resolv_conf_t:file { read getattr }; allow postfix_$1_t var_t:dir { search getattr }; allow postfix_$1_t tmp_t:dir getattr;

(B) postfix_server_domain

マクロ「postfix_server_domain」はプログラム master より起動されるデーモン

プログラムにアタッチするための domain を定義するマクロである。マクロの全容を

リスト 3-234 に示す。





リスト 3-234 マクロ「postfix_server_domain」

define(`postfix_server_domain', `

① postfix_domain($1, `$2')

② domain_auto_trans_read(postfix_master_t, postfix_$1_exec_t, postfix_$1_t)

③ allow postfix_$1_t postfix_master_t:unix_stream_socket { connectto

rw_stream_socket_perms };

④ allow postfix_$1_t self:capability { setuid setgid dac_override };

⑤ can_network(postfix_$1_t)

')

まず①において、3.5.3.3(4)(A)で解説したマクロ「postfix_domain」により

domain が定義される。②は、①で定義した domain をプログラム master が起動する

ことを許可する定義である。「postfix_$1_exec_t」は①の定義の際に同時に定義さ

れる type で、①で定義した domain をアタッチするプログラムの実行ファイルにア

タッチしておく type である。この domain 遷移ルールにより、プログラム master

が type「postfix_$1_exec_t」のアタッチされたファイルを実行した結果として起

動されるプロセスに対して①で定義した domain がアタッチされるようになる。

③は、親プロセスである master プロセスが作成した TCP ソケットに接続し、ソ

ケットに対する読み取り・書き込みを許可するためのセキュリティポリシー定義で

ある。

④は、①で定義された domain がケイパビリティ CAP_SETUID（UID の変更）、

CAP_SETGID（GID の変更）、および CAP_DAC_OVERRIDE（DAC の無効化。任意アクセス

制御の制限を無効化する）を獲得することを許可するセキュリティポリシー定義で

ある。

⑤では、①で定義された domain に対してネットワークを利用するために必要と

なる各種の権限をマクロ「can_network」を利用して与えている。

3.5.3.3(4)(C)にて解説するが、postfix 用に用意された標準セキュリティポリ

シー定義ではマクロ「 postfix_server_domain 」に似たマクロとして

「postfix_public_domain」が定義されている。3.5.3.3(3)(A)でも解説したが、

postfix ではそのデーモンプログラム毎に、各々が提供するサービスに対するアク

セスポイントの公開／非公開を設定することが可能となっている。マクロ

「postfix_server_domain」はこのアクセスポイントを非公開とするデーモンプロセ

スにアタッチする domain を定義するためのマクロ、そして

「postfix_public_domain」はアクセスポイントを公開するデーモンプロセスにア

タッチする domain を定義するためのマクロとして用意された経緯が感じられるが、

これらのマクロが利用されている箇所を見る限り、明確な使い分けがなされていな





いように感じる。これら 2 つのマクロはあまり区別して捉えない方が判りやすいと

思われる。

(C) postfix_public_domain

マクロ「postfix_public_domain」はプログラム master より起動されるデーモン

プログラムにアタッチする domain を定義するためのマクロである。特に、アクセス

ポイントを公開するデーモンプロセスにアタッチする domain を定義するためのマ

クロと見受けられるが、3.5.3.3(4)(B)で解説したマクロ「postfix_server_domain」

との使い分けが明確ではない。マクロの全容をリスト 3-235 に示す。

リスト 3-235 マクロ「postfix_public_domain」

define(`postfix_public_domain',` postfix_server_domain($1) ① allow postfix_$1_t postfix_public_t:dir search; ')

このマクロの実態はマクロ「postfix_server_domain」に対して更に付加的な権

限を与えているに過ぎないことが判る。付加的な権限とは、公開アクセスポイント

が配置されるディレクトリ/var/spool/postfix/public に対する探索権限である

（①）。

(D) postfix_user_domain

マクロ「postfix_user_domain」はコマンドラインから直接実行されるユーティ

リティプログラムあるいはそれらのプログラムから 2 次的に呼び出されるプログラ

ム、つまりユーザ domain が起動元になり得るプログラムにアタッチするための

domain を定義するマクロである。マクロの全容をリスト 3-236 に示す。





リスト 3-236 マクロ「postfix_user_domain」

define(`postfix_user_domain', ` ① postfix_domain($1, `$2') ② domain_auto_trans(user_mail_domain, postfix_$1_exec_t, postfix_$1_t) ③ in_user_role(postfix_$1_t) ④ role sysadm_r types postfix_$1_t; ⑤ allow postfix_$1_t userdomain:process sigchld; ⑥ allow postfix_$1_t userdomain:fifo_file { write getattr }; ⑦ allow postfix_$1_t { userdomain privfd }:fd use; ⑧ allow postfix_$1_t self:capability dac_override; ')

まず①において、マクロ「postfix_domain」を利用して domain を定義している。

②は、ユーザ domain から起動された、つまり非デーモンプロセスとして稼動す

る MTA プロセスが、①で定義した domain がアタッチされるプログラムの実行ファイ

ルを実行することを許可し、この際起動するプロセスに対して①で定義した domain

をアタッチするための domain 遷移ルールである。また、この domain 遷移ルールを

許可するためには、起動元である role にて①で定義した domain が許可されなけれ

ばならない。このための定義が③と④である。③では、ユーザ domain「user_t」の

roleである「user_r」にて①で定義したdomainを許可し、同様に④ではユーザdomain

「sysadm_t」の role である「sysadm_r」にて①で定義した domain を許可している。

③の「in_user_role」は macros/user_macros.te にて定義されているマクロで、そ

の実態は role「user_r」に対して④と同様の定義をしているに過ぎない。

⑤は、コマンドランから直接起動されるユーティリティプログラムを考慮したも

ので、親プロセスであるユーザ domain に対して SIGCHLD シグナルの送信を許可する

ものである。

⑥と⑦は、起動元であるユーザ domain が作成したオブジェクトに対するアクセ

スを許可するセキュリティポリシー定義である。これらは、ユーザ domain から直接

起動されるプログラムにとっても、また、ユーザ domain から起動された非デーモン

プロセスとして稼動する MTA プロセスから起動されるプログラムにとっても必要な

セキュリティポリシー定義である。

⑧は、①で定義した domain がケイパビリティ CAP_DAC_OVERRIDE（DAC の無効化。

任意アクセス制御の制限を無効化する）を獲得することを許可するセキュリティポ

リシー定義である。






ここでは、ファイル domains/program/postfix.te にて定義されるセキュリティポリ

シー定義に関して解説する。


postfix を構成するデーモンプログラムには、その多くに固有な domain が定義さ

れており、これらの domain はいずれも 3.5.3.3(4)で解説したマクロにより定義さ

れる。

プログラム master

プログラムmasterにアタッチするdomainはリスト 3-237に示す箇所で定義され

ている。

リスト 3-237 domain「postfix_master_t」の定義

postfix_domain(master)

プログラム master にアタッチする domain の定義にはマクロ「postfix_domain」

が利用されており、この定義により domain「postfix_master_t」とプログラム master

の実行ファイルにアタッチする type「postfix_master_exec_t」が定義される。そ

して、この domain「postfix_master_t」に対してリスト 3-238 に示す幾つかのセキュ

リティポリシーが定義されている。





リスト 3-238 domain「postfix_master_t」に対するセキュリティポリシー定義

dontaudit postfix_master_t postfix_spool_t:file getattr; can_exec({ sysadm_mail_t system_mail_t }, postfix_master_exec_t) file_type_auto_trans({ sysadm_mail_t system_mail_t }, etc_t, etc_aliases_t) ① allow postfix_master_t sendmail_exec_t:file r_file_perms; ② domain_auto_trans(initrc_t, postfix_master_exec_t, postfix_master_t) ifdef(`pppd.te', ` ③ domain_auto_trans(pppd_t, postfix_master_exec_t, postfix_master_t) ') can_exec(postfix_master_t, ls_exec_t) allow postfix_master_t sysctl_kernel_t:dir r_dir_perms; allow postfix_master_t sysctl_kernel_t:file r_file_perms; allow postfix_master_t self:fifo_file rw_file_perms; allow postfix_master_t usr_t:file r_file_perms; can_exec(postfix_master_t, { shell_exec_t bin_t postfix_exec_t }) allow postfix_master_t self:capability { dac_override kill setgid setuid net_bind_service }; allow postfix_master_t postfix_public_t:fifo_file create_file_perms; allow postfix_master_t postfix_public_t:sock_file create_file_perms; allow postfix_master_t postfix_public_t:dir rw_dir_perms; allow postfix_master_t postfix_private_t:dir rw_dir_perms; allow postfix_master_t postfix_private_t:sock_file create_file_perms; allow postfix_master_t postfix_private_t:fifo_file create_file_perms; ④ can_network(postfix_master_t) ⑤ allow postfix_master_t smtp_port_t:tcp_socket name_bind; ⑥ allow postfix_master_t postfix_spool_maildrop_t:dir r_dir_perms; allow postfix_master_t postfix_prng_t:file getattr; ⑦ allow postfix_master_t postfix_spool_maildrop_t:file getattr; allow postfix_master_t privfd:fd use; allow postfix_master_t etc_aliases_t:file r_file_perms; create_dir_file(postfix_master_t, postfix_spool_flush_t) allow postfix_master_t random_device_t:chr_file { read getattr }; allow postfix_master_t postfix_prng_t:file rw_file_perms; allow postfix_master_t postfix_spool_t:dir create_dir_perms; allow postfix_master_t postfix_spool_t:file { getattr setattr rename }; dontaudit postfix_master_t man_t:dir search; ⑧ can_tcp_connect(domain, postfix_master_t) allow postfix_master_t postfix_spool_t:dir r_dir_perms;

①は、 type 「 sendmail_exec_t 」のアタッチされたファイル、つまり

/usr/sbin/sendmail に対する読み取り権限を与える定義であるが、Red Hat Linux

8.0 環境における同ファイルはシンボリックリンクとなっているため、同 type のア

タッチされているリンクファイルに対する読み取り権限も必要となる。そこで、リ





スト 3-239 に示すように修正する必要がある。

リスト 3-239 シンボリックリンク/usr/sbin/sendmail に対する読み取り権限

allow postfix_master_t sendmail_exec_t:{ file lnk_file } r_file_perms;

②と③は、プログラム master の起動を許可するためのセキュリティポリシー定

義である。postfix のデーモンプログラムであるプログラム master は通常の SMTP

サーバーであれば initrc スクリプトから起動される。従って、initrc スクリプト

の domain である「initrc_t」からの起動を許可し、起動されたプロセスに対して

domain「postfix_master_t」をアタッチするように domain 遷移ルールを定義してい

る。③は、pppd を利用したダイヤルアップ接続環境で postfix を稼動させたい場合

に有効なセキュリティポリシー定義である。この場合、postfix の起動元が initrc

スクリプトではなくpppdとなるため、このためのdomain遷移ルールが必要となる。

ダイヤルアップ接続環境でない場合には、③をコメントアウトするか、pppd のセ

キュリティポリシー定義ファイルである domains/program/pppd.te を削除あるいは

名称変更しておくべきである。

④では、マクロ「can_network」を利用して、domain「postfix_master_t」に対

してネットワークアクセスに必要となる権限を一括して与えている。また⑤では、

SMTP サーバーの利用するポートに対してバインドすることを許可している。type

「smtp_port_t」は 3.5.3.4(2)(B)にて定義されている type である。

⑧では、プログラム master が作成する TCP ソケットに対する他のプロセスによ

るコネクションを許可している。

本ガイドライン作成途中である 2003 年 1 月 29 日に、SELinux に含まれる標準セ

キュリティポリシー定義の最新アップデートがリリースされている。このアップ

デートではリスト 3-238 に示した箇所での若干の修正と新たなセキュリティポリ

シー定義の追加が施されており、リスト 3-238 の⑥と⑦はリスト 3-240 に示すよう

に修正されている。

リスト 3-240 ポリシーアップデートでの修正内容（postfix_master_t）その 1

allow postfix_master_t postfix_spool_maildrop_t:dir rw_dir_perms; allow postfix_master_t postfix_spool_maildrop_t:file { rename getattr };

また、リスト 3-241 に示す新たなセキュリティポリシー定義が追加されている。





リスト 3-241 ポリシーアップデートでの修正内容（postfix_master_t）その 2

file_type_auto_trans(postfix_master_t, var_spool_t, postfix_spool_t, dir)

デーモンプログラム smtp

デーモンプログラムsmtpにアタッチするdomainはリスト 3-242に示す箇所で定

義される。

リスト 3-242 domain「postfix_smtp_t」の定義

① postfix_server_domain(smtp)

allow postfix_smtp_t postfix_spool_t:dir r_dir_perms;

allow postfix_smtp_t postfix_spool_t:file rw_file_perms;

allow postfix_smtp_t { postfix_private_t postfix_public_t }:dir search;

allow postfix_smtp_t { postfix_private_t postfix_public_t }:sock_file write;

allow postfix_smtp_t random_device_t:chr_file r_file_perms;

allow postfix_smtp_t postfix_master_t:unix_stream_socket connectto;

デーモンプログラム smtp にアタッチする domain「postfix_smtp_t」はマクロ

「postfix_server_domain」により定義されている（①）。

デーモンプログラム smtpd

デーモンプログラム smtpd にアタッチする domain はリスト 3-243 に示す箇所で

定義される。





リスト 3-243 domain「postfix_smtpd_t」の定義

① postfix_server_domain(smtpd)

allow postfix_smtpd_t random_device_t:chr_file r_file_perms;

allow postfix_smtpd_t postfix_master_t:tcp_socket rw_stream_socket_perms;

allow postfix_smtpd_t { postfix_private_t postfix_public_t }:dir search;

allow postfix_smtpd_t { postfix_private_t postfix_public_t }:sock_file

rw_file_perms;

allow postfix_smtpd_t postfix_master_t:unix_stream_socket connectto;

allow { postfix_smtp_t postfix_smtpd_t } postfix_prng_t:file rw_file_perms;

デーモンプログラム smtpd にアタッチする domain「postfix_smtpd_t」はマクロ


2003 年 1 月 29 日にリリースされたセキュリティポリシーアップデートでは、

domain「postfix_smtpd_t」に対するセキュリティポリシーとしてリスト 3-244 に

示す定義が追加されている。

リスト 3-244 ポリシーアップデートでの修正内容（postfix_smtpd_t）

allow postfix_smtpd_t etc_aliases_t:file r_file_perms;

デーモンプログラム local

デーモンプログラム local にアタッチする domain はリスト 3-245 に示す箇所で

定義される。





リスト 3-245 domain「postfix_local_t」の定義

① postfix_server_domain(local, `, mta_delivery_agent') ifdef(`procmail.te', ` domain_auto_trans_read(postfix_local_t, procmail_exec_t, procmail_t) # for a bug in the postfix local program dontaudit procmail_t postfix_local_t:tcp_socket { read write }; ') allow postfix_local_t { etc_aliases_t }:file r_file_perms; allow postfix_local_t self:fifo_file rw_file_perms; allow postfix_local_t postfix_spool_t:dir r_dir_perms; allow postfix_local_t postfix_spool_t:file rw_file_perms; # for .forward - maybe we need a new type for it? allow postfix_local_t postfix_private_t:dir search; allow postfix_local_t postfix_private_t:sock_file rw_file_perms; allow postfix_local_t postfix_master_t:unix_stream_socket connectto; allow postfix_local_t postfix_public_t:dir search; allow postfix_local_t postfix_public_t:sock_file write; can_exec(postfix_local_t, shell_exec_t)

デーモンプログラム local にアタッチする domain はマクロ


デーモンプログラム cleanup

デーモンプログラム cleanup にアタッチする domain はリスト 3-246 に示す箇所

で定義される。

リスト 3-246 domain「postfix_cleanup_t」の定義

① postfix_public_domain(cleanup) create_dir_file(postfix_cleanup_t, postfix_spool_t) allow postfix_cleanup_t postfix_public_t:fifo_file rw_file_perms; allow postfix_cleanup_t postfix_public_t:sock_file { getattr write }; allow postfix_cleanup_t postfix_private_t:dir search; allow postfix_cleanup_t postfix_private_t:sock_file rw_file_perms; allow postfix_cleanup_t postfix_master_t:unix_stream_socket connectto; allow postfix_cleanup_t { postfix_spool_bounce_t }:dir r_dir_perms;

デーモンプログラム cleanup にアタッチする domain はマクロ

「postfix_public_domain」により定義されている（①）。





プログラム postqueue

プログラム postqueue にアタッチする domain はリスト 3-247 に示す箇所で定義

される。

リスト 3-247 domain「postfix_postqueue_t」の定義

① postfix_user_domain(postqueue)

allow postfix_postqueue_t postfix_public_t:dir search;

allow postfix_postqueue_t postfix_public_t:fifo_file getattr;

allow postfix_postqueue_t self:udp_socket { create ioctl };

allow postfix_master_t postfix_postqueue_exec_t:file getattr;

# to write the mailq output, it really should not need read access!

allow postfix_postqueue_t { ptyfile ttyfile }:chr_file { read write getattr };

ifdef(`gnome-pty-helper.te', `allow postfix_postqueue_t user_gph_t:fd use;')

# wants to write to /var/spool/postfix/public/showq

allow postfix_postqueue_t postfix_public_t:sock_file rw_file_perms;

allow postfix_postqueue_t postfix_master_t:unix_stream_socket connectto;

# write to /var/spool/postfix/public/qmgr

allow postfix_postqueue_t postfix_public_t:fifo_file write;

ユーザ domain より起動されるプログラム postqueue にアタッチする domain はマ

クロ「postfix_user_domain」を利用して定義されている（①）。

デーモンプログラム showq

デーモンプログラム showq にアタッチする domain はリスト 3-248 に示す箇所で

定義される。





リスト 3-248 domain「postfix_showq_t」の定義

① postfix_user_domain(showq)

# the following auto_trans is usually in postfix server domain

domain_auto_trans_read(postfix_master_t, postfix_showq_exec_t, postfix_showq_t)

allow postfix_showq_t self:udp_socket { create ioctl };

allow postfix_showq_t { postfix_spool_t }:dir r_dir_perms;

r_dir_file(postfix_showq_t, postfix_spool_maildrop_t)

domain_auto_trans_read(postfix_postqueue_t, postfix_showq_exec_t,

postfix_showq_t)

allow postfix_showq_t self:capability { setuid setgid };

allow postfix_showq_t postfix_master_t:unix_stream_socket { accept

rw_socket_perms };

r_dir_file(postfix_showq_t, postfix_spool_t)

allow postfix_showq_t self:tcp_socket create_socket_perms;

allow postfix_showq_t ptyfile:chr_file { read write };

デーモンプログラムshowqはスーパーユーザがスタンドアロンで実行することが

許可されているプログラムである。そこで、同プログラムにアタッチする domain

はマクロ「postfix_user_domain」を利用して定義されている（①）。

プログラム postdrop

プログラムpostdropにアタッチするdomainはリスト 3-249に示す箇所で定義さ

れる。

リスト 3-249 domain「postfix_postqueue_t」の定義

① postfix_user_domain(postdrop, `, mta_user_agent')

allow postfix_postdrop_t postfix_spool_maildrop_t:dir rw_dir_perms;

allow postfix_postdrop_t postfix_spool_maildrop_t:file create_file_perms;

allow postfix_postdrop_t user_mail_domain:unix_stream_socket rw_socket_perms;

allow postfix_postdrop_t postfix_public_t:dir search;

allow postfix_postdrop_t postfix_public_t:fifo_file rw_file_perms;

dontaudit postfix_postdrop_t { ptyfile ttyfile }:chr_file { read write };

allow postfix_master_t postfix_postdrop_exec_t:file getattr;

ifdef(`crond.te', `

allow postfix_postdrop_t { crond_t system_crond_t }:fd use;

allow postfix_postdrop_t { crond_t system_crond_t }:fifo_file rw_file_perms;

')

ユーザ domain から起動されるプログラム postdrop にアタッチする domain はマ

クロ「postfix_user_domain」を利用して定義されている（①）。





デーモンプログラム pickup

デーモンプログラムpickupにアタッチするdomainはリスト 3-250に示す箇所で

定義される。

リスト 3-250 domain「postfix_pickup_t」の定義

① postfix_public_domain(pickup) allow postfix_pickup_t postfix_public_t:fifo_file rw_file_perms; allow postfix_pickup_t postfix_public_t:sock_file rw_file_perms; allow postfix_pickup_t postfix_private_t:dir search; allow postfix_pickup_t postfix_private_t:sock_file write; allow postfix_pickup_t postfix_master_t:unix_stream_socket connectto; allow postfix_pickup_t postfix_spool_maildrop_t:dir rw_dir_perms; allow postfix_pickup_t postfix_spool_maildrop_t:file r_file_perms; allow postfix_pickup_t postfix_spool_maildrop_t:file unlink; allow postfix_pickup_t self:tcp_socket create_socket_perms;

デーモンプログラム pickup にアタッチする domain はマクロ


デーモンプログラム qmgr

デーモンプログラムqmgrにアタッチするdomainはリスト 3-251に示す箇所で定

義される。

リスト 3-251 domain「postfix_qmgr_t」の定義

① postfix_public_domain(qmgr) allow postfix_qmgr_t postfix_public_t:fifo_file rw_file_perms; allow postfix_qmgr_t postfix_public_t:sock_file write; allow postfix_qmgr_t postfix_private_t:dir search; allow postfix_qmgr_t postfix_private_t:sock_file rw_file_perms; allow postfix_qmgr_t postfix_master_t:unix_stream_socket connectto; # for /var/spool/postfix/active create_dir_file(postfix_qmgr_t, postfix_spool_t)

デーモンプログラム qmgr にアタッチする domain はマクロ






デーモンプログラム bounce

デーモンプログラムbounceにアタッチするdomainはリスト 3-252に示す箇所で

定義される。

リスト 3-252 domain「postfix_bounce_t」の定義

① postfix_public_domain(bounce) type postfix_spool_bounce_t, file_type, sysadmfile; create_dir_file(postfix_bounce_t, postfix_spool_bounce_t) create_dir_file(postfix_bounce_t, postfix_spool_t) ② allow postfix_master_t postfix_spool_bounce_t:dir r_dir_perms; allow postfix_bounce_t self:capability { dac_read_search }; allow postfix_bounce_t postfix_public_t:sock_file write; allow postfix_bounce_t self:tcp_socket create_socket_perms; r_dir_file(postfix_qmgr_t, postfix_spool_bounce_t)

デーモンプログラム bounceにアタッチする domain はアクセスポイントを公開す

ることを想定して定義されている。そのため、 ① のようにマクロ

「postfix_public_domain」が利用されている。

上記セキュリティポリシーでは権限の足りない箇所がある。②の定義は、プログ

ラム master が bounce キューディレクトリ47に保存されたログメッセージの読み取

りを許可するためのものであるが、master プログラムは bounce キューディレクト

リ内のログメッセージを探索する際に find コマンドを利用しており、この際ファイ

ルの属性を指定して探索することから、bounce キューディレクトリに対する探索権

限が要求される。このセキュリティポリシーを定義しないと、bounce メッセージの

処理で失敗するので注意が必要である。2003 年 1 月 29 日にリリースされたセキュ

リティポリシーアップデートではこの点を含めて見直しがなされており、上記の②

はリスト 3-253 に示すように修正されている。

リスト 3-253 bounce キューディレクトリに対するアクセス権限の追加定義

allow postfix_master_t postfix_spool_bounce_t:dir create_dir_perms;

47 配信不可能なメールメッセージはバウンスメッセージと呼ばれ、postfix の場合、このバウンスメッセー

ジに関するログメッセージが bounce キューディレクトリ下に保存される。バウンスメッセージはこのログ

メッセージを基にして、エラーメールメッセージとして送信元ユーザ宛に送信される。





(B) type の定義

postfix に固有なオブジェクトにアタッチするための type を定義する。これらの

type の定義箇所をリスト 3-254 に示す。

リスト 3-254 postfix に固有な type

① type postfix_var_run_t, file_type, sysadmfile, pidfile; type etc_postfix_t, file_type, sysadmfile; ② type postfix_exec_t, file_type, sysadmfile, exec_type; type postfix_public_t, file_type, sysadmfile; type postfix_private_t, file_type, sysadmfile; type postfix_spool_t, file_type, sysadmfile; type postfix_spool_maildrop_t, file_type, sysadmfile; type postfix_spool_flush_t, file_type, sysadmfile; type postfix_prng_t, file_type, sysadmfile;

①は、postfix が作成する PID ファイルにアタッチする type の定義であり、同

type には属性「pidfile」が付与されている。②は、postfix を構成する各種デーモ

ンプログラムの中で、固有の domain をアタッチしないプログラムの実行ファイルに

アタッチするための type の定義であり、同 type には属性「exec_type」が付与され

ている。

(C) コンフィギュレーションファイルの参照権限

リスト 3-230 では、デーモンとして稼動する postfix プロセスに対して postfix

のコンフィギュレーションファイルを参照する権限を与えた。同様に、コマンドラ

インから/usr/sbin/sendmail.postfix が実行されることにより起動される postfix

プロセスに対してもコンフィギュレーションファイルを参照する権限を与える必要

がある。この権限の付与はリスト 3-255 に示す箇所にて定義されている。

リスト 3-255 コンフィギュレーションファイル参照権限の付与

① allow user_mail_domain etc_postfix_t:dir r_dir_perms; ② allow { user_mail_domain initrc_t } etc_postfix_t:file r_file_perms; ③ allow user_mail_domain self:capability dac_override;

①と②では、属性「user_mail_domain」に対してコンフィギュレーションファイ





ルの参照権限を与えている。この属性「user_mail_domain」は、ユーザ domain が

type「sendmail_exec_t」のアタッチされたファイルを実行することで起動されるプ

ロセスにアタッチされる domain を括る属性であり（3.5.3.4(3)(A)を参照）、postfix

が稼動する環境であれば、ユーザ domain から/usr/sbin/sendmail.postfix が実行

されて起動されるプロセスの domain を指し示すものである。③は同 domain がケイ

パビリティ CAP_DAC_OVERRIDE（DAC の無効化。任意アクセス制御の制限を無効化す

る）を獲得することを許可するセキュリティポリシー定義である。

(D) システムの cron ジョブから起動された際の権限

リスト 3-256 は、/usr/sbin/sendmail.postfix がシステムの cron ジョブから起

動された場合に、同プロセスに対して cron プロセスのソケットへのアクセスを許可

するセキュリティポリシー定義である。

リスト 3-256 システムの cron ジョブからの起動

ifdef(`crond.te', ` allow system_mail_t crond_t:tcp_socket { read write create }; ')

(6) Red Hat Linux 8.0 ベースの SELinux 環境で稼動させる際の問題

ここでは、Red Hat Linux 8.0 ベースの SELinux 環境にて postfix を稼動させる場

合に発生する問題点を解説する。

(A) initrc スクリプトによる起動時の問題

ファイル resolv.conf のコピー処理

Red Hat Linux 8.0 のインストール CD に含まれる RPM パッケージから postfix を

インストールした場合、同時に postfix 用の initrc スクリプトファイル

/etc/rc.d/init.d/postfix もインストールされる。ところが、この initrc スクリ

プトからpostfixを起動すると、ファイル/etc/resolv.confの扱いでエラーとなり、

結果として postfix の起動に失敗してしまう。同スクリプトでは postfix の起動時

にファイル/etc/resolv.conf をディレクトリ/var/spool/postfix/etc 下にコピー





しているのだが、上記エラーはこのコピー処理に起因するものである。このコピー

処理はpostfixのデーモンプロセスがchroot環境で実行されることを考慮した処理

であると思われるが、SELinux のセキュリティポリシーに反する処理として拒否さ

れてしまうのである。initrc スクリプトにより実行されるコマンド cp は起動元で

ある initrc スクリプトのプロセスにアタッチされている domain と同じ「initrc_t」

がアタッチされるのだが、この domain「 initrc_t」にはディレクトリ

/var/spool/postfix/etc の下に resolv.conf ファイル（type「resolv_conf_t」が

アタッチされたファイル）を作成する権限が与えられていないからである。しかし、

domain「initrc_t」に上記ファイルの作成権限を与えてはならない。幸い、このコ

ピー処理はファイル/var/spool/postfix/etc/resolv.conf が存在しない場合に限

られているので、あらかじめ上記ファイルを手動でコピーしておけば良いであろう。

コマンド postalias

initrc スクリプトファイル/etc/rc.d/init.d/postfix では、postfix の開始直前

にエイリアスデータベースファイル/etc/postfix/aliases.db を更新するために

コマンド postalias を呼び出している。この際起動される postalias プロセスには

domain「postfix_master_t」がアタッチされるのだが、この domain には type

「etc_aliases_t」のアタッチされたファイルを作成する権限が与えられていないた

めにエラーとなってしまう。このエラーが気になるのであればリスト 3-257 に示す

セキュリティポリシー定義を domains/program/postfix.te に追加すれば良いだろ

う。

リスト 3-257 domain「postfix_postalias_t」の定義

① type postfix_postalias_t, domain; ② type postfix_postalias_exec_t, file_type, exec_type, sysadmfile; ③ general_domain_access(postfix_postalias_t) ④ general_file_read_access(postfix_postalias_t) ⑤ uses_shlib(postfix_postalias_t) ⑥ domain_auto_trans({ initrc_t postfix_master_t userdomain user_mail_domain }, postfix_postalias_exec_t, postfix_postalias_t) role system_r types postfix_postalias_t; role sysadm_r types postfix_postalias_t; ⑦ file_type_auto_trans(postfix_postalias_t, etc_postfix_t, etc_aliases_t, file) ⑧ allow postfix_postalias_t etc_postfix_t:file read;

①～⑤では、プログラム postalias 固有の domain「postfix_postalias_t」と同





プログラムの実行ファイルにアタッチする type「postfix_postalias_exec_t」を定

義している。

⑥では、domain 遷移ルールにより、プログラム postalias の実行権限を domain

「initrc_t」、「postfix_master_t」、「userdomain」、および「user_mail_domain」に

対して与え、起動したプロセスに domain「postfix_postalias_t」がアタッチされ

るように定義している。ここで属性「userdomain」を指定しているのは、ユーザが

コマンドラインからプログラム postalias を直接実行した場合を考慮したものであ

り、属性「user_mail_domain」を指定しているのは、同じくコマンドラインからファ

イル/usr/bin/newaliases が実行された場合を考慮したものである48。なお SELinux

の標準セキュリティポリシー定義では、シンボリックリンク/usr/bin/newaliases

の最終リンク先である/usr/sbin/sendmail.postfix に対して、適切なセキュリティ

コンテキストがアタッチされていないという問題も存在する。この問題は、

3.5.3.4(2)(A)で解説しているのでそちらを参照してほしい。

⑦では、プログラム postalias がディレクトリ/etc/postfix 下にファイルを作成

した際に、同ファイルに対して type「etc_aliases_t」をアタッチするようにファ

イル type 遷移ルールを定義している。

⑧は、プログラム postalias にファイル/etc/postfix/main.cf の読み取りを許可

するためのセキュリティポリシー定義である。

リスト 3-257 に示したセキュリティポリシーを定義したら、プログラム

postalias の実行ファイル /usr/sbin/postalias に type

「 postfix_postalias_exec_t 」をアタッチするのを忘れてはいけない。

file_contexts/program/postfix.fc をリスト 3-258 に示すように修正してほしい。

リスト 3-258 type「postfix_postalias_exec_t」のアタッチ

/usr/sbin/postalias system_u:object_r:postfix_postalias_exec_t

さて上記ではプログラム postalias のために固有の domain を定義するセキュリ

ティポリシーを紹介したが、同プログラムにもともとアタッチされていた domain

48 postfix を SMTP サーバーとする環境では、シンボリックリンク/usr/bin/newaliases の最終リンク先は

/usr/sbin/sendmail.postfix となっている。この sendmail.postfix は、sendmail との互換性を保つため

に用意されているコマンドで、コマンド newaliases は sendmail.postfix の別名コマンドである。コマン

ド newaliases を実行した場合、コマンド sendmail.postfix からプログラム postalias が呼び出されるの

であるが、sendmail.postfix の起動プロセスには domain「system_mail_t」、「sysadm_mail_t」、あるいは

「user_mail_t」（これらの domain は属性「user_mail_domain」で括られる）がアタッチされるため、これ

らの domain にプログラム postalias の実行権限を与える必要がある。





「postfix_master_t」に対してエイリアスデータベースファイルを作成する権限

を与えた方が簡単であろうと感じるかもしれない。しかし、この方法はあまりお勧

めできない。何故なら、domain「postfix_master_t」がアタッチされる domain は

postalias プロセスだけではないからである。エイリアスデータベースファイル

にアクセスする必要のないプロセスにまで余計な権限を与えるのは望ましくないこ

とである。

(B) chroot 環境で実行する場合の問題

postfixではその構成されるデーモンプログラムをchroot環境で実行できるよう

になっており、RPM パッケージよりインストールされるコンフィギュレーション

ファイル/etc/postfix/master.cf のデフォルト設定でも、デーモンプログラムの多

くが chroot 環境で実行されるように設定されている。ところが、postfix 用の標準

セキュリティポリシー定義では、chroot に必要なケイパビリティが与えられていな

い。そこで、3.5.3.3(4)(A)で解説したマクロ「postfix_domain」に対してリスト

3-259 に示すセキュリティポリシー定義を追加する必要がある。

リスト 3-259 chroot に必要なケイパビリティの追加

allow postfix_$1_t self:capability sys_chroot;

3.5.3.4. MTA

本節では、MTA プログラムに共通なセキュリティポリシー定義を解説し、その留意点を明

らかにする。


MTA プログラムに共通するセキュリティポリシー定義ファイルを表 3-21 に示す。





表 3-21 MTA プログラムに共通するセキュリティポリシー定義ファイル一覧


1 file_contexts/program/mta.fc MTA プログラムに共通するファイルに対してアタッチするセキュリティコンテキストを定義したファイル

2 macros/program/mta_macros.te MTA プログラムに共通したマクロを定義したファイル

3 domains/program/mta.te MTA プログラムに共通するセキュリティポリシーを定義したファイル

なお、sendmail に固有なセキュリティポリシー定義ファイルに関しては表 3-16 を、

qmail に固有なセキュリティポリシー定義ファイルに関しては表 3-18 を、postfix に

固有なセキュリティポリシー定義ファイルに関しては表 3-20 を参照してほしい。


ここでは、MTA プログラムに共通する各種オブジェクトにアタッチするセキュリ

ティコンテキストを解説する。


MTA プログラムに共通するファイルとディレクトリにアタッチするセキュリティ

コンテキストはファイル file_contexts/program/mta.fc にて定義される。ファイル

mta.fc の内容をリスト 3-260 に示す。

リスト 3-260 MTA プログラムに共通するファイルのセキュリティコンテキスト

① /usr/sbin/sendmail(.sendmail)? system_u:object_r:sendmail_exec_t ② /etc/aliases system_u:object_r:etc_aliases_t ③ /etc/aliases.db system_u:object_r:etc_aliases_t ④ /var/spool/mail(/.*)? system_u:object_r:mail_spool_t ⑤ /var/mail(/.*)? system_u:object_r:mail_spool_t

MTA プログラムには、本ガイドラインで取り扱っているものだけでも sendmail、

qmail、および postfix と数多くの実装が存在している。そして、これら MTA プログ

ラムの機能を利用して稼動する多くのプログラムが存在している。もしこれらのプ

ログラムがシステムにインストールされている MTA プログラムの種類を意識しなけ

ればならないとしたら大変なことである。MTA プログラムの種類を変えただけでそ

のプログラムは稼動しなくなってしまうだろう。これではあまりに不便なため、MTA





プログラムをはじめとして、その実装が数多く存在するプログラムの、その種類を

意識させないための機構が用意されている。たとえば MTA プログラムの場合、シス

テムにインストールされるその実行ファイルは表 3-22 のように管理されている。

表 3-22 MTA プログラムの実行ファイルの配置の様子

＃ディレクトリファイル説明

1 sendmail 項番 4に示すファイルへのシンボリックリンク

2 sendmail.sendmail sendmail の本体プログラム

3

/usr/sbin/

sendmail.postfix postfix において、sendmail との互換性を保つために用意されているファイル。postfix の本体ファイルではない。

4 /etc/alternatives/ mta 項番 2あるいは 3に示すファイルへのシンボリックリンク

従来 SMTP サーバーと言えば sendmail であった。そのため、MTA の機能を利用す

る外部プログラムの多くが sendmail を意識して作成されている。そこで postfix

は sendmail の本体ファイルと同名のファイルを用意し、外部プログラムに対してそ

れらが必要としている機能へのインタフェースを提供する形をとなっている。更に

Red Hat Linux では、sendmail と postfix の共存を意識して表 3-22 に示したよう

なリンクファイルを利用したファイル管理が行われているのである。

リスト 3-260における①は表 3-22のシンボリックリンク/usr/sbin/sendmailと

sendmail の本体プログラムにアタッチするセキュリティコンテキストの定義であ

る。リスト 3-260 と表 3-22 をご覧になられて気付かれると思うが、ファイル

/usr/sbin/sendmail.postfix に対するセキュリティコンテキストの定義が欠けて

いる。そのため、postfix を利用する場合にはリスト 3-261 に示すように修正する

必要がある。

リスト 3-261 /usr/sbin/sendmail.postfix のセキュリティコンテキスト

/usr/sbin/sendmail(.sendmail|.postfix)? system_u:object_r:sendmail_exec_t

なお理想としては、ファイル file_contexts/program/mta.fc 、

file_contexts/program/sendmail.fc、および file_contexts/program/postfix.fc

をリスト 3-262、リスト 3-263、およびリスト 3-264 に示すように修正したいとこ

ろである。





リスト 3-262 file_contexts/program/mta.fc

･･･ # アタッチ対象を/usr/sbin/sendmail のみに修正 /usr/sbin/sendmail system_u:object_r:sendmail_exec_t ･･･

リスト 3-263 file_contexts/program/sendmail.fc

･･･ # 以下のセキュリティポリシー定義を追加 /usr/sbin/sendmail.sendmail system_u:object_r:sendmail_exec_t

リスト 3-264 file_contexts/program/postfix.fc

･･･ # 以下のセキュリティポリシー定義を追加 /usr/sbin/sendmail.postfix system_u:object_r:sendmail_exec_t

/usr/sbin/sendmail.sendmailや/usr/sbin/sendmail.postfixは各々sendmailと

postfix 固有の実行ファイルであるのだから、各々の定義ファイルにて同ファイル

に対するセキュリティコンテキストのアタッチを定義するべきであろう。

リスト 3-260 の②と③は、sendmail のエイリアスファイルと同ファイルを hash

データベース化したエイリアスデータベースファイルに対してアタッチするセ

キュリティコンテキストの定義である。qmail も postfix も、sendmail のエイリア

スデータベースファイル形式をサポートしていることから、同ファイルのセキュ

リティコンテキストがファイル mta.fc にて共通定義されているのだと思われる。し

かし Red Hat Linux 環境では、RPM パッケージから postfix や qmail をインストー

ルした場合に sendmail とは異なるディレクトリ位置に上記ファイルの存在が想定

されている。このような点を考慮した場合、上記の②と③は本来ならば sendmail

のための定義ファイル file_contexts/program/sendmail.fc にて定義されるべきだ

と感じる。

リスト 3-260 の④と⑤は、スプールディレクトリに対してアタッチするセキュリ

ティコンテキストの定義である。なお、/var/mail は/var/spool/mail へのシンボ

リックリンクである。






MTA プログラムは待ち受けポートとして 25 番ポートを利用するため、同ポートに

対してセキュリティコンテキストをアタッチしなければならない。ポートに対する

セキュリティコンテキストはファイル net_contexts にて定義される。同ファイルに

おいてリスト 3-265 に示す定義文を見つけることができるだろう。

リスト 3-265 25 番ポートにアタッチするセキュリティコンテキストの定義

ifdef(`mta.te', `portcon tcp 25 system_u:object_r:smtp_port_t')

上記定義文における「smtp_port_t」は 3.5.3.4(4)(A)にて定義される type であ

る。

(3) マクロ

マクロファイルmacors/program/mta_macros.teではMTAプログラムのための共通マ

クロが定義される。このマクロファイルではマクロ「mail_domain」が定義されており、

これはシステム domain「system_t」あるいはユーザ domain「”domain_prefix”_t」か

ら起動された MTA プロセスに対してアタッチする domain「system_mail_t」あるいは

「”domain_prefix”_mail_t」を定義するマクロである。なおこれらの domain は、init

プロセスにより起動される MTA プロセス、つまりデーモンプロセスとして起動される

MTAプロセスにアタッチする domain とは区別されたものである点に注意が必要である。

以下では、このマクロで何が定義されるのか、部分的に抜粋しながら解説していく

ことにする。なお、マクロファイル macros/program/mta_macros.te の全容は付録のリ

スト A-20 を参照してほしい。


MTA プログラムで共通して利用する domain を定義している箇所をリスト 3-266

に示す。





リスト 3-266 domain の定義

① type $1_mail_t, domain, privlog, user_mail_domain; ② every_domain($1_mail_t)

①では、MTA プロセスにアタッチする domain「"domain_prefix"_mail_t」を定義

している49。この domain には属性「user_mail_domain」を付与している点が重要で

ある。この属性は非デーモンプロセスとして稼動する MTA プロセスを括る属性であ

る。②では、①で定義した domain に対して domain として必要な権限を一括して与

えるべくマクロ「every_domain」が利用されている。

同 domain への domain 遷移ルールを定義している箇所をリスト 3-267 に示す。

リスト 3-267 domain 遷移ルール

ifelse(`$1', `system', `domain_auto_trans_read(privmail, sendmail_exec_t, system_mail_t)', `domain_auto_trans($1_t, sendmail_exec_t, $1_mail_t)' ) can_exec($1_mail_t, sendmail_exec_t)

ここでは、MTA プロセスがシステム domain「system_t」から起動された場合とユー

ザ domain「”domain_prefix”_t」から起動された場合で、domain 遷移ルールを分け

て定義している。まずは、MTA プロセスがユーザ domain「”domain_prefix”_t」から

起動された場合の domain 遷移ルールを見てみることにする。

リスト 3-268 domain 遷移ルール - ユーザ domain からの起動 -

ifelse(`$1', `system', ･･･ `domain_auto_trans($1_t, sendmail_exec_t, $1_mail_t)' )

ユーザ domain「”domain_prefix”_t」が type「sendmail_exec_t」のアタッチされ

たファイルを実行して起動したプロセスに対して domain「”domain_prefix”_mail_t」

49具体的には、domain「user_t」から起動された MTA プロセスにアタッチする domain として「user_mail_t」

を定義するといった用法となる。





をアタッチするように定義している。続いて、システム domain「system_t」から起

動された場合の domain 遷移ルールを見てみることにする。

リスト 3-269 domain 遷移ルール - システム domain からの起動 -

ifelse(`$1', `system', `domain_auto_trans_read(privmail, sendmail_exec_t, system_mail_t)', ･･･ )

属性「privmail」を付与された domain が type「sendmail_exec_t」のアタッチさ

れたファイルを実行して起動したプロセスに対して domain「system_mail_t」をア

タッチするように定義している。何故、ユーザ domain のように domain「system_t」

に対して domain 遷移ルールを定義しないのか。これはシステム domain「system_t」

がアタッチされるプロセスの全てが MTA プロセスを起動する必要があるわけではな

いからである。つまり属性「privmail」はシステム domain「system_t」がアタッチ

されるプロセスで、且つ MTA プロセスを起動する必要性を有したプロセスを括る属

性なのである。

さて以上で、MTA プロセスにアタッチする domain とその domain 遷移ルールが定

義された。しかしこれだけで domain 遷移が許可されるわけではない。それは、domain

遷移ルールはRBACの機能により起動元のroleによっても制限を受けるからである。

つまり遷移先のdomainは起動元のroleで許可されていなければならないのである。

リスト 3-270 遷移先 domain の許可

role $1_r types $1_mail_t;

ここでは、遷移先の domain「 ”domain_prefix”_mail_t」をシステム domain

「system_t」の role「system_r」とユーザ domain「”domain_prefix”_t」の role

「”domain_prefix”_r」に対して許可している。

(B) 外部プログラムの実行権限

sendmailを始めとしたMTAプログラムには受信したメールを外部のプログラムに

渡す機能がある。たとえば sendmail では、受信したメールをフィルタリングするプ





ログラムとローカルユーザのメールボックスにメールを配送するプログラムとして、

通常 promail という外部プログラムが利用される。また、転送設定50にて指定され

た任意のプログラムに対してメールを渡すことも可能となっている。従って、MTA

プロセスが外部プログラムを実行することを許可しなければならない。

リスト 3-271 外部プログラムの実行許可

can_exec($1_mail_t, bin_t) ifdef(`procmail.te', `can_exec($1_mail_t, procmail_exec_t)' )

ここでは、 type 「 bin_t 」 51 がアタッチされているファイルと type

「procmail_exec_t」52がアタッチされているファイルの実行を許可している。なお、

マクロ「can_exec」により実行許可を与えることにより、プログラム起動時の domain

遷移が起きないようにしている。つまり、起動されるプロセスにアタッチされる

domain は起動元である MTA プロセスにアタッチされている domain

「"domain_prefix"_mail_t」がそのまま引き継がれることになる。


リスト 3-272 はケイパビリティを獲得することを許可するセキュリティポリ

シー定義である。


allow $1_mail_t self:capability { setuid setgid chown };

ここでは、ケイパビリティ CAP_SETUID（UID の変更）、CAP_SETGID（GID の変更）、

および CAP_CHOWN（ファイル所有者の変更）を獲得することを許可している。

50 転送設定は通常エイリアスファイルあるいはユーザのホームディレクトリ下のファイル.forwardにて設

定される。 51 システム上の一般的なバイナリディレクトリと同ディレクトリ下のファイルにアタッチされているtype 52 procmail の実行ファイルには固有の type「procmail_exec_t」がアタッチされている。





(D) cron テンポラリファイルに対するアクセス制御

システム cron はスケジューリングされたコマンドを実行した後、そのコマンド

のすべての出力をファイル/etc/crontab の所有者対して sendmail コマンドを起動

することによりメール送信する。リスト 3-273 はシステムの cron ジョブから起動

される MTA プロセスに関する定義である。

リスト 3-273 システムの cron ジョブからの起動

ifelse(`$1', `system', ` ① allow system_mail_t system_crond_tmp_t:file { read getattr }; ② allow mta_user_agent system_crond_tmp_t:file { read getattr }; ', ` ･･･ ')

cron ジョブにより実行されたコマンドの出力は一旦テンポラリファイルに吐き

出され、システム cron から sendmail コマンドにより起動された MTA プロセスはこ

のテンポラリファイルから送信文面を取得する。このため、このテンポラリファイ

ルに対する読み取り権限をsendmailコマンドにより起動されるMTAプロセスに与え

なければならない。

MTA として sendmail を利用している環境では、sendmail コマンドにより起動さ

れる MTA プロセスはプログラム/usr/sbin/sendmail.sendmail であり、同プログラ

ムが cron デーモンプロセスから出力結果を含んだファイルのファイルハンドルを

引き継いで内容を読み取る。この場合の MTA プロセスには、3.5.3.4(3)(A)で定義し

た通り domain「system_mail_t」がアタッチされる。従って、domain「system_mail_t」

に対して cron の作成するテンポラリファイルの読み取り権限を与えなければなら

ない（①）。

MTA として qmail を利用している環境では、sendmail コマンドにより起動される

MTA プロセスはプログラム /usr/sbin/qmail-inject である。プログラム

qmail-inject は cron デーモンプロセスから引き継いだファイルハンドルを基に

メールメッセージを読み取り、然るべきメールヘッダを作成する。その後、プログ

ラム qmail-inject はプログラム/usr/sbin/qmail-queue を起動する。プログラム

qmail-queue はプログラム qmail-inject より、メールメッセージを含んだファイル

のファイルハンドルとメールヘッダを含んだファイルのファイルハンドルを引き継

ぎ、これらからメールメッセージとヘッダー情報を読み込んで、送出キューへ投函

する。つまり、プログラム qmail-inject と qmail-queue の双方が cron デーモンプ





ロセスの作成したテンポラリファイルへの読み取り権限を必要とする。同様に、MTA

として postfix を利用している環境では、sendmail コマンドにより起動される MTA

プロセスはプログラム/usr/sbin/postdrop であり、同プログラムが cron デーモン

プロセスから引き継いだファイルハンドルを基にメールメッセージを読み取り、

maildrop キューディレクトリに投函する。以上を踏まえて、プログラム

qmail-inject、qmail-queue、および postdrop に対して cron の作成するテンポラリ

ファイルの読み取り権限を与えなければならない。これらのプログラムには、ロー

カルに投函されたメールを拾い上げる役割を持ったプログラムを括る目的で属性

「mta_user_agent」が付与されている。そこで、上記プログラムに対する権限の付

与はこの属性に対する権限付与という形式で定義している。

(E) ユーザテンポラリファイルに対するアクセス制御

一般ユーザがメールを送信する場合、ディレクトリ/tmp（テンポラリ領域）下に

作成したファイルを送信するケースが考えられる。このようなケースを考慮し、ユー

ザによってディレクトリ/tmp 下に作成されたファイルに対する読み取り権限を MTA

プロセスに与える必要がある。

リスト 3-274 tmp ファイルへのアクセス

① allow $1_mail_t $1_tmp_t:file { read getattr }; dontaudit $1_mail_t $1_tmp_t:file append; ifdef(`postfix.te', ` ② allow $1_mail_t $1_tmp_t:file write; ) ③ allow mta_user_agent $1_tmp_t:file { read getattr };

リスト 3-274 の①では、ユーザ domain から起動された MTA プロセスに対してテ

ンポラリ領域下に作成されたファイルの読み取り権限を与えている。

②は、MTA として postfix を使用する場合に固有の設定である。postfix の場合

には、先の権限に加えて書き込み権限も与えている。

MTA として qmail あるいは postfix を利用している環境では、sendmail コマンド

により直接起動される MTA プロセス以外に、メールメッセージあるいはメールヘッ

ダ情報を読み取る必要のあるプログラムが存在している。これらのプログラムに対

しても、テンポラリ領域/tmp 下に一般ユーザによって作成されたファイルを読み取

る権限を与えなければならない（③）。





(F) 端末／擬似端末デバイスファイルに対するアクセス制御

リスト 3-275 は端末デバイスファイルと擬似端末デバイスファイルに対する読

み取り・書き込み権限を与えるためのセキュリティポリシー定義である。

リスト 3-275 端末／擬似端末デバイスファイルへのアクセス許可

① allow mta_user_agent { $1_devpts_t $1_tty_device_t }:chr_file { getattr read write }; ② allow $1_mail_t $1_tty_device_t:chr_file rw_file_perms; ③ allow $1_mail_t $1_devpts_t:chr_file rw_file_perms; ④ ifdef(`gnome-pty-helper.te', `allow $1_mail_t $1_gph_t:fd use;')

端末へのメッセージ出力や、端末からユーザの入力値を取得する場合に上記権限

が必要となる。①から④は、通常の端末／擬似端末デバイスファイルに対するアク

セスを制御するための定義である。

④は、GNOME の標準ターミナルプログラムである gnome-terminal53に関連する定

義である。gnome-terminal はその起動時にプログラム gnome-pty-helper54を起動す

る。この gnome-pty-helper は suid ビットの立っていないプログラムのために擬似

端末を作成する機能を持ったプログラムである。ターミナルプログラムである

gnome-terminal は自身に必要な擬似端末デバイスファイルをこの

gnome-pty-helper に作成させている。従って、gnome-terminal により作成された仮

想端末から起動された MTA プロセスは、この擬似端末デバイスファイルのファイル

ディスクリプタ55を引き継ぐ権限が必要となる。

(G) デッドレターファイルに対するアクセス制御

sendmail、qmail、および postfix といった MTA では、メール送信に失敗した際

にエラーメッセージを送り手に返信するように設定することが可能である。このよ

うな設定で稼動されている場合に、そのエラーメッセージさえもが送信に失敗した

場合には、送り手であるユーザのホームディレクトリ下に"dead.letter"という名称

53 /usr/bin/gnome-terminal 54 /usr/sbin/gnome-pty-helper 55 ユーザ domain「"domain_prefix"_t」から起動された gnome-pty-helper には type

「"domain_prefix"_gph_t」がアタッチされる。詳細は macros/program/gph_macros.te と

domains/program/gnome-pty-helper.te を参照してほしい。





のファイル（デッドレターファイル）が作成され、送信に失敗したメールはこのファ

イルに対して追記される。

リスト 3-276 デッドレターファイルへのアクセス許可

file_type_auto_trans($1_mail_t, $1_home_dir_t, $1_home_t)

リスト 3-276 は、ユーザのホームディレクトリ下にファイル"dead.letter"を作

成する権限を MTA プロセスに与え、更に同ファイルに対して適切な type をアタッチ

するための type 遷移ルールを定義する必要がある。

標準のセキュリティポリシー定義にはコメントアウトされた以下の定義が見ら

れる。

リスト 3-277 デッドレターファイルを作成させたくない場合の定義

#allow $1_mail_t { $1_home_dir_t $1_home_t }:dir r_dir_perms; #allow $1_mail_t $1_home_t:file r_file_perms;

これは、デッドレターファイルをユーザのホームディレクトリ下に作成させたく

ない場合に、先のセキュリティポリシー定義の代りに定義するものとして用意され

ている。

(H) maildir 形式56でのローカル配送に関するアクセス制御

qmail と postfix では、メールのローカル配送時の形式として maildir 形式がサ

ポートされている。maildir 形式の場合、各ユーザのホームディレクトリ下のメー

ル受信用ディレクトリにメールを配送・保存するため、これらのメール受信用ディ

レクトリに対するファイル作成権限が必要であり、且つ作成したメールファイルに

はユーザのホームディレクトリ内のファイルにアタッチされるべき然るべき type

をアタッチしなければならない。

56 受信したメールを、各ユーザのホームディレクトリ下のメール受信用ディレクトリにメールメッセージ

毎に別ファイルとして保存するローカルメール配送形式のこと。





リスト 3-278 maildir 形式でのローカル配送に関するアクセス制御

file_type_auto_trans(mta_delivery_agent, $1_home_dir_t, $1_home_t)

リスト 3-278 では、受信メールをローカル配送するプログラムに対してユーザの

ホームディレクトリ下にファイルを作成する権限を与え、同ファイルの type 遷移

ルールを定義している。ローカル配送を行うプログラムは、sendmail であれば通常

はプログラム /usr/bin/procmail 、 qmail であればプログラム

/usr/sbin/qmail-lspawn と/usr/sbin/qmail-local、postfix であればプログラム

/usr/lib/postfix/local であり、これらにアタッチされる各 domain にはローカル

配送を担当するプログラムを括る属性として「mta_delivery_agent」が付与されて

いるため、ここでの定義ではこの属性を指定することで上記の各プログラムに対し

て一括して権限を与えている。なお、これらのメールローカル配送プログラムでは

mbox形式もサポートされている。ローカルメール配送をmbox形式で行う場合には、

本アクセスベクタルールは定義するべきではない。

(I) qmail インストールディレクトリに対するアクセス制御

qmail のデフォルトのインストール先はディレクトリ/var/qmail であり、各種設

定ファイル等もこのディレクトリ下にインストールされる。従ってMTAとしてqmail

を利用する場合には、同ディレクトリ内の探索権限とディレクトリ下に存在する

ファイルあるいはリンクファイルの読み取り権限を与えなければならない。

リスト 3-279 qmail における/var/qmail のアクセス制御

ifdef(`qmail.te', ` allow $1_mail_t etc_qmail_t:dir search; allow $1_mail_t etc_qmail_t:{ file lnk_file } read; ')

このセキュリティポリシーは MTA として qmail を利用する環境に限られるため、

リスト 3-279 に示すように、セキュリティポリシー定義ファイル qmail.te が存在

する場合に有効となるように定義している。






sendmail、qmail、および postfix に共通するセキュリティポリシーはファイル

domains/program/mta.te にて定義される。

以下では、mta.te におけるセキュリティポリシー定義を部分的に抜粋しながら解説

することにする。なお、mta.te の全容は付録のリスト A-21 を参照してほしい。

(A) type の定義

ファイル mta.te では MTA プログラムに共通して必要となる type が定義されてい

る。共通して必要となる type とは、MTA プログラムの本体である実行ファイルに対

してアタッチするtypeとMTAプログラムが利用するTCPポートに対してアタッチす

る type である。

リスト 3-280 MTA で共通利用される type の定義

① type sendmail_exec_t, file_type, exec_type, sysadmfile; ② type smtp_port_t, port_type;

①では、MTA プログラムの本体である実行ファイルに対してアタッチする type と

して「sendmail_exec_t」を定義している。

②は、MTA プログラムが利用する TCP ポートに対してアタッチする type として

「smtp_port_t」を定義している。この type「smtp_port_t」はファイル net_contexts

で定義されているセキュリティポリシーにて TCP25 番ポートに対してアタッチされ

る。

(B) domain の定義と遷移ルールの定義

起動された MTA プロセスに対してアタッチする domain とその domain 遷移ルール

が定義されている。一般的な SMTP サーバーであれば、MTA プログラムはデーモンプ

ロセスとして起動されるはずである。しかし、ユーザにより mail コマンド等が実行

された場合にも MTA プログラムは起動される。つまり MTA プログラムには、その稼

動形態においてデーモンプロセスとして稼動する場合と非デーモンプロセスとして

稼動する場合の 2 通りがある。ここで重要なのは、デーモンプロセスとして起動さ

れた MTA プロセスと非デーモンプロセスとして起動された MTA プロセスにアタッチ





する domain が区別されているという点である。

リスト 3-281 domain「system_mail_t」の定義

mail_domain(system)

リスト 3-281 では、非デーモン MTA プロセスにアタッチする domain を定義して

いる。domain の定義には 3.5.3.4(3)に示したマクロ「mail_domain」が利用されて

おり、このマクロにより domain「system_mail_t」が定義されることになる。なお、

この domain「system_mail_t」はシステム domain「system_t」によって起動される

非デーモン稼動のMTAプロセスにアタッチするためのdomainであり、ユーザdomain

によって起動される非デーモン稼動のMTAプロセスのためのdomainとは異なるので

注意してほしい。ユーザ domain は複数種類存在し得るため、ここで定義するのは適

切でないのである57。これらはユーザ domain を定義している箇所にて同時に定義さ

れるべきであり、実際、ユーザ domain「sysadm_t」と「user_t」によって起動され

る非デーモン稼動の MTA プロセスにアタッチするための domain「user_mail_t」と

「sysadm_mail_t」はマクロファイル macros/user_macros.te にて定義されているマ

クロ「user_domain」にて定義されるようになっている58。ちなみに、domain

「system_mail_t」はデーモンや initrc スクリプトがメール送信のために mail コマ

ンド等を実行したときに起動する MTA プロセスにアタッチする domain である。

リスト 3-282 デーモンとして稼動する MTA プロセスのための domain 定義

ifdef(`sendmail.te', ① `domain_auto_trans(initrc_t, sendmail_exec_t, sendmail_t)', ② `domain_auto_trans(initrc_t, sendmail_exec_t, system_mail_t)' )

リスト 3-282 では、デーモン稼動の MTA プロセスにアタッチする domain の遷移

ルールを定義している。MTA プログラムがデーモンとして起動される場合の起動元

は init プロセスにより起動される initrc スクリプトである。従って、起動された

57 デフォルトのセキュリティポリシーで定義されているユーザ domain は「sysadm_t」と「user_t」の 2つ

である。 58 管理者ユーザ domain「sysadm_t」はマクロファイル macros/admin_macros.te にて定義されているマク

ロ「admin_domain」を利用して定義される domain で、この中ではマクロ「user_domain」が呼ばれており、

結果として domain「sysadm_mail_t」が定義される。





initrc スクリプトにアタッチされる domain「initrc_t」の domain 遷移ルールとし

て定義されているのである。マクロ「domain_auto_trans」によって、domain

「initrc_t」は type「sendmail_exec_t」がアタッチされたファイルの実行を許可

され、実行結果として起動するプロセスには domain「sendmail_t」あるいは

「system_mail_t」がアタッチされるようになる。ちなみに①と②は排他定義となっ

ている。セキュリティポリシーファイル macros/program/sendmail.te が存在する場

合には①が、存在しない場合には②が定義されることになる。つまり、MTA として

sendmail を利用する場合と qmail や postfix を利用する場合で、デーモンプロセス

として稼動するMTAプロセスにアタッチされるdomainが異なることになる。従って、

qmail や postfix を MTA として利用する場合にはセキュリティポリシーファイル

macros/program/sendmail.te を削除しておかなければならない。

リスト 3-283 ユーザホームディレクトリに対するアクセス制御

allow sysadm_mail_t user_home_dir_type:dir search; r_dir_file(sysadm_mail_t, user_home_type)

リスト 3-283 は、管理者ユーザ domain「sysadm_t」があらゆるユーザのホームディ

レクトリ下に存在するファイルをメール送信できるようにするための定義である。

具体的には、一般ユーザのホームディレクトリ下に存在するディレクトリとファイ

ルの探索・読み取り権限を、管理者ユーザ domain「sysadm_t」によって起動された

非デーモン稼動の MTA プロセスに対して与えている 59 。なお、属性

「user_home_dir_type」はユーザのホームディレクトリにアタッチされる type を括

る属性であり、属性「user_home_type」はユーザのホームディレクトリ下のファイ

ルとディレクトリにアタッチされる type を括る属性である。

(C) コマンドラインあるいはプロセスからの起動

特定のMTAプログラムがコマンドラインから起動された場合、起動元であるshell

プロセスに対する幾つかのアクセス権限が必要となる。「特定の MTA プログラム」と

は、qmailの構成プログラムであるqmail-inject、qmail-queue、およびqmail-qread、

そして postfix の構成プログラムである postdrop のことである。

59管理者ユーザ domain があらゆるユーザのホームディレクトリ下のファイルをメール本文としてメール送

信する必要があるのか、正直言って不明である。特に必要がないのであればこのセキュリティポリシー定

義は外しておいた方が良いかもしれない。





リスト 3-284 コマンド起動の際のアクセスルール

allow mta_user_agent userdomain:process sigchld; allow mta_user_agent { userdomain privfd }:fd use; allow mta_user_agent crond_t:process sigchld; allow mta_user_agent sysadm_t:fifo_file { read write };

リスト 3-284 では、コマンドラインあるいは cron ジョブから起動された上記プ

ログラムのプロセスが、親プロセスである shell プロセスあるいは cron ジョブプロ

セスに対して SIGCHLD シグナルを送信することを許可している。また、qmail-inject

やqmail-injectより起動されるqmail-queueは標準入力からメールメッセージを読

み込むため、shell プロセスからファイルハンドルを引き継ぐ権限が必要である。

なお、「mta_user_agent」は先に挙げたプログラム qmail-inject、qmail-queue、

qmail-qread、および postdrop を括る属性である。

同様に、メール送信を行うプロセスから起動された場合にも、起動元である同プ

ロセスの持つリソースに対する幾つかのアクセス権限が必要となる。

リスト 3-285 プロセス起動の際のアクセスルール

allow { system_mail_t mta_user_agent } privmail:fd use;

allow { system_mail_t mta_user_agent } privmail:process sigchld;

allow { system_mail_t mta_user_agent } privmail:fifo_file { read write };

allow { system_mail_t mta_user_agent } admin_tty_type:chr_file { read write };

allow mta_delivery_agent home_root_t:dir { getattr search };

リスト 3-285 では、起動元である親プロセスのリソースに対してアクセスを行う

権限を与えている。なお、「privmail」はメールの送信を行う必要のあるプロセスを

括る属性である。

(D) 外部プログラムに対するメールメッセージの受け渡し

メールメッセージをローカル配送するプログラムはその処理を支援してくれる

外部プログラムを呼び出す場合がある。たとえば、受信メールのフィルタリングを

procmail に委譲したりするだろう。このような外部プログラムを呼び出すためには、

同プログラムが配置されているディレクトリの検索といった権限が必要となる。





リスト 3-286 外部プログラムへのメール受け渡しに必要な権限の付与

can_exec(mta_delivery_agent, shell_exec_t) allow mta_delivery_agent bin_t:dir search; allow mta_delivery_agent bin_t:lnk_file read; allow mta_delivery_agent devtty_t:chr_file rw_file_perms; allow mta_delivery_agent { etc_runtime_t proc_t }:file { getattr read };

リスト 3-286 は、メールメッセージのローカル配送を受け持つプログラムに対し

て外部プログラムを実行する際に必要となる基本的な権限を与えるセキュリティポ

リシー定義である。なお「mta_delivey_agent」は、sendmail においてローカル配

送を担当するプロセスの domain「sendmail_t」、qmail においてローカル配送を担当

するプロセスの domain「qmail_lspawn_t」と「qmail_local_t」、および postfix に

おいてローカル配送を担当するプロセスの domain「postfix_local_t」を括る属性

である。外部プログラムを実行するための具体的な権限に関してはここでは与えら

れていない。それらの権限は各 MTA に固有のセキュリティポリシー定義ファイルに

て定義される。





3.5.4. FTP サーバー

FTP サーバー構築の際のセキュリティポリシー定義指針を解説する。

Red Hat Linux 8.0 では、標準 FTP サーバー60として vsftpd61と呼ばれる FTP サーバープ

ログラムが採用されている。しかし、従来の Red Hat Linux における標準 FTP サーバーは

WU-FTPD と呼ばれる FTP サーバープログラムであった。Red Hat Linux を導入して FTP サー

バーを稼動させている環境では、WU-FTPD に慣れ親しんでいる方も多いのではないだろうか。

そこで本ガイドラインでは、FTP サーバーとして WU-FTPD を用いる場合のセキュリティポリ

シー定義指針を解説することにする。実は、SELinux には標準セキュリティポリシー定義と

して FTP サーバーに関連した設定ファイルが用意されているのだが、これらは vsftpd でも

WU-FTPD でもない、ProFTPD62と呼ばれる FTP サーバープログラムを利用する場合のセキュリ

ティポリシー定義である。従って、WU-FTPD を利用する場合には新たにセキュリティポリ

シーを定義しなければならない。

3.5.4.1. WU-FTPD

(1) WU-FTPD のディレクトリ構造

Red Hat Linux 8.0 のインストール CD に含まれる RPM パッケージから WU-FTPD をイ

ンストールした際のディレクトリ構造を表 3-23 に示す。以降ではこのディレクトリ

構造に則してセキュリティポリシー定義を解説する。なお同表ではドキュメントファ

イルあるいは man ページ等のインストール先は記載していないので注意してほしい。

60 「標準 FTP サーバー」とは、Red Hat Linux のインストーラーにて FTP サーバーを選択した場合にイン

ストールされる FTP サーバープログラムのことを指している。 61 http://vsftpd.beasts.org/ 62 http://proftpd.linux.co.uk/





表 3-23 WU-FTPD のディレクトリ構成

＃ディレクトリファイル備考

1 ftpaccess

2 ftpconversions

3 ftpgroups

4 ftphosts

5

/etc/

ftpusers

WU-FTPD の設定ファイル

6 /etc/logrotate.d/ ftpd -

7 /etc/pam.d/ ftp -

8 /etc/xinetd.d/ wu-ftpd -

9 ftpcount

10

/usr/bin/

ftpwho

11 ckconfig

12 ftprestart

13 ftpshut

14 privatepw

15 xferstats

管理コマンドプログラム

16 in.ftpd WU-FTPD 本体プログラム

17 in.wuftpd in.ftpd へのシンボリックリンク

18

/usr/sbin/

wu.ftpd in.ftpd へのシンボリックリンク

19 /var/ftp/ *

20 /var/ftp/bin/ *

21 /var/ftp/etc/ *

22 /var/ftp/lib/ *

23 /var/ftp/pub/ *

匿名ユーザ用のホームディレクトリ

24 /var/log/ xferlog ログファイル

25 ftp.pids-all

26

/var/run/

ftp.rips-all PID ファイル

(2) サーバー要件

FTP サーバーの運用形態は色々と考えられるが、インターネットサーバーという観

点から、本ガイドラインでは以下の要件を満たす FTP サーバーを前提としたセキュリ

ティポリシー定義指針を解説する。

• 接続クラスは匿名ユーザのみを許可する。

• 公開形態はダウンロードのみとしアップロードは認めない。

• サーバーの管理には専用ユーザを用意し、同ユーザにのみ必要なアクセスを

許可する。





(3) セキュリティポリシー定義ファイル

WU-FTPD に関連するセキュリティポリシー定義ファイルを表 3-24 に示す。

表 3-24 WU-FTPD のセキュリティポリシー定義ファイル一覧


1 domains/program/wu-ftpd.te WU-FTPD のセキュリティポリシーを定義したファイル

2 domains/wuftpadmin.te WU-FTPD 管理用の専用ユーザ domain を定義したファイル

3 file_contexts/program/wu-ftpd.fc WU-FTPD に関連するファイルに対してアタッチするセキュリティコンテキストを定義したファイル

4 net_contexts ポート番号に対するセキュリティコンテキストのマップルールを定義したファイル

5 domains/program/inetd.te スーパーサーバーxinetd のセキュリティポリシーを定義したファイル

項番 4 と 5 のファイルは ProFTPD 用に定義されている既存のセキュリティポリシー

定義ファイルと、新たに定義する WU-FTPD 用のセキュリティポリシー定義との親和性

を考慮して若干の修正を加える必要がある。

(4) オブジェクトへのセキュリティコンテキストのアタッチ

WU-FTPD に関連する各種オブジェクトに対してセキュリティコンテキストをアタッ

チする。


WU-FTPD に関連するファイルとディレクトリにアタッチするセキュリティコンテ

キストはファイル file_contexts/program/wu-ftpd.fc にて定義される。以下では、

このファイルの内容を部分的に抜粋しながら解説していくことにする。なお、ファ

イル wu-ftpd.fc は 3.5.4.1(1)のディレクトリ構造に基づいて設計されたものであ

る。WU-FTPD のインストール先等、ディレクトリ構造に相違がある場合にはセキュ

リティコンテキストが適切にアタッチされるように同ファイルを編集する必要があ

る。

ファイルfile_contexts/program/wu-ftpd.fcの全容は付録のリスト A-22を参照

してほしい。





設定ファイルに対するセキュリティコンテキストのアタッチ

リスト 3-287 は、WU-FTPD 自身がその稼動時に必要とする設定ファイルに対する

セキュリティコンテキストのアタッチである。

リスト 3-287 WU-FTPD 自身が必要とする設定ファイル

/etc/ftpaccess system_u:object_r:etc_wuftpd_t /etc/ftpconversions system_u:object_r:etc_wuftpd_t /etc/ftpgroups system_u:object_r:etc_wuftpd_t /etc/ftphosts system_u:object_r:etc_wuftpd_t /etc/ftpusers system_u:object_r:etc_wuftpd_t

これらのファイルは WU-FTPD 固有の設定ファイルであるため、他のプロセスによ

るアクセスを防ぐ目的で WU-FTPD 固有の type である「etc_wuftpd_t」をアタッチし

ている。

リスト 3-288 は、WU-FTPD と関連のある他のプログラムにとって必要な設定ファ

イルに対するセキュリティコンテキストのアタッチである。

リスト 3-288 WU-FTPD に関連を持つプログラムが必要とする設定ファイル

① /etc/logrotate.d/ftpd system_u:object_r:etc_t ② /etc/pam.d/ftp system_u:object_r:etc_t ③ /etc/xinetd.d/wu-ftpd system_u:object_r:etc_t

①は、プログラム logrotate のための WU-FTPD の設定ファイルにアタッチするセ


②は、WU-FTPD の PAM 設定ファイルにアタッチするセキュリティコンテキストの

定義である。

③は、スーパーサーバーxinetd のための WU-FTPD の設定ファイルにアタッチする

セキュリティコンテキストの定義である。

実行ファイルに対するセキュリティコンテキストのアタッチ

リスト 3-289 は、WU-FTPD の実行ファイルに対するセキュリティコンテキストの

アタッチである。





リスト 3-289 実行ファイルに対するセキュリティコンテキストのアタッチ

/usr/bin/ftpcount system_u:object_r:wuftpd_tool_exec_t /usr/bin/ftpwho system_u:object_r:wuftpd_tool_exec_t /usr/sbin/ckconfig system_u:object_r:wuftpd_tool_exec_t /usr/sbin/ftprestart system_u:object_r:wuftpd_tool_exec_t /usr/sbin/ftpshut system_u:object_r:wuftpd_tool_exec_t /usr/sbin/in.ftpd system_u:object_r:wuftpd_exec_t /usr/sbin/in.wuftpd system_u:object_r:wuftpd_exec_t /usr/sbin/privatepw system_u:object_r:wuftpd_tool_exec_t /usr/sbin/wu.ftpd system_u:object_r:wuftpd_exec_t /usr/sbin/xferstats system_u:object_r:wuftpd_tool_exec_t

WU-FTPD 関連の実行ファイルには type 「 wuftpd_exec_t 」あるいは

「wuftpd_tool_exec_t」をアタッチしている。WU-FTPD の本体である実行ファイル

には「wuftpd_exec_t」を、その他の管理用コマンド等のプログラムには

「wuftpd_tool_exec_t」をアタッチしている。

ホームディレクトリに対するセキュリティコンテキストのアタッチ

匿名ユーザがログインした際のホームディレクトリ/var/ftp 下のサブディレク

トリとファイルに対して WU-FTPD 固有のセキュリティコンテキストをアタッチする。

リスト 3-290 ホームディレクトリ下に対するセキュリティコンテキスト

① /var/ftp system_u:object_r:wuftpd_pub_dir_t ② /var/ftp/.* system_u:object_r:wuftpd_pub_t ③ /var/ftp/bin(/.*)? system_u:object_r:wuftpd_bin_t ④ /var/ftp/etc(/.*)? system_u:object_r:wuftpd_etc_t ⑤ /var/ftp/lib(/.*)? system_u:object_r:wuftpd_lib_t

ホームトップディレクトリ/var/ftp に対して WU-FTPD 固有の type である

「wuftpd_pub_dir_t」をアタッチしている（①）。このように固有の type をアタッ

チすることで、同ディレクトリ下の参照を許可されるサブジェクトを意図的に制限

することが可能となる。また、/var/ftp 下の各サブディレクトリ bin、etc、lib、

および pub と、それらのディレクトリ下のサブディレクトリとファイルに対しては、

さらに個別の type をアタッチしている（②、③、④、⑤）。





注意「ホームディレクトリ下のコマンドファイルとライブラリの扱い」

FTP ログインした際のホームディレクトリ下には、FTP サーバーが利用する各種プログラムとそれらが必要

とするライブラリを配置するが、この件に関して非常に注意すべきことがある。結論から先に言えば、こ

れらのファイルをハードリンクにて用意してはならない。上記のファイルに対しては WU-FTPD 固有のセ

キュリティコンテキストをアタッチする。もし、システム上のコマンドプログラムあるいはライブラリが

ハードリンクとして配置されていたとしたらどうなるだろうか。セキュリティコンテキストは inode を基

準にアタッチされるため、リンク元であるシステムファイル自体のセキュリティコンテキストも変更して

しまうことになるのである。従って、決してハードリンクを利用してはいけないのである。危険なのは、

RPM パッケージより WU-FTPD をインストールした場合に、ディレクトリ/var/ftp/bin と/var/ftp/lib 下に

はシステムのコマンドプログラムとライブラリがハードリンクされることである。忘れずにこれらを一旦

削除し、同システムファイルはコピーし直してほしい。

ログファイルに対するセキュリティコンテキストのアタッチ

WU-FTPD の出力するログファイルに対するアクセスを制限するためには、同ファ

イルに対して WU-FTPD 固有の type をアタッチしなければならない。

リスト 3-291 ログファイルに対するセキュリティコンテキストのアタッチ

/var/log/xferlog(¥..*)? system_u:object_r:wuftpd_xferlog_t

リスト 3-291 では、WU-FTPD のログファイル/var/log/xferlog に対して WU-FTPD

固有の type である「wuftpd_xferlog_t」をアタッチしている。

(B) ポートに対するセキュリティコンテキストのアタッチ


れる。FTP サーバーは待ち受けポートとして 21 番ポートを利用するため、同ポート

に対してセキュリティコンテキストをアタッチしなければならない。本来ならば、

そのためにまず同ポートにアタッチするための type を新たに宣言する必要がある

のだが、標準セキュリティポリシーとして用意されている ProFTPD 用のセキュリ

ティポリシー定義 domains/program/ftpd.te では、21 番ポートにアタッチするため

の type「ftp_port_t」がを宣言されている。リスト 3-292 に示す定義文を見つける

ことができるだろう。





リスト 3-292 ポートにアタッチする type の宣言（domains/program/ftpd.te）

################################# # # Rules for the ftpd_t domain # type ftp_port_t, port_type; ･･･

同一のポートに複数の type をアタッチすることはできないため、WU-FTPD におて

いもこのtypeを利用することが望ましい63。しかしこの場合、ファイルnet_contexts

を若干修正する必要がある。同ファイルの修正箇所をリスト 3-293 に示す。

リスト 3-293 21 番ポートに対するセキュリティコンテキストのアタッチ

･･･ ifdef(`ftpd.te', `portcon tcp 21 system_u:object_r:ftp_port_t') ･･･

ここでは、ファイル domains/program/ftpd.te が存在する場合に限り、21 番ポー

トに対してセキュリティコンテキスト64をアタッチするように宣言している。今回、

WU-FTPD 用のセキュリティポリシー定義を用意するわけであるから、たとえファイ

ル domains/program/ftpd.te が存在していなくても、上記のセキュリティコンテキ

ストのアタッチが宣言される必要がある。そこで、リスト 3-293 の定義文をリスト

3-294 に示すように修正することが望ましい。

リスト 3-294 21 番ポートに対するセキュリティコンテキストのアタッチ（修正後）

･･･ ifdef(`ftpd.te', `portcon tcp 21 system_u:object_r:ftp_port_t', ifdef(`wu-ftpd.te', `portcon tcp 21 system_u:object_r:ftp_port_t')) ･･･

ファイル domains/program/ftpd.te が存在しない場合あっても、今回新たに用意

63 ファイル domains/program/ftpd.te が存在しない場合も考慮して、ファイル

domains/program/wu-ftpd.te においても type「ftp_port_t」を宣言しておかなければならない

（3.5.4.1(6)(B)を参照）。 64このセキュリティコンテキストを構成する type 属性は、もちろん「ftp_port_t」である。





するWU-FTPD用のセキュリティポリシー定義ファイルdomains/program/wu-ftpd.te

が存在していれば、21 番ポートに対するセキュリティコンテキストのアタッチを宣

言するように定義するのである。これと同じ理由で、セキュリティポリシー定義ファ

イル domains/porgram/inetd.te も修正しなければならない。このファイルはスー

パーサーバーのためのセキュリティポリシー定義ファイルである。通常 FTP サー

バーは常時稼動させるのではなく、スーパーサーバーにより随時起動される形態で

運用する。従って、ソケットに対して FTP の待ち受けポートをバインドするのはスー

パーサーバーである。そのためファイル domains/porgram/inetd.te にはリスト

3-295 に示すセキュリティポリシー定義が存在する。

リスト 3-295 FTP ポートのバインドを許可（修正前）

･･･ ifdef(`ftpd.te', àllow inetd_t ftp_port_t:tcp_socket name_bind;') ･･･

これは、ファイル domains/program/ftpd.te が存在している場合、つまり type

「ftp_port_t」が宣言されている場合に同ポートのバインドをスーパーサーバーに

許可するためのセキュリティポリシー定義である。リスト 3-294 と同様に、この部

分もリスト 3-296 に示すように修正する必要がある。

リスト 3-296 FTP ポートのバインドを許可（修正後）

･･･ ifdef(`ftpd.te', àllow inetd_t ftp_port_t:tcp_socket name_bind;', ifdef(`wu-ftpd.te', àllow inetd_t ftp_port_t:tcp_socket name_bind;')) ･･･

(5) マクロ

FTP サーバーの管理には専任のユーザを用意すべきだろう。しかし、管理者ユーザ

がその管理を受け持ったのでは、余分な権限を持ち過ぎていて危険である。FTP サー

バーの管理に必要充分な権限のみを有したユーザを用意するべきである。そのために

は、同ユーザに割り当てる role とユーザ domain を用意しなければならない。本ガイ

ドラインでは以下の要件を満たす role と domain を用意する。





• FTP サーバー管理ユーザは一般ユーザ role「user_r」でシステムにログイン

する（FTP サーバー管理用 role でログインしない）。

• FTP サーバー管理ユーザはコマンド newrole により一般ユーザ role「user_r」

から FTP サーバー管理用 role に切り替えることができる。

FTP サーバー管理用 role とユーザ domain はマクロ「wuftpd_admin_domain」により

定義される形としている。なお、同マクロはファイル domains/wuftpadmin.te にて定

義している。

以下では、マクロ「wuftpd_admin_domain」の中で定義しているセキュリティポリシー

を解説する。解説で登場する"$1"はマクロ「wuftpd_admin_domain」に渡される第１引

数を示していることに注意して欲しい。

ファイル domains/wuftpadmin.te あるいはマクロ「wuftpd_admin_domain」の全容は

付録のリスト A-24 を参照してほしい。

(A) 一般ユーザ domain の新規作成

FTP サーバー管理用のユーザ domain は一般のユーザ domain に FTP サーバーの管

理に必要な最低限のアクセス権限を追加したものとして定義する。そこでまず、新

規の一般ユーザ domain を宣言する。

リスト 3-297 新規一般ユーザ domain の宣言

define(`wuftpd_admin_domain', ` ･･･ full_user_role($1) ･･･ ')

リスト 3-297 のマクロ「full_user_role」は一般ユーザ domain とその role を宣

言するものである。このマクロにより、一般ユーザ domain として必要な各種権限を

与えられた domain「$1_t」と role「$1_r」が定義される。

(B) newrole コマンドによる role 遷移ルール

SELinux の標準セキュリティポリシー定義にて用意されている一般ユーザ role

「user_r」から、リスト 3-297 で定義された role「$1_r」へ newrole コマンドによ





り role 遷移を行うことを許可する。

リスト 3-298 newrole による role 遷移ルール

define(`wuftpd_admin_domain', ` ･･･ ① allow user_r $1_r; ② allow $1_r user_r; ③ type_change $1_t user_tty_device_t:chr_file $1_tty_device_t; ④ type_change user_t $1_tty_device_t:chr_file user_tty_device_t; ⑤ type_change $1_t user_devpts_t:chr_file $1_devpts_t; ⑥ type_change user_t $1_devpts_t:chr_file user_devpts_t; ⑦ allow $1_t user_home_dir_t:dir { search r_dir_perms }; ⑧ file_type_auto_trans($1_t, user_home_dir_t, user_home_t) ･･･ ')

①と②は、role「user_r」と role「$1_r」との間で相互に role 遷移を許可する

定義である。③～⑥は、newrole コマンドによる role 遷移の際に、端末デバイスファ

イルと擬似端末デバイスファイルにアタッチされている type を変更することを許

可する定義である。⑦と⑧は、role「user_r」から role「$1_r」に role 遷移した

後もホームディレクトリに対するアクセスを許可する定義である。


リスト 3-299 は、FTP サーバー管理ユーザ domain がケイパビリティを獲得する

ことを許可するセキュリティポリシー定義である。


define(`wuftpd_admin_domain', ` ･･･ allow $1_t $1_t:capability { dac_override }; ･･･ ')

ここでは、ケイパビリティ CAP_DAC_OVERRIDE（DAC の無効化。任意アクセス制御

の制限を無効化する）を獲得することを許可している。





(D) FTP サーバー管理ユーザ domain のアクセスベクタルール

FTP サーバーの管理ユーザであれば、WU-FTPD の設定ファイルをエディタで編集

したり、ログファイルを直接参照するといった行為が必要となるだろう。

リスト 3-300 FTP サーバー管理ユーザ domain のアクセスベクタルール

define(`wuftpd_admin_domain', ` ･･･ ① allow $1_t etc_wuftpd_t:file { read write getattr setattr }; ② allow $1_t wuftpd_sys_type:dir create_dir_perms; ③ allow $1_t wuftpd_sys_type:{ file lnk_file } create_file_perms; ④ allow $1_t wuftpd_pub_type:dir create_dir_perms; ⑤ file_type_auto_trans($1_t, wuftpd_pub_type, wuftpd_pub_t) ⑥ allow $1_t wuftpd_xferlog_t:file r_file_perms; ･･･ ')

リスト 3-300 は、FTP サーバー管理ユーザ domain「$1_t」に対して管理作業に必

要となるアクセス権限を付与するための定義である。

①は、ディレクトリ/etc 下に配置されている WU-FTPD の設定ファイルの読み取

り・書き込みを許可する定義である。

②と③は、ホームディレクトリ下のサブディレクトリ bin、etc、および lib に対

するアクセスベクタルールの定義である。これらのサブディレクトリ下にファイル、

リンクファイル、およびディレクトリの作成を許可している。なお、作成されるファ

イルあるいはディレクトリには親ディレクトリにアタッチされている type がその

まま継承されてアタッチされる。

④と⑤は、ホームディレクトリとそのサブディレクトリ pub に対するアクセスベ

クタルールの定義である。ホームディレクトリ下あるいはサブディレクトリ bin 下

に対するファイルとディレクトリの作成を許可している。ここでは、②と③とは違っ

てマクロ「file_type_auto_trans」を利用しているが、これはホームディレクトリ

の直下に作成されたファイルとディレクトリに対しても type「wuftpd_pub_t」をア

タッチするためである。

⑥は、WU-FTPD のログファイル/var/log/xferlog を直接参照することを許可する

定義である。





(E) 管理コマンド用 domain の定義

WU-FTPD に含まれる管理用コマンドプログラム実行時のプロセスにアタッチする

domain「wuftpd_tool_t」を定義する。この domain は WU-FTPD サーバープロセスに

アタッチする domain「wuftpd_t」とは異なる domain である。

リスト 3-301 管理コマンドプログラム用の type/domain の定義

define(`wuftpd_admin_domain', ` ･･･ ① type wuftpd_tool_exec_t, file_type, sysadmfile, exec_type; ② type wuftpd_tool_t, domain; ③ general_domain_access(wuftpd_tool_t) ④ general_proc_read_access(wuftpd_tool_t) ⑤ general_file_read_access(wuftpd_tool_t) ⑥ uses_shlib(wuftpd_tool_t) ⑦ role $1_r types wuftpd_tool_t; ⑧ domain_auto_trans($1_t, wuftpd_tool_exec_t, wuftpd_tool_t) ･･･ ')

リスト 3-301は、WU-FTPDに含まれる管理コマンドプログラム用のtypeとdomain

の定義である。①は、WU-FTPD に含まれる管理用コマンドプログラムの実行ファイ

ルにアタッチする type「wuftpd_tool_exec_t」の定義である。②は、同コマンドプ

ログラムのプロセスにアタッチする domain「wuftpd_tool_t」の定義である。③～

⑥では、この「wuftpd_tool_t」に対して domain として必要な幾つかの権限を付与

している。ここでマクロ「every_domain」を利用していない理由は、必要のない権

限を与え過ぎないようにするためである。⑦では、FTP サーバー管理ユーザ用の role

「$1_r」に対してこの domain「wuftpd_tool_t」を許可しており、⑧では、同 role

のユーザ（domain が「$1_t」であるユーザ）がこの管理用コマンドを実行した際に、

起動されるプロセスに対して domain「wuftpd_tool_t」をアタッチするための domain

遷移ルールを定義している。





リスト 3-302 管理用コマンドのアクセスベクタルール

define(`wuftpd_admin_domain', ` ･･･ ① allow wuftpd_tool_t etc_wuftpd_t:file rw_file_perms; ② allow wuftpd_tool_t wuftpd_xferlog_t:file r_file_perms; ③ allow wuftpd_tool_t etc_wuftpd_t:dir rw_dir_perms; ④ allow wuftpd_tool_t etc_wuftpd_t:file create_file_perms; ⑤ allow wuftpd_tool_t wuftpd_pub_dir_t:dir search; ⑥ allow wuftpd_tool_t wuftpd_etc_t:dir { search write add_name remove_name }; ⑦ allow wuftpd_tool_t wuftpd_etc_t:file create_file_perms; ⑧ can_exec(wuftpd_tool_t, bin_t) ⑨ allow wuftpd_tool_t { $1_tty_device_t $1_devpts_t }:chr_file { ioctl read getattr write }; ･･･ ')

リスト 3-302 は、リスト 3-301 で定義した domain「wuftpd_tool_t」に対するア

クセスベクタルールの定義である。

①は、ディレクトリ/etc 下に配置されている WU-FTPD の設定ファイルに対しての

アクセスベクタルールであり、読み取りと書き込みを許可する定義である。

②は、WU-FTPD が出力するログファイル/var/log/xferlog に対する読み取りを許

可する定義である。

③～⑦は、コマンドプログラム/usr/sbin/ftpshut と/usr/sbin/ftprestart を考

慮したものである。プログラム ftpshut は FTP サーバーを停止させるコマンドで、

このコマンドは特定のディレクトリ下にファイル shutmsg を作成する。プログラム

ftprestart は FTP サーバーを再開させるコマンドで、プログラム ftpshut が作成し

たファイル shutmsg を削除する。そこで、domain「wuftpd_tool_t」に対してファイ

ル shutmsg を作成・削除する権限を与える必要がある。

⑧は、WU-FTPD に含まれるコマンドプログラム「xferstats」を考慮したものであ

る。同コマンドプログラムは perl スクリプトであるため、domain「wuftpd_tool_t」

が perl プログラムを起動することを許可しなければならない。ここではマクロ

「can_exec」により実行権限を与えている。なお「bin_t」は perl の実行ファイル

にアタッチされている type である。

⑨は、domain「wuftpd_tool_t」に対して制御端末あるいは擬似端末へのアクセ

スを許可する定義である。






WU-FTPDに関するセキュリティポリシーはファイルdomains/program/wu-ftpd.teと

domains/wuftpadmin.te にて定義される。ここでは、これらのファイルにて定義され

るセキュリティポリシーを抜粋しながら解説していくことにする。なお、ファイルの

全容は付録のリスト A-23 とリスト A-24 を参照してほしい。


WU-FTPDサーバープロセスにアタッチするdomainを定義する。このdomainはファ

イル domains/program/wu-ftpd.te にて定義される。


① type wuftpd_t, domain, privlog, auth; ② every_domain(wuftpd_t) ③ role system_r types wuftpd_t;

①は、WU-FTPD サーバープロセスに対してアタッチする domain「wuftpd_t」の宣

言である。WU-FTPD はシステムのユーザアカウントを参照するため、shadow パスワー

ドを導入している環境ではファイル/etc/shadow に対する読み取り権限が必要とな

る。そこで、/etc/shadow への読み取り権限を必要とすることを示す属性「auth」

を付与している65。②では、マクロ「every_domain」を利用することで domain とし

て必要となる各種の権限を一括して「wuftpd_t」に付与している。また、WU-FTPD

はスーパーサーバーxinetd によって起動されるため、xinetd プロセスの role であ

る「system_r」で「wuftpd_t」が許可されなければならない（③）。

(B) type の宣言

WU-FTPD に関連する各種オブジェクトにアタッチする type を宣言する。これらの

宣言をリスト 3-304 に示す。

65 属性「auth」が付与されたdomainはファイルtypes/file.teにおけるセキュリティポリシー定義にてファ

イル/etc/shadow の読み取り権限が与えられる。





リスト 3-304 WU-FTPD 固有の type の宣言

① type wuftpd_exec_t, file_type, sysadmfile, exec_type; ② type etc_wuftpd_t, file_type, sysadmfile; ③ attribute wuftpd_sys_type; ④ type wuftpd_bin_t, file_type, sysadmfile, wuftpd_sys_type; ⑤ type wuftpd_etc_t, file_type, sysadmfile, wuftpd_sys_type; ⑥ type wuftpd_lib_t, file_type, sysadmfile, wuftpd_sys_type; ⑦ type wuftpd_var_run_t, file_type, sysadmfile, pidfile; ⑧ type wuftpd_xferlog_t, file_type, sysadmfile, logfile; ⑨ attribute wuftpd_pub_type; ⑩ type wuftpd_pub_dir_t, file_type, sysadmfile, wuftpd_pub_type; ⑪ type wuftpd_pub_t, file_type, sysadmfile, wuftpd_pub_type; ⑫ ifdef(`ftpd.te', `', `type ftp_port_t, port_type;')

①は、WU-FTPD の実行ファイルにアタッチする type の宣言である。実行ファイル

であることを示す属性「exec_type」を付与している。②は、ディレクトリ/etc 下

に配置されている各種設定ファイルにアタッチする type の宣言である。④～⑥は、

ホームディレクトリ下のサブディレクトリbin、etc、およびlibにアタッチするtype

を、各々異なる type「wuftpd_bin_t」、「wuftpd_etc_t」、および「wuftpd_lib_t」

として宣言しており、これらの type を括る属性として「wuftpd_sys_type」を宣言

している（③）。⑦は、WU-FTPD がその稼動時に作成する PID ファイルにアタッチす

る type の宣言であり、PID ファイルを示す属性「pidfile」を付与している。⑧は、

WU-FTPD が出力するログファイルにアタッチする type の宣言であり、ログファイル

を示す属性「logfile」を付与している。⑩は、anonymous ユーザのホームトディレ

クトリにアタッチする type の宣言であり、⑪は、同ディレクトリ下のサブディレク

トリとファイル（先のサブディレクトリ bin、etc、および lib は除く）にアタッチ

する type の宣言である。また、属性「wuftpd_pub_type」を宣言しており（⑨）、⑩

と⑪の type を括っている。

⑫は、FTP サーバーが利用するポートにアタッチする type の宣言である。SELinux

に標準で用意されている ProFTPD 用のセキュリティポリシー定義ファイル

domains/program/ftpd.te において、既に同名の type「ftp_port_t」が宣言されて

いるため、同ファイルが存在しない場合に限りこの場所で type「ftp_port_t」を宣

言するように定義している。





(C) TE ルールの定義

3.5.4.1(6)(A)にて定義した domain「wuftpd_t」に対して必要なアクセスベクタ

ルールを定義する。

domain 遷移ルール

スーパーサーバーxinetd が WU-FTPD サーバープロセスを起動した際に、その

WU-FTPD サーバープロセスに domain「wuftpd_t」をアタッチする domain 遷移ルール

を定義する必要がある。

リスト 3-305 domain 遷移ルールの定義

domain_auto_trans(inetd_t, wuftpd_exec_t, wuftpd_t)

リスト 3-305 では、domain「inetd_t」がアタッチされたプロセス（スーパーサー

バーxinetd）が、type「wuftpd_exec_t」のアタッチされた実行ファイル（WU-FTPD

の実行ファイル）を実行した際に起動されるプロセスに対して、domain「wuftpd_t」

をアタッチするように定義している。

socket オブジェクトの継承

WU-FTPD をスーパーサーバーxinetd 配下で稼動させるのであれば、リクエストを

待ち受けるポートに対してバインドする権限を WU-FTPD 自身に与える必要はない。

同ポートはスーパーサーバーxinetd によって作成されたソケットにバインドされ、

WU-FTPD サーバープロセスはそのソケットを引き継ぐだけである。

リスト 3-306 スーパーサーバー所有のソケットに対するアクセス権限の付与

allow wuftpd_t inetd_t:{ udp_socket tcp_socket } rw_stream_socket_perms;

リスト 3-306 では、domain「wuftpd_t」に対してスーパーサーバーxinetd の稼

動プロセス（domain「inetd_t」がアタッチされている）が作成したソケットに対す

る読み取りと書き込みを許可している。





ケイパビリティ

リスト 3-307 は、domain「wuftpd_t」がケイパビリティを獲得することを許可す

る定義である。


allow wuftpd_t wuftpd_t:capability { net_bind_service setuid setgid sys_nice dac_override sys_chroot };

ここでは、ケイパビリティ CAP_NET_BIND_SERVICE（ソケットの bind）、CAP_SETUID

（UID の設定）、CAP_SETGID（GID の設定）、CAP_SYS_NICE（nice 値の変更）、

CAP_DAC_OVERRIDE（DAC の無効化。任意アクセス制御の制限を無効化する）、および

CAP_SYS_SHROOT（chroot システムコールの許可）を獲得することを許可している。

ソケット通信

WU-FTPD サーバープロセスはスーパーサーバーxinetd の稼動プロセスとの間で

TCP によるソケット通信が許可される必要がある。

リスト 3-308 WU-FTPD と xinetd との間のソケット通信を許可

can_tcp_connect(wuftpd_t, inetd_t)

リスト 3-308 は、domain「wuftpd_t」と domain「inetd_t」との間の TCP ソケッ

ト通信を許可する定義である。「can_tcp_connect」は TCP ソケット通信に必要な権

限を一括して与えるマクロである。ここでは、domain「wuftpd_t」のアタッチされ

たプロセスをクライアント側プロセス、domain「inetd_t」がアタッチされたプロセ

スをサーバー側プロセスとして、両プロセス間でのソケット通信を許可している。

SIGCHLD シグナルの送信

WU-FTPD サーバープロセスが、親プロセスであるスーパーサーバーxinetd に対し

て SIGCHLD シグナルを送信すること許可する必要がある。





リスト 3-309 xinetd プロセスに対する SIGCHLD シグナル送信を許可する

allow wuftpd_t inetd_t:process sigchld;

スーパーサーバーxinetd は子プロセスである WU-FTPD サーバープロセスからの

SIGCHLD シグナルを受信した際に wait()システムコールを呼び出す。この wait()シ

ステムコールが呼び出されることによって、処理を終了してゾンビプロセスとなっ

た WU-FTPD サーバープロセスがシステムから削除されるのである。このため、

SIGCHLD シグナルの送信を許可してやらないと、起動された WU-FTPD サーバープロ

セスはゾンビプロセスとしてシステム上に残留してしまうので注意が必要である。

ファイルとディレクトリに対するアクセス

domain「wuftpd_t」には WU-FTPD サーバープロセスがアクセスする各種ファイル

とディレクトリに対しての適切なアクセス権限を定義しなければならない。

リスト 3-310 設定ファイルとログファイルに対するアクセス制御

① allow wuftpd_t etc_wuftpd_t:file r_file_perms; ② allow wuftpd_t wtmp_t:file append; ③ allow wuftpd_t lastlog_t:file { read write }; ④ file_type_auto_trans(wuftpd_t, var_run_t, wuftpd_var_run_t) ⑤ file_type_auto_trans(wuftpd_t, var_log_t, wuftpd_xferlog_t);

リスト 3-310 は、WU-FTPD 自身の設定ファイルやログファイルに対するアクセス

制御である。①は、ディレクトリ/etc 下に配置されている、WU-FTPD 自身の設定ファ

イル ftpaccess、ftpconversions、ftpgroups、ftphosts、および ftpusers の読み

取りを許可する定義である。②は、システムへのログイン・ログアウト情報を記録

するログファイル/var/log/wtmp に対する追記を許可する定義である。③は、シス

テムへの最終ログイン情報を記録するログファイル/var/log/lastlog の読み取

り・書き込みを許可する定義である。④は、PID ファイルの作成を許可する定義で

ある。動的に作成される PID ファイルは、その作成時に適切な type をアタッチする

ことで他のサブジェクトから保護しなければならない。ここでは、WU-FTPD サーバー

プロセスが type「var_run_t」のアタッチされているディレクトリ、つまり/var/run





下にファイルを作成した際に、同ファイルに対して WU-FTPD 固有の type

「wuftpd_var_run_t」をアタッチするように定義している。⑤は、ログファイルの

作成を許可する定義である。④の PID ファイルと同様に動的に作成されるログファ

イルには、typeの遷移ルールを用いて適切なtypeをアタッチしなければならない。

ここでは、WU-FTPD サーバープロセスが type「var_log_t」のアタッチされているディ

レクトリ、つまり/var/log 下にファイルを作成した際に、同ファイルに対して

WU-FTPD 固有の type「wuftpd_xferlog_t」をアタッチするように定義している。

リスト 3-311 ホームディレクトリに対するアクセス制御

allow wuftpd_t { wuftpd_sys_type wuftpd_pub_type }:dir r_dir_perms; allow wuftpd_t { wuftpd_sys_type wuftpd_pub_type }:{ file lnk_file } r_file_perms;

リスト 3-311 は、ホームディレクトリ/var/ftp に対するアクセス制御である。

anonymous ユーザのホームディレクトリである同ディレクトリに対しては、そのサ

ブディレクトリとファイルを含め、読み取りアクセスのみを許可する。

リスト 3-312 コマンドプログラムの実行許可

① can_exec(wuftpd_t, wuftpd_bin_t) ② allow wuftpd_t wuftpd_lib_t:lnk_file read; ③ allow wuftpd_t wuftpd_lib_t:file execute;

リスト 3-312 は、コマンドプログラムの実行を domain「wuftpd_t」に許可する

定義である。①は、ホームディレクトリ下のサブディレクトリ bin に収められてい

るコマンドプログラムの実行権限を domain「wuftpd_t」に与える定義である。マク

ロ「can_exec」により権限を与えているため、実行されたコマンドプロセスにアタッ

チされる domain も「wuftpd_t」となる。②と③は、コマンドプログラムが必要とす

るライブラリの実行権限を与える定義である。

(D) FTP サーバー管理ユーザ domain の定義

3.5.4.1(5)で解説したマクロ「wuftpd_admin_domain」の呼び出しは、実は同マ

クロの定義ファイルである domains/wuftpadmin.te にて行っている。同マクロの呼

び出し箇所をリスト 3-313 に示す。





リスト 3-313 wuftpd_admin_r と wuftpd_admin_t の定義

wuftpd_admin_domain(wuftpd_admin)

同マクロには、引数として「wuftpd_admin」を指定しており、これにより、role

「wuftpd_admin_r」と domain「wuftpd_admin_t」が定義されることになる。

(E) ユーザの登録

3.5.4.1(6)(D)にて定義した role「wuftpd_admin_r」を具体的なユーザに割り当

てなければならない。このためには、FTP サーバー管理に用いるユーザがシステム

上に用意されている必要があるが、本ガイドラインでは「ftpadmin」というアカウ

ントがシステムに用意されているものとして話を進める。また、ユーザ「ftpadmin」

はグループ「ftpadmin」に所属しているユーザであるものとする。

SELinuxにて特定roleをシステムのユーザに割り当てる際にはファイルusersを

編集する。ここでは、ユーザ「ftpadmin」に role「wuftpd_admin_r」を割り当てな

ければならない。そこで、リスト 3-314 に示すエントリをファイル users に追加す

る。

リスト 3-314 ユーザ「ftpadmin」の登録

user ftpadmin roles { user_r wuftpd_admin_r };

FTP サーバー管理ユーザに必要とする要件を 3.5.4.1(5)にて挙げたが、同要件を

満たすため、ユーザ「ftpadmin」には role「wuftpd_admin_r」だけでなく role「user_r」

も割り当てている。

(7) その他

ここでは、セキュリティポリシー定義以外の部分において重要なポイントとなる設

定を解説する。なお本節で解説する設定指針には WU-FTPD 自体に関する内容も含まれ

ているが、これらの設定指針は上記で解説したセキュリティポリシー定義の下で有効

的な設定である。従って、WU-FTPD における慣例的な設定方針に沿わない内容となっ

ている部分もあることに注意してほしい。





(A) FTP サーバー管理ユーザ

本ガイドラインでは、3.5.4.1(6)(D)で定義した role「wuftpd_admin_r」を割り

当てるユーザとして、グループ「ftpadmin」に所属するユーザ「ftpadmin」を想定

している。以降での解説においてもこのユーザがポイントとなるので注意してほし

い。

(B) /etc/security/default_type への登録

新たに role を定義した場合には、同 role を有効化するためにファイル

/etc/security/default_type にエントリを登録しなければならない。そこで、リス

ト 3-315 に示すエントリを追加する。

リスト 3-315 /etc/security/default_type の編集

wuftpd_admin_r:wuftpd_admin_t

これは、コマンド newrole により role を「wuftpd_admin_r」に切り替えられる

ようにするための設定である。コマンド newrole はファイル

/etc/security/default_type のエントリを参照して、切り替え先の role とペアと

なる type を決定するため、この設定は必須である。なお今回は、role

「 wuftpd_admin_r 」でのログインを想定していないため、ファイル

/etc/security/default_contexts の修正は必要ない。

(C) WU-FTPD の設定

本ガイドラインで解説したセキュリティポリシー定義を有効的に生かすために

は、WU-FTPD 自体の設定を若干カスタマイズする必要がある。なお上記でも述べた

が、WU-FTPD 自体の慣例的な設定方針に沿わない部分もあるので注意してほしい。

shutmsg の作成位置

WU-FTPD には ftpshut というコマンドが用意されている。このコマンドの詳細な

解説は省くが、同コマンドが発行されると shutmsg というファイルが作成される。

このファイル shutmsg のデフォルトの作成場所はディレクトリ/etc 下であるが、コ

マンドftpshutにシステムディレクトリである/etc下にファイルの作成権限を与え





るのは望ましくないため、3.5.4.1(5)(E)で解説した管理コマンド用 domain におい

てもこの権限を与えていない。従って、コマンド ftpshut 発行の際にファイル

/etc/shutmsg の作成に失敗してしまう。そこで、以下の手順にてファイル shutmsg

の作成場所を変更しなければならない。

• ディレクトリ/etc/wu-ftpd を作成する。また、ファイル shutmsg は FTP で

ログインした際のホームディレクトリ下にも作成されるため、ディレクト

リ/var/ftp/etc/wu-ftpd も作成する。そして、これらのディレクトリの所

有者とグループを各々、ユーザ「ftpadmin」とグループ「ftpadmin」とす

る。

• WU-FTPD のコンフィギュレーションファイルにて、ファイル shutmsg の作

成場所を"/etc/wu-ftpd/shutmsg"とする。

ファイル所有者とグループの変更

WU-FTPD のコンフィギュレーションファイル/etc/ftp*、ディレクトリ/var/ftp

以下のサブディレクトリとファイル、そしてログファイル/var/log/xferlog*の所有

者とグループを各々、「ftpadmin」と「ftpadmin」に変更する。





3.5.5. セキュリティポリシーの検証・確認方法

本節では、SELinux でセキュリティポリシーを設定する場合に、そのポリシーをどのよう

に設定し、どのように検証し、そしてどのように動作の確認を行うかについて説明する。

ここでは、“testprog”という架空のプログラムを例に取り説明を行う。

SELinux でセキュリティポリシーを設定する大まかな流れを図 3-1 示す。


ファイル作成(fcファイル)


ファイル作成(teファイル)

セキュリティポリシーの

ロード (make reload)


の設定 (make relabel)

プログラムの実行

syslogの確認

問題あり？

Y

修正・追加

運用開始

N

syslogを監視する

問題あり？ N

Y

図 3-1 セキュリティポリシー設定・確認手順

SELinux のセキュリティシステムの仕様としては、まず type の宣言を行いシステムに反

映した後に、セキュリティコンテキストを定義してファイルに設定する、というのが順当

な考え方である。これは、図 3-1 の順序とは異なる。筆者の経験上、まずファイル名を見

ながら type 名を決定し(fc ファイル作成)、その後で type の宣言(te ファイル作成)をした





方が効率的だと考え、このような手順にした。エディタで fc ファイルと te ファイルの両

方のファイルを同時に開いて、それぞれを見ながら設定を行うのも効率がよいかと考える。

3.5.5.1. セキュリティコンテキストファイルの作成

まず、SELinux に組み込もうとしているプログラム(testprog)に関連したファイルを列挙

する必要がある。testprog がインストールされているパスや testprog が参照するコンフィ

ギュレーションファイルおよびデータファイル、一時ファイルはもちろん、読み込み専用

か、書き込みも行うか等の詳しい情報も把握しなければならない。ただし、この段階では

必ずしもすべてのファイルを挙げる必要はないが、実行プログラムがどのディレクトリに

インストールされているかぐらいは最低限把握しておかなければならない。

表 3-25 に、testprog に関連したファイル群の例を挙げる。

表 3-25 testprog 関連ファイル群の例


1 /usr/sbin/testprog 実行プログラム

2 /etc/testprog/testprog.conf conf ファイル（読み込み専用）

3 /var/log/testprog.log log ファイル（読み書き）

4 /var/testprog/data_r データファイル(読み込み専用)

5 /var/testprog/data_w データファイル（読み書き）

6 /var/testprog/data_a データファイル（追加書き専用）

7 /tmp/testprog.* 一時ファイル（読み書き）

この一覧を基にファイルのセキュリティコンテキストを作成する。セキュリティコンテ

キストの type は、他の type を競合しないようにユニークな名称を付けなければならない。

一般的には、プログラム名の文字列を type 名の一部に使用する。ここでの説明ではプログ

ラム名が“testprog”なので、“testprog_xxx_t”や“xxx_testprog_t”のような type 名

となる。サフィックスの“_t”は type を表す意味として習慣的に使用される。

(1) 実行プログラム

実行プログラムの type には、一般的に“exec_t”がサフィックスとして付加される。

よって、今回の設定ではリスト 3-316 に示すような形式になる。





リスト 3-316 実行プログラムのセキュリティコンテキスト

/usr/sbin/testprog system_u:object_r:testprog_exec_t

ユーザと role は、システムデフォルトの“system_u”と“object_r”である。

実行プログラムが複数存在し、セキュリティ上それらのプログラムを区別する必要

がない場合は、同一のセキュリティコンテキストを付与していもよい。ただし、セキュ

リティ上区別する必要がある場合、たとえば一方のプログラムに対しては読み込み専

用にしたほうがよく他方のプログラムからは書き込みも許すというような状況があれ

ば、type を別々に付加してセキュリティのアクセス権限を明確に分けなければならな

い。つまり、当該実行ファイルから起動された domain を明確に区別するということで

ある。

(2) config ファイル

一般に config ファイルは、システム管理者が設定した内容を実行プログラムから読

み込むだけのファイルである。つまり、システム管理者にはファイルの書き込み権限

や作成権限は必要であるが、プログラムからは読み込み専用でよい。

また、/etc ディレクトリ下に config ファイルを作成する場合は、デフォルトで作

成ディレクトリ(または、親ディレクトリ)の type を継承し、“etc_t”という type が

付与される。“etc_t”という type を持つファイルに対して書き込みを行うには、ある

程度の権限が必要になるので、わざわざ新しい type を宣言する必要はない。ただし、

「一般ユーザからファイルの内容を読まれないようにしたい」とか「アクセスできる

プログラムを絞り、セキュリティを向上させたい」というような場合は、新しい type

を宣言し、そのセキュリティコンテキストを付与すべきである。

一般的に、/etc ディレクトリ下に置かれるファイルに対しては、“etc_*_t”や

“*_etc_t”のような type 名が付けられる。また、config ファイルとしては“conf_*_t”

や“*_conf_t”のような type 名が一般的である。ここでは、リスト 3-317 のような

セキュリティコンテキストを定義する。

リスト 3-317 config ファイルのセキュリティコンテキスト

/etc/testprog/testprog.conf system_u:object_r:testprog_conf_t

たとえば、/etc/testprog ディレクトリ下に config ファイルが複数存在する場合は





すべてのファイルを列挙することもできるが、リスト 3-318 のように正規表現を利用

して/etc/testprog ディレクトリ下すべてのファイルに同一のセキュリティコンテキ

ストを設定する定義文を１行で記述することができる。

リスト 3-318 正規表現を使用した例

/etc/testprog(/.*)? system_u:object_r:testprog_conf_t

(3) log ファイル

log ファイルのセキュリティコンテキストを宣言する。syslogd 経由でログを出力す

る場合は必要ないが、プログラム自身が独自にログを出力する場合に必要となる。こ

のファイルにはプログラムからアクセスとして作成・書き込みの権限が必要となる。

プログラムによっては、削除権限やリンク権限も必要になるかもしれない。

ここの例では、/var/log ディレクトリ下に log ファイルを作成することにした。一

般的に/var/log 下のファイルには、“*_var_log_t”や“var_log_*_t”のような type

名をつけるが、長くなるのでリスト 3-319 のように“testprog_log_t”とした。

リスト 3-319 log ファイルのセキュリティコンテキスト

/var/log/testprog.log system_u:object_r:testprog_log_t

(4) データファイル

データファイルの場合でも、アプリケーションによっては読み込み専用のファイル

と読み書き可能なファイルがある。また、追加書きしかしないファイルもあるかもし

れない。それぞれのデータファイルに同じセキュリティコンテキストを付与し運用す

ることができるが、セキュリティ上好ましくはない。やはり、それぞれ目的別にセキュ

リティコンテキストを設定し、それに見合ったアクセス権限を付与すべきである。こ

の方がもしもの時に被害を最小に抑えることができる。

表 3-25 には、3種類のデータファイルを示したが、プログラムによってはもっと細

かい設定をした方がいい場合もあるし、それほど神経質にならなくてもいい場合があ

るので、プログラムの性質や格納するデータの重要性を鑑みて判断してほしい。

今回の例では、リスト 3-320 のようなセキュリティコンテキストを設定した。デー

タファイルの性質によりわかりやすい type を付けた方がよい。たとえば、BIND が使





用するゾーンファイルには“named_zone_t”、ユーザ用の crontab ファイルは

/var/spool/cron ディレクトリ下に置かれるので“user_cron_spool_t”というように

人がみて簡単に連想できるような type が付与されている。

リスト 3-320 データファイルのセキュリティコンテキスト

/var/testprog/data_r system_u:object_r:testprog_r_file_t /var/testprog/data_w system_u:object_r:testprog_w_file_t /var/testprog/data_a system_u:object_r:testprog_a_file_t

(5) 一時ファイル

一時ファイルに関しては、セキュリティポリシー設定ファイルで type 宣言をする必

要があるが、あえてセキュリティコンテキストファイルに定義する必要はない。これ

は、特定のディレクトリ(たとえば、/tmp)に作成されたファイルを自動的に別の type

に遷移するマクロが用意されているからである。ただし、セキュリティポリシー設定

ファイル内で遷移後に付与される type の宣言は必要である。

また、システム運用中に“make relabel”でセキュリティコンテキストの再設定を

行うと、明示的な定義がないと一時ファイルのセキュリティコンテキストが変更され

てしまい、プログラムからアクセスできなくなる場合もある。これを、設定ミスとい

うか運用ミスというかは難しいが、一時ファイルの名称がわかっている場合は、リス

ト 3-321 のようにセキュリティコンテキストを宣言しておいた方がよい。

リスト 3-321 一時ファイルのセキュリティコンテキスト

/tmp/testprog.* system_u:object_r:testprog_tmp_t

ファイル名として“testprog.*”としたが、これは testprog で始まる任意のファイ

ルにマッチする正規表現である。testprog というプログラムが、一時ファイルを作成

するときに、そのプリフィックスとして“testprog”を使用するというのがわかって

いる場合のみに使用できる宣言である。

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

次に、セキュリティポリシーを定義する te ファイルを作成する。このファイルは domain

や type を宣言し、プログラム実行時の domain 遷移やその domain にどのようなアクセス権





限を許可するかを指定する。必要最低限の権限を許可し、少しでもセキュリティホールを

作らないようにしなければならない。

(1) domain 定義

プログラムを実行したときの domain の定義を行う。一般的な domain の名称は、プ

ログラム名に“_t”を付加した文字列となる。ここでは、リスト 3-322 のようになる。


type testprog_t, domain, privlog;

type 文を使用して“testprog_t”に domain 属性(“domain”)を設定している。こ

の例では、domain 属性以外に“privlog”属性を付与し syslogd 経由でのログ出力の

権限を与えている。属性は、“attrib.te”ファイルに定義されているので必要に応じ

て付与すること(A-1.1.1.1.1 付録 B 属性一覧参照)。

(2) role 宣言

次に、どの role がこのリスト 3-316 で定義した domain になれるかを宣言する。間

単にいうと、どのような権限を持ったユーザがこのプログラムを実行することができ

るか、を定義する。

リスト 3-323 role 宣言

① role system_r types testprog_t; ② role sysadm_r types testprog_t;

①はシステムから起動されるとき(システム立ち上げ時など)に当該プログラムを起

動する必要があるときに指定する。②はシステム管理者権限がこのプログラムを手動

で実行する必要があるときに指定しなければならない。

(3) type 宣言

ファイル等のセキュリティコンテキストに使用する type の宣言を行う。この type





は、3.5.5.1 で説明したファイルのセキュリティコンテキストに必要な宣言である。

リスト 3-324 type 宣言

① type testprog_exec_t, file_type, sysadmfile, exec_type; ② type testprog_conf_t, file_type, sysadmfile; ③ type testprog_log_t, file_type, sysadmfile, logfile; ④ type testprog_r_file_t, file_type, sysadmfile; ⑤ type testprog_w_file_t, file_type, sysadmfile; ⑥ type testprog_a_file_t, file_type, sysadmfile; ⑦ type testprog_tmp_t, file_type, sysadmfile, tmpfile;

すべてのファイルには“file_type”および“sysadmfile”の属性が定義されている。

これは、宣言した type は「ファイル」であり「管理者用ファイル」とうい意味である。

また、ファイルの種類により付与する属性も異なる、①の実行ファイルには

“exec_type”という属性を、③のログファイルには“logfile”という属性を、⑦の

一時ファイルには“tmpfile”という属性を付与しなければならない。特に、実行ファ

イルに“exec_type”を付け忘れるとプログラムが実行できなくなるので注意が必要で

ある。この例で示した属性以外によく使用するものとして“lockfile”、“pidfile”が

ある。

また、type 宣言はファイルばかりではなく、ネットワークで使用するソケットの

ポートを表す“port_type”やファイルシステムを表す“fs_type”などもある。詳細

は、A-1.1.1.1.1 付録 B 属性一覧を参照してほしい。

(4) domain 遷移

プログラムを適正な domain、この場合は“testprog_t”、で実行させるには domain

を遷移しなければならない。また、不正に実行されないようにするためにも、遷移元

の domain は極力少なく絞る必要がある。

domain 遷移を考える上で、そのパターンは表 3-26 のように 5つに分類できる。





表 3-26 domain 遷移のパターン

# プログラム実行者遷移元の domain

1 システム起動時に実行される(rc スクリプト) initrc_t

2 システム管理者 sysadm_t

3 cron ジョブ system_crond_t

4 一般ユーザ user_t

5 特定プログラム xxx_t

システムのデーモンのように、システム起動時に実行されるようなプログラムであ

れば“#1”に該当する。“#2”は、システム運用中に管理者が手動でプログラムを実行

する場合に該当する。“#3”は cron ジョブから起動する場合で、“#4”は一般ユーザか

ら起動する場合に該当する。“#5”の特定プログラムとは、たとえば djbdns は

daemontools からしか起動されないと分かっていれば daemontools からのみの domain

遷移を定義すればよい。

また、システム管理者が手動で実行する場合もあるし、cron ジョブからも起動され

るというような場合は、それぞれ定義すればよい。リスト 3-325にその定義例を示す。

リスト 3-325 domain 遷移の例

① domain_auto_trans(sysadm_t, testprog_exec_t, testprog_t) ② domain_auto_trans(system_crond_t, testprog_exec_t, testprog_t)

domain 遷移には domain_auto_trans マクロを使用する。第１引数が遷移元の domain

で表 3-26 に挙げた「遷移元の domain」がここに入る。この遷移元の domain が第２引

数に指定された type を持つファイル(実行プログラム)を実行した場合に、第３引数の

domain に遷移する。

domain 遷移が正しく行われたかどうかは、SELinux 用にエンハンスされた ps コマン

ドで調べることができる。“--context”を指定することにより、プロセスのセキュリ

ティコンテキストを表示することができる。リスト 3-326 は、ps コマンドを実行した

ときの例で、プログラム/bin/testprog が“testprog_t”の domain で実行されている

ことがわかる(①)。





リスト 3-326 ps コマンドの表示例

# ps --context PID SID CONTEXT COMMAND 28359 343 root:user_r:user_t -bash 28468 345 root:user_r:newrole_t newrole -r sysadm_r 28470 346 root:sysadm_r:sysadm_t /bin/bash ① 28478 346 root:sysadm_r:testprog_t /usr/bin/testprog 29693 346 root:sysadm_r:sysadm_t ps --context

(5) ファイル type 遷移

通常 SELinux では、ディレクトリ下に作成されたファイルやサブディレクトリのセ

キュリティコンテキストは、作成元のディレクトリに付与されているセキュリティコ

ンテキストを継承する。/tmp ディレクトリ下に作成された一時ファイルであっても、

他者から参照できるのはセキュリティ上問題がないとはいえない。また、/var/run や

/var/log ディレクトリ下に作成した PIDファイルやログファイルを他者に変更されな

いようにするためにも、プログラムが新たに作成したファイルのセキュリティコンテ

キストは適切なものに変更しなければならない。

SELinux では、file_type_auto_trans マクロが用意されている。リスト 3-327 は、

ファイル type 遷移の例である。

リスト 3-327 ファイル type 遷移の設定例

① file_type_auto_trans(testprog_t, tmp_t, testprog_tmp_t) ② file_type_auto_trans(testprog_t, var_log_t, testprog_log_t)

この例は、testprog が使用する一時ファイルとログファイルの遷移の設定である。

①は、testprog_t domain を持つプログラムが tmp_t を持つディレクトリ(/tmp ディレ

クトリ)にファイルを作成した場合、そのファイルの type を“testprog_tmp_t”に変

更する。②も同様に var_log_t を持つディレクトリ(/var/log ディレクトリ)にファイ

ルを作成すると、“testprog_log_t”の type に自動的に変更される。

(6) アクセス権限

testprog_t に必要最低限の権限を与える必要がある。最低でも、3.5.5.2(3)の type

宣言で定義したファイルへのアクセス権限は指定しなければならない。また、それ以





外のファイルに対してもアクセス行うのであればその権限設定も必要である。しかし、

この段階では不必要な権限を与えるのは危険なので最低限の権限のみにとどめておい

た方がよい。プログラムを実際に実行させ、問題があった場合のみに不足した権限を

追加すればよい。

リスト 3-328 は、testprog_t domain に対するアクセス権限の設定例である。

リスト 3-328 アクセス権限の設定例

① allow testprog_t testprog_conf_t:dir r_dir_perms; ② allow testprog_t testprog_conf_t:file r_file_perms; ③ allow testprog_t testprog_log_t:file create_file_perms; ④ allow testprog_t testprog_r_file_t:file r_file_perms; ⑤ allow testprog_t testprog_w_file_t:file rw_file_perms; ⑥ allow testprog_t testprog_a_file_t:file ra_file_perms; ⑦ allow testprog_t testprog_tmp_file_t:file create_file_perms;

①、②は testprog_conf_t の type を持つディレクトリとファイルに対する読み込み

権限を与えている。“r_dir_perms”および“r_file_perms”はマクロ定義されている。

③、⑦はログファイルと一時ファイルの作成権限で、“create_file_perms”マクロを

使用して定義している。このマクロは、作成権限ばかりではなく読み込みや書き込み

の権限も同時に与える。④、⑤、⑥はそれぞれの type に対して読み込み権限、読み込

みと書き込み権限、読み込みと追加書き権限を与えている。

ここで、必要以上のアクセス権限を与えてしまうとそれだけでセキュリティホール

を作りやすくなるため、よく考えて定義しなければならない。

(7) cron からの起動

testprog が cron から起動されるようなプログラムである場合、cron からの domain

遷移の定義が必要である。ここでの domain 遷移も domain_auto_trans マクロを使用し

てもよいが、system_crond_entry マクロが用意されている。

リスト 3-325 は、その設定例で、第１引数に指定した type を持つプログラムを実

行したとき、第２引数に指定した domain に遷移にすることを意味している。





リスト 3-329 cron の domain 遷移の設定例

system_crond_entry(testprog_exec_t, testprog_t)

このマクロは domain 遷移ばかりでなく、crond が持つ FIFO ファイルへのアクセス

権限(読み書き等)や、crondから引き継いだファイルディスクリプタの使用権限、crond

プロセスに対する SIGCHLD シグナルの送信権限(プロセス終了時)も同時に許可してい

る。selinux/policy/macros/program/crond_macros.te ファイルを参照のこと。

3.5.5.3. 設定内容のシステムへの反映

それぞれの設定ファイル、つまりセキュリティポリシーおよびセキュリティコンテキス

トが完成したら、その内容をシステムに反映しなければならない。

順序としては、まずセキュリティポリシーのロード(“make load”または“make reload”)

を行い、セキュリティコンテキストの設定(“make relabel”)を行う。セキュリティポリ

シーを設定する前にセキュリティコンテキストを設定しようとすると、未定義 type を設定

しようとしたとしてエラー(リスト 3-330)になるので注意が必要である。

リスト 3-330 未定義 type によるエラー

setfiles: invalid context system_u:object_r:test_t on line number 24

3.5.5.4. syslog の確認と検証方法

セキュリティポリシーおよびセキュリティコンテキストの設定が完了したら、実際にプ

ログラムを実行し設定内容が正しいか検証する必要がある。

セキュリティポリシーが正しく動作しているか、不足している権限はないか等の動作検

証を行う場合、プログラム自身が出力するエラーメッセージもそのヒントになる。しかし、

もっとも有効なのは SELinux の Access Vector Cache (AVC)66が出力するカーネルメッセー

ジ(syslog)である。

本節は、AVC が出力するメッセージを解説しながら、設定内容の検証方法について触れる。

66 アクセス権限のチェックを行うカーネルコンポーネントである。一旦問い合わせた(チェックした)アク

セス権限はキャッシュし、性能向上を図っている。





(1) メッセージの形式

このメッセージは、リスト 3-331 に示すような形式67で出力される。このメッセー

ジを解析すると、どのプロセスがどのファイルにどのような権限で拒否されたかが分

かり、この情報を基に不足したセキュリティポリシーを追加することができる。

リスト 3-331 AVC が出力するメッセージの例

Feb 2 04:02:21 ホスト名 kernel: avc: denied { read } for pid=9096 exe=/usr/sbin/testprog path=/etc/resolv.conf dev=03:01 ino=182324 scontext=system_u:system_r:testprog_t tcontext=system_u:object_r:resolv_conf_t tclass=file

まず、“avc:”が SELinux の AVC が出力したメッセージということを表しており、何

らかのアクセス拒否(denied)が発生したことが分かる。次の“{ read }”は読み込み

権限で拒否されていることを表す。“exe=/usr/sbin/testprog”がアクセスしようとし

たプログラムで、“path=/etc/resolv.conf”がそのアクセスの対象となったファイル

である。testprog プログラムは“testprog_t”という domain で実行しており、

/etc/resolv.conf ファイルは“resolv_conf_t”という type を持っていることがこの

メッセージから分かる。

つまり、testprog プログラムが/etc/resolv.conf ファイルに対して読み込みを行お

うとしたが、その処理を SELinux により拒否されたということである。

(2) メッセージをポリシーに変換する方法

SELinux には、AVC からのメッセージをセキュリティポリシーに変換する perl スク

リプトが組み込まれている。ソースディレクトリ下の selinux/scripts/newrules.pl

にあり、自動的にはインストールされないので PATH の通ったディレクトリにコピーし

ておいた方がよい。

newrules.pl スクリプトは、dmesg コマンドの出力、標準入力、指定ファイルから

AVC のカーネルメッセージを読み込み解析を行う。解析した結果をセキュリティポリ

シーの allow 文として標準出力に表示する便利なツールである。

67 実際には１行で出力される。





リスト 3-332 メッセージの変換例

allow testprog_t resolv_conf_t:file { read };

リスト 3-332 は、前述のリスト 3-331 を newrule.pl スクリプトを使用して変換さ

せてものである。

(3) 検証方法

プログラムの動作検証する方法は、前述の syslog メッセージおよびプログラム自身

のメッセージをチェックすることである。ただし、その方法として 2 種類の方法があ

る。１つは、システムを permissive モード68にしてプログラムを実行し syslog の内容

を確認する方法と、システムを enforcing モード69にしてプログラムを実行し、１ス

テップずつアクセスエラーを確認する方法である。どちらも、newrules.pl スクリプ

トを使用してアクセス拒否された事象のセキュリティポリシーを生成し、システムに

再設定し、そして再度プログラムを実行する。これの繰り返しである。

permissive モードでセキュリティポリシー未設定のプログラムを実行すると、シス

ログメッセージが大量に出力される。これを一括して変換しシステムに登録するすれ

ばよいが、不必要なアクセス許可まで登録する可能性があるので注意が必要である。

enforcing モードでプログラムを実行すると、アクセスを拒否された時点でプログ

ラムが異常終了し、そこまでのシスログ情報でセキュリティポリシーを作成し、シス

テムに再設定し、再度プログラムを実行する。これを１つずつ繰り返すため非常に手

間と時間がかかる。しかし、設定するセキュリティポリシーを１つ１つ吟味できるの

で設定ミスの可能性が低くなる。

68 セキュリティポリシーのチェックを執行しないモードである。ただし、権限に違反しているかどうかの

メッセージはシスログに出力される。 69 セキュリティポリシーのチェックを執行するモードである。





リスト 3-333 newrules.pl スクリプトの実行例(その１)

# newrules.pl -d ① allow ftpd_t file_t:dir { getattr search }; ② allow user_t httpd_sys_content_t:dir { getattr search }; ③ allow user_t user_t:capability { setuid };

リスト 3-333 は、newrules.pl スクリプトの実行例である。目的のプログラムを実

行しsyslogメッセージを確認しながらnewrules.plスクリプトと組み合わせてセキュ

リティポリシーを生成すると、作業効率が向上する。ただ、注意しなければならない

のは、この newrules.pl スクリプトが生成した allow 文が必ずしも当該システムのセ

キュリティポリシーに必要かどうかは自分で判断しなければならない、という点であ

る。リスト 3-333 の出力例では、①ftpd プログラムが“file_t”という type(ファイ

ルのデフォルト type)が付加されたディレクトリの検索、②一般ユーザが

“httpd_sys_content_t”という type(システムの WEB コンテンツ)が付加されたディ

レクトリの検索、③一般ユーザが一般ユーザのプログラムを実行し setuid システム

コールを発行していることが、推察できる。これは、システム運用中に、一般ユーザ

が故意または不注意で権限のないファイルをアクセスしたりしたために syslog に記

録された内容である。これらの権限を許可することはシステム上好ましくないので、

設定を行ってはいけない。

リスト 3-334 newrules.pl スクリプトの実行例(その２)

# tail /var/log/messages | newrules.pl allow testprog_t testprog_conf_t:file { write };

次に、テスト中の testprog プログラムを実行してリスト 3-334 のような allow 文

が出力された場合はどのようなことが考えられるだろうか。この allow 文の意味は、

testprog プログラム(testprog_t domain)が、testprog_conf_t の type を持ったファ

イルに対して書き込みを行おうとしたことを意味している。config ファイルに対して

は読み込み権限しか与えておらず、プログラム自身は読み込みしか行っていないので

あれば、ファイルに設定したセキュリティコンテキストの設定ミスが考えられる。こ

の allow 文を生成したシスログメッセージを確認し、アクセスの対象となったファイ

ルを確認しなければならない。





3.5.5.5. 運用と監視

セキュリティポリシーおよびセキュリティコンテキストの設定が完了したら、システム

を enforcing モードに設定し実際にシステム運用を行う。この運用を開始しても定期的に

syslog をチェックし、セキュリティポリシー等の設定漏れがないかどうかを監視しなけれ

ばならない。セキュリティポリシーを設定したプログラムの仕様をすべて把握しているの

であれば設定漏れも少ないであろうが、長時間運用するにつれてチェックしていない動作

条件が発生し、新たなセキュリティポリシーの設定が必要になる場合があるからである。

また、cron ジョブとして実行する際も、通常の動作環境とは異なる場合がありアクセス

権限等の設定漏れでプログラムが正常に動作していない場合がある。特に、cron は夜中や

週に１回、月に１回しか実行しないような設定をする場合もあるので、長期的な監視は必

要である。





4. 運用

4.1. 本章の目的

本章では、SELinux サーバーを運用する場合についての留意点および指針を以下の項目に

従いまとめる。

導入計画

信頼性の確保

システムの管理

4.2. 導入計画

本節では、SELinux 導入時の留意点をまとめる。

4.2.1. SELinux 導入のメリット・デメリット

SELinux を導入するメリットを表 4-1 と表 4-2 にまとめる。表 4-1 はインターネット

サーバーの OS として SELinux を導入するメリットを、表 4-2 はセキュア OS として SELinux

を選択するメリットをまとめたものである。





表 4-1 SELinux 導入のメリット

# 項目内容

1 セキュア OS SELinux が実装する各種アクセス制御により、システムの堅牢性が向上する。通常の Linux に比べれば、はるかにセキュアなシステムを構築できる。(B1 レベル相当)

2 被害拡大の抑制ユーザやプロセスに与えられる権限が必要最低限なものに限定されていることで各プログラムの堅牢性が高まり、たとえ攻撃を受けた場合でも、その被害の範囲を最低限（そのユーザあるいはプログラムの範疇内）に抑えることができる。

3 未知の攻撃の防御 #2 の効果として、IDS 等では防ぐことの難しい未知の攻撃に対してもシステムを保護する高いセキュリティを確保することが可能である。

4 サーバーシステムの統合化

#2 の効果として、従来はセキュリティ上の問題から分散して稼動させていたサーバーシステムを1台のSELinuxシステムに統合することで、システム構成の簡略化やシステムコストの削減が可能となる。

5 アプリケーションのメンテナンス作業を軽減

利用しているアプリケーションに重大なセキュリティホールが見つかった場合のメンテナンス作業の至急性が軽減される。一般の Linux の場合、セキュリティホールによる被害を防ぐために早急なパッチ当て作業等が管理者に求められる。しかし、攻撃された場合でも被害を最小限に抑制する SELinux であれば、管理者は慌てる必要はないケースが多い。結果として、管理者は余裕を持って間違いなくメンテナンス作業に対応できる。

表 4-2 セキュア OS として SELinux を選択するメリット

# 項目内容

1 フリーソフト非常に高度なセキュリティアーキテクチャが実装されていながら、SELinux は GPL で配布されており、無料で使用することができる。

2 オープンソース Linux と同様にソースコードが公開されており、不良やセキュリティホールを見つけやすく、改善しやすい。

3 Linux との互換性 SELinuxは Linuxのカーネルと数個のコマンドを入れ替えるだけのため、非常に高い互換性が保持されている。Linux を使用した経験のある管理者であれば、SELinux の操作に戸惑うことはない。

4 ソフトウェアの動作 Linux との高い互換性により、Linux で動作するソフトウェアはそのまま SELinux でも動作する(ただし、正常に動作させるためにはセキュリティポリシーの定義が必要である)。ソフトウェア自身に改良を加えることなく、その動作時のセキュリティを高めることが可能である。





SELinux を導入するデメリットを表 4-3 にまとめる。

表 4-3 SELinux 導入のデメリット

# 項目内容

1 無保証多くのフリーソフトがそうであるように、SELinux も無保証である(GPL)。

2 サポートがない Linux ディストリビューション(たとえば、Red Hat Linux 等)によっては企業のサポートがあるが、SELinux にはサポートがない。ただし、メーリングリストによるコミュニティに相談すれば、問題解決の相談に乗ってもらえる場合がある。

3 商用アプリケーション商用アプリケーションの動作実績が少ない。Linux で動作する商用アプリケーションであれば SELinux 上でも動作すると考えられるが、動作確認がとられていない。また、メーカーとしてもサポート範囲外となるであろう。

4 情報が少ないドキュメントや技術情報が少ない。NSA が公開しているドキュメント類も更新が遅れがちである。

5 仕様変更開発途中のため、仕様変更の可能性がある。

6 設定が複雑 #4 にも関係しているが、セキュリティポリシーの設定方法が複雑である。セキュリティポリシーの設定を支援する GUI を利用したツールも開発・リリースされてはいるが、この問題を根本から解決する優れたツールとは言いがたい。また、セキュリティポリシーの XML 化が推進されており、さらに複雑さを増す可能性がある。

4.2.2. 導入システムの留意点

セキュア OS である SELinux サーバーを導入する場合は、その目的と用途を考慮した上で

選択する必要がある。たとえば、数値計算システムやプログラムの開発環境のように特定

のユーザを対象としたシステムや特定のアプリケーションサーバーからしかアクセスされ

ない DB サーバーのようなシステムに SELinux を導入する必要性はないであろう。また、特

定部署のイントラネット用サーバーとしても、試験的に導入する場合を除いてその必要性

は感じられない。

通常の Linux と比較して堅牢なシステムを構築することができるため、サーバーの用途

としては不特定多数がアクセスするようなサーバーに向いている。たとえば、外部公開用

の WEB サーバーや FTP サーバー、また、DMZ(非武装地帯)に設置するメールサーバーや DNS

サーバーに適したシステムといえる。また、前節のメリット・デメリットにも挙げたよう

に Linux で動作するフリーソフトはほとんど問題なく動作するが、商用アプリケーション

の動作実績がないので、これらの要素も留意する必要がある。

システム管理者の技術レベルと教育も留意点に入れておく必要がある。セキュリティポ

リシーやセキュリティコンテキストの設定部分を除くとほぼ通常の Linux システムと変わ





らない。Linux サーバーの構築経験者や管理経験者であれば、SELinux サーバーの導入は容

易であると考える。

4.2.3. ユーザの意識管理

セキュアOSといってもSELinuxは完璧なシステムではないことは留意しなければならな

い。次節に記述するように、SELinux にはそのアクセス制御機能で悪意あるユーザから保護

できるものと保護できないものがあることに留意してシステムの管理を行わなければなら

ない。一般的に言われるサーバー管理は SELinux であっても実施するように心掛けるべき

である。

インターネットサーバーとしてシステムを構築する場合、登録する一般ユーザを極力控

え、パスワードの設定方法等十分な教育を行うとともに、必要最小限の権限しか与えない

ような設定をしなければならない。たとえば、FTP サーバーであればホームディレクトリよ

り上は見せないとか、一般ユーザをシステムにログインさせる必要がなければログイン

シェルを別のプログラム(/bin/true や/usr/bin/passwd)に変更するといった対策が必要で

ある。





4.3. 信頼性の確保

4.3.1. 保護の対象

SELinux は、TE(Type Enforcement)モデルと RBAC(Role-Based Access Control)モデルを

組み合わせたセキュリティモデルとして実装し、きめ細かな MAC(Mandatory Access

Control:強制アクセス制御)を実現している。

表 4-4 アクセスの対象とパーミッション概略

# セキュリティクラスパーミッションの概略

1 filesystem mount、remount、umount 等の 10 種類

2 dir add_name、remove_name、rmdir 等の 22 種類

3 file read、write、append 等の 19 種類

4 lnk_file file と同じ

5 chr_file file と同じ

6 blk_file file と同じ

7 sock_file file と同じ

8 fifo_file file と同じ

9 fd use のみ

10 socket read、write、bind 等の 22 種類

11 tcp_socket socket に加え connectto、acceptfrom、newconn の 25 種類

12 udp_socket tcp_socket と同じ

13 rawip_socket tcp_socket と同じ

14 node tcp_send、tcp_recv、udp_send、udp_recv 等の 7種類

15 netif tcp_send、tcp_recv、udp_send、udp_recv 等の 6種類

16 netlink_socket socket と同じ

17 packet_socket socket と同じ

18 key_socket socket と同じ

19 unix_stream_socket tcp_socket と同じ

20 unix_dgram_socket socket と同じ

21 process fork、signal、transition 等の 16 種類

22 ipc create、read、write 等の 9種類

23 sem ipc と同じ

24 msgq ipc に加え enqueue の 10 種類

25 msg ipc に加え send、receive の 11 種類

26 shm ipc に加え lock の 10 種類

27 security load_policy、sid_to_context、context_to_sid の 9 種類

28 system ipc_info、avc_toggle、syslog_read 等の 8種類

29 capability chown、dac_override、dac_read_search 等の 29 種類

SELinux が提供するセキュリティ機能により保護の対象となるセキュリティクラス(アク

セスの対象)とそのセキュリティクラスに関連付けられるパーミッション(アクセスベク





タ)の概略を表 4-4 に示す70。この表 4-4 に挙げたアクセス制御の対象となるセキュリティ

クラスを大きく分けると以下の 5つに分類することができる

1. ファイル関連

2. ネットワーク関連

3. プロセス関連(ケイパビリティ含む)

4. プロセス間通信(IPC)関連

5. システム・セキュリティ関連

SELinux のセキュリティポリシー設定の基本は、プロセスに特定の domain を設定し、そ

の domain がどのオブジェクトにどのような権限でアクセスできるかを定義するものである。

また、この権限はプロセスのユーザ ID(ここでは、Linux が管理する従来のユーザ ID を指

す)が変更されても設定された権限はそのまま継承される。このため、デーモンプロセスに

何らかのセキュリティ上の脆弱性があり、外部からの侵入者に乗っ取られそれを踏み台に

root ユーザが奪われても、セキュリティポリシーにより設定された権限は継承されている

のでシステムファイル破壊による被害は最小限に抑えることができる。

逆を言うと、デーモンプロセスに対して不必要な権限(たとえば、読み込み専用のファイ

ルに対して書き込み権限を与える)を設定していると、外部からデーモンを乗っ取られた場

合にファイルを破壊されてしまう。また、システムの重要な情報を盗まれる可能性やこの

システムが踏み台となって他のサーバーに攻撃を繰り返す場合もある。

プログラムの実行権限に関してもセキュリティポリシーで厳しく設定することができ、

不用意にプログラムを実行できないようにすることができる。2002 年 9 月に発見された

Slapper は Apache/OpenSSL のバッファオーバーフローの脆弱性を利用するワームである71。

この Slapper は/tmp ディレクトリ下にソースコードを送り込み、gcc でコンパイル後、そ

のプログラムを実行しようとする。しかし SELinux 環境下では、/tmp ディレクトリ下のファ

イルには type「tmp_t」(または、類似の type「*_tmp_t」)が付与され、この「tmp_t」に

は実行権限が付与されていないため、プログラムは実行不可となりバックドアの設置に失

敗する。このように外部からの侵入を防ぐこともできる。

4.3.2. 保護の対象外

セキュアOSであるSELinuxであっても万全のシステムではないということを念頭におい

てシステムの構築を行わなければならない。

70 詳細は、lsm-2.4/security/selinux/flask/access_vectors に記述されている。 71 http://www.ipa.go.jp/cgi-bin/security/virus/search/virus?ID=314





SELinux の保護の対象とならない事象として以下が考えられる。

1. セキュリティホールを持ったアプリケーションのサービス停止

2. 書き込み権限のあるファイルの破壊

3. 侵入検知

4. セキュリティポリシーの設定ミス・設定漏れ

アプリケーションにセキュリティホールがあった場合、セキュリティポリシーを適正に

設定していれば被害を最小限に抑えることができるが、攻撃によってアプリケーション自

体が停止してしまうケースもある。このような事態はたとえ SELinux であっても防ぐこと

はできない。

アプリケーションによっては、システムで使用するファイルに対する書き込み権限が与

えられていなければならないものがある。たとえば、ダイナミック DNS を運用している場

合は、アプリケーション(BIND)に対してゾーンファイルへの書き込み権限を付与しておか

なければならない。この場合、アプリケーションのセキュリティホールにより外部から侵

入されると、書き込み権限のあるファイルは破壊される可能性がある。

4.3.3. 信頼性確保のための方針

前節に述べた SELinux における保護の対象・対象外を踏まえて、信頼性確保の指針を表

4-5 に示す。





表 4-5 信頼性を確保する際の指針

# 指針内容

1 root ユーザとセキュリティ管理者は分けること

2 セキュリティポリシーの見直しを定期的に行うこと

3 重要なファイルのセキュリティコンテキストが変更されていないか定期的にチェックすること

4 不要なアプリケーションはインストールしない。システムに不要なアプリケーションには管理者の意識が及ばない可能性が高い。結果として、そのアプリケーションのセキュリティポリシー定義が不適切な状態で放置されかねない。

5 不要なアプリケーション（デーモン類）は起動しない。理由は#4と同様である。

6 syslog の監視は定期的(最低でも週 1回)に行う

7 アプリケーションのセキュリティ対策はこまめに行う。緊急性のあるセキュリティ情報が流れたら、業務をとめてでも確認・対応する。

8 セキュア OS を過信せずに他のセキュリティ向上機能、たとえばパケットフィルタや IDS72

の機能を組み合わせたシステムも考慮にいれる

9 パスワードの管理を徹底し、不要なユーザは作らない

10 システムのバックアップは定期的に採取する

SELinux を利用したサーバーに関する特有の指針で無い部分もあるが、本指針は最低限遵

守してほしい。また、時間的に余裕があれば SELinux の開発者が参加するメーリングリス

ト73で情報を収集することを勧める。このメーリングリストは、一般的なユーザからの質問

等も受け付けるが、たまにセキュリティポリシーの改訂版や SELinux カーネルに対するパッ

チ等の有益な情報も流れ、SELinux の動向についても知ることができる。

4.4. システム管理

4.4.1. 監査・診断方法

SELinux には、システム監査や診断を行うための便利なプログラムやツールが存在してい

ない。このため、システムが正常に動作しているかどうかを確認するには既存のコマンド

類を利用して目視による確認が必要となる。

本節では ps コマンド、ls コマンド、およびカーネルメッセージ(syslog)による確認方法

を説明する。SELinux での ps および ls コマンドは独自にエンハンスされており、追加され

たオプションを指定することでプロセスやファイルのセキュリティコンテキストを表示す

ることができる。また、カーネルメッセージには SELinux の１コンポーネントである Access

Vector Cache(AVC)によるログが出力され、その内容からシステムの状態を判断することが

できる。

72 参考：LISD(Linux Intrusion Detection System) http://www.lids.org/ 73 http://www.nsa.gov/selinux/list.html





4.4.1.1. ps コマンドによる確認

SELinux 用にエンハンスされた ps コマンドには、“--context”および“--SID”オプショ

ンが追加されている。それぞれプロセスの「セキュリティコンテキスト」と「セキュリティ

ID」を表示するオプションである。「セキュリティ ID」は、SELinux の内部で使用する ID(数

値)のためここでは言及しない。

リスト 4-1 は、“ps -ax --context”を実行したときの表示内容の一部である。ここで

注目しなければならないのは、個々のプロセスのセキュリティコンテキストである。特に、

セキュリティコンテキストの３番目のフィールド(domain)が目的の domain に遷移している

かどうかをチェックしなければならない。たとえば、syslogd プロセスのセキュリティコン

テキストは“system_u:system_r:syslogd_t”となっており、同プロセスの domain が適切

な“syslogd_t”に遷移しているので問題ないことが分かる。

リスト 4-1 ps コマンドの出力例

PID SID CONTEXT COMMAND 1 7 system_u:system_r:init_t init 2 1 system_u:system_r:kernel_t [keventd] 3 1 system_u:system_r:kernel_t [ksoftirqd_CPU0] 4 1 system_u:system_r:kernel_t [kswapd] 5 1 system_u:system_r:kernel_t [bdflush] 6 1 system_u:system_r:kernel_t [kupdated] 7 7 system_u:system_r:init_t [khubd] 8 7 system_u:system_r:init_t [kjournald] 105 7 system_u:system_r:init_t [kjournald] 416 276 system_u:system_r:syslogd_t syslogd -m 0 420 290 system_u:system_r:klogd_t klogd -x 458 292 system_u:system_r:inetd_t xinetd -stayalive -reuse - 472 298 system_u:system_r:ntpd_t ntpd -U ntp -g 491 299 system_u:system_r:sendmail_t sendmail: accepting connec 501 299 system_u:system_r:sendmail_t sendmail: Queue runner@01: 522 305 system_u:system_r:crond_t crond 548 311 system_u:system_r:atd_t /usr/sbin/atd 557 314 system_u:system_r:local_login_t login -- foobar 559 313 system_u:system_r:getty_t /sbin/mingetty tty3 565 316 foobar:user_r:user_t -bash

特に注意しなければならないのは常時稼動しているデーモン類である。ネットワークの

接続待ちをしているプロセスは外部からの攻撃をを受けやすく、仮に当該プログラムがセ

キュリティ上の脆弱性を持っていた場合、攻撃されてシステムに侵入される恐れがある。

デーモンプロセスは init プロセスの延長である rc スクリプトから起動される。rc スクリ

プトには“initrc_t”という domain が付与されており、デーモン類を起動するために特別





な権限が与えられている。この rc スクリプトから起動されたデーモンプロセスの domain

を“initrc_t”の状態で放置しておくと、不要なまたは危険な権限を保持しているためセ

キュリティ上非常に問題である。

不正な domain を持ったプロセスが存在する原因としては、以下の３点が考えられる。

① セキュリティポリシーが未設定である。

② セキュリティポリシー内で domain 遷移を定義していない、

または設定が間違っている

③ 実行ファイルに正しいセキュリティコンテキストが付与されていない

原因が①の場合は、早急にプロセスを停止してセキュリティポリシーの作成に取り掛か

るべきである。②と③に関してはセキュリティポリシー設定ファイル(te ファイル)および

セキュリティコンテキスト設定ファイル(fc ファイル)の見直しを行わなければならない。

②はセキュリティポリシー設定ファイルに“domain_auto_trans”マクロを使用してリスト

4-2 に示すような domain 遷移の定義があるどうかを確認し、なければ定義を追加する。

リスト 4-2 domain 遷移の設定例

domain_auto_trans(initrc_t, xxx_exec_t, xxx_t)

ファイルのセキュリティコンテキストの確認は 4.4.1.2 で説明するが、セキュリティコ

ンテキスト不正の原因としては、「プログラムの再インストール」や「プログラムのアップ

デート」によるものが考えられる。この場合は、“make relabel”でセキュリティコンテキ

ストの設定を行えばよい。

それ以外の原因としては、セキュリティコンテキスト設定ファイルに設定しているファ

イルのパス名(もしくは、パス名の正規表現)が誤っている場合が考えられる。定義内容の

見直しは慎重に行わなければならない。

4.4.1.2. ls コマンドによる確認

SELinux 用にエンハンスされた ls コマンドには、セキュリティコンテキストを表示する

オプション“--context”、“--lcontext”、および“--scontext”と、セキュリティ ID を表

示するオプションである“--lsid”と“--sid”が追加されている(リスト 4-3 参照)。「セ

キュリティ ID」は SELinux の内部で使用する ID(数値)のためここでは言及しない。





リスト 4-3 ls コマンドに追加されたオプション

--lsid Display Security ID (SID). Enable -l --sid Display SID. --lcontext Display security context. Enable -l. Lines will probably be too wide for most displays. --context Display security context so it fits on most displays. Displays only mode, user, group, security context and file name. --scontext Display only security context and file name.

ls コマンドに“--context”を付けて実行すると、リスト 4-4 のようにセキュリティコ

ンテキストが表示される。“sytem_u:object_r:syslogd_exec_t”がセキュリティコンテキ

ストであり、“syslogd_exe_t”が type である。

セキュリティコンテキスト設定ファイルのパス名不正や設定漏れの場合、カレントディ

レクトリまたは親ディレクトリのセキュリティコンテキストを継承して設定される場合が

ある。たとえば、/sbin ディレクトリには type“sbin_t”が設定されているが、リスト 4-4

の例で示しているファイル/sbin/syslogd が/sbin ディレクトリのセキュリティコンテキス

トである“system_u:object_r:sbin_t”に変更されていたら、正しいセキュリティコンテ

キストに設定しなおさなければならない。

リスト 4-4 ls コマンドの実行例

# ls --context /sbin/syslogd -rwxr-xr-x root root system_u:object_r:syslogd_exec_t /sbin/syslogd

ファイルに設定されているセキュリティコンテキストはプログラムの再インストールや

アップデートにより書き換わってしまう場合がある。ファイルのセキュリティコンテキス

トを設定し直すには、selinux/policy ディレクトリ下で“make relabel”を実行するか、

SELinux独自プログラムであるchconコマンドを使用して個々に再設定しなければならない。

リスト 4-5 chcon コマンドの実行例

① chcon system_u:object_r:syslogd_exec_t /sbin/syslogd ② chcon -R system_u:object_r:httpd_sys_content_t /var/www/html

リスト 4-5 は chcon コマンドの実行例である。①は/sbin/syslogd ファイルに対してセ

キュリティコンテキストを設定する例で、②は/var/www/html ディレクトリ下のすべての





ファイルに対してセキュリティコンテキストを設定する例である。

ls コマンドだけでファイルのセキュリティコンテキストの不正を発見することはなかな

か難しい。次節 4.4.1.3 で説明するカーネルメッセージを観察し、アプリケーション自身

が出力する(エラー)メッセージを定期的に監視しなければならない。

4.4.1.3. カーネルメッセージによる確認

SELinux カーネルを起動するとセキュリティポリシーに違反した情報がカーネルメッ

セージとしてsyslogに出力される。これは、SELinuxのコンポーネントであるAccess Vector

Cache(AVC)が権限のチェックを行ったときに出力するメッセージで、permissive モード・

enforcing モードに関係なく出力される。リスト 4-6 は、この AVC が出力するカーネルメッ

セージの形式を示したものである。これは、あるプログラムがあるファイルまたはディレ

クトリにアクセスしようとして、それが拒否されたときに出力されるメッセージの形式で

ある。アクセス対象がネットワークやケイパビリティの場合は、ネットワークインタフェー

ス・IP アドレス・ポート番号、ケイパビリティ名が表示される74。

リスト 4-6 カーネルメッセージの形式

avc: denied { パーミッションリスト } for pid=プロセス ID exe=実行プログラムファイル名 path=対象ファイル名 dev=デバイス番号 ino=i-node 番号 scontext=ソースセキュリティコンテキスト tcontext=ターゲットセキュリティコンテキスト tclass=クラス

以下では、リスト 4-6 に示した形式のログにて出力される各種情報に関して個別に解説

する。

(1) avc メッセージ

AVC からのメッセージは、“avc:”が付与されて出力される。アクセスが拒否された

場合には、リスト 4-6 のように“denied”が出力される。auditallow 文により指定さ

れたアクセス(標準のセキュリティポリシー定義では avc_toggle コマンドの実行が指

定されている)が行われた場合には、この部分に“granted”が表示される。

74 ドキュメントが整備されていないためソースコードを参考にするしかない。

lsm-2.4/security/selinux/avc.c の avc_audit()関数が処理部分である。





(2) パーミッションリスト

パーミッションリストは、どのようなアクセスが許可あるいは拒否されたがが表示

される。たとえば、アクセスした対象がファイルの場合には、read、write、create、

unlink など 17 種類のパーミッションが表示され得る。ディレクトリの場合はファイ

ルのパーミッションに加えて、更に add_name、remove_name、search など 5 種類が存

在する。

(3) ファイル名

exe や path には、アクセス拒否の原因を起こしたプログラムのパス名(exe)や、そ

の対照となったファイル名(path)が表示される。dev および ino は対象ファイル(この

場合は path のファイル)が存在するデバイスのメジャー・マイナー番号と i-node 番号

である。ネットワーク関連の操作の場合は、IP アドレスやポート番号が表示される。

(4) セキュリティコンテキスト

“scontext”はアクセス元のセキュリティコンテキストを示しており、“tcontext”

はアクセス先のセキュリティコンテキストを示している。プログラムを実行したとき

の domain が、アクセスしようとしたオブジェクト(ファイル)の type に対するアクセ

ス権限が無かったことがこの 2対のセキュリティコンテキストから判断できる。

(5) クラス

クラスは、アクセスの対象が何かを表す。たとえば、ファイルの場合は“file”と

表示され、ディレクトリの場合は“dir”と表示される。ソケットに関しても、TCP と

UDP を区別して“tcp_socket”と“udp_socket”が定義されている。

表 4-6 にクラスの一覧を示す。現段階で 29 種類のクラスが定義されている。

表 4-6 クラス一覧

security process system capability filesystem

file dir fd lnk_file chr_file

blk_file sock_file fifo_file socket netlink_socket

udp_socket netif node rawip_socket unix_stream_socket

ipc key_socket sem tcp_socket unix_dgram_socket

msg msgq shm packet_socket





4.4.2. アプリケーションの追加・更新

4.4.2.1. アプリケーションの追加

アプリケーションを追加する場合は、まず当該アプリケーションのセキュリティポリ

シー定義ファイルが既にあるかどうかを確認する必要がある。本ガイドライン作成段階の

SELinux (2003011510 版)では、policy/domain/program の下の te ファイルは 119 個存在す

る。これらは基本的にボランタリーベースで作成されているものであるが、フリーソフト

のメジャーなものは揃っている。

セキュリティポリシー定義ファイルが存在しない場合は、「3.5.5 セキュリティポリシー

の検証・確認方法」を参考に新規に作成しなければならない。

セキュリティポリシー定義ファイルが存在する場合は、以下の手順でアプリケーション

をインストールし、セキュリティポリシーの設定を行う。

1. インストールするアプリケーションとセキュリティコンテキスト設定ファイ

ル(fc ファイル)のファイルパスの確認

2. 必要であればインストールパスまたは fc ファイルの定義を変更する

3. セキュリティポリシー定義ファイル(te ファイル)の確認・修正

4. セキュリティポリシーをロードする(make load または make reload)

5. セキュリティコンテキストの設定(make relabel)

6. アプリケーションを実行し、設定漏れがないか確認する

7. 問題があれば、te/fc ファイルの修正・追加を行う

4.4.2.2. アプリケーションの更新

アプリケーションを更新(または、再インストール)する場合に注意しなければならない

のは、更新した時点で各ファイルのセキュリティコンテキストが変更されれてしまうこと

である。たとえば共有ライブラリ関連のセキュリティコンテキストが変更されると、コマ

ンドが実行できなくなる。特に、glibc 関連のライブラリ(/lib/libc.so.*や/lib/ld-*)の

セキュリティコンテキストを変更してしまうと、システム上のほとんどのコマンドが実行

できなくなるので、更新の際は十分な注意が必要である。

アプリケーション更新時には以下の手順を踏んで行う。





1. avc_toggle コマンドでシステムを permissive モードにする75

2. アプリケーションの更新を行う

3. セキュリティポリシー、セキュリティコンテキストの設定を見直す

4. セキュリティポリシーを変更した場合、ロードする(make load)

5. セキュリティコンテキストの再設定を行う(make relabel)

6. avc_toggle コマンドでシステムを enforcing モードにする76

7. アプリケーションを実行し、設定漏れがないかを確認する

アプリケーションによってはメジャーバージョンアップでインストールパスや設定ファ

イルのパスおよびデータファイルのパスが変更になっている場合もあるので、セキュリ

ティポリシー設定ファイルおよびセキュリティコンテキスト設定ファイルの見直しを行う

必要がある。

デーモン類のプログラムを更新した場合は、手動による起動確認よりは一旦システムを

再起動させ、ps コマンドでプロセスのセキュリティコンテキストの確認および syslog にア

クセス拒否のメッセージが残されていないかを確認すべきである。

4.4.3. 保護範疇外の管理指針

SELinux は、セキュア OS といっても完璧なシステムではない。過信は禁物である。不測

の事態に備え種々の対策を施しておくべきである。

SELinux の保護の範疇外についての管理指針を示す。

4.4.3.1. tripwire (ファイルの整合性チェック)

tripwire とは、ファイルの整合性をチェックするソフトウェアでトリップワイヤ社が販

売している商用版と Tripwire オープンソースプロジェクトが提供している無償版がある。

tripwire は、システム内のファイルの情報をデータベース化し、再度チェックしたときに

ファイルに何らかの変更があった場合にレポートを表示する。cron ジョブとして定期的に

実行し、ファイルの改ざんを検知したときにメールで通知することもできる。Red Hat Linux

8.0 には、tripwire 2.3.1 が RPM として組み込まれているので手軽に使用できる。

SELinux で使用する場合は当然であるが、セキュリティポリシー設定ファイルとセキュリ

ティコンテキスト設定ファイルを用意する必要がある。

75 必要であればネットワークを停止する 76 ネットワークを停止していた場合は起動する





リスト 4-7 はセキュリティコンテキスト定義の内容で、リスト 4-8 はセキュリティポリ

シーの設定内容である。SELinux には標準では付属していないため、弊社で作成した設定内

容である。

リスト 4-7 tripwire のファイルコンテキスト定義

/etc/tripwire(/.*)? system_u:object_r:etc_tripwire_t /usr/sbin/tripwire system_u:object_r:tripwire_exec_t /usr/sbin/twadmin system_u:object_r:twadmin_exec_t /var/lib/tripwire(/.*)? system_u:object_r:var_tripwire_t

リスト 4-8 tripwire のセキュリティポリシー定義

type tripwire_t, domain, auth, privlog; role system_r types tripwire_t; role sysadm_r types tripwire_t; every_domain(tripwire_t) type twadmin_t, domain; role system_r types twadmin_t; role sysadm_r types twadmin_t; type tripwire_exec_t, file_type, sysadmfile, exec_type, privmail; type etc_tripwire_t, file_type, sysadmfile; type var_tripwire_t, file_type, sysadmfile; type twadmin_exec_t, file_type, sysadmfile, exec_type; allow tripwire_t etc_tripwire_t:dir r_dir_perms; allow tripwire_t etc_tripwire_t:file r_file_perms; allow tripwire_t var_tripwire_t:dir rw_dir_perms; allow tripwire_t var_tripwire_t:file create_file_perms; domain_auto_trans(system_crond_t, tripwire_exec_t, tripwire_t) domain_auto_trans(sysadm_t, tripwire_exec_t, tripwire_t) domain_auto_trans(user_t, tripwire_exec_t, tripwire_t) type tripwire_tmp_t, file_type, sysadmfile, tmpfile; file_type_auto_trans(tripwire_t, tmp_t, tripwire_tmp_t) allow tripwire_t sysadm_devpts_t:chr_file rw_file_perms; allow tripwire_t tripwire_t:capability { dac_override dac_read_search setgid setuid }; can_exec(tripwire_t, sendmail_exec_t)





can_exec(tripwire_t, shell_exec_t) can_tcp_connect(tripwire_t, sendmail_t) allow tripwire_t var_spool_t:dir rw_dir_perms; allow tripwire_t var_spool_t:file create_file_perms; allow tripwire_t mqueue_spool_t:dir rw_dir_perms; allow tripwire_t mqueue_spool_t:file create_file_perms; ifdef(`crond.te', ` domain_auto_trans(system_crond_t, tripwire_exec_t, tripwire_t) allow tripwire_t crond_t:fifo_file { read write ioctl }; ') allow tripwire_t file_type:dir r_dir_perms; allow tripwire_t file_type:{ file lnk_file } r_file_perms;

4.4.3.2. バックアップ

サーバーを運用する上でバックアップは必須である。外部からの破壊攻撃に備えるのは

勿論だが、不注意による操作ミスやハードウェア障害の対策も考慮すべきである。

SELinux では、バックアップ関係のセキュリティポリシーとして backup.fc/backup.te

ファイルと amdanda.fc/amanda.te ファイルが用意されている。それぞれのファイルを参照

して参考にしていただきたい。

4.4.3.3. アプリケーションのセキュリティ対策

SELinux を使用するメリットの１つとして、アプリケーションに未知のセキュリティホー

ルがあっても、OS レベルでアクセス権限のチェックを行っており、またアプリケーション

には必要最小限の権限しか与えていないため、被害を最小限にとどめることができる、と

いうのがある。しかし、アプリケーションが停止し、これによってサービスが停止してし

まうのは問題である。最近では、アプリケーションのセキュリティホールが発見されると

ほぼ同時に対策パッチや対策モジュール、あるいは対策パッケージが公開されるように

なった。公開された対策内容を吟味し、本当に必要かを確認後対策しなければならない。

システム管理者としては、常に安定した最新バージョンのアプリケーションを使用するよ

う心掛けるべきである。

4.4.3.4. パケットフィルタ

外部に公開したサーバーにはさまざまな所からさまざまな手法のアクセスがある。また、

一連のポート番号にアクセスを試みるポートスキャンと呼ばれるクラッキング手法も存在





する。

このような不正なアクセスを防ぐために、ファイアウォールを設置やパケットフィルタ

を設定したルータを設置する方法がある。

Linux においても iptables(2.4 系カーネル)77によるパケットフィルタが実装されており、

SELinux でも使用することができる。内部からの不正アクセスを防ぐ意味でも、パケット

フィルタは設定しておいた方が無難であろう。

本機能を使用して、必要最低限のポートを開き、不要な・不正なアクセスを排除すべき

である。

リスト 4-9 パケットフィルタの設定例

-A INPUT -j RH-Lokkit-0-50-INPUT ① -A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 80 --syn -j ACCEPT ② -A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 21 -s 133.X.Y.0/24 --syn -j ACCEPT③ -A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 23 -s 133.X.Y.0/24 --syn -j ACCEPT④ -A RH-Lokkit-0-50-INPUT -p udp -m udp -s 202.X.Y.2 --sport 53 -d 0/0 -j ACCEPT ⑤ -A RH-Lokkit-0-50-INPUT -p udp -m udp -s 202.X.Y.2 --sport 123 -d 0/0 -j ACCEPT -A RH-Lokkit-0-50-INPUT -p tcp -m tcp --syn -j REJECT -A RH-Lokkit-0-50-INPUT -p udp -m udp -j REJECT ⑥ -A RH-Lokkit-0-50-INPUT -p icmp -j REJECT

リスト 4-9 は iptables を利用したパケットフィルタの設定例78で、WEB サーバーを想定

している。まず、①により 80 番ポート(http)のアクセスを許可している。②、③は社内の

特定のネットワークから 21 番ポート(ftp)と 23 番ポート(telnet)を許可し、④、⑤は特定

のホストからのソースポートとして 53 番ポート(domain)と 123 番ポート(ntp)のアクセス

を許可している。

4.4.3.5. ユーザ管理と passwd 管理

通常のシステムと同様に SELinux のシステムにおいてもパスワード管理は厳重に行わな

ければならないし、アカウントを持つユーザにもパスワードの管理を徹底するよう指導し

なければならない。インターネットサーバーとしてシステムを構築する場合は、一般ユー

ザのアカウントは管理者のみにとどめるべきであり、不要となったアカウントは直ちに削

除すべきである。

SELinux では従来の root ユーザが持っていた権限を排除し、代わりに個々のユーザに管

77 2.2 系カーネルで実装された ipchains も使用できる 78 /etc/sysconfig/iptables ファイルの一部





理者の権限を分散した方がよい。たとえば、表 4-7 に示すように、外部からアタックを受

けやすい root ユーザには権限を付与せず、別アカウント(この例では secadmin)にセキュリ

ティ管理者権限を与える。この場合、sysadm_r を付与しているの、従来の root ユーザに相

当する。また、WEB 管理者や FTP 管理者を設定することもできる。ただし、各ユーザはログ

イン時には一般ユーザである“user_r”を付与するようにし、SELinux 独自コマンドである

newrole でそれぞれの role に遷移するような設定しなければならない。

表 4-7 管理者権限の分散

# Linux アカウント SELinux の role 説明

1 root - (なし) root ユーザには権限を与えない

2 secadmin sysadm_r セキュリティ管理者

3 webadmin httpd_admin_r WEB 管理者

4 ftpadmin ftpd_admin_r FTP 管理者

secadmin ユーザがセキュリティ管理者権限(sysadm_r)を持っていてもすべてのファイル

を編集できるわけではない。これは、SELinux の強制アクセス制御を通過したからといって、

従来の Linux が保持する任意アクセス制御(DAC)は許可されていないからである。つまり、

root が所有者となっているファイルは su コマンドで root ユーザにならないと編集するこ

とができないのである。逆に、root ユーザが su コマンドで secadmin になっても管理者権

限は継承しないので問題はない。

結論としては、管理者権限を root ユーザ以外に付与し、それぞれのパスワードは個別に

設定し管理を行う、ということである。





5. コスト評価

3.4 では、SELinux においてセキュリティポリシーを定義する方法を解説した。SELinux

でのセキュリティポリシー定義形式はお世辞にも簡単ではないことが分かってもらえただ

ろう。3.5 では、実際にインターネットサーバーを構築する際に重要となるセキュリティポ

リシー定義とその留意点を解説した。具体的なアプリケーションのセキュリティポリシー

を定義することがいかに複雑で難しいことか分かってもらえただろう。しかし、具体的に

SELinux の導入を検討されている方にとっては、「実際にシステムを構築する場合にはどの

程度の作業量が要求されるのか。どのような箇所でつまずくのか。」といった点が気になる

に違いない。そこで本章では、SELinux に関する詳細な事前知識を持たないユーザが SELinux

を利用したインターネットサーバーを構築する際の作業工数を評価・分析する。

5.1. 作業対象者のスキル

作業工数を評価・分析するにあたり、以下に示すユーザを作業対象者とした。

• Red Hat Linux を適切にインストールできる

• Red Hat Linux と一般的な UNIX システムで利用される各種コマンドを知っている

• Red Hat Linux の稼動するシステムでインターネットサーバーを構築できる

• Linux カーネルの再構築経験がある

つまりここでの作業対象者は、Linux に関する基礎知識を十分に有していることを前提と

している。したがって、本章で評価・分析する作業工数には、Linux 未経験者がそれらの習

得に必要となる作業工数に関しては含まれていないことに注意してほしい。

5.2. 実施手順

作業工数を評価・分析するためのデータ採取は、上記に示した作業対象者に対して表 5-1

に示す手順にて実施した。





表 5-1 作業工数評価データ採取手順

＃作業内容内容

1 SELinux に関する学習

SELinux に関する既存ドキュメントを利用して、SELinux の独習を実施してもらう。

2 システムの構築・設定・運用作業

SELinux の独習結果を基に以下の作業を実施してもらう。

• SELinux のインストール • インターネットサーバーの構築（セキュリティポリシー

の定義）

3 本ガイドライン参照

本ガイドラインを参照し、項番 2での自身のセキュリティポリシー定義を見直してもらう。この際、以下のデータを採取する。

• 設定ミス・設定漏れの項目と項目数 • 上記の設定ミス・設定漏れの再設定作業工数 • 本ガイドライン参照により短縮される作業工数 • 本ガイドラインの理解度

作業工数の評価・分析にあたっては、本ガイドラインを参照した場合の作業工数も評価

することで、本ガイドラインの有効性に関しても併せて評価・分析する。

5.3. 結果

本節では、5.2 で示した手順に従って得られたデータをまとめる。

5.3.1. 理解度

既存のドキュメントを基に SELinux を独習した場合と、本ガイドラインを参照した場合

でのSELinuxの理解度はどの程度なのだろうか。理解度に関する調査結果を表 5-2に示す。





表 5-2 SELinux の理解度平均値

理解度（100 を満点とした抽象的な評価数値）＃項目

既存ドキュメントのみ参照ガイドライン参照

1 セキュリティアーキテクチャ 50 80

2 インストール 55 70

3 セキュリティポリシー定義 30 70

4 運用方法 30 70

なお、本ガイドラインの理解度は平均 80（100 を満点とした抽象的な評価数値）という

結果が得られた。

5.3.2. 作業工数

本ガイドラインは参照せずに、SELinux に関連した既存ドキュメントのみを頼りにイン

ターネットサーバー構築を実施した場合の作業工数と、本ガイドライン参照時の作業工数

を表 5-3、表 5-4、表 5-5、および表 5-6 に示す。

表 5-3 作業者 A（WEB サーバーと DNS サーバーを構築）

作業工数（単位：日79）

ガイドライン未参照ガイドライン参照 # 作業内容

WEB DNS WEB DNS

1 SELinux の学習 1.50 1.00

2 SELinux のインストール 0.50 0.50

3 セキュリティポリシーの定義方法の習得 1.50 1.00

4 アプリケーションのインストール・設定 0.50 0.50 0.50 0.50

5 アプリケーションのセキュリティポリシー定義 5.00 4.50 1.00 1.00

作業工数計 9.00 8.50 4.50 4.00

79 1 日≒8時間としている。





表 5-4 作業者 B（SMTP サーバーと FTP サーバーを構築）

作業工数（単位：日）


SMTP FTP SMTP FTP






作業工数計 9.50 8.50 5.00 4.50

表 5-5 作業者 C（DNS サーバーと SMTP サーバーを構築）



DNS SMTP DNS SMTP






作業工数計 9.50 8.50 4.00 4.50

表 5-6 作業者 D（WEB サーバーと FTP サーバーを構築）



WEB FTP WEB FTP






作業工数計 9.00 9.50 5.50 5.50

5.3.3. 設定ミス・設定漏れ

サービスを無事稼動させることができた作業者でも平均して 3～4箇所の設定ミス・設定





漏れがみられた。これらの設定ミス・設定漏れは以下に挙げる内容にほぼ分類される。

セキュリティコンテキストのファイルへのアタッチミス

本ガイドラインの本文でも度々触れているが、SELinux を Red Hat Linux ベースで

稼動させる場合にはファイルに対するセキュリティコンテキストのアタッチが適切で

あるか慎重に確認する必要がある。特に SELinux に含まれる標準のセキュリティポリ

シーでは、想定されているファイルパスが Red Hat Linux 環境のそれとは異なるケー

スが多い。これらのカスタマイズが適切に行われていないケースが目立った。

role の利用方法ミス

SELinux に含まれる標準のセキュリティポリシー定義では Apache 固有の role が定

義されている。この role は Apache を起動することを目的として定義されているもの

ではなく、Web サーバーでの配信コンテンツを管理することを目的として用意されて

いる role だが、この role で Apache の起動を試みようとするケースが目立った。

コマンド newrole を利用した新たな role への切替え

アプリケーション固有の role を新たに定義し、コマンド newrole で当該 role への

切替えを許可するセキュリティポリシー定義に苦戦する作業者がみられた。

新たな role でのログイン

新たに role を定義して特定のユーザに割り当てるまでは良いが、同ユーザにてログ

イン時にその role を選択できるように設定することに苦戦する作業者がみられた。

run_init での initrc スクリプトの起動

SELinux 環境においてコマンドラインから initrc スクリプトを実行する場合には、

SELinux固有のコマンドrun_initを利用しなければならない。SELinuxに標準のセキュ

リティポリシー定義では initrc スクリプトの起動元を init プロセスにのみ限定して

いるため、コマンドラインから initrc スクリプトを起動しても適切な domain 遷移が

行われず、結果としてサーバープログラムは正常に稼動しないのである。この点を見

落としている作業者が多くみられた。





initrc スクリプトのセキュリティコンテキスト間違い

本ガイドラインの本文でも触れているが、SELinux に標準で含まれるセキュリティ

ポリシー定義では initrc スクリプトに不適切なセキュリティコンテキストがアタッ

チされてしまう。これは、標準セキュリティポリシー定義が誤っているのではなく、

恐らく Debian と Red Hat Linux での initrc スクリプトの配置構造の相違により発生

する問題だろう。コマンド run_init によるスクリプト起動が上手くいかない状況で上

記理由に辿り着けない作業者が多く見られた。

5.4. 評価・分析

本節では、5.3 に示した結果の各項目毎に、評価・分析した見解を述べる。

5.4.1. 理解度

表 5-2 から判るように、既存のドキュメントのみを参考とした場合では「セキュリティ

ポリシー定義」と「運用方法」に関する理解度が特に低い。

「セキュリティポリシー定義」の理解度が低いのは何が理由であろうか。恐らく、既存

のドキュメントがいずれも定義書式の解説に終始していることが原因であると考えられる。

SELinux に実装されている TE、RBAC、および constraint は、アーキテクチャの概念として

は各々独立したものであるが、いずれもサブジェクトとオブジェクトにアタッチされたセ

キュリティコンテキストという共通のセキュリティラベルを制御基準とすることから、実

際の利用上では各々が関係し合っているものである。定義書式のみが示されただけでは、

このあたりの微妙な関係を把握するのは難しいだろう。

「運用方法」に関するイメージが掴めないのは当然のことだと考える。既存のドキュメ

ントは SELinux のセキュリティアーキテクチャやセキュリティポリシー定義に視点を置い

たものばかりであり、運用面に関して言及しているドキュメントは存在しないからである。

また、「セキュリティアーキテクチャ」や「セキュリティポリシー定義」を十分に理解する

ことなく、運用面に関しての理解が深まることはあり得ない。

本ガイドラインでは、セキュリティポリシー定義書式の詳細な解説はもちろん、アプリ

ケーション毎のセキュリティポリシー定義に関しても詳細に解説を行っている。また、運

用面に関する指針・留意点も明らかとしており、インターネットサーバー構築作業者を大

きく支援するに足る有効性があると考える。また、本ガイドラインをもってしても理解度

100 を得られなかったことに関しては、ある面想像できたことである。SELinux で実装され





ているセキュリティアーキテクチャは非常に複雑・難解であり、そのセキュリティポリシー

定義もまたしかりである。いくら詳細なドキュメントを読み尽くしても、実際に設定・運

用しなければ実感が持てない、理解できない面が多々あると思われる。SELinux を完全に理

解するためには、本ガイドラインを傍らに SELinux を操作し尽くすことが必要である。

5.4.2. 作業工数

表 5-3、表 5-4、表 5-5、および表 5-6 に示した作業工数は、定義されている（定義し

ている）セキュリティポリシーを十分に理解した上で構築作業を行った場合における、シ

ステムが運用可能なレベルまで至るに必要な工数であることに注意してほしい。SELinux に

含まれる標準のセキュリティポリシー定義を利用する場合、特別それらを修正することな

くサービスを稼動させることが可能な場合もある。セキュリティポリシーを十分に把握す

ることなく、「なんとなく動いてしまった」というような構築形態であればもっと工数は少

なく済むはずである。もちろん、それでは SELinux を導入する意味が薄れてしまうことは

あえて説明することもないだろう。

本ガイドラインを参照せずに構築作業を行った場合の DNS サーバーと FTP サーバーの作

業工数が、アプリケーションの規模を考えると若干高めである。これは、対象である djbdns

と Wu-FTPD のセキュリティポリシー定義が標準では用意されていないことが原因だろう。

アプリケーションのセキュリティポリシーを新規に作成することが非常に大変であること

を示す結果であると判断できる。特に、アプリケーション固有の role を定義するようなケー

スでは、アプリケーションへの権限付与を最低限にするためのセキュリティポリシー定義

に加えて、アプリケーションの運用・管理形態を考慮したセキュリティポリシー定義方針

を決定する必要があり、アプリケーションの取り得る運用形態が多岐であるほど複雑さが

増すものである。

Web サーバーと SMTP サーバーの作業工数の高さは、DNS サーバーや FTP サーバーのそれ

とは意味が違うものである。WebサーバーやSMTPサーバーはあらかじめ標準のセキュリティ

ポリシー定義が用意されているため、多くの場合、新規にセキュリティポリシーを定義し

直すことはないだろう。その代わり、既に用意されているセキュリティポリシーを理解す

る作業が課せられる。セキュリティポリシー定義ファイルを眺めているだけでは判らない

定義も少なくなく、この場合には実際にアプリケーションを稼動させながら確認する作業

を行わなければならない。特に SMTP サーバーは多くのセキュリティポリシー定義ファイル

に分割されているため、全体を見通す作業は簡単ではない。

ガイドラインを参照して構築を行った場合は、いずれの作業者においても一様に作業工

数が削減されている。SELinux の学習に必要な工数やセキュリティポリシーの定義書式の理

解に必要な工数の削減もみられるが、やはり一番大きく削減されている箇所はセキュリ





ティポリシー定義にかかる工数である。SELinux でセキュリティポリシーを定義する際に最

も時間がかかる作業は、実際のところ対象アプリケーションの仕様・挙動を把握する作業

である。3.5 でのセキュリティポリシーの解説を読んでもらえれば判るとおり、セキュリ

ティポリシー定義の 1 つ 1 つが当該アプリケーションのまさに仕様・挙動と密接な関係を

持っている。自ら新たなセキュリティポリシーを定義する際にはもちろんだが、標準で用

意されているセキュリティポリシー定義を理解する際にもアプリケーションの仕様・挙動

に関する知識が要求されるのである。ここで要求されるのは表面的な知識には留まらない。

そのアプリケーションはどのようなプログラムで構成されているのか、それらのプログラ

ムは互いにどのように連携しあって稼動するのか、それらのプログラムは起動時、稼動中、

あるいは停止時にどのようなリソースにアクセスするのか、そしてそのアクセスはどのよ

うな形態なのか、といった非常に深い知識が要求されるのである。このような仕様・挙動

を調査・把握することは簡単なことではない。しかし逆にいえば、本ガイドラインのよう

なセキュリティポリシー定義の詳細な解説書があれば、セキュリティポリシー定義で要求

される多くの工数は一気に削減されるのである。なぜなら、セキュリティポリシー定義の

多くはアプリケーションの内部仕様に絡んだ部分であり、サーバーの設置環境に依存する

部分、つまりシステム構築者が適宜カスタマイズしなければならない部分はそれ程多くは

ないからである。

5.4.3. 設定ミス・設定漏れ

評価分析作業において、作業対象者にみられた設定ミス・設定漏れの多くは SELinux の

基本部分を十分に押さえていないことに起因するものである。セキュリティポリシー定義

において設定ミス・設定漏れを防ぐためには、対象アプリケーションの仕様を十分に理解

することが重要だが、その前に、以下に挙げる SELinux の基本を押さえることはもっと重

要なことである。

a) セキュリティアーキテクチャ

b) セキュリティポリシー定義書式

c) 属性・マクロ

なかでも c)は重要である。特定のアプリケーションに固有なものから、アプリケーショ

ン間で汎用的に使用可能なものまで、標準で多くの属性・マクロが定義されている。それ

らの属性・マクロにおいて定義されるセキュリティポリシーをきちんと理解して使いこな

すスキルを身に付けなければならない。また、これらの属性・マクロを解析することで、

構築者の意識は SELinux のセキュリティポリシー定義に慣れていくだろう。セキュリティ

ポリシー定義への慣れも重要である。





以下では、5.3.3 で挙げた設定ミス・設定漏れの各項目に関する見解を述べる。

セキュリティコンテキストのファイルへのアタッチミス

標準でセキュリティポリシーが用意されているとそれだけで安心するのだろうか。

既存の定義の見直しが甘いという印象を受けた。繰り返すが、SELinux に標準で用意

されているファイルコンテキストの定義は、Red Hat Linux 環境においてはファイル

パスの相違が生じるケースが少なくない。アプリケーションの設定ファイル等に関す

るパスは意識的に確認しているようであるが、PID ファイル等のパスを確認していな

いケースが目立ったのも気になった点である。PID ファイルの出力先が標準セキュリ

ティポリシーの想定と異なることは十分考えられるため、これらはきちんと確認しな

ければならない。このあたりの設定ミス・設定漏れは作業者の意識の低さに起因して

いると言える。

role に関連した設定ミス

role を適切に定義できないケースに関しては、結論から言えばマクロを十分に理解

できていないことに起因している。

単純に新たな role を定義し、特定のユーザに割り当てることは簡単なことである。

問題は以下に挙げる項目を実現する方法だろう。

• コマンド newrole により、新たに定義した role への遷移を可能とする

• 新たに定義した role をログイン時に選択可能とする

これらを実現するためには、適切なセキュリティポリシーを追加定義しなければな

らない。しかし、上記の要件を満たす role を作成するマクロが用意されている。特に

理由がない限りそのマクロを利用すれば良いのである。SELinux であらかじめ用意さ

れているマクロを熟知していればこのような role を追加する際に戸惑うこともない

筈である。

run_init での initrc スクリプトの起動

initrc スクリプトをコマンドラインから実行する際にコマンド run_init を利用し

なければならないことに関しては、SELinux で利用される独自コマンドをきちんと理

解しておくことで回避できる問題であると考える。





initrc スクリプトのセキュリティコンテキスト間違い

initrc スクリプトに誤ったセキュリティコンテキストがアタッチされてしまう件

に関しては、なかなか気付かない問題である。こういった問題を回避していくために

は、SELinux の出力するアクセス拒否のログを慎重に監査することが一番だろう。少

しでも気になる点があれば、標準のセキュリティポリシー定義を疑うことももちろん

必要である。

5.5. 結論

SELinux を用いてインターネットサーバーを構築するのであれば、大きくのしかかる作業

工数の問題を回避することは諦めた方が良いと考える。現状では、構築段階において以下

に挙げる面での作業工数が要求されるだろう。

• 対象アプリケーションの仕様調査

• 標準セキュリティポリシー定義の調査・解析・修正あるいは新規セキュリティポリ

シーの定義

これだけでは終わらない。アプリケーションの開発者でもない第三者が、はじめからそ

の仕様を十分に把握することなど不可能である。運用を開始した後も、セキュリティポリ

シー上の問題が明らかになっていくはずである。その度に管理者は適切な対応を取らなけ

ればならない。また、アプリケーションのバージョンアップによりその仕様が大きく変る

ことも考えられる。一度作成したセキュリティポリシーがいつまでも有効である保証もな

いのである。運用段階では以下に挙げる面での作業工数が要求されるだろう。

• ログの監査

• セキュリティポリシーの見直し

• アプリケーションバージョンアップ時の対応

ただし、5.4.2 でも述べたが、本ガイドラインのようにセキュリティポリシー定義を詳細

に解説したドキュメントが完備されれば、構築面での作業工数は大きく削減される余地が

あると言える。また、著名なディストリビューションに統合されることも望ましいことで

ある。ディストリビューションに取り込まれることがあれば、各アプリケーション開発者

自身の手によるセキュリティポリシー定義の提供が期待できるからである。そうなれば、

より安心して使用できるセキュリティポリシー定義を手にすることができる。





付録 A セキュリティポリシー定義ファイル

本文中で取り上げたセキュリティポリシー定義ファイルを以下に掲載する。

A-1 Web サーバー

リスト A-1 policy/file_contexts/program/apache.fc

1 # apache

2 /var/www/html(/.*)? system_u:object_r:httpd_sys_content_t

3 /var/www/mrtg(/.*)? system_u:object_r:httpd_sys_content_t

4 /var/www/error(/.*)? system_u:object_r:httpd_sys_content_t

5 /var/www/manual(/.*)? system_u:object_r:httpd_sys_content_t

6 /var/www/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_t

7 /usr/lib/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_t

8 /var/www/perl(/.*)? system_u:object_r:httpd_sys_script_t

9 /var/www/icons(/.*)? system_u:object_r:httpd_sys_content_t

10 /var/cache/httpd(/.*)? system_u:object_r:httpd_cache_t

11 /etc/httpd system_u:object_r:httpd_config_t

12 /etc/httpd/conf(/.*)? system_u:object_r:httpd_config_t

13 /etc/httpd/logs system_u:object_r:httpd_log_files_t

14 /etc/httpd/modules system_u:object_r:httpd_modules_t

15 /etc/apache(2)?(/.*)? system_u:object_r:httpd_config_t

16 /etc/vhosts system_u:object_r:httpd_config_t

17 /usr/lib/apache(/.*)? system_u:object_r:httpd_modules_t

18 /usr/lib/apache2/modules(/.*)? system_u:object_r:httpd_modules_t

19 /usr/lib/httpd/modules(/.*)? system_u:object_r:httpd_modules_t

20 /usr/sbin/httpd system_u:object_r:httpd_exec_t

21 /usr/sbin/apache(2)? system_u:object_r:httpd_exec_t

22 /usr/sbin/suexec system_u:object_r:httpd_suexec_exec_t

23 /usr/lib/cgi-bin/(nph-)?cgiwrap(d)? system_u:object_r:httpd_suexec_exec_t

24 /usr/lib/apache(2)?/suexec(2)? system_u:object_r:httpd_suexec_exec_t

25 /var/log/httpd(/.*)? system_u:object_r:httpd_log_files_t

26 /var/log/apache(2)?(/.*)? system_u:object_r:httpd_log_files_t

27 /var/log/cgiwrap.log.* system_u:object_r:httpd_log_files_t

28 /var/cache/ssl.*¥.sem system_u:object_r:httpd_cache_t

29 /var/run/apache(2)?.pid.* system_u:object_r:httpd_var_run_t

リスト A-2 policy/domains/program/apache.te

1 #DESC Apache - Web server

2 #

3 ###############################################################################





4 #

5 # Policy file for running the Apache web server

6 #

7 # NOTES:

8 # This policy will work with SUEXEC enabled as part of the Apache

9 # configuration. However, the user CGI scripts will run under the

10 # system_u:system_r:httpd_user_script_process_t domain.

11 #

12 # The user CGI scripts must be labeled with the httpd_user_script_t

13 # type, and the directory containing the scripts should also be labeled

14 # with these types. This policy allows user_r role to perform that

15 # relabeling. If it is desired that only sysadm_r should be able to relabel

16 # the user CGI scripts, then relabel rule for user_r should be removed.

17 #

18 ###############################################################################

19 type http_port_t, port_type;

20 type http_cache_port_t, port_type;

21

22 #########################################################

23 # Apache types

24 #########################################################

25 # httpd_config_t is the type given to the configuration

26 # files for apache /etc/httpd/conf

27 #

28 type httpd_config_t, file_type, sysadmfile;

29

30 # httpd_log_files_t is the type that is given to the log files

31 # that httpd generates. /var/log/httpd

32

33 type httpd_log_files_t, file_type, sysadmfile, logfile;

34

35 # httpd_modules_t is the type given to module files (libraries)

36 # that come with Apache /etc/httpd/modules and /usr/lib/apache

37 #

38 type httpd_modules_t, file_type, sysadmfile;

39

40 # httpd_cache_t is the type given to the /var/cache/httpd

41 # directory and the files under that directory

42 #

43 type httpd_cache_t, file_type, sysadmfile;

44

45 # httpd_exec_t is the type give to the httpd executable.

46 #

47 type httpd_exec_t, file_type, sysadmfile, exec_type;

48

49 # httpd_t is the type that httpd process runs as

50 #

51 type httpd_t, domain, privlog;

52 role system_r types httpd_t;

53 every_domain(httpd_t)

54 allow httpd_t console_device_t:chr_file { read write };

55 domain_auto_trans(initrc_t, httpd_exec_t, httpd_t)

56 type_transition init_t httpd_exec_t:process httpd_t;

57





58 # for php

59 tmp_domain(httpd)

60

61 #

62 # A type for files in /var/run specific to httpd

63 #

64 type httpd_var_run_t, file_type, sysadmfile, pidfile;

65

66 #

67 # A type for tmpfs file system

68 #

69 type httpd_tmpfs_t, file_type, sysadmfile;

70

71 #This type is for system webpages

72 #

73 type httpd_sys_content_t, file_type, sysadmfile;

74

75 #This type is for user webpages

76 #

77 type httpd_user_content_t, file_type, sysadmfile;

78

79 # This type is used for system .htaccess files

80 #

81 type httpd_sys_htaccess_t, file_type, sysadmfile;

82

83 #This type is used for user .htaccess files

84 #

85 type httpd_user_htaccess_t, file_type, sysadmfile;

86

87 # Type that system CGI scripts run as

88 #

89 type httpd_sys_script_process_t, domain;

90 role system_r types httpd_sys_script_process_t;

91 every_domain(httpd_sys_script_process_t)

92

93 # Type that user CGI scripts run as

94 #

95 type httpd_user_script_process_t, domain;

96 role system_r types httpd_user_script_process_t;

97 in_user_role(httpd_user_script_process_t)

98 every_domain(httpd_user_script_process_t)

99

100 # Types that system CGI scripts on the disk are

101 # labeled with

102 #

103 type httpd_sys_script_t, file_type, sysadmfile;

104

105 # Types that user CGI scripts on disk are

106 # labeled with

107 #

108 type httpd_user_script_t, file_type, sysadmfile;

109

110 # The following are the only areas that

111 # system scripts can read, read/write, or





112 # append to

113 #

114 type httpd_sys_script_r_t, file_type, sysadmfile;

115 type httpd_sys_script_rw_t, file_type, sysadmfile;

116 file_type_auto_trans(httpd_sys_script_process_t, tmp_t, httpd_sys_script_rw_t)

117 type httpd_sys_script_a_t, file_type, sysadmfile;

118

119 # The following are the only areas that

120 # user scripts can read, read/write, or

121 # append to

122 #

123 type httpd_user_script_r_t, file_type, sysadmfile;

124 type httpd_user_script_rw_t, file_type, sysadmfile;

125 file_type_auto_trans(httpd_user_script_process_t, tmp_t, httpd_user_script_rw_t)

126 type httpd_user_script_a_t, file_type, sysadmfile;

127

128 # The following are types for SUEXEC,which runs user scripts as their

129 # own user ID

130 #

131 type httpd_suexec_process_t, domain;

132 role system_r types httpd_suexec_process_t;

133 every_domain(httpd_suexec_process_t)

134 type httpd_suexec_exec_t, file_type, exec_type, sysadmfile;

135 #

136

137 #########################################################

138 # Permissions for running child processes and scripts

139 ##########################################################

140 domain_auto_trans(httpd_t, httpd_suexec_exec_t, httpd_suexec_process_t)

141 domain_auto_trans(httpd_suexec_process_t, httpd_user_script_t,

httpd_user_script_process_t)

142

143 allow httpd_suexec_process_t httpd_suexec_process_t:capability { setuid setgid };

144 allow httpd_suexec_process_t httpd_user_script_t:dir { search getattr };

145 allow httpd_suexec_process_t httpd_user_script_t:file { execute entrypoint };

146

147 allow httpd_suexec_process_t bin_t:file rx_file_perms;

148 allow httpd_suexec_process_t lib_t:file { execute };

149

150 allow httpd_suexec_process_t httpd_log_files_t:dir { search };

151 allow httpd_suexec_process_t httpd_log_files_t:file { append getattr };

152 allow httpd_suexec_process_t httpd_log_files_t:lnk_file { read };

153

154 allow httpd_suexec_process_t httpd_user_script_process_t:process { transition };

155

156 allow httpd_suexec_process_t httpd_t:fifo_file {getattr} ;

157 allow httpd_user_script_process_t httpd_t:fifo_file {getattr} ;

158

159 allow httpd_suexec_process_t httpd_var_run_t:file rw_file_perms;

160 allow httpd_suexec_process_t httpd_cache_t:file rw_file_perms;

161

162 # apache should set close-on-exec

163 dontaudit httpd_suexec_process_t httpd_t:unix_stream_socket { read write };

164 dontaudit { system_mail_t mta_user_agent } httpd_t:unix_stream_socket { read write };





165

166 #

167 # If a user starts a script by hand it gets the proper context

168 #

169 domain_auto_trans(user_t, httpd_user_script_t, httpd_user_script_process_t)

170

171 # When the server starts the script it needs to get the proper context

172 #

173 domain_auto_trans(httpd_t, httpd_user_script_t, httpd_user_script_process_t)

174 domain_auto_trans(httpd_t, httpd_sys_script_t, httpd_sys_script_process_t)

175

176 # If the httpd admin starts a script by hand it gets the proper context

177 #

178 domain_auto_trans(httpd_admin_t, httpd_sys_script_t, httpd_sys_script_process_t)

179 domain_auto_trans(httpd_admin_t, httpd_user_script_t, httpd_user_script_process_t)

180

181 #######################################################

182 # Allow the httpd admin to run stuff in the bin directory

183 #######################################################

184 can_exec(httpd_admin_t, bin_t)

185

186 #############################################################

187 # Allow the script access to the library files so it can run

188 #############################################################

189 can_exec(httpd_user_script_process_t, lib_t)

190 can_exec(httpd_sys_script_process_t, lib_t)

191

192 ##################################################################

193 # Allow the script to get the file descriptor from the http deamon

194 # and send sigchild to http deamon

195 #################################################################

196 allow httpd_user_script_process_t httpd_t:process {sigchld};

197 allow httpd_user_script_process_t httpd_t:fd use;

198 allow httpd_user_script_process_t httpd_t:fifo_file { write };

199

200 allow httpd_sys_script_process_t httpd_t:process {sigchld};

201 allow httpd_sys_script_process_t httpd_t:fd use;

202 allow httpd_sys_script_process_t httpd_t:fifo_file {getattr write};

203

204 ########################################################################

205 # The script needs to inherit the file descriptor and find the script it

206 # needs to run

207 ########################################################################

208 allow httpd_user_script_process_t initrc_t:fd {use};

209 allow httpd_user_script_process_t init_t:fd {use};

210

211 allow httpd_user_script_process_t random_device_t:chr_file r_file_perms;

212

213 allow httpd_sys_script_process_t initrc_t:fd {use};

214 allow httpd_sys_script_process_t init_t:fd {use};

215

216 allow httpd_sys_script_process_t random_device_t:chr_file r_file_perms;

217

218 #######################################################################





219 # Allow the script to return its output

220 ######################################################################

221

222 allow httpd_user_script_process_t httpd_var_run_t: file rw_file_perms;

223

224 allow httpd_user_script_process_t null_device_t: chr_file rw_file_perms;

225

226 allow httpd_user_script_process_t httpd_cache_t: file rw_file_perms;

227

228 allow httpd_sys_script_process_t httpd_var_run_t: file rw_file_perms;

229

230 allow httpd_sys_script_process_t null_device_t: chr_file rw_file_perms;

231

232 allow httpd_sys_script_process_t httpd_cache_t: file rw_file_perms;

233

234 ###########################################################################

235 # Allow the script interpreters to run the scripts. So

236 # the perl executable will be able to run a perl script

237 #########################################################################

238 can_exec(httpd_user_script_process_t, bin_t)

239 can_exec(httpd_sys_script_process_t, bin_t)

240

241 ############################################################################

242 # Allow the script process to search the cgi directory, and users directory

243 ##############################################################################

244 allow httpd_user_script_process_t httpd_user_script_t:dir {search add_name};

245 allow httpd_user_script_process_t home_root_t:dir { getattr search };

246 allow httpd_user_script_process_t user_home_dir_type:dir {getattr search};

247 allow httpd_user_script_process_t httpd_user_content_t:dir {search};

248 allow httpd_user_script_process_t httpd_sys_script_t:dir {search};

249

250 allow httpd_sys_script_process_t httpd_sys_script_t:dir {search add_name};

251 allow httpd_sys_script_process_t httpd_sys_content_t:dir {search};

252

253 #############################################################################

254 # Allow the scripts to read, read/write, append to the specified directories

255 # or files

256 ############################################################################

257 allow httpd_user_script_process_t httpd_user_script_r_t:file r_file_perms;

258 allow httpd_user_script_process_t httpd_user_script_r_t:dir r_dir_perms;

259

260 allow httpd_user_script_process_t httpd_user_script_rw_t:file rw_file_perms;

261 allow httpd_user_script_process_t httpd_user_script_rw_t:dir rw_dir_perms;

262

263 allow httpd_user_script_process_t httpd_user_script_a_t:file ra_file_perms;

264 allow httpd_user_script_process_t httpd_user_script_a_t:dir ra_dir_perms;

265

266

267 #################

268 # For system scripts

269 #####################

270 allow httpd_sys_script_process_t httpd_sys_script_r_t:file r_file_perms;

271 allow httpd_sys_script_process_t httpd_sys_script_r_t:dir r_dir_perms;

272





273 allow httpd_sys_script_process_t httpd_sys_script_rw_t:file create_file_perms;

274 allow httpd_sys_script_process_t httpd_sys_script_rw_t:dir create_dir_perms;

275 allow httpd_sys_script_rw_t fs_t:filesystem {associate};

276

277 allow httpd_sys_script_process_t httpd_sys_script_a_t:file ra_file_perms;

278 allow httpd_sys_script_process_t httpd_sys_script_a_t:dir ra_dir_perms;

279

280 #######################################

281 # Allow users to create or edit user web content

282 #########################################

283

284 allow user_t httpd_user_content_t:file create_file_perms;

285 allow user_t httpd_user_content_t:dir create_dir_perms;

286 allow user_t httpd_user_content_t:lnk_file {create};

287

288 #######################################################################

289 # Allow the users to edit or create user scripts

290 ####################################################################

291 allow user_t httpd_user_script_t:file create_file_perms;

292 allow user_t httpd_user_script_t:file {relabelto};

293 allow user_t httpd_user_script_t:dir create_dir_perms;

294 allow user_t httpd_user_script_t:lnk_file {create};

295

296 ######################################################################

297 # Allow the users to create htaccess files

298 #####################################################################

299

300 allow user_t httpd_user_htaccess_t:file create_file_perms;

301 allow user_t httpd_user_htaccess_t:lnk_file {create};

302

303 #########################################################################

304 # Allow users to create files or directories

305 # that scripts are able to read, write, or append to

306 ###########################################################################

307

308 allow user_t httpd_user_script_r_t:file create_file_perms;

309 allow user_t httpd_user_script_r_t:lnk_file {create};

310 allow user_t httpd_user_script_r_t:dir create_dir_perms;

311

312 allow user_t httpd_user_script_rw_t:file rw_file_perms;

313 allow user_t httpd_user_script_rw_t:lnk_file {create};

314 allow user_t httpd_user_script_rw_t:dir rw_dir_perms;

315

316 allow user_t httpd_user_script_a_t:file ra_file_perms;

317 allow user_t httpd_user_script_a_t:lnk_file {create};

318 allow user_t httpd_user_script_a_t:dir ra_dir_perms;

319 allow user_t httpd_user_content_t:dir {relabelto relabelfrom};

320 allow user_t httpd_user_content_t:file {relabelto};

321 allow user_t httpd_user_htaccess_t:file {relabelto};

322

323 allow httpd_sys_script_t fs_t:filesystem {associate};

324 allow httpd_sys_script_a_t fs_t:filesystem {associate};

325 allow httpd_sys_script_r_t fs_t:filesystem {associate};

326 allow httpd_sys_script_rw_t fs_t:filesystem {associate};





327

328 allow httpd_user_script_t fs_t:filesystem {associate};

329 allow httpd_user_script_a_t fs_t:filesystem {associate};

330 allow httpd_user_script_r_t fs_t:filesystem {associate};

331 allow httpd_user_script_rw_t fs_t:filesystem {associate};

332

333 allow httpd_sys_content_t fs_t:filesystem {associate};

334 allow httpd_sys_htaccess_t fs_t:filesystem {associate};

335 allow httpd_user_content_t fs_t:filesystem {associate};

336 allow httpd_user_htaccess_t fs_t:filesystem {associate};

337

338

339 ################################################################

340 # Allow the web server to run scripts and serve pages

341 ##############################################################

342 allow httpd_t httpd_sys_content_t:file r_file_perms;

343 allow httpd_t httpd_sys_content_t:dir r_dir_perms;

344

345 allow httpd_t httpd_sys_htaccess_t: file r_file_perms;

346

347 allow httpd_t bin_t:file { read execute }; # execute perl

348

349 allow httpd_t httpd_sys_script_t:file {execute getattr read};

350 allow httpd_t httpd_sys_script_process_t:process {signal sigkill sigstop};

351 allow httpd_t httpd_sys_script_process_t:process {transition};

352 allow httpd_t httpd_sys_script_t:dir r_dir_perms;

353 allow httpd_t httpd_sys_script_rw_t:dir r_dir_perms;

354 allow httpd_t httpd_sys_script_rw_t:file r_file_perms;

355

356 allow httpd_t httpd_user_content_t:file r_file_perms;

357 allow httpd_t httpd_user_content_t:dir r_dir_perms;

358

359 allow httpd_t httpd_user_htaccess_t: file r_file_perms;

360

361 allow httpd_t httpd_user_script_t:file {execute getattr read};

362 allow httpd_t httpd_user_script_process_t:process {signal sigkill sigstop};

363 allow httpd_t httpd_user_script_process_t:process {transition};

364 allow httpd_t httpd_user_script_t:dir r_dir_perms;

365

366 allow httpd_t httpd_user_script_rw_t:file r_file_perms;

367 allow httpd_t httpd_user_script_rw_t:dir r_dir_perms;

368

369 ###########################

370 # Allow httpd to receive messages from the network card

371 ########################################

372 #allow httpd_t netmsg_eth0_t:tcp_socket{acceptfrom};

373

374 ###################

375 # Allow httpd to search users diretories

376 ######################

377 allow httpd_t home_root_t:dir { getattr search };

378 allow httpd_t user_home_dir_type:dir { getattr search };

379 allow httpd_t user_home_type:dir { getattr search read };

380 # need ioctl for php3





381 allow httpd_t user_home_type:{ file lnk_file } { getattr read ioctl };

382 dontaudit httpd_t sysadm_home_dir_t:dir { getattr search };

383

384 ############################################################################

385 # Allow the httpd_t the capability to bind to a port and various other stuff

386 ############################################################################

387 allow httpd_t httpd_t:capability {chown net_bind_service setgid setuid kill

dac_override dac_read_search };

388

389 #################################################

390 # Allow the httpd_t to read the web servers config files

391 ###################################################

392 r_dir_file(httpd_t, httpd_config_t)

393 # allow logrotate to read the config files for restart

394 ifdef(`logrotate.te', `

395 r_dir_file(logrotate_t, httpd_config_t)

396 ')

397 r_dir_file(initrc_t, httpd_config_t)

398 ##################################################

399

400 ##################################################

401 # Allow the httpd_t to access the files under /var/log/httpd

402 ####################################################

403 allow httpd_t httpd_log_files_t:dir rw_dir_perms;

404 allow httpd_t httpd_log_files_t:file create_file_perms;

405 allow httpd_t httpd_log_files_t:lnk_file r_file_perms;

406

407 ############################################

408 # Allow scripts to append to http logs

409 #########################################

410 allow httpd_sys_script_process_t httpd_log_files_t:file {append};

411 allow httpd_user_script_process_t httpd_log_files_t:file {append};

412

413 #############################

414 # Allow httpd_t to get the file descriptor from init

415 #####################

416 allow httpd_t init_t:fd use;

417 #allow httpd_t init_t:process { sigchld };

418

419 ########################################

420 # Allow httpd_t access to the libraries

421 # that it needs

422 #########################################

423 can_exec(httpd_t, lib_t)

424

425 ########################################

426 # Allow access to /dev/null

427 ########################################

428 allow httpd_t null_device_t:chr_file rw_file_perms;

429

430 ########################################

431 # Allow httpd_t to bind to the HTTP port

432 ########################################

433 allow httpd_t { http_port_t http_cache_port_t }:tcp_socket name_bind;





434

435 ###############################

436 # Allow httpd_t to put a pid file

437 # in /var/run

438 ##############################

439 file_type_auto_trans(httpd_t, var_run_t, httpd_var_run_t)

440

441 ###############################

442 # Allow httpd_t to put files in /var/cache

443 ##############################

444 file_type_auto_trans(httpd_t, var_t, httpd_cache_t)

445

446 ###############################

447 # Allow httpd_t to access the tmpfs file system

448 ##############################

449 file_type_auto_trans(httpd_t, tmpfs_t, httpd_tmpfs_t)

450 allow httpd_tmpfs_t tmpfs_t:filesystem associate;

451

452 #####################

453 # Allow httpd_t to access

454 # libraries for its modules

455 ###############################

456 can_exec(httpd_t, httpd_modules_t)

457 allow httpd_t httpd_modules_t:dir r_dir_perms;

458 allow httpd_t httpd_modules_t:lnk_file r_file_perms;

459

460 ######################################################################

461 # Allow initrc_t to access the Apache modules directory.

462 ######################################################################

463 allow initrc_t httpd_modules_t:dir r_dir_perms;

464 allow initrc_t httpd_user_script_rw_t:dir r_dir_perms;

465

466 ##############################################

467 # Allow httpd_t to have access to files

468 # such as nisswitch.conf

469 ###############################################

470 allow httpd_t etc_t:file { read getattr };

471

472 # Several options for handling SSI exec cmd elements:

473 # Option #1: Don't support them at all. This is the default, since

474 # httpd_t is not permitted to execute shell_exec_t.

475 # Option #2: Run SSI exec's in the same domain as system CGI scripts.

476 # Uncomment the following line to enable:

477 #domain_auto_trans(httpd_t, shell_exec_t, httpd_sys_script_process_t)

478 # Option #3: Run SSI exec's directly in the httpd_t domain. This means

479 # that they have the same permissions as the daemon. Probably not a good idea.

480 # Uncomment the following line to enable:

481 #can_exec(httpd_t, shell_exec_t)





リスト A-3 policy/domains/httpadm.te

1 ########################################

2 # httpd_admin domain macro and rules for

3 # httpd_admin_t

4 ########################################

5

6 include(user_macros.te)

7

8 define(`httpd_admin_domain',`

9

10 ################################

11 # Allow httpd_admin_t to do everything user_t can do

12 #################################

13

14 user_domain($1)

15

16 ######################################

17 # Allow httpd_admin_t to edit the server config files

18 ######################################

19 allow $1_t httpd_config_t:file create_file_perms;

20 allow $1_t httpd_config_t:dir rw_dir_perms;

21 allow $1_t httpd_config_t:lnk_file link_file_perms;

22 allow $1_t httpd_config_t:security { sid_to_context };

23

24 ######################################################

25 # Allow the httpd_admin_t to view or edit the web server log files

26 #######################################################

27 allow $1_t httpd_log_files_t:file create_file_perms;

28 allow $1_t httpd_log_files_t:dir rw_dir_perms ;

29 allow $1_t httpd_log_files_t:security { sid_to_context };

30 allow $1_t httpd_log_files_t:lnk_file link_file_perms;

31

32 ##################################################

33 # Allow the httpd_admin_t to view files in /etc/httpd/modules

34 # directory. This is where the module libraries for

35 # Apache are kept

36 ##################################################

37 allow $1_t httpd_modules_t:dir r_dir_perms;

38 allow $1_t httpd_modules_t:file r_file_perms;

39

40 ####################################################

41 # Allow the httpd_admin_t to do the following to httpd

42 # executable and process if you want the httpd admin role to run the binary

43 #######################################################

44 #allow $1_t httpd_exec_t:file rx_file_perms;

45 #allow $1_t httpd_t:security { sid_to_context };

46 #allow $1_t httpd_t:process{ sigkill sigstop signal transition};

47

48 ###########################################################################

49 # Allow the httpd admin to edit or create content, scripts, and

50 # htaccess files

51 ##########################################################################





52 allow $1_t httpd_sys_content_t:file create_file_perms;

53 allow $1_t httpd_user_content_t:file create_file_perms;

54 allow $1_t httpd_sys_content_t:dir rw_dir_perms;

55 allow $1_t httpd_user_content_t:dir rw_dir_perms;

56 allow $1_t httpd_sys_content_t:lnk_file {create};

57 allow $1_t httpd_user_content_t:lnk_file {create};

58

59 allow $1_t httpd_sys_script_t:file create_file_perms;

60 allow $1_t httpd_sys_script_t:dir create_dir_perms;

61 allow $1_t httpd_sys_script_t:lnk_file {create};

62

63 allow $1_t httpd_sys_htaccess_t:file create_file_perms;

64 allow $1_t httpd_sys_htaccess_t:lnk_file {create};

65

66 allow $1_t httpd_sys_script_r_t:file create_file_perms;

67 allow $1_t httpd_sys_script_r_t:lnk_file {create};

68 allow $1_t httpd_sys_script_r_t:dir create_dir_perms;

69

70 allow $1_t httpd_user_script_r_t:file create_file_perms;

71 allow $1_t httpd_user_script_r_t:lnk_file {create};

72 allow $1_t httpd_user_script_r_t:dir create_dir_perms;

73

74 allow $1_t httpd_sys_script_rw_t:file rw_file_perms;

75 allow $1_t httpd_sys_script_rw_t:lnk_file {create};

76 allow $1_t httpd_sys_script_rw_t:dir rw_dir_perms;

77

78 allow $1_t httpd_user_script_rw_t:file rw_file_perms;

79 allow $1_t httpd_user_script_rw_t:lnk_file {create};

80 allow $1_t httpd_user_script_rw_t:dir rw_dir_perms;

81

82 allow $1_t httpd_sys_script_a_t:file ra_file_perms;

83 allow $1_t httpd_sys_script_a_t:lnk_file {create};

84 allow $1_t httpd_sys_script_a_t:dir ra_dir_perms;

85

86 allow $1_t httpd_user_script_a_t:file ra_file_perms;

87 allow $1_t httpd_user_script_a_t:lnk_file {create};

88 allow $1_t httpd_user_script_a_t:dir ra_dir_perms;

89

90 ####################################

91 # Allow a domain change to httpd_admin_t via the newrole command

92 #####################################

93 allow $1_t newrole_t:fd use;

94 allow $1_t newrole_t:process {sigchld};

95 can_exec($1_t, shell_exec_t)

96 allow $1_t shell_exec_t:file {entrypoint};

97 allow newrole_t $1_t:process {transition};

98

99 #############################################################################

100 # Allow the httpd admin to use chcon to change contexts on scripts, web pages,

101 # and htaccess files.

102 ###########################################################################

103 allow $1_t httpd_sys_script_t:dir {relabelto};

104 allow $1_t httpd_sys_script_a_t:dir {relabelto};

105 allow $1_t httpd_sys_script_r_t:dir {relabelto};





106 allow $1_t httpd_sys_script_rw_t:dir {relabelto};

107

108 allow $1_t httpd_user_script_t:dir {relabelto};

109 allow $1_t httpd_user_script_a_t:dir {relabelto};

110 allow $1_t httpd_user_script_r_t:dir {relabelto};

111 allow $1_t httpd_user_script_rw_t:dir {relabelto};

112

113 allow $1_t httpd_sys_script_a_t:file {relabelto};

114 allow $1_t httpd_sys_script_r_t:file {relabelto};

115 allow $1_t httpd_sys_script_rw_t:file {relabelto};

116

117 allow $1_t httpd_user_script_r_t:file {relabelto};

118 allow $1_t httpd_user_script_rw_t:file {relabelto};

119 allow $1_t httpd_user_script_a_t:file {relabelto};

120

121 allow $1_t httpd_sys_content_t:dir {relabelto};

122 allow $1_t httpd_user_content_t:dir {relabelto};

123

124 allow $1_t httpd_sys_content_t:file {relabelto};

125 allow $1_t httpd_sys_htaccess_t:file {relabelto};

126 allow $1_t httpd_user_content_t:file {relabelto};

127 allow $1_t httpd_user_htaccess_t:file {relabelto};

128

129 ')

130

131

132 # httpd_admin_t has access to all of the httpd files, such as

133 # the configuration files and the log files. They also

134 # have access to system content and/or user content

135 #

136 type httpd_admin_t, domain;

137 role httpd_admin_r types httpd_admin_t;

138 every_domain(httpd_admin_t)

139

140 httpd_admin_domain(httpd_admin)





A-2 DNS サーバー

リスト A-4 policy/file_contexts/program/named.fc

1 # named

2 /etc/named.conf system_u:object_r:named_conf_t

3 /var/named(/.*)? system_u:object_r:named_zone_t

4 /etc/bind(/.*)? system_u:object_r:named_zone_t

5 /etc/bind/named.conf system_u:object_r:named_conf_t

6 /etc/bind/rndc.key system_u:object_r:rndc_conf_t

7 /etc/rndc.* system_u:object_r:rndc_conf_t

8 /usr/sbin/named.* system_u:object_r:named_exec_t

9 /usr/sbin/r?ndc system_u:object_r:ndc_exec_t

10 /var/cache/bind(/.*)? system_u:object_r:named_cache_t

11 #/var/named(/.*)? system_u:object_r:named_cache_t

12 /var/run/ndc system_u:object_r:var_run_named_t

13 /var/run/bind(/.*)? system_u:object_r:var_run_named_t

14 /var/run/named(/.*)? system_u:object_r:var_run_named_t

15 /usr/sbin/lwresd system_u:object_r:named_exec_t

リスト A-5 policy/domains/program/named.te

1 #DESC BIND - Name server

2 #

3 # Authors: Yuichi Nakamura

4 # Russell Coker

5 #

6

7 #################################

8 #

9 # Rules for the named_t domain.

10 #

11 type named_port_t, port_type;

12 type rndc_port_t, port_type;

13

14 daemon_domain(named)

15 # ndc_t is the domain for the ndc program

16 type ndc_t, domain, privlog;

17 role sysadm_r types ndc_t;

18

19 can_exec(named_t, named_exec_t)

20 allow named_t sbin_t:dir search;

21

22 allow named_t self:process setsched;

23





24 # A type for configuration files of named.

25 type named_conf_t, file_type, sysadmfile;

26 type rndc_conf_t, file_type, sysadmfile;

27

28 # for primary zone files

29 type named_zone_t, file_type, sysadmfile;

30

31 # for secondary zone files

32 type named_cache_t, file_type, sysadmfile;

33

34 # Use capabilities. Surplus capabilities may be allowed.

35 allow named_t named_t:capability { setuid setgid net_bind_service chown fowner

dac_override sys_nice };

36

37 allow named_t etc_t:{ file lnk_file } { getattr read };

38 allow named_t etc_runtime_t:{ file lnk_file } { getattr read };

39 allow named_t resolv_conf_t:file { getattr read };

40

41 #Named can use network

42 can_network(named_t)

43 # allow UDP transfer to/from any program

44 can_udp_send(domain, named_t)

45 can_udp_send(named_t, domain)

46 can_tcp_connect(domain, named_t)

47

48 # Bind to the named port.

49 allow named_t named_port_t:udp_socket name_bind;

50 allow named_t { named_port_t rndc_port_t }:tcp_socket name_bind;

51

52 #read configuration files

53 r_dir_file(named_t, named_conf_t)

54

55 #read zone files - change this to rw_dir_create_file() to

56 # enable domain auto updates.

57 r_dir_file(named_t, named_zone_t)

58

59 #write cache for secondary zones

60 rw_dir_create_file(named_t, named_cache_t)

61

62 allow named_t self:unix_stream_socket create_stream_socket_perms;

63 allow named_t self:unix_dgram_socket create_socket_perms;

64

65 # Read sysctl kernel variables.

66 allow named_t sysctl_t:dir r_dir_perms;

67 allow named_t sysctl_kernel_t:dir r_dir_perms;

68 allow named_t sysctl_kernel_t:file r_file_perms;

69

70 # Read /proc/cpuinfo.

71 allow named_t proc_t:dir r_dir_perms;

72 allow named_t proc_t:file r_file_perms;

73

74 # Read /dev/random.

75 allow named_t device_t:dir r_dir_perms;

76 allow named_t random_device_t:chr_file r_file_perms;





77

78 # Use a pipe created by self.

79 allow named_t self:fifo_file rw_file_perms;

80

81 # Set own capabilities.

82 allow named_t self:process setcap;

83

84 #A type for /usr/sbin/ndc

85 type ndc_exec_t, file_type,sysadmfile, exec_type;

86 domain_auto_trans(sysadm_t, ndc_exec_t, ndc_t)

87 uses_shlib(ndc_t)

88 can_network(ndc_t)

89 can_tcp_connect(ndc_t, named_t)

90 allow { named_t ndc_t initrc_t } rndc_conf_t:file { getattr read };

91

92 allow ndc_t etc_t:dir r_dir_perms;

93 allow ndc_t self:unix_stream_socket create_stream_socket_perms;

94 allow ndc_t self:unix_stream_socket connect;

95 allow ndc_t self:capability dac_override;

96 allow ndc_t var_run_named_t:sock_file rw_file_perms;

97 allow ndc_t named_t:unix_stream_socket connectto;

98 allow ndc_t privfd:fd use;

99 # seems to need read as well for some reason

100 allow ndc_t admin_tty_type:chr_file { getattr read write };

101 allow ndc_t fs_t:filesystem getattr;

102

103 # Read sysctl kernel variables.

104 allow ndc_t sysctl_t:dir r_dir_perms;

105 allow ndc_t sysctl_kernel_t:dir r_dir_perms;

106 allow ndc_t sysctl_kernel_t:file r_file_perms;

107

108 allow ndc_t self:process { fork signal_perms };

109 allow ndc_t self:fifo_file { read write getattr ioctl };

110 allow ndc_t named_zone_t:dir search;

111

112 # for chmod in start script

113 dontaudit initrc_t var_run_named_t:dir setattr;

114

115 # for ndc_t to be used for restart shell scripts

116 ifdef(`ndc_shell_script', `

117 allow ndc_t crond_t:fd use;

118 allow ndc_t crond_t:fifo_file { read write ioctl };

119 allow ndc_t crond_t:process sigchld;

120 allow ndc_t devtty_t:chr_file { read write ioctl };

121 allow ndc_t etc_runtime_t:file { getattr read };

122 allow ndc_t proc_t:dir search;

123 allow ndc_t proc_t:file { getattr read };

124 can_exec(ndc_t, { bin_t sbin_t shell_exec_t })

125 allow ndc_t var_run_named_t:file getattr;

126 allow ndc_t named_zone_t:dir { read getattr };

127 allow ndc_t named_zone_t:file getattr;

128 dontaudit ndc_t sysadm_home_t:dir { getattr search read };

129 ')





リスト A-6 policy/file_contexts/program/djbdns.fc

1 # djbdns

2 /etc/dnsroots.global system_u:object_r:djbdns_etc_t

3

4 /usr/local/bin/axfr-get system_u:object_r:djbdns_exec_t

5 /usr/local/bin/axfrdns.* system_u:object_r:djbdns_exec_t

6 /usr/local/bin/dnscache.* system_u:object_r:djbdns_exec_t

7 /usr/local/bin/dnsfilter system_u:object_r:djbdns_exec_t

8 /usr/local/bin/dnsip system_u:object_r:djbdns_exec_t

9 /usr/local/bin/dnsipq system_u:object_r:djbdns_exec_t

10 /usr/local/bin/dnsmx system_u:object_r:djbdns_exec_t

11 /usr/local/bin/dnsname system_u:object_r:djbdns_exec_t

12 /usr/local/bin/dnsq system_u:object_r:djbdns_exec_t

13 /usr/local/bin/dnsqr system_u:object_r:djbdns_exec_t

14 /usr/local/bin/dnstrace system_u:object_r:djbdns_exec_t

15 /usr/local/bin/dnstracesort system_u:object_r:djbdns_exec_t

16 /usr/local/bin/dnstxt system_u:object_r:djbdns_exec_t

17 /usr/local/bin/pickdns.* system_u:object_r:djbdns_exec_t

18 /usr/local/bin/random-ip system_u:object_r:djbdns_exec_t

19 /usr/local/bin/rbldns.* system_u:object_r:djbdns_exec_t

20 /usr/local/bin/tinydns.* system_u:object_r:djbdns_exec_t

21 /usr/local/bin/walldns.* system_u:object_r:djbdns_exec_t

22

23 /var/dnscache system_u:object_r:djbdns_var_t

24 /var/dnscache/env(/.*)? system_u:object_r:djbdns_var_env_t

25 /var/dnscache/log(/.*)? system_u:object_r:djbdns_var_log_t

26 /var/dnscache/root(/.*)? system_u:object_r:djbdns_var_root_t

27 /var/dnscache/seed system_u:object_r:djbdns_var_seed_t

28 /var/dnscache/supervise(/.*)? system_u:object_r:djbdns_var_supervise_t

29 /var/dnscache/run system_u:object_r:djbdns_exec_t

30 /var/dnscache/log/run system_u:object_r:djbdns_exec_t

31

32

33 /var/dnscachex system_u:object_r:djbdns_var_t

34 /var/dnscachex/env(/.*)? system_u:object_r:djbdns_var_env_t

35 /var/dnscachex/log(/.*)? system_u:object_r:djbdns_var_log_t

36 /var/dnscachex/root(/.*)? system_u:object_r:djbdns_var_root_t

37 /var/dnscachex/seed system_u:object_r:djbdns_var_seed_t

38 /var/dnscachex/supervise(/.*)? system_u:object_r:djbdns_var_supervise_t

39 /var/dnscachex/run system_u:object_r:djbdns_exec_t

40 /var/dnscachex/log/run system_u:object_r:djbdns_exec_t

41

42 /var/tinydns system_u:object_r:djbdns_var_t

43 /var/tinydns/env(/.*)? system_u:object_r:djbdns_var_env_t

44 /var/tinydns/log(/.*)? system_u:object_r:djbdns_var_log_t

45 /var/tinydns/root(/.*)? system_u:object_r:djbdns_var_root_t

46 /var/tinydns/root/add-alias system_u:object_r:djbdns_exec_t

47 /var/tinydns/root/add-childns system_u:object_r:djbdns_exec_t

48 /var/tinydns/root/add-host system_u:object_r:djbdns_exec_t





49 /var/tinydns/root/add-mx system_u:object_r:djbdns_exec_t

50 /var/tinydns/root/add-ns system_u:object_r:djbdns_exec_t

51 /var/tinydns/seed system_u:object_r:djbdns_var_seed_t

52 /var/tinydns/supervise(/.*)? system_u:object_r:djbdns_var_supervise_t

53 /var/tinydns/run system_u:object_r:djbdns_exec_t

54 /var/tinydns/log/run system_u:object_r:djbdns_exec_t

55

56 /var/axfrdns system_u:object_r:djbdns_var_t

57 /var/axfrdns/Makefile system_u:object_r:djbdns_var_t

58 /var/axfrdns/env(/.*)? system_u:object_r:djbdns_var_env_t

59 /var/axfrdns/log(/.*)? system_u:object_r:djbdns_var_log_t

60 /var/axfrdns/tcp.* system_u:object_r:djbdns_var_tcp_t

61 /var/axfrdns/supervise(/.*)? system_u:object_r:djbdns_var_supervise_t

62 /var/axfrdns/run system_u:object_r:djbdns_exec_t

63 /var/axfrdns/log/run system_u:object_r:djbdns_exec_t

リスト A-7 policy/domains/program/djbdns.te

1 # djbdns

2 ifdef(`named.te',`',`

3 type named_port_t, port_type;

4 ')

5

6 type djbdns_t, domain, privlog;

7 role system_r types djbdns_t;

8 role sysadm_r types djbdns_t;

9 type djbdns_exec_t, file_type, sysadmfile, exec_type;

10

11 every_domain(djbdns_t)

12

13 type djbdns_etc_t, file_type, sysadmfile;

14 type djbdns_var_env_t, file_type, sysadmfile;

15 type djbdns_var_log_t, file_type, sysadmfile;

16 type djbdns_var_root_t, file_type, sysadmfile;

17 type djbdns_var_run_t, file_type, sysadmfile;

18 type djbdns_var_seed_t, file_type, sysadmfile;

19 type djbdns_var_t, file_type, sysadmfile;

20 type djbdns_var_supervise_t, file_type, sysadmfile;

21 type djbdns_var_tcp_t, file_type, sysadmfile;

22

23 domain_auto_trans(sysadm_t, djbdns_exec_t, djbdns_t)

24 domain_auto_trans(daemontools_t, djbdns_exec_t, djbdns_t)

25 can_exec(djbdns_t, { bin_t daemontools_exec_t shell_exec_t djbdns_exec_t } )

26

27 allow djbdns_t djbdns_t:capability { setgid setuid net_bind_service sys_chroot };

28 allow djbdns_t named_port_t:udp_socket { name_bind };

29 allow djbdns_t named_port_t:tcp_socket { name_bind };

30

31 allow djbdns_t daemontools_exec_t:dir { search };

32 allow djbdns_t djbdns_var_env_t:dir r_dir_perms;





33 allow djbdns_t djbdns_var_env_t:file r_file_perms;

34 allow djbdns_t djbdns_var_log_t:dir create_dir_perms;

35 allow djbdns_t djbdns_var_log_t:file create_file_perms;

36 allow djbdns_t djbdns_var_root_t:dir create_dir_perms;

37 allow djbdns_t djbdns_var_root_t:file create_file_perms;

38 allow djbdns_t djbdns_var_seed_t:file r_file_perms;

39 allow djbdns_t djbdns_var_t:dir r_dir_perms;

40 allow djbdns_t null_device_t:chr_file { read };

41 allow djbdns_t djbdns_var_tcp_t:file r_file_perms;

リスト A-8 policy/file_contexts/program/daemontools.fc

1 # daemontools

2 /command system_u:object_r:bin_t

3 /command/(.*)? system_u:object_r:daemontools_exec_t

4 /service(/.*)? system_u:object_r:daemontools_serv_t

5 /package(/.*)? system_u:object_r:src_t

6 /package/admin/daemontools.*/command(/.*)? system_u:object_r:daemontools_exec_t

リスト A-9 policy/domains/program/daemontools.te

1 # daemontools

2 type daemontools_t, domain, privlog;

3 role system_r types daemontools_t;

4 every_domain(daemontools_t)

5

6 type daemontools_exec_t, file_type, sysadmfile, exec_type;

7 type daemontools_serv_t, file_type, sysadmfile;

8

9 domain_auto_trans(init_t, daemontools_exec_t, daemontools_t)

10 allow init_t daemontools_exec_t:dir { search };

11

12 can_exec(daemontools_t, { daemontools_exec_t bin_t shell_exec_t })

13

14 allow daemontools_t daemontools_exec_t:dir r_dir_perms;

15 allow daemontools_t daemontools_serv_t:dir r_dir_perms;

16

17 allow daemontools_t daemontools_serv_t:lnk_file r_file_perms;

18

19 # for djbdns

20 allow daemontools_t djbdns_var_log_t:dir create_dir_perms;

21 allow daemontools_t djbdns_var_log_t:file create_file_perms;

22 allow daemontools_t djbdns_var_log_t:fifo_file rw_file_perms;

23 allow daemontools_t djbdns_var_supervise_t:dir create_dir_perms;

24 allow daemontools_t djbdns_var_supervise_t:fifo_file create_file_perms;





25 allow daemontools_t djbdns_var_supervise_t:file create_file_perms;

26 allow daemontools_t djbdns_var_t:dir r_dir_perms;





A-3 SMTP サーバー

リスト A-10 file_contexts/program/sendmail.fc

1 # sendmail

2 /etc/mail(/.*)? system_u:object_r:etc_mail_t

3 /var/spool/mqueue(/.*)? system_u:object_r:mqueue_spool_t

4 /var/log/sendmail.st system_u:object_r:sendmail_var_log_t

5

6 # For sending mail from local.

7 /var/spool/clientmqueue(/.*)? system_u:object_r:clientmqueue_spool_t

リスト A-11 file_contexts/program/smclient.fc

1 # sendmail

2 # For sending mail from local.

3 /var/spool/clientmqueue(/.*)? system_u:object_r:clientmqueue_spool_t

リスト A-12 macros/program/sendmail_macros.te

1 #

2 # Macros for sendmail domains.

3 #

4

5 #

6 # Authors: Stephen Smalley <[email protected]> (NAI Labs) and Timothy Fraser

7 # Russell Coker <[email protected]>

8 #

9

10 #

11 # sendmail_user_domain(domain_prefix)

12 #

13 # Define a derived domain for the sendmail program when executed by

14 # a user domain to send outgoing mail. These domains are separate and

15 # independent of the domain used for the sendmail daemon process.

16 #

17 undefine(`sendmail_user_domain')

18 define(`sendmail_user_domain', `

19

20 # Use capabilities

21 allow $1_mail_t self:capability net_bind_service;





22

23 # Type for temporary files.

24 type $1_mail_tmp_t, file_type, sysadmfile, tmpfile;

25 # Use this type when creating files in /tmp.

26 file_type_auto_trans($1_mail_t, tmp_t, $1_mail_tmp_t)

27

28 # Update /etc/mail/statistics.

29 allow $1_mail_t etc_mail_t:file rw_file_perms;

30

31 # Write to /var/spool/mail and /var/spool/mqueue.

32 allow $1_mail_t mail_spool_t:dir rw_dir_perms;

33 allow $1_mail_t mail_spool_t:file create_file_perms;

34 allow $1_mail_t mqueue_spool_t:dir rw_dir_perms;

35 allow $1_mail_t mqueue_spool_t:file create_file_perms;

36

37 # Write to /var/log/sendmail.st

38 file_type_auto_trans($1_mail_t, var_log_t, sendmail_var_log_t)

39

40 ')

リスト A-13 domains/program/sendmail.te

1 #DESC sendmail mail server

2 #

3 # Authors: Stephen Smalley <[email protected]> and Timothy Fraser <[email protected]>

(NAI Labs)

4 #

5

6 #################################

7 #

8 # Rules for the sendmail_t domain.

9 #

10 # sendmail_t is the domain for the sendmail

11 # daemon started by the init rc scripts.

12 #

13 # depends on mta.te

14 #

15 type sendmail_t, domain, privlog, mta_delivery_agent;

16 role system_r types sendmail_t;

17 every_domain(sendmail_t)

18

19 type sendmail_tmp_t, file_type, sysadmfile, tmpfile;

20 file_type_auto_trans(sendmail_t, tmp_t, sendmail_tmp_t)

21 type sendmail_var_log_t, file_type, sysadmfile, logfile;

22 file_type_auto_trans(sendmail_t, var_log_t, sendmail_var_log_t)

23 type sendmail_var_run_t, file_type, sysadmfile, pidfile;

24 file_type_auto_trans(sendmail_t, var_run_t, sendmail_var_run_t)

25


27 allow sendmail_t sendmail_t:capability { setuid setgid net_bind_service sys_nice chown };





28

29 # Inherit and use descriptors from init.

30 allow sendmail_t init_t:fd use;

31

32 # Use the network.

33 can_network(sendmail_t)

34

35 # Bind to the SMTP port.

36 allow sendmail_t smtp_port_t:tcp_socket name_bind;

37

38 # Write to /etc/aliases and /etc/mail.

39 allow sendmail_t etc_aliases_t:file { setattr rw_file_perms };

40 allow sendmail_t etc_mail_t:dir rw_dir_perms;

41 allow sendmail_t etc_mail_t:file create_file_perms;

42

43 # Write to /var/spool/mail and /var/spool/mqueue.

44 allow sendmail_t mail_spool_t:dir rw_dir_perms;

45 allow sendmail_t mail_spool_t:file create_file_perms;

46 allow sendmail_t mqueue_spool_t:dir rw_dir_perms;

47 allow sendmail_t mqueue_spool_t:file create_file_perms;

48

49 # /usr/sbin/sendmail asks for w access to utmp, but it will operate

50 # correctly without it. Do not audit write denials to utmp.

51 dontaudit sendmail_t initrc_var_run_t:file { read write };

52

53 # When sendmail runs as user_mail_domain, it needs some extra permissions.

54 allow user_mail_domain etc_mail_t:file rw_file_perms;

55

56 # Silently deny attempts to access /root.

57 dontaudit sendmail_t sysadm_home_dir_t:dir { getattr search };

58 dontaudit system_mail_t sysadm_home_dir_t:dir { getattr search };

59

60 # Run procmail in its own domain, if defined.

61 ifdef(`procmail.te',`

62 domain_auto_trans(sendmail_t, procmail_exec_t, procmail_t)

63 domain_auto_trans(system_mail_t, procmail_exec_t, procmail_t)

64 ')

65

66 # sendmail -q

67 allow system_mail_t mqueue_spool_t:dir rw_dir_perms;

68 allow system_mail_t mqueue_spool_t:file create_file_perms;

69

70 # Inherit and use pipes created by rc scripts.

71 allow system_mail_t initrc_t:fd use;

72 allow system_mail_t initrc_t:fifo_file { getattr read write };





リスト A-14 domains/program/smclient.te

1 # For clientmqueue.

2 type clientmqueue_spool_t, file_type, sysadmfile;

3 allow user_mail_domain clientmqueue_spool_t:dir create_dir_perms;

4 allow user_mail_domain clientmqueue_spool_t:file create_file_perms;

5

6 allow sendmail_t clientmqueue_spool_t:dir rw_dir_perms;

7 allow sendmail_t clientmqueue_spool_t:file create_file_perms;

8

9 # For local command "mail" etc.

10 allow sendmail_t user_mail_domain:tcp_socket { recvfrom acceptfrom };

11 allow user_mail_t sendmail_t:tcp_socket { connectto recvfrom };

12

13 allow sendmail_t self:tcp_socket { connectto recvfrom acceptfrom };

リスト A-15 file_contexts/program/qmail.fc

1 # qmail

2 /etc/qmail(/.*)? system_u:object_r:etc_qmail_t

3 /var/qmail(/.*)? system_u:object_r:etc_qmail_t

4 /var/qmail/queue(/.*)? system_u:object_r:qmail_spool_t

5 /var/qmail/bin(/.*)? system_u:object_r:bin_t

6 /var/qmail/bin/qmail-start system_u:object_r:qmail_start_exec_t

7 /var/qmail/bin/qmail-lspawn system_u:object_r:qmail_lspawn_exec_t

8 /var/qmail/bin/tcp-env system_u:object_r:qmail_tcp_env_exec_t

9 /var/qmail/bin/qmail-inject system_u:object_r:qmail_inject_exec_t

10 /var/qmail/bin/qmail-smtpd system_u:object_r:qmail_smtpd_exec_t

11 /var/qmail/bin/qmail-queue system_u:object_r:qmail_queue_exec_t

12 /var/qmail/bin/qmail-local system_u:object_r:qmail_local_exec_t

13 /var/qmail/bin/qmail-clean system_u:object_r:qmail_clean_exec_t

14 /var/qmail/bin/qmail-send system_u:object_r:qmail_send_exec_t

15 /var/qmail/bin/qmail-rspawn system_u:object_r:qmail_rspawn_exec_t

16 /var/qmail/bin/qmail-remote system_u:object_r:qmail_remote_exec_t

17 /var/qmail/bin/qmail-qread system_u:object_r:qmail_qread_exec_t

18 /var/qmail/bin/splogger system_u:object_r:qmail_splogger_exec_t

19 /var/qmail/bin/qmail-getpw system_u:object_r:qmail_exec_t

20 /usr/local/bin/serialmail/.* system_u:object_r:qmail_serialmail_exec_t

21 /var/qmail/bin/sendmail system_u:object_r:sendmail_exec_t





リスト A-16 domains/program/qmail.te

1 #DESC Qmail mail server

2 #

3 # Author: Russell Coker <[email protected]>

4 #

5

6 # bug

7 can_exec(tcpd_t, tcpd_exec_t)

8

9 # Type for files created during execution of qmail.

10 type qmail_var_run_t, file_type, sysadmfile, pidfile;

11

12 type etc_qmail_t, file_type, sysadmfile;

13

14 ifdef(`inetd.te', `

15 allow inetd_t smtp_port_t:tcp_socket name_bind;

16 ')

17

18 type qmail_exec_t, file_type, sysadmfile, exec_type;

19 type qmail_spool_t, file_type, sysadmfile;

20 type var_qmail_t, file_type, sysadmfile;

21

22 define(`qmaild_sub_domain', `

23 daemon_sub_domain($1, $2, `$3')

24 allow $2_t etc_qmail_t:dir { getattr search };

25 allow $2_t etc_qmail_t:{ lnk_file file } { getattr read };

26 allow $2_t var_spool_t:dir search;

27

28 # Allow qmail_$1_t to search under /var.

29 allow $2_t var_t:dir search;

30

31 ')

32

33 #################################

34 #

35 # Rules for the qmail_$1_t domain.

36 #

37 # qmail_$1_exec_t is the type of the qmail_$1 executables.

38 #

39 define(`qmail_daemon_domain', `

40 qmaild_sub_domain(qmail_start_t, qmail_$1, `$2')

41 allow qmail_$1_t qmail_start_t:fifo_file { read write };

42 allow qmail_start_t qmail_$1_exec_t:file read;

43 ')dnl

44

45

46 daemon_base_domain(qmail_start)

47 allow qmail_start_t self:capability { setgid setuid };

48 allow qmail_start_t { bin_t sbin_t var_t }:dir search;

49

50 # Allow qmail_start_t to search under /var/qmail.

51 allow qmail_start_t etc_qmail_t:dir search;





52

53 # Allow qmail_start_t to execute procmail as MDA.

54 # The procmail needs to read self executable file.

55 #ifdef(`procmail.te', `

56 # domain_auto_trans_read(qmail_start_t, procmail_exec_t, procmail_t)

57 # allow procmail_t etc_qmail_t:dir search;

58 # allow procmail_t initrc_t:fd use;

59 # allow procmail_t initrc_t:fifo_file write;

60 #')

61

62 qmail_daemon_domain(lspawn, `, mta_delivery_agent')

63 allow qmail_lspawn_t self:fifo_file { read write };

64 allow qmail_lspawn_t self:capability { setuid setgid };

65 allow qmail_lspawn_t self:process { fork signal_perms };

66 allow qmail_lspawn_t sbin_t:dir search;

67 can_exec(qmail_lspawn_t, qmail_exec_t)

68 allow qmail_lspawn_t self:unix_stream_socket create_socket_perms;

69 allow qmail_lspawn_t qmail_spool_t:dir search;

70 allow qmail_lspawn_t qmail_spool_t:file { read getattr };

71 allow qmail_lspawn_t etc_t:file { getattr read };

72 allow qmail_lspawn_t tmp_t:dir getattr;

73 dontaudit qmail_lspawn_t user_home_dir_type:dir { getattr search };

74

75 # Allow qmail-getpw to search under /var/run.

76 allow qmail_lspawn_t var_run_t:dir search;

77

78

79 qmail_daemon_domain(send)

80 rw_dir_create_file(qmail_send_t, qmail_spool_t)

81 allow qmail_send_t qmail_spool_t:fifo_file read;

82 allow qmail_send_t self:process { fork signal_perms };

83 allow qmail_send_t self:fifo_file write;

84 domain_auto_trans_read(qmail_send_t, qmail_queue_exec_t, qmail_queue_t)

85 allow qmail_send_t bin_t:dir search;

86

87

88 qmail_daemon_domain(splogger)

89 allow qmail_splogger_t self:unix_dgram_socket create_socket_perms;

90 allow qmail_splogger_t etc_t:lnk_file read;

91 dontaudit qmail_splogger_t initrc_t:fd use;

92

93 # Allow qmail_splogger_t to read /etc/localtime.

94 allow qmail_splogger_t etc_t:file { getattr read };

95

96

97 qmail_daemon_domain(rspawn)

98 allow qmail_rspawn_t qmail_spool_t:dir search;

99 allow qmail_rspawn_t qmail_spool_t:file rw_file_perms;

100 allow qmail_rspawn_t self:process { fork signal_perms };

101 allow qmail_rspawn_t self:fifo_file read;

102 allow qmail_rspawn_t { bin_t sbin_t }:dir search;

103

104 qmaild_sub_domain(qmail_rspawn_t, qmail_remote)

105 allow qmail_rspawn_t qmail_remote_exec_t:file read;





106 can_network(qmail_remote_t)

107 allow qmail_remote_t qmail_spool_t:dir search;

108 allow qmail_remote_t qmail_spool_t:file rw_file_perms;

109 allow qmail_remote_t resolv_conf_t:file { getattr read };

110 allow qmail_remote_t self:tcp_socket create_socket_perms;

111 allow qmail_remote_t self:udp_socket create_socket_perms;

112

113 qmail_daemon_domain(clean)

114 allow qmail_clean_t qmail_spool_t:dir rw_dir_perms;

115 allow qmail_clean_t qmail_spool_t:file { unlink read getattr };

116

117 # privhome will do until we get a separate maildir type

118 qmaild_sub_domain(qmail_lspawn_t, qmail_local, `, privhome, mta_delivery_agent')

119 allow qmail_lspawn_t qmail_local_exec_t:file read;

120 allow qmail_local_t self:process { fork signal_perms };

121 domain_auto_trans(qmail_local_t, qmail_queue_exec_t, qmail_queue_t)

122 allow qmail_local_t qmail_queue_exec_t:file read;

123 allow qmail_local_t qmail_spool_t:file { ioctl read };

124 allow qmail_local_t self:fifo_file write;

125 allow qmail_local_t sbin_t:dir search;

126 allow qmail_local_t self:unix_stream_socket create_stream_socket_perms;

127 allow qmail_local_t etc_t:file { getattr read };

128

129 # for piping mail to a command

130 can_exec(qmail_local_t, shell_exec_t)

131 allow qmail_local_t bin_t:dir search;

132 allow qmail_local_t bin_t:lnk_file read;

133 allow qmail_local_t devtty_t:chr_file rw_file_perms;

134 allow qmail_local_t { etc_runtime_t proc_t }:file { getattr read };

135

136 # Allow qmail_local_t to append $HOME/Mailbox.

137 # The type of $HOME/Mailbox must be mail_spool_t.

138 allow qmail_local_t mail_spool_t:file { lock append };

139

140

141 qmaild_sub_domain(tcpd_t, qmail_tcp_env)

142 allow qmail_tcp_env_t inetd_t:fd use;

143 allow qmail_tcp_env_t inetd_t:tcp_socket { read write getattr };

144 allow qmail_tcp_env_t inetd_t:process sigchld;

145 allow qmail_tcp_env_t resolv_conf_t:file { read getattr };

146 allow qmail_tcp_env_t bin_t:dir search;

147

148 can_network(qmail_tcp_env_t)

149

150 # Allow tcpd_t to search under /var/qmail.

151 allow tcpd_t etc_qmail_t:dir search;

152

153 qmaild_sub_domain(qmail_tcp_env_t, qmail_smtpd)

154 allow qmail_tcp_env_t qmail_smtpd_exec_t:file read;

155 can_network(qmail_smtpd_t)

156 allow qmail_smtpd_t inetd_t:fd use;

157 allow qmail_smtpd_t inetd_t:tcp_socket { read write };

158 allow qmail_smtpd_t inetd_t:process sigchld;

159 allow qmail_smtpd_t self:process { fork signal_perms };





160 allow qmail_smtpd_t self:fifo_file write;

161 allow qmail_smtpd_t self:tcp_socket create_socket_perms;

162 allow qmail_smtpd_t bin_t:dir search;

163

164 domain_auto_trans(qmail_smtpd_t, qmail_queue_exec_t, qmail_queue_t)

165 allow qmail_smtpd_t qmail_queue_exec_t:file read;

166

167 qmaild_sub_domain({ system_mail_t sysadm_mail_t user_mail_t }, qmail_inject, `,

mta_user_agent')

168 allow qmail_inject_t self:process { fork signal_perms };

169 allow qmail_inject_t self:fifo_file { write };

170 allow qmail_inject_t sbin_t:dir search;

171 role sysadm_r types qmail_inject_t;

172 in_user_role(qmail_inject_t)

173

174 qmaild_sub_domain(userdomain, qmail_qread, `, mta_user_agent')

175 in_user_role(qmail_qread_t)

176 role sysadm_r types qmail_qread_t;

177 r_dir_file(qmail_qread_t, qmail_spool_t)

178 allow qmail_qread_t self:capability dac_override;

179 allow qmail_qread_t privfd:fd use;

180

181 qmaild_sub_domain(qmail_inject_t, qmail_queue, `, mta_user_agent')

182 role sysadm_r types qmail_queue_t;

183 in_user_role(qmail_queue_t)

184 allow qmail_inject_t qmail_queue_exec_t:file read;

185 rw_dir_create_file(qmail_queue_t, qmail_spool_t)

186 allow qmail_queue_t qmail_spool_t:fifo_file { read write };

187 allow qmail_queue_t { qmail_start_t qmail_lspawn_t }:fd use;

188 allow qmail_queue_t qmail_lspawn_t:fifo_file write;

189 allow qmail_queue_t qmail_start_t:fifo_file { read write };

190 allow qmail_queue_t privfd:fd use;

191 allow qmail_queue_t crond_t:fifo_file { read write };

192 allow qmail_queue_t inetd_t:fd use;

193 allow qmail_queue_t inetd_t:tcp_socket { read write };

194 allow qmail_queue_t sysadm_t:fd use;

195 allow qmail_queue_t sysadm_t:fifo_file write;

196

197 allow user_crond_t etc_qmail_t:dir search;

198 allow user_crond_t etc_qmail_t:file read;

199

200 qmaild_sub_domain(user_crond_t, qmail_serialmail)

201 in_user_role(qmail_serialmail_t)

202 can_network(qmail_serialmail_t)

203 can_exec(qmail_serialmail_t, qmail_serialmail_exec_t)

204 allow qmail_serialmail_t self:process { fork signal_perms };

205 allow qmail_serialmail_t proc_t:file { getattr read };

206 allow qmail_serialmail_t { resolv_conf_t etc_runtime_t }:file { getattr read };

207 allow qmail_serialmail_t home_root_t:dir search;

208 allow qmail_serialmail_t user_home_dir_type:dir { search read getattr };

209 rw_dir_create_file(qmail_serialmail_t, user_home_type)

210 allow qmail_serialmail_t self:fifo_file { read write };

211 allow qmail_serialmail_t self:udp_socket create_socket_perms;

212 allow qmail_serialmail_t self:tcp_socket create_socket_perms;





213 allow qmail_serialmail_t privfd:fd use;

214 allow qmail_serialmail_t crond_t:fifo_file { read write ioctl };

215 allow qmail_serialmail_t devtty_t:chr_file { read write };

216

217 # for tcpclient

218 can_exec(qmail_serialmail_t, bin_t)

219 allow qmail_serialmail_t bin_t:dir search;

リスト A-17 file_contexts/program/postfix.fc

1 # postfix

2 /etc/postfix(/.*)? system_u:object_r:etc_postfix_t

3 /etc/postfix/aliases(.db)? system_u:object_r:etc_aliases_t

4 /etc/postfix/postfix-script.* system_u:object_r:postfix_exec_t

5 /etc/postfix/prng_exch system_u:object_r:postfix_prng_t

6 /usr/lib(exec)?/postfix/.* system_u:object_r:postfix_exec_t

7 /usr/lib(exec)?/postfix/cleanup system_u:object_r:postfix_cleanup_exec_t

8 /usr/lib(exec)?/postfix/local system_u:object_r:postfix_local_exec_t

9 /usr/lib(exec)?/postfix/master system_u:object_r:postfix_master_exec_t

10 /usr/lib(exec)?/postfix/pickup system_u:object_r:postfix_pickup_exec_t

11 /usr/lib(exec)?/postfix/(n)?qmgr system_u:object_r:postfix_qmgr_exec_t

12 /usr/lib(exec)?/postfix/showq system_u:object_r:postfix_showq_exec_t

13 /usr/lib(exec)?/postfix/smtp system_u:object_r:postfix_smtp_exec_t

14 /usr/lib(exec)?/postfix/smtpd system_u:object_r:postfix_smtpd_exec_t

15 /usr/lib(exec)?/postfix/bounce system_u:object_r:postfix_bounce_exec_t

16 /usr/sbin/postalias system_u:object_r:postfix_postalias_exec_t

17 /usr/sbin/postcat system_u:object_r:postfix_master_exec_t

18 /usr/sbin/postconf system_u:object_r:postfix_master_exec_t

19 /usr/sbin/postdrop system_u:object_r:postfix_postdrop_exec_t

20 /usr/sbin/postfix system_u:object_r:postfix_master_exec_t

21 /usr/sbin/postkick system_u:object_r:postfix_master_exec_t

22 /usr/sbin/postlock system_u:object_r:postfix_master_exec_t

23 /usr/sbin/postlog system_u:object_r:postfix_master_exec_t

24 /usr/sbin/postmap system_u:object_r:postfix_master_exec_t

25 /usr/sbin/postqueue system_u:object_r:postfix_postqueue_exec_t

26 /usr/sbin/postsuper system_u:object_r:postfix_master_exec_t

27 /usr/sbin/rmail system_u:object_r:postfix_master_exec_t

28 /usr/bin/rmail system_u:object_r:postfix_master_exec_t

29 /usr/bin/rmail.postfix system_u:object_r:postfix_master_exec_t

30 /var/spool/postfix/active(/.*)? system_u:object_r:postfix_spool_t

31 /var/spool/postfix/incoming(/.*)? system_u:object_r:postfix_spool_t

32 /var/spool/postfix/maildrop(/.*)? system_u:object_r:postfix_spool_maildrop_t

33 /var/spool/postfix/pid system_u:object_r:var_run_t

34 /var/spool/postfix/pid/.* system_u:object_r:postfix_var_run_t

35 /var/spool/postfix/private(/.*)? system_u:object_r:postfix_private_t

36 /var/spool/postfix/public(/.*)? system_u:object_r:postfix_public_t

37 /var/spool/postfix/defer(red)?(/.*)? system_u:object_r:postfix_spool_t

38 /var/spool/postfix/bounce(/.*)? system_u:object_r:postfix_spool_bounce_t

39 /var/spool/postfix/flush(/.*)? system_u:object_r:postfix_spool_flush_t

40 /var/spool/postfix/usr(/.*)? system_u:object_r:usr_t





41 /var/spool/postfix(/usr)?/lib(/.*)? system_u:object_r:lib_t

42 /var/spool/postfix(/usr)?/lib/ld.*¥.so.* system_u:object_r:ld_so_t

43 /var/spool/postfix(/usr)?/lib/lib.*¥.so.* system_u:object_r:shlib_t

44 /var/spool/postfix(/usr)?/lib/[^/]*/lib.*¥.so.* system_u:object_r:shlib_t

45 /var/spool/postfix(/usr)?/lib/devfsd/.*¥.so.* system_u:object_r:shlib_t

46 /var/spool/postfix/etc/services system_u:object_r:etc_t

リスト A-18 domains/program/postfix.te

1 #DESC Postfix mail server

2 #


4 #

5

6 # Type for files created during execution of postfix.

7 type postfix_var_run_t, file_type, sysadmfile, pidfile;

8

9 type etc_postfix_t, file_type, sysadmfile;

10 type postfix_exec_t, file_type, sysadmfile, exec_type;

11 type postfix_public_t, file_type, sysadmfile;

12 type postfix_private_t, file_type, sysadmfile;

13 type postfix_spool_t, file_type, sysadmfile;

14 type postfix_spool_maildrop_t, file_type, sysadmfile;

15 type postfix_spool_flush_t, file_type, sysadmfile;

16 type postfix_prng_t, file_type, sysadmfile;

17

18 #################################

19 #

20 # Rules for the postfix_$1_t domain.

21 #

22 # postfix_$1_exec_t is the type of the postfix_$1 executables.

23 #

24 define(`postfix_domain', `

25 daemon_base_domain(postfix_$1, `$2')

26 allow postfix_$1_t self:process setpgid;

27 allow postfix_$1_t postfix_master_t:process sigchld;

28 allow postfix_master_t postfix_$1_t:process signal;

29

30 allow postfix_$1_t { etc_t etc_postfix_t }:dir r_dir_perms;

31 allow postfix_$1_t { etc_t etc_postfix_t }:{ file lnk_file } r_file_perms;

32 allow postfix_$1_t self:unix_dgram_socket create_socket_perms;

33 allow postfix_$1_t self:unix_stream_socket create_stream_socket_perms;

34 allow postfix_$1_t self:unix_stream_socket connectto;

35

36 allow postfix_$1_t { sbin_t bin_t }:dir r_dir_perms;

37 allow postfix_$1_t bin_t:lnk_file r_file_perms;

38 allow postfix_$1_t shell_exec_t:file rx_file_perms;

39 allow postfix_$1_t var_spool_t:dir r_dir_perms;

40 allow postfix_$1_t postfix_exec_t:file rx_file_perms;

41 allow postfix_$1_t devtty_t:chr_file rw_file_perms;





42 allow postfix_$1_t etc_runtime_t:file r_file_perms;

43 allow postfix_$1_t proc_t:dir r_dir_perms;

44 allow postfix_$1_t proc_t:file r_file_perms;

45 allow postfix_$1_t postfix_exec_t:dir r_dir_perms;

46 allow postfix_$1_t fs_t:filesystem getattr;

47 can_exec(postfix_$1_t, postfix_$1_exec_t)

48 allow postfix_$1_t resolv_conf_t:file { read getattr };

49 allow postfix_$1_t var_t:dir { search getattr };

50

51 allow postfix_$1_t tmp_t:dir getattr;

52

53 file_type_auto_trans(postfix_$1_t, var_run_t, postfix_var_run_t)

54

55 # For chroot environment.

56 allow postfix_$1_t self:capability sys_chroot;

57

58 ')dnl

59

60 ifdef(`crond.te',

61 `allow system_mail_t crond_t:tcp_socket { read write create };')

62

63 postfix_domain(master)

64 # postfix does a "find" on startup for some reason - keep it quiet

65 dontaudit postfix_master_t postfix_spool_t:file getattr;

66 can_exec({ sysadm_mail_t system_mail_t }, postfix_master_exec_t)

67 file_type_auto_trans({ sysadm_mail_t system_mail_t }, etc_t, etc_aliases_t)

68 allow postfix_master_t sendmail_exec_t:{ file lnk_file } r_file_perms;

69 domain_auto_trans(initrc_t, postfix_master_exec_t, postfix_master_t)

70 ifdef(`pppd.te', `

71 domain_auto_trans(pppd_t, postfix_master_exec_t, postfix_master_t)

72 ')

73 can_exec(postfix_master_t, ls_exec_t)

74 allow postfix_master_t sysctl_kernel_t:dir r_dir_perms;

75 allow postfix_master_t sysctl_kernel_t:file r_file_perms;

76 allow postfix_master_t self:fifo_file rw_file_perms;

77 allow postfix_master_t usr_t:file r_file_perms;

78 can_exec(postfix_master_t, { shell_exec_t bin_t postfix_exec_t })

79 allow postfix_master_t self:capability { dac_override kill setgid setuid net_bind_service };

80 allow postfix_master_t postfix_public_t:fifo_file create_file_perms;

81 allow postfix_master_t postfix_public_t:sock_file create_file_perms;

82 allow postfix_master_t postfix_public_t:dir rw_dir_perms;

83 allow postfix_master_t postfix_private_t:dir rw_dir_perms;

84 allow postfix_master_t postfix_private_t:sock_file create_file_perms;

85 allow postfix_master_t postfix_private_t:fifo_file create_file_perms;

86 can_network(postfix_master_t)

87 allow postfix_master_t smtp_port_t:tcp_socket name_bind;

88 allow postfix_master_t postfix_spool_maildrop_t:dir rw_dir_perms;

89 allow postfix_master_t postfix_prng_t:file getattr;

90 allow postfix_master_t postfix_spool_maildrop_t:file { rename getattr };

91 allow postfix_master_t privfd:fd use;

92 allow postfix_master_t etc_aliases_t:file r_file_perms;

93 create_dir_file(postfix_master_t, postfix_spool_flush_t)

94 allow postfix_master_t random_device_t:chr_file { read getattr };

95 allow postfix_master_t postfix_prng_t:file rw_file_perms;





96 file_type_auto_trans(postfix_master_t, var_spool_t, postfix_spool_t, dir)

97

98 # allow access to deferred queue

99 allow postfix_master_t postfix_spool_t:dir create_dir_perms;

100 allow postfix_master_t postfix_spool_t:file { getattr setattr rename };

101

102 dontaudit postfix_master_t man_t:dir search;

103

104 # allow anyone to connect to port 25

105 can_tcp_connect(domain, postfix_master_t)

106

107 # for /var/spool/postfix/active

108 allow postfix_master_t postfix_spool_t:dir r_dir_perms;

109

110 define(`postfix_server_domain', `

111 postfix_domain($1, `$2')

112 domain_auto_trans_read(postfix_master_t, postfix_$1_exec_t, postfix_$1_t)

113 allow postfix_$1_t postfix_master_t:unix_stream_socket { connectto

rw_stream_socket_perms };

114 allow postfix_$1_t self:capability { setuid setgid dac_override };

115 can_network(postfix_$1_t)

116 ')

117

118 postfix_server_domain(smtp)

119 allow postfix_smtp_t postfix_spool_t:dir r_dir_perms;

120 allow postfix_smtp_t postfix_spool_t:file rw_file_perms;

121 allow postfix_smtp_t { postfix_private_t postfix_public_t }:dir search;

122 allow postfix_smtp_t { postfix_private_t postfix_public_t }:sock_file write;

123 allow postfix_smtp_t random_device_t:chr_file r_file_perms;

124 allow postfix_smtp_t postfix_master_t:unix_stream_socket connectto;

125

126 postfix_server_domain(smtpd)

127 allow postfix_smtpd_t random_device_t:chr_file r_file_perms;

128 allow postfix_smtpd_t postfix_master_t:tcp_socket rw_stream_socket_perms;

129 allow postfix_smtpd_t { postfix_private_t postfix_public_t }:dir search;

130 allow postfix_smtpd_t { postfix_private_t postfix_public_t }:sock_file rw_file_perms;

131 allow postfix_smtpd_t postfix_master_t:unix_stream_socket connectto;

132 allow postfix_smtpd_t etc_aliases_t:file r_file_perms;

133

134 allow { postfix_smtp_t postfix_smtpd_t } postfix_prng_t:file rw_file_perms;

135

136 postfix_server_domain(local, `, mta_delivery_agent')

137 ifdef(`procmail.te', `

138 domain_auto_trans_read(postfix_local_t, procmail_exec_t, procmail_t)

139 # for a bug in the postfix local program

140 dontaudit procmail_t postfix_local_t:tcp_socket { read write };

141 ')

142 allow postfix_local_t { etc_aliases_t }:file r_file_perms;

143 allow postfix_local_t self:fifo_file rw_file_perms;

144 allow postfix_local_t postfix_spool_t:dir r_dir_perms;

145 allow postfix_local_t postfix_spool_t:file rw_file_perms;

146 # for .forward - maybe we need a new type for it?

147 allow postfix_local_t postfix_private_t:dir search;

148 allow postfix_local_t postfix_private_t:sock_file rw_file_perms;





149 allow postfix_local_t postfix_master_t:unix_stream_socket connectto;

150 allow postfix_local_t postfix_public_t:dir search;

151 allow postfix_local_t postfix_public_t:sock_file write;

152 can_exec(postfix_local_t, shell_exec_t)

153

154 define(`postfix_public_domain',`

155 postfix_server_domain($1)

156 allow postfix_$1_t postfix_public_t:dir search;

157 ')

158

159 postfix_public_domain(cleanup)

160 create_dir_file(postfix_cleanup_t, postfix_spool_t)

161 allow postfix_cleanup_t postfix_public_t:fifo_file rw_file_perms;

162 allow postfix_cleanup_t postfix_public_t:sock_file { getattr write };

163 allow postfix_cleanup_t postfix_private_t:dir search;

164 allow postfix_cleanup_t postfix_private_t:sock_file rw_file_perms;

165 allow postfix_cleanup_t postfix_master_t:unix_stream_socket connectto;

166 allow postfix_cleanup_t { postfix_spool_bounce_t }:dir r_dir_perms;

167

168 allow user_mail_domain etc_postfix_t:dir r_dir_perms;

169 allow { user_mail_domain initrc_t } etc_postfix_t:file r_file_perms;

170 allow user_mail_domain self:capability dac_override;

171

172 define(`postfix_user_domain', `

173 postfix_domain($1, `$2')

174 domain_auto_trans(user_mail_domain, postfix_$1_exec_t, postfix_$1_t)

175 in_user_role(postfix_$1_t)

176 role sysadm_r types postfix_$1_t;

177 allow postfix_$1_t userdomain:process sigchld;

178 allow postfix_$1_t userdomain:fifo_file { write getattr };

179 allow postfix_$1_t { userdomain privfd }:fd use;

180 allow postfix_$1_t self:capability dac_override;

181 ')

182

183 postfix_user_domain(postqueue)

184 allow postfix_postqueue_t postfix_public_t:dir search;

185 allow postfix_postqueue_t postfix_public_t:fifo_file getattr;

186 allow postfix_postqueue_t self:udp_socket { create ioctl };

187 allow postfix_master_t postfix_postqueue_exec_t:file getattr;

188

189 # to write the mailq output, it really should not need read access!

190 allow postfix_postqueue_t { ptyfile ttyfile }:chr_file { read write getattr };

191 ifdef(`gnome-pty-helper.te', `allow postfix_postqueue_t user_gph_t:fd use;')

192

193 # wants to write to /var/spool/postfix/public/showq

194 allow postfix_postqueue_t postfix_public_t:sock_file rw_file_perms;

195 allow postfix_postqueue_t postfix_master_t:unix_stream_socket connectto;

196 # write to /var/spool/postfix/public/qmgr

197 allow postfix_postqueue_t postfix_public_t:fifo_file write;

198

199 postfix_user_domain(showq)

200 # the following auto_trans is usually in postfix server domain

201 domain_auto_trans_read(postfix_master_t, postfix_showq_exec_t, postfix_showq_t)

202 allow postfix_showq_t self:udp_socket { create ioctl };





203 allow postfix_showq_t { postfix_spool_t }:dir r_dir_perms;

204 r_dir_file(postfix_showq_t, postfix_spool_maildrop_t)

205 domain_auto_trans_read(postfix_postqueue_t, postfix_showq_exec_t, postfix_showq_t)

206 allow postfix_showq_t self:capability { setuid setgid };

207 allow postfix_showq_t postfix_master_t:unix_stream_socket { accept rw_socket_perms };

208 r_dir_file(postfix_showq_t, postfix_spool_t)

209 allow postfix_showq_t self:tcp_socket create_socket_perms;

210 allow postfix_showq_t ptyfile:chr_file { read write };

211

212 postfix_user_domain(postdrop, `, mta_user_agent')

213 allow postfix_postdrop_t postfix_spool_maildrop_t:dir rw_dir_perms;

214 allow postfix_postdrop_t postfix_spool_maildrop_t:file create_file_perms;

215 allow postfix_postdrop_t user_mail_domain:unix_stream_socket rw_socket_perms;

216 allow postfix_postdrop_t postfix_public_t:dir search;

217 allow postfix_postdrop_t postfix_public_t:fifo_file rw_file_perms;

218 dontaudit postfix_postdrop_t { ptyfile ttyfile }:chr_file { read write };

219 allow postfix_master_t postfix_postdrop_exec_t:file getattr;

220 ifdef(`crond.te',

221 `allow postfix_postdrop_t { crond_t system_crond_t }:fd use;

222 allow postfix_postdrop_t { crond_t system_crond_t }:fifo_file rw_file_perms;')

223

224 postfix_public_domain(pickup)

225 allow postfix_pickup_t postfix_public_t:fifo_file rw_file_perms;

226 allow postfix_pickup_t postfix_public_t:sock_file rw_file_perms;

227 allow postfix_pickup_t postfix_private_t:dir search;

228 allow postfix_pickup_t postfix_private_t:sock_file write;

229 allow postfix_pickup_t postfix_master_t:unix_stream_socket connectto;

230 allow postfix_pickup_t postfix_spool_maildrop_t:dir rw_dir_perms;

231 allow postfix_pickup_t postfix_spool_maildrop_t:file r_file_perms;

232 allow postfix_pickup_t postfix_spool_maildrop_t:file unlink;

233 allow postfix_pickup_t self:tcp_socket create_socket_perms;

234

235 postfix_public_domain(qmgr)

236 allow postfix_qmgr_t postfix_public_t:fifo_file rw_file_perms;

237 allow postfix_qmgr_t postfix_public_t:sock_file write;

238 allow postfix_qmgr_t postfix_private_t:dir search;

239 allow postfix_qmgr_t postfix_private_t:sock_file rw_file_perms;

240 allow postfix_qmgr_t postfix_master_t:unix_stream_socket connectto;

241

242 # for /var/spool/postfix/active

243 create_dir_file(postfix_qmgr_t, postfix_spool_t)

244

245 postfix_public_domain(bounce)

246 type postfix_spool_bounce_t, file_type, sysadmfile;

247 create_dir_file(postfix_bounce_t, postfix_spool_bounce_t)

248 create_dir_file(postfix_bounce_t, postfix_spool_t)

249 allow postfix_master_t postfix_spool_bounce_t:dir create_dir_perms;

250 allow postfix_bounce_t self:capability { dac_read_search };

251 allow postfix_bounce_t postfix_public_t:sock_file write;

252 allow postfix_bounce_t self:tcp_socket create_socket_perms;

253

254 r_dir_file(postfix_qmgr_t, postfix_spool_bounce_t)

255

256 # For /usr/sbin/postalias command.





257 type postfix_postalias_t, domain;

258 type postfix_postalias_exec_t, file_type, exec_type, sysadmfile;

259 general_domain_access(postfix_postalias_t)

260 general_file_read_access(postfix_postalias_t)

261 uses_shlib(postfix_postalias_t)

262

263 domain_auto_trans({ initrc_t postfix_master_t userdomain user_mail_domain },

postfix_postalias_exec_t, postfix_postalias_t)

264 role system_r types postfix_postalias_t;

265 role sysadm_r types postfix_postalias_t;

266 file_type_auto_trans(postfix_postalias_t, etc_postfix_t, etc_aliases_t, file)

267

268 # Allow postfix_postalias_t to read /etc/postfix/main.cf.

269 allow postfix_postalias_t etc_postfix_t:file read;

リスト A-19 file_contexts/program/mta.fc

1 # types for general mail servers

2 /usr/sbin/sendmail(.sendmail|.postfix)? system_u:object_r:sendmail_exec_t

3 /etc/aliases system_u:object_r:etc_aliases_t

4 /etc/aliases.db system_u:object_r:etc_aliases_t

5 /var/spool/mail(/.*)? system_u:object_r:mail_spool_t

6 /var/mail(/.*)? system_u:object_r:mail_spool_t

7

8 # For sendmail.postfix.

9 /usr/sbin/sendmail(.postfix)? system_u:object_r:sendmail_exec_t

リスト A-20 macros/program/mta_macros.te

1 #

2 # Macros for MTA domains.

3 #

4

5 #


7 # Based on the work of: Stephen Smalley <[email protected]> (NAI Labs)

8 # Timothy Fraser

9 #

10

11 #

12 # mail_domain(domain_prefix)

13 #

14 # Define a derived domain for the sendmail program when executed by

15 # a user domain to send outgoing mail. These domains are separate and

16 # independent of the domain used for the sendmail daemon process.





17 #

18 # The type declaration for the executable type for this program is

19 # provided separately in domains/program/mta.te.

20 #

21 undefine(`mail_domain')

22 define(`mail_domain',`

23 # Derived domain based on the calling user domain and the program.

24 type $1_mail_t, domain, privlog, user_mail_domain;

25

26 ifelse(`$1', `system', `

27 # Transition from a system domain to the derived domain.

28 domain_auto_trans_read(privmail, sendmail_exec_t, system_mail_t)

29 ', `

30 # Transition from the user domain to the derived domain.

31 domain_auto_trans($1_t, sendmail_exec_t, $1_mail_t)

32 ')

33 can_exec($1_mail_t, sendmail_exec_t)

34

35 # The user role is authorized for this domain.

36 role $1_r types $1_mail_t;

37

38 # This domain is granted permissions common to most domains (including can_net)

39 every_domain($1_mail_t)

40


42 allow $1_mail_t self:capability { setuid setgid chown };

43

44 # Execute procmail.

45 can_exec($1_mail_t, bin_t)

46 ifdef(`procmail.te',`

47 can_exec($1_mail_t, procmail_exec_t)')

48

49 ifelse(`$1', `system', `

50 # Read cron temporary files.

51 allow system_mail_t system_crond_tmp_t:file { read getattr };

52 allow mta_user_agent system_crond_tmp_t:file { read getattr };

53

54 ', `

55 # Read user temporary files.

56 allow $1_mail_t $1_tmp_t:file { read getattr };

57 dontaudit $1_mail_t $1_tmp_t:file append;

58 ifdef(`postfix.te', `

59 # postfix seems to need write access if the file handle is opened read/write

60 allow $1_mail_t $1_tmp_t:file write;

61 ')

62 allow mta_user_agent $1_tmp_t:file { read getattr };

63

64 allow mta_user_agent { $1_devpts_t $1_tty_device_t }:chr_file { getattr read write };

65

66 # Write to the user domain tty.

67 allow $1_mail_t $1_tty_device_t:chr_file rw_file_perms;

68 allow $1_mail_t $1_devpts_t:chr_file rw_file_perms;

69

70 # Inherit and use descriptors from gnome-pty-helper.





71 ifdef(`gnome-pty-helper.te', `allow $1_mail_t $1_gph_t:fd use;')

72

73 # Create dead.letter in user home directories.

74 file_type_auto_trans($1_mail_t, $1_home_dir_t, $1_home_t)

75

76 # if you do not want to allow dead.letter then use the following instead

77 #allow $1_mail_t { $1_home_dir_t $1_home_t }:dir r_dir_perms;

78 #allow $1_mail_t $1_home_t:file r_file_perms;

79

80 # for reading .forward - maybe we need a new type for it?

81 # also for delivering mail to maildir

82 file_type_auto_trans(mta_delivery_agent, $1_home_dir_t, $1_home_t)

83 ')

84

85 ifdef(`qmail.te', `

86 allow $1_mail_t etc_qmail_t:dir search;

87 allow $1_mail_t etc_qmail_t:{ file lnk_file } read;

88 ')

89

90 ')

リスト A-21 domains/program/mta.te

1 #


3 #

4 # policy for all mail servers, including allowing user to send mail from the

5 # command-line and for cron jobs to use sendmail -t

6

7 #

8 # sendmail_exec_t is the type of /usr/sbin/sendmail

9 #

10 type sendmail_exec_t, file_type, exec_type, sysadmfile;

11 type smtp_port_t, port_type;

12

13

14 # create a system_mail_t domain for daemons, init scripts, etc when they run

15 # "mail user@domain"

16 mail_domain(system)

17

18 ifdef(`sendmail.te', `

19 # sendmail has an ugly design, the one process parses input from the user and

20 # then does system things with it.

21 domain_auto_trans(initrc_t, sendmail_exec_t, sendmail_t)

22 ', `

23 domain_auto_trans(initrc_t, sendmail_exec_t, system_mail_t)

24 ')

25

26 # allow the sysadmin to do "mail someone < /home/user/whatever"

27 allow sysadm_mail_t user_home_dir_type:dir search;





28 r_dir_file(sysadm_mail_t, user_home_type)

29

30 # for a mail server process that does things in response to a user command

31 allow mta_user_agent userdomain:process sigchld;

32 allow mta_user_agent { userdomain privfd }:fd use;

33 allow mta_user_agent crond_t:process sigchld;

34 allow mta_user_agent sysadm_t:fifo_file { read write };

35

36 allow { system_mail_t mta_user_agent } privmail:fd use;

37 allow { system_mail_t mta_user_agent } privmail:process sigchld;

38 allow { system_mail_t mta_user_agent } privmail:fifo_file { read write };

39 allow { system_mail_t mta_user_agent } admin_tty_type:chr_file { read write };

40

41 allow mta_delivery_agent home_root_t:dir { getattr search };

42

43 # for piping mail to a command

44 can_exec(mta_delivery_agent, shell_exec_t)

45 allow mta_delivery_agent bin_t:dir search;

46 allow mta_delivery_agent bin_t:lnk_file read;

47 allow mta_delivery_agent devtty_t:chr_file rw_file_perms;

48 allow mta_delivery_agent { etc_runtime_t proc_t }:file { getattr read };





A-4 FTP サーバー

リスト A-22 file_contexts/program/wu-ftpd.fc

1 #

2 # Wu-FTPD

3 #

4

5 # ---------------------------------------

6 # Wu-FTPD configuration files under /etc.

7 /etc/ftpaccess system_u:object_r:etc_wuftpd_t

8 /etc/ftpconversions system_u:object_r:etc_wuftpd_t

9 /etc/ftpgroups system_u:object_r:etc_wuftpd_t

10 /etc/ftphosts system_u:object_r:etc_wuftpd_t

11 /etc/ftpusers system_u:object_r:etc_wuftpd_t

12 /etc/wu-ftpd system_u:object_r:etc_wuftpd_t

13

14 # -------------------------------------------------

15 # Wu-FTPD the other configuration files under /etc.

16 /etc/logrotate.d/ftpd system_u:object_r:etc_t

17 /etc/pam.d/ftp system_u:object_r:etc_t

18 /etc/xinetd.d/wu-ftpd system_u:object_r:etc_t

19

20 # -------------------------

21 # Wu-FTPD executable files.

22 /usr/bin/ftpcount system_u:object_r:wuftpd_tool_exec_t

23 /usr/bin/ftpwho system_u:object_r:wuftpd_tool_exec_t

24 /usr/sbin/ckconfig system_u:object_r:wuftpd_tool_exec_t

25 /usr/sbin/ftprestart system_u:object_r:wuftpd_tool_exec_t

26 /usr/sbin/ftpshut system_u:object_r:wuftpd_tool_exec_t

27 /usr/sbin/in.ftpd system_u:object_r:wuftpd_exec_t

28 /usr/sbin/in.wuftpd system_u:object_r:wuftpd_exec_t

29 /usr/sbin/privatepw system_u:object_r:wuftpd_tool_exec_t

30 /usr/sbin/wu.ftpd system_u:object_r:wuftpd_exec_t

31 /usr/sbin/xferstats system_u:object_r:wuftpd_tool_exec_t

32

33 # ---------------------------------------------

34 # Under the home directory for anonymous users.

35 /var/ftp system_u:object_r:wuftpd_pub_dir_t

36 /var/ftp/.* system_u:object_r:wuftpd_pub_t

37 /var/ftp/bin(/.*)? system_u:object_r:wuftpd_bin_t

38 /var/ftp/etc(/.*)? system_u:object_r:wuftpd_etc_t

39 /var/ftp/lib(/.*)? system_u:object_r:wuftpd_lib_t

40

41 # --------

42 # xferlog.

43 /var/log/xferlog(¥..*)? system_u:object_r:wuftpd_xferlog_t





リスト A-23 domains/program/wu-ftpd.te

1 # ##############################################

2 # Rules for the wuftpd_t domain.

3 #

4 # wuftpd_t is the domain for the WU-FTPD daemon

5 # started by the xinetd daemon.

6 #

7

8 # ----------------------

9 # Declaration of domain.

10 type wuftpd_t, domain, privlog, auth;

11 every_domain(wuftpd_t)

12 role system_r types wuftpd_t;

13

14 # ---------------------

15 # Declaration of types.

16

17 # for files and directories.

18 type wuftpd_exec_t, file_type, sysadmfile, exec_type;

19 type etc_wuftpd_t, file_type, sysadmfile;

20

21 attribute wuftpd_sys_type;

22 type wuftpd_bin_t, file_type, sysadmfile, wuftpd_sys_type;

23 type wuftpd_etc_t, file_type, sysadmfile, wuftpd_sys_type;

24 type wuftpd_lib_t, file_type, sysadmfile, wuftpd_sys_type;

25

26 type wuftpd_var_run_t, file_type, sysadmfile, pidfile;

27 type wuftpd_xferlog_t, file_type, sysadmfile, logfile;

28

29 attribute wuftpd_pub_type;

30 type wuftpd_pub_dir_t, file_type, sysadmfile, wuftpd_pub_type;

31 type wuftpd_pub_t, file_type, sysadmfile, wuftpd_pub_type;

32

33 # for port.

34 ifdef(`ftpd.te', `', `type ftp_port_t, port_type;')

35

36 # -----------------------

37 # Doamin transition rule.

38 domain_auto_trans(inetd_t, wuftpd_exec_t, wuftpd_t)

39

40 # ----------------------------------

41 # Use sockets inherited from xinetd.

42 allow wuftpd_t inetd_t:{ udp_socket tcp_socket } rw_stream_socket_perms;

43

44 # ----------------------------------------

45 # Allow wuftpd_t to use some capabilities.

46 #allow wuftpd_t wuftpd_t:capability { net_bind_service setuid setgid fowner fsetid

chown sys_resource sys_chroot sys_nice dac_override };

47 allow wuftpd_t wuftpd_t:capability { net_bind_service setuid setgid sys_nice

dac_override sys_chroot };

48

49 # ------------------------------------





50 # Allow wuftpd_t to connect to xinetd.

51 can_tcp_connect(wuftpd_t, inetd_t)

52

53 # --------------------------------------------------

54 # Allow wuftpd_t to send SIGCHLD to xinetd on death.

55 allow wuftpd_t inetd_t:process sigchld;

56

57 # -----------------------------------------------

58 # Allow wuftpd_t to read the configuration files.

59 allow wuftpd_t etc_wuftpd_t:file r_file_perms;

60

61 # ------------------------------------------

62 # Allow wuftpd_t to append to /var/log/wtmp.

63 allow wuftpd_t wtmp_t:file append;

64

65 # -----------------------------------------

66 # Allow wuftpd_t to write /var/log/lastlog.

67 allow wuftpd_t lastlog_t:file { read write };

68

69 # -----------------------------------

70 # Allow wuftpd_t to create pid files.

71 file_type_auto_trans(wuftpd_t, var_run_t, wuftpd_var_run_t)

72

73 # -----------------------------------------------------

74 # Allow wuftpd_t to create and modify /var/log/xferlog.

75 file_type_auto_trans(wuftpd_t, var_log_t, wuftpd_xferlog_t);

76

77 # ---------------------

78 # For anonymous access.

79 # ---------------------

80 # Allow wuftpd_t to access the /var/ftp/bin, etc, lib, pub.

81 allow wuftpd_t { wuftpd_sys_type wuftpd_pub_type }:dir r_dir_perms;

82 allow wuftpd_t { wuftpd_sys_type wuftpd_pub_type }:{ file lnk_file } r_file_perms;

83

84 # Allow wuftpd_t to execute the commands in <home-dir>/bin/.

85 can_exec(wuftpd_t, wuftpd_bin_t)

86

87 # Allow wuftpd_t to execute the libraries in <home-dir>/lib/.

88 allow wuftpd_t wuftpd_lib_t:lnk_file read;

89 allow wuftpd_t wuftpd_lib_t:file execute;

90

91 # -----------------

92 # For guest access.

93

94 # If you allow guest user to connect your FTP saerver,

95 # you have to enable following rules.

96 #allow wuftpd_t user_home_dir_t:dir create_dir_perms;

97 #file_type_auto_trans(wuftpd_t, user_home_dir_t, user_home_t)





リスト A-24 domains/wuftpadmin.te

1 #

2 # Domain for WU-FTPD administrator users.

3 #

4 ifdef(`wu-ftpd.te', `

5

6 define(`wuftpd_admin_domain', `

7

8 full_user_role($1)

9

10 # allow system_r $1_r;

11

12 # Allow user_r to change role to wuftpd_admin_r by newrole command.

13 allow user_r $1_r;

14 allow $1_r user_r;

15 type_change $1_t user_tty_device_t:chr_file $1_tty_device_t;

16 type_change user_t $1_tty_device_t:chr_file user_tty_device_t;

17 type_change $1_t user_devpts_t:chr_file $1_devpts_t;

18 type_change user_t $1_devpts_t:chr_file user_devpts_t;

19

20 allow $1_t user_home_dir_t:dir { search r_dir_perms };

21 file_type_auto_trans($1_t, user_home_dir_t, user_home_t)

22


24 allow $1_t $1_t:capability { dac_override };

25

26 # Allow wuftpd_admin_t to access the configuration

27 # files(/etc/ftp*).

28 allow $1_t etc_wuftpd_t:file { read write getattr setattr };

29

30 # ----------------------------------------------------

31 # Allow wuftpd_admin_t to create files and directories

32 # in the public directory.

33

34 # Allow $1_t to create files and directories

35 # under /var/ftp/etc/.

36 allow $1_t wuftpd_sys_type:dir create_dir_perms;

37 allow $1_t wuftpd_sys_type:{ file lnk_file } create_file_perms;

38

39 # Allow $1_t to create files and directories

40 # under /var/ftp/ and /var/ftp/pub/.

41 allow $1_t wuftpd_pub_type:dir create_dir_perms;

42 file_type_auto_trans($1_t, wuftpd_pub_type, wuftpd_pub_t)

43

44 # Allow wuftpd_admin_t to read /var/log/xferlog.

45 allow $1_t wuftpd_xferlog_t:file r_file_perms;

46

47 # Declaration of type and domain for management programs

48 # include Wu-FTPD.

49 type wuftpd_tool_exec_t, file_type, sysadmfile, exec_type;

50 type wuftpd_tool_t, domain;

51 general_domain_access(wuftpd_tool_t)





52 general_proc_read_access(wuftpd_tool_t)

53 general_file_read_access(wuftpd_tool_t)

54 uses_shlib(wuftpd_tool_t)

55 role $1_r types wuftpd_tool_t;

56

57 # Domain transition rule.

58 domain_auto_trans($1_t, wuftpd_tool_exec_t, wuftpd_tool_t)

59

60 # Allow wuftpd_tool_t to access some files.

61 allow wuftpd_tool_t etc_wuftpd_t:file rw_file_perms;

62 allow wuftpd_tool_t wuftpd_xferlog_t:file r_file_perms;

63

64 # ... for /usr/sbin/ftpshut and /usr/sbin/ftprestart.

65 allow wuftpd_tool_t etc_wuftpd_t:dir rw_dir_perms;

66 allow wuftpd_tool_t etc_wuftpd_t:file create_file_perms;

67 allow wuftpd_tool_t wuftpd_pub_dir_t:dir search;

68 allow wuftpd_tool_t wuftpd_etc_t:dir { search write add_name remove_name };

69 allow wuftpd_tool_t wuftpd_etc_t:file create_file_perms;

70

71 # Allow wuftpd_tool_t to execute /usr/bin/perl.

72 # This rule is needed for /usr/bin/xferstats.

73 can_exec(wuftpd_tool_t, bin_t)

74

75 # Allow wuftpd_tool_t to access control tty and pseudo tty.

76 allow wuftpd_tool_t { $1_tty_device_t $1_devpts_t }:chr_file { ioctl read

getattr write };

77

78 ')

79

80 # The domain for WU-FTPD administrator users is wuftpd_admin_t.

81 wuftpd_admin_domain(wuftpd_admin)

82

83 ')





付録 B 属性一覧

ファイル attrib.te で定義されているデフォルトの属性を表 B-1 に示す。

表 B-1 デフォルト属性一覧

＃分類属性名称説明

1 domain 関連

domain プロセスにアタッチする type つまり domain であることを示す属性。domain を定義する際には必ずこの属性を付与する必要がある。

2 privuser domain に対して自身にアタッチされたユーザ属

性80の変更を許可する属性。この属性はconstraint の定義で利用される。

3 privrole domain に対して自身にアタッチされた role の

変更を許可する属性。この属性は constraint の定義で利用される。

4

privowner domain に対して自身にアタッチされたユーザ属性とは異なるユーザ属性をファイルにアタッチすることを許可する属性。この属性はconstraint の定義で利用される。

5 privlog domain に対して syslogd を通じたログの出力を

許可する属性

6 privmem domain に対してカーネルメモリのデバイスス

ペシャルファイルへのアクセスを許可する属性

7 privfd domain に対して、継承されたファイルハンドル

を利用することを許可する属性

8 privhome domain に対してユーザのホームディレクトリ下

にファイルの作成を許可する属性

9 auth domain に対してユーザ認証の実行を許可する属

性

10

admin 管理者ユーザ domain であることを示す属性。標準のセキュリティポリシーでは sysadm_t と、管理ユーティリティにアタッチする幾つかのdomain に付与されている。

11 userdomain ユーザ domain であることを示す属性。標準のセ

キュリティポリシーでは sysadm_t と user_t に付与されている。

12 userpty_type 非管理者ユーザdomainが作成する擬似端末デバ

イススペシャルファイルにアタッチする typeであることを示す属性

13

user_crond_domain ユーザ domain から起動される cron ジョブプロセスにアタッチするdomainであることを示す属性。標準のセキュリティポリシー定義ではuser_crond_t と sysadm_crond_t に付与されている。

80 セキュリティコンテキストを構成する、つまり SELinux 管理下のユーザ属性のこと。






14 unpriv_userdomain 非管理者ユーザ domain であることを示す属性。

標準のセキュリティポリシー定義ではuser_tに付与されている。

15 user_home_dir_type 非管理者ユーザのホームトップディレクトリ

にアタッチする type であることを示す属性

16

gphdomain suid ビットの立っていないプログラムに代って擬似端末を作成するヘルパープログラムgnome-pty-helper にアタッチする domain であることを示す属性

17 ファイル関連

file_type 永続的なファイルシステム上のファイルにアタッチする type であることを示す属性

18 sysadmfile 管理者ユーザによるフルアクセスを許可する

ファイルにアタッチするtypeであることを示す属性

19 fs_type ファイルシステムにアタッチするtypeであるこ

とを示す属性

20 root_dir_type ファイルシステムのルートディレクトリにア

タッチする type であることを示す属性

21 exec_type プログラムの実行ファイルにアタッチする type

であることを示す属性

22 tmpfile テンポラリファイルにアタッチするtypeである

ことを示す属性

23 user_tmpfile 非管理者ユーザdomainによって作成されるテン

ポラリファイルにアタッチするtypeであることを示す属性

24

xserver_tmpfile ユーザdomainにより起動されたXサーバーが作成するテンポラリファイルにアタッチする type等を示す属性とされているが、この属性が付与されている type は存在しない。

25 tmpfsfile テンポラリファイルシステム上に作成される

ファイル・ディレクトリにアタッチする type であることを示す属性

26 home_type ユーザのホームディレクトリと同ディレクトリ

下のサブディレクトリ・ファイルにアタッチする type であることを示す属性

27 home_dir_type ユーザのホームトップディレクトリにアタッ

チする type であることを示す属性

28 ttyfile 端末デバイススペシャルファイルにアタッチ

する type であることを示す属性

29 ptyfile 擬似端末デバイススペシャルファイルにア

タッチする type であることを示す属性

30 pidfile PID ファイルにアタッチする type であることを

示す属性

31 ネットワーク関連

socket_type カーネルによって作成されるソケットにアタッチする type であることを示す属性

32 port_type ポート番号にアタッチするtypeであることを示

す属性

33 netif_type ネットワークインタフェースにアタッチする

type であることを示す属性

34 netmsg_type ネットワークインタフェースで受信したパケッ

トにアタッチする type であることを示す属性






35 node_type ネットワークノード（ホスト）にアタッチする

type であることを示す属性

36 logfile ログファイルとログファイルを配置するために

のみ存在しているディレクトリにアタッチするtype であることを示す属性

37 lockfile ロックファイル（/var/lock/*）とロックファイ

ルを配置するためにのみ存在しているディレクトリにアタッチするtypeであることを示す属性

38

セキュリティポリシー関連

login_contexts ログイン時のデフォルトセキュリティコンテキストを決定するために使用するファイルにアタッチする type であることを示す属性。現状では、type「default_context_t」に付与されている。

39

user_mail_domain デーモン起動でないSMTPプロセスにアタッチする domain であることを示す属性。標準のセキュリティポリシー定義では domain「user_mail_t」と「sysadm_mail_t」に付与されている。

40

privmail メールの送信を行う必要のあるシステムプロセスにアタッチする domain であることを示す属性。メール送信を行うシステムプロセスのための domain を定義する際には、この属性を付与する必要がある。

41 user_home_type 非管理者ユーザのホームディレクトリと同ディ

レクトリ下のサブディレクトリ・ファイルにアタッチする type であることを示す属性

42 mta_user_agent ローカルに投函されたメールを拾い上げる役割

を持ったプロセスにアタッチするdomainであることを示す属性。

43 mta_delivery_agent MDA(Mail Delivery Agent)にアタッチする

domain であることを示す属性





付録 C グローバルマクロ一覧

ファイル macros/global_macros.te で定義されているグローバルマクロの概要を表 C-1

と表 C-2 に示す。各マクロの詳細は先の定義ファイルを参照してほしい。

表 C-1 パーミッショングルーピングマクロ一覧

＃マクロ名称概要

1 dir_file_class_set すべてのディレクトリ関連 class とすべてのファイル関

連 class に展開されるマクロ

2 file_class_set すべてのファイル関連 class に展開されるマクロ

3 notdevfile_class_set デバイスファイル以外のすべてのファイル関連 class に

展開されるマクロ

4 devfile_class_set すべてのデバイスファイル関連 class に展開されるマク

ロ

5 socket_class_set すべてのソケット関連 class に展開されるマクロ

6 dgram_socket_class_set すべてのデータグラム型ソケット関連 class に展開され

るマクロ

7 stream_socket_class_set すべてのストリーム型ソケット関連 class に展開される

マクロ

8 unpriv_socket_class_set 非特権ソケット関連 class に展開されるマクロ

9 stat_file_perms ファイルに対して access(2)あるいは stst(2)を呼び出

すことを許可するパーミッションに展開されるマクロ

10 x_file_perms ファイルを実行するために必要なパーミッションに展開

されるマクロ

11 r_file_perms ファイルを読み取るために必要なパーミッションに展開

されるマクロ

12 rx_file_perms ファイルの読み取り・実行に必要なパーミッションに展

開されるマクロ

13 rw_file_perms ファイルの書き込み・実行に必要なパーミッションに展


14 ra_file_perms ファイルの読み取り・追記に必要なパーミッションに展


15 link_file_perms ファイルのリンク・リンクの解除・リネームに必要なパー

ミッションに展開されるマクロ

16 create_file_perms ファイルの作成と一般的なアクセスに必要なパーミッ

ションに展開されるマクロ

17 r_dir_perms ディレクトリの読み取り・探索に必要なパーミッション

に展開されるマクロ

18 rw_dir_perms ディレクトリの読み取り・修正に必要なパーミッション


19 ra_dir_perms ディレクトリの読み取りと同ディレクトリに対するディ

レクトリ・ファイルの追加に必要なパーミッションに展開されるマクロ

20 create_dir_perms ディレクトリの作成・一般的なアクセス・削除に必要な

パーミッションに展開されるマクロ

21 mount_fs_perms ファイルシステムのマウント・アンマウントに必要な







22 rw_socket_perms ソケットの読み取り・書き込みに必要なパーミッション


23 create_socket_perms ソケットの作成・読み取り・書き込みに必要なパーミッ


24 rw_stream_socket_perms ストリーム型ソケットの読み取り・書き込みに必要な


25 create_stream_socket_perms ストリーム型ソケットの作成・読み取り・書き込みに必

要なパーミッションに展開されるマクロ

26 signal_perms 任意のシグナル送信に必要なパーミッションに展開され

るマクロ

27 packet_perms ネットワークパケットの送信・受信に必要なパーミッ


28 r_sem_perms System V セマフォの読み取りに必要なパーミッション


29 rw_sem_perms System V セマフォの作成・読み取り・書き込みに必要な


30 r_msgq_perms System V メッセージキューの読み取りに必要なパー

ミッションに展開されるマクロ

31 rw_msgq_perms System V メッセージキューの作成・読み取り・書き込み

に必要なパーミッションに展開されるマクロ

32 r_shm_perms System V 共有メモリの読み取りに必要なパーミッショ

ンに展開されるマクロ

33 rw_shm_perms System V 共有メモリの作成・読み取り・書き込みに必要

なパーミッションに展開されるマクロ

表 C-2 アクセスベクタルール定義マクロ一覧


1 r_dir_file domain に対して特定のディレクトリと同ディレクトリ

下のファイルとリンクファイルの読み取りを許可するアクセスベクタルールを定義するマクロ

2 rw_dir_file domain に対して特定のディレクトリ下のファイル・リ

ンクファイルの読み取り・書き込みを許可するアクセスベクタルールを定義するマクロ

3

rw_dir_create_file domain に対して特定のディレクトリ下のファイル・リンクファイルの読み取り・書き込みを許可し、同ディレクトリ下にファイルを作成・削除することを許可するアクセスベクタルールを定義するマクロ

4

create_dir_file domain に対して特定のディレクトリの作成を許可し、同ディレクトリ下にファイルの作成を許可するマクロ。同ディレクトリ下のファイル・リンクファイルの読み取り・書き込みも許可される。

5

create_dir_notdevfile domain に対して特定のディレクトリの作成を許可し、同ディレクトリ下に非デバイスファイルの作成を許可するマクロ。同ディレクトリ下の非デバイスファイルの読み取り・書き込みも許可される。

6 create_append_log_file 特定ディレクトリ下に対するログファイルの作成、同ロ

グファイルへの追記に適したパーミッションを domainに許可するマクロ






7

domain_trans domain に対して特定のプログラムの実行を許可し、同プログラム実行の結果として起動するプロセスに対して自身とは異なる domain をアタッチすることを許可するマクロ。domain 遷移ルールは定義されない点に注意が必要である。domain 遷移ルールを同時に定義したい場合にはマクロ「domain_auto_trans」を利用する。

8 domain_auto_trans マクロ「domain_trans」に加えて、domain 遷移ルール

も同時に定義するマクロ

9 domain_auto_trans_read マクロ「domain_auto_trans」に加えて、実行するプロ

グラムファイルの読み取りも許可するマクロ

10 uses_shlib domain に対して共有ライブラリの利用を許可するマク

ロ

11 can_exec domain に対して特定のプログラムの実行を許可するマ

クロ。実行されたプログラムのプロセスには起動元と同一の domain がアタッチされる。

12 can_exec_any domain に対して任意の実行可能ファイルの実行を許可

するマクロ。実行されたプログラムのプロセスには起動元と同一の domain がアタッチされる。

13

file_type_trans domain に対して特定のディレクトリ下に特定のディレクトリと非デバイスファイルの作成を許可し、同ディレクトリ下のディレクトリ・非デバイスファイルの読み取り・書き込みを許可するマクロ。なお本マクロの引数では、作成を許可するオブジェクトの class を指定することも可能である。また、type 遷移ルールは定義されない点に注意が必要である。type 遷移ルールを同時に定義したい場合にはマクロ「file_type_auto_trans」を利用する。

14 file_type_auto_trans マクロ「file_type_trans」に加えて、type 遷移ルール

も同時に定義するマクロ

15 can_network domain に対してネットワークアクセスを許可するマク

ロ

16 can_unix_connect UNIX ストリーム型ソケットによる接続を確立すること

を domain に対して許可するマクロ

17 can_unix_send 特定のdomainが作成したUNIXデータグラム型ソケット

に対して、データグラムを送信することを許可するマクロ

18 can_tcp_connect 特定の domain が作成した TCP ソケットとコネクション

を確立することを許可するマクロ

19 can_udp_send 特定の domain が作成した UDP ソケットとの間で UDP

データグラムの送信・受信を許可するマクロ

20 can_sysctl domain に対してあらゆるカーネルパラメータの操作を

許可するマクロ

21 can_create_pty domain に対して擬似端末デバイスファイルの作成と同

擬似端末デバイスファイルに対する読み取り・書き込みを許可するマクロ

22 can_create_other_pty domain に対して別 domain のための擬似端末デバイス

ファイルの作成と同擬似端末デバイスファイルに対する読み取り・書き込みを許可するマクロ

23

general_domain_access domain に対して、domain として一般的に必要とされるアクセスベクタルールを一括して定義するマクロ。本マクロにより、自身と同一の domain のアタッチされているプロセス、PID ファイル、UNIX ソケット、System V IPCオブジェクトに対するアクセスを許可できる。






24

general_proc_read domain に対してディレクトリ/proc 下のほぼ全てのファイル・ディレクトリの読み取りを許可する。PIDファイルと一部のセキュリティ上重要なファイルの読み取りは許可されない。

25 base_file_read_access domain に対して幾つかのシステムファイルの読み取り

を許可するマクロ

26 general_file_read_access マクロ「base_file_read_access」に加えて、さらに幾

つかのシステムファイルの読み取りが許可されるマクロ

27 general_file_write_access domain に対してディレクトリ/tmp、/dev/tty、/dev/null

等のシステムファイルへの書き込みを許可するマクロ

28

every_test_domain マクロ「general_domain_access」、「general_proc_read_access」、「general_file_read_access」、「general_file_write_access」、および「uses_shlib」を呼び出し、加えて、任意のセキュリティ ID からのセキュリティコンテキストの取得と任意のセキュリティコンテキストからのセキュリティ ID の取得を許可するマクロ。本マクロはマクロ「every_domain」で利用されている。

29

every_domain マクロ「every_test_domain」と「can_network」により、domain に共通して必要なアクセスベクタルールを一括して定義するマクロ。新たに定義した domain にこのマクロを適用する場合には良く考えるべきである。不必要な権限を与えてしまう可能性があるのならば、このマクロを構成する各種マクロを個別に利用することが望ましい。

30 daemon_base_domain プロセスがデーモン稼動する場合に一般的に必要とな

るアクセスベクタルールを一括して定義するマクロ

31 daemon_domain マクロ「daemon_base_domain」に加えて、幾つかの付加

的なアクセスベクタルール（PIDファイルの作成権限等）を定義するマクロ

32 uses_authbind domain に対してヘルパープログラム authbind81の利用

を許可するマクロ

33 dameon_sub_domain 特定のdomainを起動元とするdomainを定義するマクロ

34

tmp_domain domain 固有の type の定義した上で同 domain がテンポラリディレクトリ下にファイルとディレクトリを作成することを許可し、作成されたファイル・ディレクトリに先のtypeをアタッチするtype遷移ルールを定義するマクロ

35

var_lib_domain domain 固有の type を定義した上で同 domain がディレクトリ/var/lib 下にファイルとディレクトリを作成することを許可し、作成されたファイル・ディレクトリに先のtypeをアタッチするtype遷移ルールを定義するマクロ

81 Debian で利用されているヘルパープログラム。root 特権を持たないプロセスのために low ポートへのバ

インドを肩代わりするヘルパープログラム。low ポートへのバインドを必要とするプログラムを非 root

ユーザで起動することをサポートする。






36

log_domain domain 固有の type を定義した上で同 domain がディレクトリ/var/log 下にファイルとディレクトリを作成することを許可し、作成されたファイル・ディレクトリに先のtypeをアタッチするtype遷移ルールを定義するマクロ

37

application_domain 単純なアプリケーションプログラムのための domain を定義するマクロ。プログラムの実行ファイルにアタッチする type と、プロセスにアタッチする domain が定義され、管理者ユーザ domain に同プログラムの実行が許可される。また、共有ライブラリの利用が許可される。

38 user_application_domain マクロ「application_domain」に加えて、一般ユーザ

domain からの起動も許可するマクロ

39

system_domain システム domain から起動されるアプリケーションプログラムのための domain を定義するマクロ。プログラムの実行ファイルにアタッチする type と、プロセスにアタッチする domain が定義され、システム domain に同プログラムの実行が許可される。また、共有ライブラリの利用とディレクトリ/etc の読み取りが許可される。





付録 D その他のマクロ

グローバルマクロ以外で重要な汎用マクロの概要を表 D-1 と表 D-2 に示す。各マクロの

詳細はそれぞれの定義ファイルを参照してほしい。

表 D-1 macros/user_macros.te で定義されているマクロ


1 user_domain ユーザ domain を定義するマクロ。標準で用意されてい

るユーザ domain「user_t」はこのマクロにより定義されている。

2 full_user_role 新たな role を定義するマクロ。本マクロでは、role の

定義と同時にペアとなる domain も定義される。新たにrole を追加する場合に有用なマクロである。

3 in_user_role 標準で用意されている role「user_r」から特定の role

（通常は新規定義した role だろう）への遷移を許可するマクロ。

表 D-2 macros/admin_macros.te で定義されているマクロ


1 admin_domain 管理者ユーザ domain を定義するマクロ。標準で用意さ

れている管理者ユーザ domain「sysadm_t」はこのマクロにより定義されている。

第Ⅱ編 security-enhanced linux 編

Documents