SourceForge.JP: Open Source Software

SELinuxの利点は2つだ。まず、ユーザベースモデルがポリシー中心モデルに置き換えられる。アプリケーションの実行やデータの読み取り、変更など、あらゆる操作がセキュリティポリシーに従って制御される。ポリシーに違反する操作は拒否される。第二に、SELinuxを使うと、システムで動作中のさまざまなアプリケーションとプロセスが区画に分けられる。その結果、侵入を1つの区画で阻止できるばかりか、サービスの乗っ取りによる損害も限定できる。

SELinuxは、LSM（Linux Security Module）を通じてLinuxディストリビューションにプラグインとして組み込まれる。LSMは、カーネル2.6.xでサポートされる機能だ。セキュリティモデルを、パッチとしてカーネルに適用するのではなく、カーネルに統合し、連携して機能させることができる。

SELinuxの歩み

SELinuxの中心にはセキュリティポリシーがある。NSA（National Security Agency）からオープンソース・コミュニティに渡された時点で、SELinuxにはstrictポリシーというポリシーしかなかった。これは、ホワイトリストの概念に基づくポリシーだ。ホワイトリストとは、デフォルトポリシーでアプリケーションアクセスがすべて禁止され、アクセスを認めるアプリケーションについては個別に許可を指定することを指す。

strictポリシーは、Fedora Core 2で初めて使用された。Fedora Core 2では、SELinuxがすべてのものをロックする。strictポリシーは許可（Allow）宣言のコレクションである。しかし、このようなポリシーは常にメンテナンスの必要があり、システム設定を変更するたびに見直しが避けられない。おかげで、新しいアプリケーションをインストールしたり、既存のアプリケーションをポリシー作成者の予想しなかった方法で使用したりすると、strictポリシーから苦情が来る。strictポリシーは、制御が徹底され、規則で縛られた環境には最適であっても、通常のデスクトップでは使いにくい。

Fedora Core 6でSELinuxを管理する － クリックで拡大表示

strictポリシーの問題点を解消するため、Fedora Core 3でtargetedポリシーがサポートされた。strictポリシーとは違って、targetedポリシーは禁止（Deny）宣言のリストである。デフォルトですべての操作が許可されるので、デスクトップ・ユーザはSELinuxが有効になっていないかのごとく自由にシステムを使える。そして、特定のアプリケーションだけを指定してアクセスを制限することで、重要なネットワーク・デーモンが保護される。このポリシーは、Red Hat Enterprise Linux（RHEL）4でも採用された。

それは、Red HatのSELinuxエンジニアがパフォーマンスのチューニングに注意を向けさせたときでもある。SELinux Fedora Core 5 FAQによると、最新のベンチマークテストで7%のパフォーマンス低下が測定された。パフォーマンスの強化が図られたFedora Core 6を筆者は試したが、このリリースではSELinuxのオン/オフでパフォーマンスに目立った差は感じなかった。