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

(1)

(2)

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

(3)

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

(4)

変更履歴

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

(5)

1. 本書の概要

1.1. 調査概要

本ガイドラインは、セキュア OS の１つである Security-Enhanced Linux（SELinux）を利用してインターネットサーバーを構築する際の理想的な設定・運用指針をまとめたものである。セキュア OS である SELinux では、システムの運用を開始する前の段階におけるセキュリティポリシーの定義が非常に重要な作業項目である。このセキュリティポリシーの定義において定義ミスや定義漏れがあったのでは、いくら SELinux といえども高いセキュリティを確保することは不可能である。しかし、SELinux に実装されているセキュリティアーキテクチャは非常に高度であり、それ故にセキュリティポリシーの定義は非常に複雑である。加えて、セキュリティポリシーの定義を支援するツールに乏しく、なかなかに導入に踏み切れないという問題がある。このような実情を踏まえて、SELinux をベースとしたインターネットサーバーを構築・運用する際の重要なポイントをまとめたのが本ガイドラインである。また本ガイドラインには、SELinux の難易度・手間・負担といったものを読者に感じ取らせるという目的も含まれている。

1.2. 調査期間

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

1.3. 調査対象

本ガイドラインは、表 1-1 に示すシステムとバージョンを対象として調査・分析を実施し、その結果として作成されている。

(6)

表 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 に標準で含まれるセキュリティポリシーを解析し、その留意点を明らかとする。また、標準で含まれないセキュリティポリシーは新たに作成し、その留意点を明らかとする。 • セキュリティポリシーを定義する際の手順・検証方法・確認方法を明らかとする。

(7)

運用面 • 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 システムの構造・仕様に関する知識やプログラマレベルの知識も要求されることがある。従って、上記に挙げたスキルを有する者であっても難しいと感じる部分があるかも知れない。このような踏み込んだ部分に関しては、極力脚注等で解説するように心掛けてはいるが、時には他の文献等を調べる必要が生じるかもしれない。

(8)

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_{判りやすく言えば、サブジェクトとオブジェクト間のアクセス許可／拒否を定義する「アクセスルール」} である。

(9)

アクセスを実現することは不可能となる。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 の実装はまだ試験段階であるため、本ガイドラインでは詳しくは言及しない。}

(10)

が実装されたシステムの利用者は、常に何らかの 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 特権を獲得して稼動

(11)

している場合（つまりプロセスの実効ユーザ 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 におけるパーミッションチェック機構はそのままに、その手前にセキュリティポリシーによるアクセス制御機構が追加された形となっている。このセキュリティポリシーによるアクセス制御機構では、あらかじめ定義された

(12)

Ⅱ-8 Copyright © 2003 IPA, All Rights Reserved. アクセスルール（セキュリティポリシー）に従ってプロセスのファイルへのアクセス可否をシステムが判断しており、この段階ではプロセスの実効ユーザ ID や実効グループ ID といった情報は一切関係のないものである。したがって、たとえプロセスの実効ユーザ ID と実効グループ ID が 0 であったとしても、つまりプロセスが root 特権を持って稼動していたとしても、あらかじめ定義されたアクセスルールにおいて、このプロセスが当該ファイルに対するアクセスを許可されていなければ、システムは単純にアクセスを拒否するのである。当然、この段階でアクセスが拒否されてしまえば、同アクセス要求はパーミッションチェックによるアクセス制御機構に降りていくことはない。また SELinux では、セキュリティポリシーにて特権の継承が明示的に許可されていない限り、子プロセスが親プロセスから特権を継承することはない。したがって、たとえプロセスが外部の攻撃者により乗っ取られ、同プロセスから悪意あるプログラムが実行されたとしても、親プロセスの特権が継承されないため、悪意あるプログラムはほとんど何の権限も持たないプロセスとしてしか起動することができないのである。以上のような特長が、「SELinux では root 特権が廃止されている」といわれる所以である。ただ厳密には、「root 特権が廃止されている」のではなく、セキュリティポリシーを適切に定義することで「パーミッションチェックによるアクセス制御の手前でアクセスを拒否することが可能である」というのが正しい。この点は勘違いしないでほしい。

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

TE と RBAC がシステムにもたらす効果は何か。それは権限の細分化である。Linux をはじめとした従来の UNIX システムでは、root ユーザにはシステムの全権（root 特権）が与えられている。そして、管理者がシステムをメンテナンスする場合であっても、何らかのプログラムが一般ユーザ以上の権限を必要とするオブジェクトにアクセスする場合であっても、この root 特権を獲得するという非常に憂慮すべき状態となっている。システム管理者やプログラムは、「システムに対する全権」を必要としているわけでない。システム管理者が日常のメンテナンスの際にアクセスするオブジェクトはごく一部に限られているだろうし、プログラムであればなおさらである。SELinux であれば、セキュリティポリシーを適切に定義することにより、ユーザやプログラムのアクセス範囲（権限）を制限することが可能である。結果として、そのユーザあるいはプログラムは、必要最低限な権限のみが付与された形となる。プログラムに与えられた権限が必要最低限であれば、プログラムに潜在する不良を攻撃することでシステムに侵入されたとしても、侵入者はごく限られた範囲でしか活動できなくなる。このことにより、被害を大幅に減らすことが可能なのである。現在、名の知れたアプリケーションプログラムのセキュリティホールが日々報告されている。ある程度の規模に達したプログラムに、不良が皆無であることを期待することなど

