第4回 ReferenceポリシーをEnforcingモードで動かそう
古田 真己サイオステクノロジー株式会社
インフラストラクチャービジネスユニット
Linuxテクノロジー部
OSSテクノロジーグループ
2006/4/18
Fedora Core 5がリリースされました。皆さんはもうインストールしましたか？
第3回「Referenceポリシーを設定してみよう」では新しく採用されるReferenceポリシーでのモジュールの動作を確認するところまで行いました。今回は、実際にモジュールを使える状態に持っていき、さらに独自のモジュールを作成してみましょう。
また、2006年3月に米メリーランド州ボルチモアで開催された「SELinux Symposium」の様子についてお伝えします。
モジュール構造の確認
Referenceポリシーの大きな特徴は、ポリシー全体をモジュール化したことです。これは後からポリシーを開発する場合の手間の軽減や、ニーズに応じてモジュールの組み込み／取り外しが行えるという運用上の柔軟性をもたらします。
各ポリシーは起動時にあらかじめ読み込まれるベースモジュール（必要なポリシーがいくつか合わさったもの）と、必要に応じて選択できるアプリケーションごとのポリシーモジュールに分けて作成するようになっています。
 |
| 図1 モジュールの構成イメージ |
前回は可能な限りすべてのポリシーをポリシーモジュールとして分割したうえで、ベースモジュールの上にuserdomain.ppのみを組み込んだ様子を確認しました。ベースモジュールに含まれたものは、corecommands、mls、teminal、filesystem、domain、kernel、devices、files、selinux、corenetworkの10個のモジュールです。これはデフォルトの/etc/selinux/refpolicy/src/policy/policy/modules.confの記述に従っています。
 |
| 図2 前回のモジュール構成 |
ベースモジュールとポリシーモジュールは、それぞれ「*.te」「*.if」「*.fc」というファイルから構成されます。/etc/selinux/refpolicy/src/policy/policy/modules/の下には、「Admin」「Services」「Apps」「System」「Kernel」というディレクトリがあり、それぞれの関係を図にすると以下のようになります。
 |
| 図3 モジュールのレイヤ構造 Admin、Services、Appsは各アプリケーション別の設定、SystemとKernelはカーネルやコンソールなど基本的な動作に必要な基礎設定をつかさどる（前回試したuserdomain.ppはSystemレイヤに属する） |
KernelレイヤとSystemレイヤが動作に必要な最小限度のセットとなります。実際に使用可能なシステムを構築するためにはmodules.confを編集し、2つのレイヤに属するポリシーをすべてベースモジュールに含める必要があります。
前回ベースモジュールに組み込んだ10個のモジュールはいずれもKernelレイヤに属するものでした。実は2006/1/24版のKernelレイヤには合計12個のポリシーがあります。システムをきちんと動作させるためには、Kernelレイヤのモジュールだけでももっと多くのモジュールが必要ですし、さらにSystemレイヤのモジュール（合計24個）も必要になります。
ベースモジュールの設定を変更する
SELinuxのポリシーを記述し、有効にするためには、以下のようなステップを踏むのがよいと思います。順に説明します。
早速動作に必要な設定作業を始めましょう。SELinuxのポリシーは前回から引き続き2006/1/24版のReferenceポリシーを使い、モードをPermissiveにした環境での作業を前提とします。前回設定した「Runlevel3で起動させるサービス」がここで生きてきます。
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Runlevel3で起動させるサービス |
前述のKernelレイヤ、Systemレイヤに含まれるものに加え、この表にあるもので対応しているサービスはすべてベースモジュールに組み込みます。また、サービス以外の管理用コマンド（rpm、prelink、dmesgなど）も組み込んでおいた方がよいので、Adminレイヤも組み込みます。従って作成されるmodules.confは以下のようになります。
|
|
| modules.confの変更例 |
これでKernel、System、Adminレイヤの設定の変更とサービスのモジュールの追加は終わりです。moduleからbaseに変更したモジュールは以下のとおりです。
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ベースモジュールに組み込むよう変更したポリシー |
|
1/4
|
 |
| Index | |
| ReferenceポリシーをEnforcingモードで動かそう | |
 |
Page1 モジュール構造の確認 ベースモジュールの設定を変更する |
| Page2 ベースモジュールの設定の作り直し Enforcingモードでの動作確認 |
|
| Page3 追加記述するモジュールの選定 ひな型でみ見る大まかなモジュールの記述方法 |
|
| Page4 SELinux Symposium 2006 SELinuxの今後の方向性 |
|
 |
Security&Trust記事一覧 |
- Windows起動前後にデバイスを守る工夫、ルートキットを防ぐ （2017/7/24）
Windows 10が備える多彩なセキュリティ対策機能を丸ごと理解するには、5つのスタックに分けて順に押さえていくことが早道だ。連載第1回は、Windows起動前の「デバイスの保護」とHyper-Vを用いたセキュリティ構成について紹介する。 - WannaCryがホンダやマクドにも。中学3年生が作ったランサムウェアの正体も話題に （2017/7/11）
2017年6月のセキュリティクラスタでは、「WannaCry」の残り火にやられたホンダや亜種に感染したマクドナルドに注目が集まった他、ランサムウェアを作成して配布した中学3年生、ランサムウェアに降伏してしまった韓国のホスティング企業など、5月に引き続きランサムウェアの話題が席巻していました。 - Recruit-CSIRTがマルウェアの「培養」用に内製した動的解析環境、その目的と工夫とは （2017/7/10）
代表的なマルウェア解析方法を紹介し、自社のみに影響があるマルウェアを「培養」するために構築した動的解析環境について解説する - 侵入されることを前提に考える――内部対策はログ管理から （2017/7/5）
人員リソースや予算の限られた中堅・中小企業にとって、大企業で導入されがちな、過剰に高機能で管理負荷の高いセキュリティ対策を施すのは現実的ではない。本連載では、中堅・中小企業が目指すべきセキュリティ対策の“現実解“を、特に標的型攻撃（APT：Advanced Persistent Threat）対策の観点から考える。
 |
|
|
|
|
