SELinux：使いやすさを犠牲にセキュリティを強化
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のオン/オフでパフォーマンスに目立った差は感じなかった。
TE（Type Enforcement）
少し踏み込んで説明をすると、SELinuxのポリシーは実際にはTE（Type Enforcement）と呼ばれるアクセス制御方式に基づいている。TEでは”セキュリティ・コンテキスト”属性を使ってアクセスが決定される。SELinuxでは、ユーザ、ロール、タイプの3種類のセキュリティ・コンテキストが使われる。
現在、TEでは情報開示に関する規則を含むアクセス・マトリクスが使われる。これらは、異なるユーザやプログラム（サブジェクトと呼ばれる）に、ファイル、ソケット、ネットワークホスト（オブジェクトと呼ばれる）に対する権限を各自のセキュリティ・コンテキストに従って許可する規則だ。たとえば、Xというアプリケーション（サブジェクト）にYというファイル（オブジェクト）への書き込み（アクション）を許可するかどうかがTEで決定されるという具合だ。
SELinuxを使用すると、一般的なシステム・ユーティリティの一部が変更され、-Zオプションを使ってオブジェクトやサブジェクトのセキュリティ・コンテキストを表示できるようになる。たとえば、ls -Zでは、現在のディレクトリにあるファイルシステム・オブジェクトのセキュリティ・コンテキストが表示され、id -Zでは、ユーザのセキュリティ・コンテキストが表示される。ps -Zの表示には、現在のプロセスのセキュリティ・コンテキストが追加される。
これらはポリシーファイルにどのように定義されるのだろうか。targetedポリシーの規則は次のようなものだ。
allow user_t bin_t : file {read execute getattr};
この例では、user_tタイプのアプリケーション（サブジェクト）は、セキュリティ・コンテキストがbin_tタイプであるすべてのクラスファイルのオブジェクトに対して読み取り、実行、取得の属性を持つ。
この規則は、タイプがbin_tであるファイル・オブジェクトのみに適用される。タイプはbin_tだがファイル・クラスではないオブジェクトや、タイプがbin_tではないファイル・オブジェクトには適用されない。ややこしいかもしれないが、これによりSELinuxで使用できる制御のレベルが高くなる。
SELinuxをもっと扱いやすく
SELinuxの紹介記事を前にも書いたが、基本は今も変わらない。ただし、ポリシーはタイヤが路面に接する場所なので、リリースのたびに少しずつ改良されている。現在のFedora Coreには、すべての主要なネットワーク・サービスをカバーするtargetedポリシーが付属する。さらにFC6のSELinuxでは、MLS（Multilevel Security）アクセス制御メカニズムに基づく新しいMCS（Multi-Category Security）ポリシーもサポートされた。ファイルにセキュリティ・ラベルを付けて、機密レベルに応じてファイルを分類できる機能である。
 |
|
| setroubleshootユーティリティ － クリックで拡大表示 |
SELinuxの監査機能も改善されている。AVC（Access Vector Cache）メッセージは、アクセスが拒否されたときに生成される監査メッセージだが、FC2/FC3ではシステムログにあふれる大量の”avc: denied”メッセージの解読に多くの管理者が悩まされた。現在は、SELinux監査メッセージの解釈に役立つツールがいくつもある。
米Tresysは、数種類のポリシー用、監査メッセージ分析用のグラフィカルツールとコマンドラインツールをSEToolsパッケージにバンドルした。また、FC6で導入されたSELinux Troubleshooterも便利なツールだ。監査ログを検索してAVCメッセージを取得する機能があり、AVCメッセージが見つかると、拒否された理由を簡潔でわかりやすい説明文にまとめ、修正方法に関するヒントと併せて通知してくれる。
とはいえ、SELinuxのポリシーを理解し、独自のポリシーを作成するのは容易ではない。そこで、簡単に使用できて、新しいポリシーの書き方を習得する土台ともなる標準的なポリシーとして設計されたのが、referenceポリシーである。FC5では、この方式に基づくポリシーが使用される。また、SLIDEという、Eclipse SDKにプラグインされる統合開発環境（IDE）を使うと、referenceポリシーに基づいてポリシーを簡単に作成できる。
SELinuxは、成熟した製品である。2000年12月にオープンソース・コミュニティに解放される前に、NSAは開発に数年間を費やした。今なお、多数の個人や企業が開発に参加している。アプリケーションとデータのセキュリティに責任を負う人々は、ゼロデイアタックや粗雑に設計されたアプリケーションを相手にするときにSELinuxの堅牢性に感謝するだろう。見たところ、Red HatとTresysは、SELinuxを使いやすく、管理しやすくしようと熱心だ。RHELやFedora Coreだけでなく、Gentoo、Debian、UbuntuのユーザもSELinuxの恩恵を受けられる。
デスクトップコンピュータやエンタープライズコンピュータのセキュリティに関心がある人々は当然として、オペレーティングシステムのセキュリティを学習テーマとする学生にもSELinuxはうってつけだ。馴れるまでに時間はかかるが、腰を据えて取り組む価値がある。
SELinuxは壮大なトピックであり、この記事はSELinuxアクセス制御の概要を説明し、サポートされる制御のレベルを明らかにすることに狙いをしぼった。さらに詳しくSELinuxを知るには、SELinux FAQを参照するか、SELinuxについて書かれた専門書に目を通すことをお奨めする。