(13)

到底できるものではない。開発者の努力により日々安定性が向上したとしても、バージョンアップ等による大幅な改変時にその安定性は再び地に落とされる可能性もある。システムのセキュリティを向上させる際のアプローチとして、「侵入させない」アプローチは重要である。現に、これまでの主流はこの形態であった。しかし、「侵入させない」というアプローチは、ウィルス駆除にしろ、IDS にしろ、既知の攻撃に関するデータベースを基準としたものであり、未知の攻撃手法には無力である。これからは「侵入されても何もさせない」というアプローチも重要だろう。そしてこれこそがセキュア OS の導入意義である。

(14)

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/ 最後に、「セキュリティポリシーの検証・確認方法」ではセキュリティポリシーをどのように設定し、どのように検証し、そしてどのように確認するかについて説明する。

(15)

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_から

参照することができる。

(16)

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/}

(17)

リティポリシー設定ファイル群や新規に追加されたアプリケーションおよび 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”は例として定義さ

(18)

スト 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 存在しないプログラムやファイルパスに対する定義は削除してもかまわないが、特にシステムに支障をきたすわけではないのでそのまま残しておいても問題はない。

(19)

(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)

(20)

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 が稼動しているので、実際は再インストール（バージョンアップ含む）になる}

(21)

リスト 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 ディレクトリ下に格納されている。

(22)

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

(23)

リスト 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)を参照のこと。

(24)

Ⅱ-20 Copyright © 2003 IPA, All Rights Reserved. (6) X Display Manager Quick Install の 3.2.2.2(3)を参照のこと。 (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 ディレクトリ下にコピーされる。インストール後、セキュリティポリシーやファイルコンテキストの修正が必要な場合は、このディレクトリ下で作業を行うことになる。

(25)

(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 に示す実行例でこれらのアプリケーションがインストールされる。

(26)

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 はその実行例である。

(27)

リスト 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 のセキュリティコンテキスト

(28)

Ⅱ-24 Copyright © 2003 IPA, All Rights Reserved. (14) ラベルマッピングファイルの削除 LSM バージョンでない SELinux(初期の SELinux は LSM をベースとしていなかった) を立ち上げていた場合には、ファイルとセキュリティコンテキストのマッピング情報が格納されているラベルマッピングファイルをファイルシステム上から削除しなければならない。このファイルは、各ファイルシステムのルートディレクトリ下の “...security”サブディレクトリに格納されている。ラベルマッピングファイルを削除する例をリスト 3-18 に示す。リスト 3-18 既存ラベルマッピングファイルを削除する例

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

(15) ファイルのセキュリティコンテキスト定義 Quick Install の 3.2.2.2(2)を参照のこと。 (16) セキュリティコンテキストの設定まず、各ファイルにセキュリティコンテキストを設定するプログラム setfiles のビルドとインストールを行う。リスト 3-19 はその実行例である。リスト 3-19 setfiles プログラムのインストール cd setfiles make su (root ユーザでない場合) make install cd .. setfiles プログラムのインストールが完了したら、リスト 3-20 に示すような方法でセキュリティコンテキストの初期化と設定を行う。使用しているマシンやディスク性能およびディスク上のファイル数にもよるが、全ファイルの設定を行うのに数分から 20 数分程度かかる場合がある。

(29)

リスト 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"

(30)

リスト 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 モードでシステムを立ち上げて、セキュリティ

(31)

コンテキストの再設定を行ったほうがよい。 (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”というセキュリティコンテキストを設定する例である。

(32)

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

chcon system_u:object_r:system_crond_script_t /etc/crontab

システムが enforcing(セキュリティ執行)モードで稼動しているときにセキュリティポリシーの再設定やセキュリティコンテキストの再設定を行うには、セキュリティ管理者(ロールが sysadm_r でドメインが sysadm_t)の権限が必要である。

(33)

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 下のサブディレクトリとファイルには}

(34)

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 にその変更例を示す。

(35)

リスト 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 コマンドでセキュリティコンテストを元に戻さなければならない。

(36)

リスト 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?)のセキュリティコンテキストがリセットされ、種々のコマンドでメッセージの出力が表示されなくなる。このような状態になった場合は、ログアウトし再度ログインすればよい。

(37)

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

(38)

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_{および LIDS}17_{の機能を有効にすること}

ができる。システムを構築する上で必須のオプションは、#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/}

(39)

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

本章では、SELinux におけるセキュリティポリシー定義ファイルの配置位置とそのディレクトリ構造を解説し、その後、各セキュリティポリシー定義ファイルにおける定義内容の概要とセキュリティポリシー定義書式を解説する。また後半では、セキュリティポリシーを操作する上で重要となる各種のコマンドに関しても解説を行う。

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

SELinux には標準のセキュリティポリシー定義が含まれている。これらは一般的な Linux システムで通常インストールされているプログラムや、Apache、sendmail といった多くのユーザによって利用されているプログラムのためのセキュリティポリシー定義から構成されている。SELinux を通常とおりインストールした場合、標準のセキュリティポリシー定義ファイルはディレクトリ/etc/security/selinux/src/policy 下にインストールされる。 SELinux インストール後のセキュリティポリシーの変更は、このディレクトリ下にインストールされた各種ファイルを操作してシステムに適用することになる。表 3-6 にディレクトリ/etc/security/selinux/src/policy 下の様子を示す。