Security-Enhanced Linux (SELinux)
  とは何か？

執筆：Russell Coker

はじめに

高速なインターネット接続が普及し、喫茶店では無料のワイヤレスアクセスが提供され、極めて多くのroot用キットがWeb上に氾濫している現在の世界では、コンピュータのセキュリティについて考えるのが当たり前になっています。米国家安全保障局（NSA）はこの問題に対処するため、Linuxコミュニティの協力のもと、プロセスのアクセス範囲をその動作の完了に必要なファイルのみに制限するアクセス制御アーキテクチャを開発しました。このアーキテクチャは、Security-Enhanced Linux、略してSELinuxと呼ばれています。

SELinuxの概要

SELinuxは、ドメイン-タイプモデルに基づくLinux用の強制アクセス制御（MAC:Mandatory Access Control）セキュリティシステムです。NSA(http://www.nsa.gov/selinux/)が開発を行い、（すべての2.6カーネルに含まれている）カーネルモジュール、特定のセキュリティ関連アプリケーションに対するパッチ、およびセキュリティポリシーで構成されます。

標準的なUnixのセキュリティモデルは、任意アクセス制御（DAC:Discretionary Access Control）と呼ばれるものです。これは、各プログラムがそのリソースに対するすべてのアクセスに関して全面的な制御権を持つという意味です。もしそのプログラムが、機密データを含む可能性のあるファイルを /tmp/ に入れて、誰でも読み出し可能にしてしまうと、もうそれを止める手段は存在しません。MACはこれとは根本的に異なっており、各リソースに与えられるアクセス権についての全面的な制御をシステムのセキュリティポリシーが握っています。SELinuxにおけるMACの実装でも、プログラムがファイルを/tmp/ に作成し、Unixのパーミッションによれば誰でも読み出しアクセス可能な状態にできますが、Unixのパーミッションチェック適用後に、SELinuxのパーミッションチェックによってファイルへのアクセスを許すかどうかが決定されます。すなわち各種のセキュリティ対策の中でも際だった特徴として、たとえファイルがUnixのパーミッションモード0777を持っていても、そのファイルの読み出し、書き込み、または実行のためのアクセスを拒否される可能性があるわけです。DACのみの場合、ユーザが実行するプログラムはすべて、そのユーザがアクセス権を持つ任意のファイルの内容を漏洩あるいは変更できてしまいます。SELinuxでは、各プロセスがどのファイルにアクセスできるか、どのレベルのアクセスまで認めるかを制限できます。つまり、あるプログラムが機密データを扱う場合、それより低い権限を持つプログラムが読み出し可能なファイルには書き込みを行わせないということが可能です。

SELinuxでは、伝統的なUnixパーミッションが提供するものよりきめの細かいアクセス制御が可能になります。たとえば特定のアプリケーションに対してだけ、ログファイルへのアペンド（追加書き込み）は許すが、書き換えや割愛は認めないという設定を行うことができます。ext2およびext3ファイルシステムにはchattr(1)で設定可能なアペンドオンリーフラグがありますが、これはそのファイルへのすべてのアクセスに適用されます（あるプロセスからはアペンドオンリー、別のプロセスからは完全に書き込み可能という設定はできません）。また、あるアプリケーションに対してファイルの作成とそのファイルへのデータ書き込みは許可するが、同じディレクトリにある同じパーミッションの既存ファイルを削除することは認めないという設定も可能です。これもアペンドオンリーファイルのバリエーションの1つですが、SELinuxでない標準のLinuxカーネルでは実現不可能です。各種ネットワークプログラムに対して、必要なポート（たとえばBINDならポート53）へのバインドだけを許し、その他のポートへのバインドアクセスを拒否することもできます。

ドメイン-タイプモデルというのは、個々のプロセスがそれぞれ1つのセキュリティドメイン内で実行され、各リソース（ファイル、ディレクトリ、ソケットなど）にそれぞれ1つのタイプが関連づけられているという意味です。1組のルールによって、それぞれのドメインがそれぞれのタイプに対して実行可能な動作が列挙されます。ドメイン-タイプモデルのメリットの1つに、ポリシーの分析によってどんな情報の流れが可能か判断できるという点があります。標準的なUnixの場合、ユーザがps コマンドを使ってお互いのプロセスを表示できるのが普通ですが、これは攻撃者に貴重な情報を提供することにつながります。たとえワイドなpsアクセスがブロックされていても、データが偶然または故意に漏洩される方法は他にも数多く考えられ、与えられたUnixの構成においてどのような情報の流れが許可されうるかを判断する方法は存在しません。SELinuxなら、ポリシーを分析してどんなデータフローが可能か判断するためのツールが用意されています。たとえば、今仮に2つのアプリケーションに対して、ログファイルに使用されるファイルタイプへのアペンドアクセスが許されている場合、両者が通信するための直接的な方法はないことになります。一方のアプリケーションがリードアクセス権も与えられている場合には、一方向通信の可能性があることが分かります。

ポリシー分析のメリットの一例として、/etc/shadow に対するアクセスの制限をあげることができます。Fedora Core 3の場合、strictな構成のFedora SELinuxポリシーで（/etc/shadow に使用される）タイプshadow_tへのアクセスを許されているドメインは17個あり、そのうち9個だけが書き込みアクセス権を持っています。これら17のドメインのうち、ユーザドメインから入れるのは2つだけです。1つは /usr/bin/passwd に対するもの、もう1つは /sbin/unix_chkpwd（スクリーンセーバーやその他の非特権プログラムでパスワードチェックを行うためのヘルパプログラム）に対するものです。この17個のドメインの中には、ほとんどのシステムでは使用されないプログラム用のものがいくつか含まれています（たとえば、RADIUSサーバ用のradius_tドメインなど）。ですから、RADIUSサーバがインストールされていないマシンなら、アクセス可能ドメインのうち /etc/shadow にアクセスできるのは最大で16個ということになります。注意していただきたいのは、Fedoraポリシーの調整可能オプションが順次増加している点です。将来のバージョンのポリシーでは、調整可能オプションの選択次第で17より多くのドメインが/etc/shadow へのアクセスを許されるようになるかも知れません。また、この数は最も厳格なオプションを選択したstrict ポリシーの場合だという点にもご注意ください。デフォルトのインストール状態ではもっと多くのアクセスが許可されます。

非SEマシンでは、rootで実行されるすべてのプロセスが /etc/shadow にアクセスできます。すなわち、SETUID rootされたすべてのバイナリあるいはrootで実行されるすべてのネットワークデーモンに含まれるあらゆるセキュリティ上の問題が、そのまま破滅的状況につながることを意味しています。SELinuxでは、各デーモンによるアクセスを、そのデーモンが必要とするものだけに制限できます。BINDはポート53でだけサービスを提供でき、DHCPサーバはネットワークに直接アクセスし、DHCPクライアントはネットワークへの直接アクセスとローカルインタフェースの変更を行うことができます。しかしこれらのプログラムの中に、/etc/shadow、/home、/root、その他の重要なリソースにアクセスできるものはありません。したがってSELinuxでは、もしBINDが乗っ取られても、最悪の場合で偽のDNSパッケージを送出されるだけです。DHCPDが乗っ取られても、最悪の場合でIPアドレス割り当てを攪乱させられるだけです。これは、リモートroot権限奪取に比べればはるかにましというものです！

さて、明らかにプログラムは他のプログラムを呼び出すことができます。この場合、たとえばDHCPDが /sbin/unix_chkpwdを手動で呼び出して、ブルートフォース（総当たり）攻撃でパスワードを破ろうとするかも知れません。しかし、この潜在的な脆弱性さえ塞がれています。SELinuxには「遷移」ルールを指定する機能があり、あるドメインが他のドメインに入れるかどうかをそのルールが決定するからです。この場合、ローカルユーザの代理として起動されたスクリーンセーバーは /sbin/unix_chkpwdの特権ドメインに遷移することを許されますが、その遷移はDHCPDに対しては拒否されます。

これらの制限は、システムの状態に関する保証を与えてくれます。自分が使っているDHCPサーバがバグのあるバージョンだと判明した場合、単に修正済みバージョンをインストールして、すべてのクライアントに正しいIPアドレスが与えられたことを確認すれば終わりです。非SEシステムだと、攻撃者がシステムを乗っ取って痕跡を隠しているのではないかという不安が残ります。

SELinuxはドメイン間の強力な分離を提供します。私は、rootパスワードを公開したDebian機を2年間に渡って稼働させ、現在は同じくrootパスワードを公開したFedora Core機を数ヶ月間稼働させています。これらのマシンは、root権限でクラッキングを行おうとする数多くの試みに耐えてきました。ご自分でもログインしてみたければ、http://www.coker.com.au/selinux/play.htmlで詳細を参照してください。また、DebianとGentooを搭載したSELinuxプレーマシンの情報を掲載したサイトへのリンクも設けてあります。こうしたマシンにログインする際には、同じrootアカウントを自分の敵かも知れない他の人々と共有することになるという点に注意が必要です。X11またはSSH エージェントのフォワーディングを有効にした状態でこうしたマシンにログインしたり、秘密にすべきだと思われるデータをこうしたマシンに送信したりするのは、極めて愚かな行為です。こうしたマシンにログインした後で、別のマシンにsshしてもいけません！ もしこれらの問題に自分で対処する自信がなければ、プレーマシンを使うのはやめておく方が無難でしょう。なお、著者はこのFedora Core SELinuxプレーマシンを、自分のハードウェア上で、自分の余暇を使って稼働させているという点にご注意ください。これは、Red Hatの公式なサービスではありません。

これらのプレーマシンは常に稼働しているわけではないこと、こうしたマシンのモニタリングには時間がかかること、および所有者が多忙なときには電源を落とされることにご注意ください。

Fedora Core 2のリリースでは、SELinuxのサポートが統合化されました（ただしデフォルトでは無効化されています）。これを使って、Red Hat Enterprise Linux（RHEL）4でリリースするコードのテストが行われました。しかし、細かい点では多少の違いが生じるはずです。予定では、RHELのデフォルトポリシーはFedora Coreに比べて若干制限がきつくなります。それがユーザにとって必要なものだという判断からです。計画によると、Fedora Coreの将来のバージョンでもFedora Core 2より制限の強いポリシーが採用されることになっていますが、それでもRHELよりは制限の弱いものになるでしょう。

SELinuxの動作の詳細

SELinuxのすべての面を制御するのが、SELinux ポリシーデータベースです。各プログラムがどのドメインで実行可能かを決定し、各ドメインがアクセスできるタイプを指定します。典型的なポリシーは10万以上のルールで構成されます。しかし、この数を気にする必要はありません。ポリシーを書く場合には高水準マクロを使用するので、たった1つの行が1万個ものポリシールールになる可能性もあるからです。ポリシーを分析して自分のセキュリティ目標が正しく実装されているか確認するためのツールが用意されていますし、Unixパーミッションを使用するシステム上にあるすべてのファイルのパーミッションに比べれば、10万個のルールというのはかなり少ないと言えます。

Fedora Core 2の目標は、何も変更を加えなくてもデフォルトポリシーのままでほとんどのユーザが利用できることです。ポリシーに対する最も一般的な変更を1行オプションの形で利用できるようにするため、ポリシー中に1組の調整可能オプションが用意されます。これには、ユーザが dmesgでカーネルメッセージログを読めるようにするか、システム管理者（sysadm_r）が直接SSH経由で、またはXセッションを起動してログインできるようにするか、ユーザがTCPソケットにバインドできるようにするか、などが含まれます。

10万個のルールを含むポリシーデータベースは、ディスク上でおよそ2.6 MBのファイルになり、ロード後はそれと同じサイズのカーネルメモリを占有します。Fedora Core 3に添付されているデフォルトのstrict ポリシーには29万個以上のルールが含まれており、7 MB以上のカーネルメモリを使用します。Fedora Core 3用のデフォルトのtargeted ポリシーには約5000個のルールがあり、およそ150KBのカーネルメモリを占有します。

現時点では、SELinux はメモリ使用に関する最適化がまだ行われていません。しかし、この点については将来的な作業の計画が存在し、メモリ使用量を削減する方法が明らかにされています。使う予定のないデーモンに対するポリシーファイルを削除して、ずっと小さなポリシーを構築するのは難しくありません。オタワLinuxシンポジウム2003で、著者はHP iPAQ PDAへのSELinuxの移植作業に関する論文を発表しました（http://archive.linuxsymposium.org/ols2003/Proceedings/でお読みいただけます）。64MBのRAMと32MBのストレージを持つiPAQ上でstrict ポリシーを適用したSELinuxを完全に動作させることに成功し、さらに小さなマシンでも動作可能だと考えています。しかしFedora Core 2に関しては、デフォルトの構成として現在最も一般的に使用されているハードウェアをターゲットにしています。旧式のマシンを使用している場合は、最小限のポリシーを構成することでメモリ使用量を削減し、性能を向上させるのが良いかも知れません。

SELinuxシステムでは、すべてのプロセスが、アイデンティティ、ロール、ドメインの3つの部分からなるコンテキストを持ちます。アイデンティティは、該当するユーザ名がSELinuxポリシー内に記述されている場合にはログイン用のUnixアカウント名、それ以外の場合は、システムプロセスならsystem_u 、ポリシーに名前が記述されていないユーザのプロセスならuser_u になります。ロールは、どのドメインが許可されるかを決定するもので、他のドメインへの遷移を制限するために使用されます。たとえばuser_r ロールはドメインsysadm_t（システム管理用の主要ドメイン）を持つことが許されません。したがって、user_u というアイデンティティはuser_r というロールを持つことしか許されず、そのuser_r ロールはsysadm_t ドメインを持つことが許されていないという関係になります。こうして、アイデンティティuser_u でログインした人は、絶対にsysadm_t ドメインに到達できないことになるわけです。これらの機能すべてがFedora Core 2のデフォルトのポリシーで有効化されているわけではありません。現在我々はデーモン用のポリシーに作業を集中しており、ユーザドメインのポリシーをより制限の弱いものにする予定です（targetedポリシーにはユーザログインに対する制限はありません）。

セキュリティコンテキストは、「アイデンティティ:ロール:ドメイン」という形のプレーンテキスト文字列で表されます。ですから、システム管理に使用される典型的なコンテキストは、root:sysadm_r:sysadm_tになります。アクセス可能なすべてのオブジェクトが、この形式のセキュリティコンテキストを持ちます。ドメインというのは、単にプロセスに付与されるタイプのことです。そしてパーミッションがプロセスにシグナルを送ったり、ps用に /proc エントリを調べる場合、プロセスのドメインをタイプとして使ってドメイン-タイプルールのチェックが行われます。ディスク上のファイルについては現在のところロールは使用されておらず、すべてのファイルがobject_r というロールを持つことになります（このロールは単なるプレースホルダーとして使われているだけで、ポリシーにとって特に意味はありません）。ファイルのアイデンティティは、常に作成元プロセスのアイデンティティと同じになります。これを制約ポリシーソースファイルの中で使用して、ファイルのタイプを変更するアクセスの可否を決定します。ファイルのコンテキスト変更へのアクセスはポリシーによって制御されますが、非特権での変更が許される場合、ユーザドメインがファイルのタイプを変更するためには、ファイルのアイデンティティが（変更の前後ともに）プロセスのアイデンティティと一致していなければなりません。たとえば、rjc:user_r:user_t というコンテキストを持つプロセスがrjc:object_r:user_games_rw_t を rjc:object_r:user_games_ro_t に変更することは可能ですが、john:object_r:user_games_rw_t というタイプとの間で変更を行うことはできません。

実行中プロセスのセキュリティコンテキストを表示するには、(例1)に示すように、psの-Zオプションを使用します。

  PID CONTEXT                                  COMMAND
 1634 root:user_r:user_t                       -bash
 1662 root:user_r:user_t                       ps ax -Z

ファイルとディレクトリのセキュリティコンテキストを表示するには、(例2)に示すように、lsの-Zオプションを使用します。

drwxr-xr-x  root     root     system_u:object_r:bin_t          bin
drwxr-xr-x  root     root     system_u:object_r:boot_t         boot
drwxr-xr-x  root     root     system_u:object_r:device_t       dev
drwxr-xr-x  root     root     system_u:object_r:etc_t          etc
drwxr-xr-x  root     root     system_u:object_r:home_root_t    home
drwxr-xr-x  root     root     system_u:object_r:root_t         initrd
drwxr-xr-x  root     root     system_u:object_r:lib_t          lib
drwx------  root     root     system_u:object_r:lost_found_t   lost+found
drwxr-xr-x  root     root     system_u:object_r:default_t      misc
drwxr-xr-x  root     root     system_u:object_r:mnt_t          mnt
drwxr-xr-x  root     root     system_u:object_r:usr_t          opt
?---------  ?        ?                                         oracle
dr-xr-xr-x  root     root                                      proc
drwxr-x---  root     root     system_u:object_r:user_home_dir_t root
drwxr-xr-x  root     root     system_u:object_r:sbin_t         sbin
drwxr-xr-x  root     root                                      selinux
drwxr-xr-x  root     root     system_u:object_r:default_t      srv
drwxr-xr-x  root     root                                      sys
drwxrwxrwt  root     root     system_u:object_r:tmp_t          tmp
drwxr-xr-x  root     root     system_u:object_r:usr_t          usr
drwxr-xr-x  root     root     system_u:object_r:var_t          var

コンテキストが割り当てられていないファイルの場合、lsで表示されるコンテキストが空欄になることに注意してください（通常これは /proc、/selinux、/sys などの永続ラベルをサポートしていないファイルシステムの場合にだけ生じます）。lsに stat(2) の実行権限がないファイルについては、Unixパーミッションが“?---------”、ユーザとグループが“?”で表示され、コンテキストは空欄になります。

シェルプロンプトからidコマンドを使うと、例3.「idコマンドの出力例」に示すようにコンテキストも表示されます。

uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=root:user_r:user_t

strict ポリシーを適用してSELinux システムを稼働させると、プログラムのおかしな動作に気づくことが珍しくありません。アプリケーションにとって必要なことだけを許すようにSELinuxポリシーを書いていると、多くのアプリケーションがそれ以外のことをしようとすることが分かり、アプリケーションのバグが見つかるのです。

SELinuxを使用する場合、プロセスのコンテキストを変更できるのは実行時だけです。プロセスのドメインとロールは、execシステムコールで使われたコンテキストとファイルのタイプに基づいて自動的に変化します。また、execを呼び出す前にプロセスがコンテキストを指定することも可能です。当然、これはSELinuxポリシーに依存します。アイデンティティ、ロール、およびドメインは、すべてポリシーによって制御されるからです。

Fedoraにおけるポリシーの実装

Fedora Core 3から、SELinuxポリシーのソースは /etc/security/selinux/X/src/policy/ に格納されることになりました（X は使用するポリシーに応じて“strict” または“targeted”になります）。このディレクトリ内で、make loadコマンドを使ってポリシーのコンパイルとロードを行います。このコマンドによって、ポリシーがバイナリ形式にコンパイルされ、その後カーネル内にロードされます（即座に効力が現れます）。また、/etc/selinux/X/policy/policy.YYというファイルにポリシーのバイナリが格納されます（X は “strict”または“targeted”、 YYはポリシーのバージョン番号）。この位置から、ブートの初期段階で /sbin/init がロードを行います。コンフィグファイル /etc/selinux/config が、どのポリシーファイルをロードすれば良いかinit に指示します。Fedora Core 3はポリシーバージョン18をサポートしています。

SELinuxシステムの起動に際して、initはまず最初に /proc をマウントし、SELinuxが有効化されているか判断します。SELinuxがカーネル内に存在するかどうかは、selinuxfs というファイルシステムタイプの有無でチェックします。SELinuxがカーネル内に存在しないか、または selinux=0 というカーネルパラメータによって無効化されている場合は、非SEシステム上と同様にブートが進行します。SELinuxが検出された場合は、仮想ファイルシステム /selinux がマウントされ、カーネルがサポートしているポリシーバージョンを調べるために /selinux/policyvers がチェックされます。その後、ポリシーデータベース/etc/selinux/X/policy/policy.YY がカーネル内にロードされます。

ポリシーのロードが終わると、実行中の全プロセス（ポリシーはブートの初期段階でロードされるので、init とカーネルスレッド群だけ）にsystem_u:system_r:kernel_t というセキュリティコンテキストが付与されます（注意：以後任意の時点で起動されるすべてのカーネルスレッドにこのコンテキストが与えられます）。ポリシーをロードし終わった init は、自分自身を再実行します。ポリシーには、domain_auto_trans(kernel_t, init_exec_t, init_t)というルールが含まれています。これは、kernel_t ドメインがタイプinit_exec_t のファイル（たとえば /sbin/init）を実行する場合、ドメインが自動的にinit_t（/sbin/init にとっての正しいドメイン）に遷移することを意味しています。その後、init は通常と同じ作業を行い、システムが起動します。各カーネルスレッドはkernel_t のまま実行を続けます。

ファイルとディレクトリのコンテキストは、拡張属性（XATTRと呼ばれるもの）に格納されます。詳しくは、attr(5)、getfattr(1)、およびsetfattr(1)の各manページを参照してください。基本的には、XATTR というのはディスク上のファイルのプロパティであり、名前と何らかのデータというペアで構成されます。SELinuxのファイルまたはディレクトリのコンテキストは、永続ファイルシステムではsecurity.selinux という属性に格納されます。proc ファイルシステムはこれをサポートしておらず、SELinuxは内部的に自分専用のラベルをファイルとディレクトリに付与していますが、この情報はgetxattr(2) APIを通して公開はされません。devpts ファイルシステム（/dev/pts のUnix98疑似ttyに使用）は、getxattr(2) を通して各疑似ttyのコンテキストをアプリケーションに公開するとともに、setxattr(2) によるデバイスのコンテキスト変更をサポートしています（sshdやその他の類似プログラムがttyデバイスのコンテキストを変更できるようにするため）。永続ストレージを備えるファイルシステム（ext2、ext3、Reiserfs、XFS、vfat、その他）の場合は、2つの選択肢があります。そのファイルシステムタイプ上にあるすべてのファイルに特定のコンテキストを付与する方法と、XATTRを使って各ファイルシステムオブジェクトごとにコンテキストを格納する方法です。たとえば、iso9660（CD-ROM）ファイルシステム内のファイルは、すべてsystem_u:object_r:iso9660_tというコンテキストを持つことになります。これをgenfs ラベリングと呼びます。ext2、ext3、およびXFSはXATTRをサポートしており、Fedoraはセキュリティ属性名前空間のサポートつきでコンパイルされているので、デフォルトのポリシーではこれらはXATTRを使ってラベリングされますが、これは任意に選択可能です。Fedoraに含まれるReiserFSのコードは、SELinuxのラベル付き操作を正しくサポートしていません。これは、Reiser4以前はハンス・ライザー氏がXATTRのサポートに無関心だったためです。したがって、SELinuxを動作させる場合ReiserFSをルートファイルシステムとして使うことはできません。

XFSには、XATTRに関して1つ大きな問題があります。XATTRがiノードに収まらない場合は、1つのデータブロックごとに1つのiノードという形でデータブロックに格納されるのです。mkfs.xfs のデフォルトの設定は、ブロックサイズが4096バイト、iノードのサイズが256バイトになっています（SELinuxのXATTRを格納するには、iノードが30バイトほど小さすぎます）。つまり、デフォルトのXFSファイルシステムでは、SELinux のXATTRが1つのiノードにつき4096バイトを占めることになり、多くの場合これはディスク空間のかなりの部分に相当してしまいます！ XFSファイルシステムの作成時に“-i size=512”というオプションを使用すると、iノードのサイズが512バイトになり、SELinuxのXATTRがiノードに収まるようになります（スペースと性能の面で大きなメリットが得られます）。また、512バイトのiノードにすると、明らかにその他の操作も少し性能が向上します。XFSを使用する場合、もし将来SELinuxを使う予定があるなら、512バイトのiノードを使ってすべてのファイルシステムを作成しておくと良いでしょう。

最近のLinuxカーネル（たとえば最新のFedoraカーネルや標準の2.6.8.1カーネル）上で、最新バージョンのmount を使ってファイルシステムをマウントする場合、ファイルシステムのコンテキストを設定するためのオプションが利用できます。たとえば、メールスプール用ファイルシステム内のすべてのファイルに対してコンテキストを設定するには、“-o context=system_u:object_r:mail_spool_t”というオプションを指定してファイルシステムをマウントします。メールスプールにXFSファイルシステムを使用した大規模なメールサーバがある場合、これによってiノードサイズの問題を回避することが可能です。ext3のような、XATTRのオーバーヘッドがほとんどないファイルシステムの場合でも、context= というマウントオプションを使うことで若干オーバーヘッドを減らすことができ、既存のファイルシステムを再ラベリングする必要もなくなります（ファイルシステムに多数のファイルが存在する場合、再ラベリングには長い時間がかかります）。

FedoraにおけるデフォルトのSELinuxポリシー

Fedora Core 3では、targetedポリシーがデフォルトのポリシーになっています。この決定に至るまでには多くの議論がありましたが、要点はSELinuxをできるだけ多くの人に使ってもらいたいということでした。あまりにもチェックが厳しく、したいことが自由にできなくなると判断されれば、みんなSELinuxを無効にしてしまうでしょう。我々としては、現時点で少数の人に大量の保護を提供するよりも、むしろ多くの人にほどほどの量の保護を提供したいと考えました。Fedora Core 3をデフォルト通りインストールするとtargetedポリシーを使ってSELinuxが有効化され、これをstrict ポリシーに変更するにはsystem-config-securitylevel というプログラムを実行します。

ポリシーのソースパッケージをインストールすると、/etc/selinux/X/src/policy/ にSELinuxポリシーのソースがインストールされます（Xの部分は使用するポリシーによって“strict”または“targeted”になります）。このポリシーソースディレクトリの下に、各ドメインの .te ファイルが格納された domains/program/ というサブディレクトリがあります。使用していない（そして使用する予定もない）ドメインに相当する .teファイルを削除することによって、カーネルメモリの使用量を削減できます（同時に性能も向上します）。たとえば、BINDを実行していないマシンがある場合は、named.te を削除すると良いでしょう。その後“make load”コマンドでポリシーを再ロードすれば、カーネルメモリの使用量が減少します。ただし、間違ったファイルを削除するとシステムをenforcingモードで起動できなくなってしまうので注意してください。今のところ、こうしたチューニングは上級者にだけお勧めします。

SELinuxの使用を開始する際には、enforcingというカーネルパラメータがあることに注意してください。これは、カーネルをenforcingモードとpermissiveモードのどちらにするか決めるものです。permissive モードの場合、SELinuxは自分がすべきことをログに記録しますが、実際には何の操作も阻止しません。enforcingモードの場合、SELinuxは操作の阻止を行います。ポリシーに間違いがあると、ログインもできなくなる可能性があります！ ですから、SELinuxを平常稼働させるときはenforcing=1 というブートパラメータを使用します。そして何か問題が生じたときに、enforcing=0 でブートして問題のデバッグを行います。また、/etc/selinux/config ファイルにもpermissiveモードでのブートを可能にする設定項目があります。

SELinuxの使用を中止するときは、カーネルパラメータselinux=0 を使用します。するとSELinuxの全機能が無効化され、SELinux サポートを有効にせずにカーネルをコンパイルしたのと同じ結果になります。この機能を利用して、ファイルシステムの破壊といった問題が生じたときのリカバリを行った人もいます。しかしこれはお勧めしません。selinux=0で動作しているときは、ファイルやディレクトリを作成してもSELinuxのコンテキストが付与されません。ということは、もしも /etc/passwd や/etc/shadow といったシステムの動作に欠かせないファイルを差し替えると、次にSELinuxを起動したときシステムが正しく動作しないことになります。これは重大な問題ではなく、CDからのブート、システムリカバリのためのブート、XATTRをサポートしていないバックアップソフトを使用したバックアップからのリストアなどを行った場合にも、同じ問題が生じます。これを解決するには、ファイルシステムを再ラベリングすれば良いのですが、破損したシステムを修復して作業を保存する際には selinux=0 の代わりにenforcing=0 を使う方が簡単です。ファイル /etc/selinux/config を編集することによってSELinuxを恒久的に無効化することもできます。

Fedora Core 2のリリースは、SELinuxにとって大きな意味を持つ出来事でした。主要ディストリビューションが完全なSELinuxサポートを含む形でリリースされたのは、これが初めてだったからです。もう1つの重要な一里塚がFedora Core 3であり、主要ディストリビューションが初めてSE Linuxをデフォルトのインストールオプションとしてリリースされました。Red Hat Enterprise Linux 4はFedora Coreの開発を引き継ぐ形で作られ、SELinuxのサポートがさらに進められます。RHEL 4がリリースされるときには、Fedora Coreの業績およびFedoraでSELinuxを学んだユーザから多くの恩恵を受けたものになるでしょう。

FedoraのSELinuxに関するサポートは、IRCサーバirc.freenode.netの #fedora-selinux チャンネルと、Fedora SELinuxメーリングリスト（http://www.redhat.com/mailman/listinfo/fedora-selinux-list）で行われています。著者は普段 #fedora-selinuxに接続しており、同メーリングリストにも参加しています。これらのフォーラムで皆さんのご質問にお答えできるのを楽しみにしています。

関連情報

• Security-Enhanced Linuxに関するNSAのサイト: http://www.nsa.gov/selinux/

• Fedora Core SELinux FAQ： http://people.redhat.com/kwade/fedora-docs/selinux-faq/

• Fedora CoreのSELinuxに関するIRCチャンネル： irc.freenode.net、 #fedora-selinux

• Fedora CoreのSELinuxに関するメーリングリスト： http://www.redhat.com/mailman/listinfo/fedora-selinux-list

• SELinuxプレーマシン： http://www.coker.com.au/selinux/play.html

著者について

Russell Cokerは、2003年8月以来Red HatでSELinuxプロジェクトに携わっています。Red Hatに入る前は個人でコンサルタントを営み、余暇を使ってSELinuxの作業を行っていました。彼が初めてSELinuxについて知ったのは、2001年のオタワLinuxシンポジウム（OLS）でNSAのPete Loscocco氏がSELinuxについて講演したときのことです。翌2002年のOLSでは、DebianディストリビューションにSELinuxサポートを追加するという自分の作業について論文を発表しました。Debianに関する作業の一環として、自分が使用するすべてのプログラムをサポートするポリシーを書き、その過程でSELinuxサンプルポリシーの中心的寄稿者になりました。OLS2003およびLinux Kongress 2002でも、SELinuxに関する論文を発表しています。