Red Hat Enterprise LinuxでのSELinuxの活用

執筆者: Faye Coker、Russell Coker

• はじめに
• targetedポリシー
• targetedポリシーの目的
• サポートされている設定変更
• strictポリシーのサポート
• /etc/selinux/ディレクトリ
• targetedポリシーのユーザロール
• その他のポリシーの開発
• 執筆者について

はじめに

Red Hat Enterprise Linux 4のリリースによって、商業的にサポートされるSecurity-Enhanced Linux（SELinux）の実装が初めて登場しました。レッドハットの最新のエンタープライズオペレーティングシステムのインストールにはSELinuxが導入され、デフォルトで有効となっています。以前は、SELinuxは商業的サポートが存在しないことが問題として指摘され、そのために多くの大規模サイトがSELinuxの利用を見合わせました（Fedora Core 3にはそれらのサイトで必要とされるサポートがありません）。現在、Red Hat Enterprise Linux 4ではSELinuxがOSの一部としてサポートされており、SELinuxの利用に対するそうした拒絶は解消しました。SELinuxは現在、最大規模のサイトでの使用に適していると広く考えられています。

targetedポリシー

targetedポリシーは、SELinuxで利用できる2つのポリシータイプの1つです。もう1つのタイプはstrictポリシーです。Red Hat Enterprise Linux 4はstrictポリシーをサポートしていませんが、これはFedora Core 3システムでは利用できます。targetedポリシーはFedora Core 3で導入されました。その目的は、特によく使用される一部のデーモン（httpd、dhcpd、mailman、named、portmap、nscd、ntpd、portmap、mysqld、postgres、squid、syslogd、winbind、およびypbind）のセキュリティを、強制アクセス制御（MAC）ルールを利用して強化することです。これらのデーモンは、それぞれ独自のドメインで動作します（httpdではhttpd_t、namedではnamed_tなど）。専用に作成されたポリシーを持たないシステム上のその他のデーモンは、unconfined_tドメインで動作します。unconfined_tドメインで動作するデーモンとシステムプロセスは、SELinuxのポリシーがすべてのアクセス権を付与するため、Linuxの標準である任意アクセス制御（DAC）方式のみをアクセス制御に使用します。SELinuxでは、アクセス権がドメイン単位でプロセスに付与されます。各ドメインには、ファイル、ディレクトリ、その他のリソースの各タイプに対して実行可能な動作のセットがあります。

strictポリシーでは、あらゆるプログラムが制限的なドメインで動作します。これは使いやすいとはいえません。targetedポリシーの目的は、ユーザビリティを損なうことなく、最も重要な領域でセキュリティを強化することです。

targetedポリシーを実行しているかどうかを判定するには、以下を確認します。

・/etc/selinux/configファイルにはSELINUXTYPE=targetedという行が含まれるはずですが、これはコンピュータがブート時に使用するポリシーを指定するものであることに注意してください。マシンでポリシーを変更しても、リブートするまではSELINUXTYPE変数は実行中のポリシーと異なる値のままです。

・idコマンドを実行すると、下記のような出力が返ります。

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

rootのセキュリティコンテキストの最後の部分から、rootシェルがunconfined_tドメインで実行されていることが分かるため、targetedポリシーが使用されています。strictポリシーを実行しているシステムでは、rootシェルのSELinuxコンテキストはroot:staff_r:staff_tまたはroot:sysadm_r:sysadm_tのいずれかになります。id -Zコマンドを実行すれば、UNIXのUID/GID情報なしでセキュリティコンテキストを確認できます（シェルスクリプトに役立ちます）。

固有のポリシーを持つデーモンはデフォルトでは独自のドメインで動作しますが、管理者はそれらのデーモンが実行時にドメインを移行しないように指定することによって、それらがunconfined_tドメインで動作するように設定できます。たとえば、setsebool -P httpd_disable_trans 0コマンドを実行すると、httpdプロセスはunconfined_tドメインで動作します。あらゆるデーモンは、unconfined_tドメインでの動作を指定するbooleanを持っています。これは、管理者がデーモンを独自のドメインで正しく動作させることができない場合に使用できます（ただし、できるだけセキュリティを高めるため、対象のデーモンに制限的なドメインでの動作を許可する必要がある場合は、ポリシーに変更を加えることを推奨します）。こうしたやり方でデーモンをunconfined_tドメインで実行すると、システムのセキュリティが低下するため、可能なかぎり避ける必要があります。

boolean値の変更は、setseboolコマンドか、system-config-securitylevelプログラムで実行できます。setseboolを使用する場合、リブートしても変更が維持されるようするには、-Pオプションを使用します。

boolean値を表示するには、getseboolコマンドを使用します。単一のbool値を取得するには、コマンドラインでその名前を指定します（getsebool httpd_disable_transなど）。すべてのboolean値を表示するには、getsebool -aコマンドを使用します。

このbooleanを変更する最も簡単な方法は、system-config-securitylevelコマンドを使用することです（「図1. boolean値の変更」を参照）。httpdサーバは、たいていのデーモンよりも多くのbooleanを持っています。httpdサーバは設定の幅が非常に広く、SELinuxポリシーの設定はデーモンの設定と一致する必要があるからです。

おそらくtargetedポリシーで最もよく使用されるbooleanは、SELinuxとうまく連携できない設定になっているデーモンのSELinux保護をディセーブルにするものです。そうしたbooleanはイネーブルにしないよう推奨します。それらは非常時の措置として提供されているだけです。ビジネス要件のためにSELinuxで制限できないような方式でデーモンを実行する必要がある場合は、システム全体の保護をディセーブルにするよりも、そのデーモンの保護をディセーブルにする方がはるかに望ましい方法です。


図1. boolean値の変更

デーモンのポリシーファイルは、targetedポリシーを使用する場合、/etc/selinux/targeted/src/policy/domains/program/ディレクトリに置かれます。それらのポリシーのソースファイルは、一般に命名規約（syslogd.teなど）に基づいて.teファイルと呼ばれています。

ポリシーまたは.teファイルには、対応するドメインのルールが含まれます。たとえば、syslogd.teファイルには、syslogd_tドメインの動作のルールが定義されています。これには、コンソールへのロギング、ログファイルの変更と作成、およびリモートロギングといった動作が含まれます。

ポリシーファイルは、ファイルコンテキスト（.fcファイル）と対応している必要があります（/etc/selinux/targeted/src/policy/file_contexts/program/）。ファイルコンテキストファイルには、デーモンが使用するファイルおよびディレクトリに適用する必要のあるセキュリティコンテキストが一覧されています。たとえば、named.fcファイルには、次のような行が含まれます。

/var/named(/.*)?                system_u:object_r:named_zone_t
/var/named/data(/.*)?           system_u:object_r:named_cache_t

最初の行から、/var/named/ディレクトリがnamed_zone_tタイプであることが分かり、第2の行からは、/var/named/data/ディレクトリがnamed_cache_tタイプであることが分かります。

/usr/sbin/named         --      system_u:object_r:named_exec_t

この行からは、実行可能ファイルnamedがnamed_exec_tタイプであることが分かります。デーモンのエントリポイントの実行可能ファイルに対する命名規約は、X_exec_tです。ここで、Xはデーモンドメインの名前です。

これによって、デーモンが実行された場合、unconfined_tドメインからデーモンのドメイン（この例ではnamed_t）への移行が発生します。strictポリシーを使用している場合、デーモンは正しく動作するために管理セッション（sysadm_rロールとsysadm_tドメイン）から起動する必要があります。targetedポリシーを使用している場合は、ユーザのログインに使用されるドメインはunconfined_tだけなので、こうした問題はありません。

namedの主なポリシーファイルはnamed.teです。これには、named_tドメインへのアクセスを許可するルール、およびドメインを定義し、それに対する移行を発生させるルールが含まれています。named.teで最も重要な行は、次の行です。

daemon_domain(named, `, nscd_client_domain')

これは、named_tドメインを定義し、このドメインで/var/runへのpidファイルの書き込み、子プロセスの分岐、syslogへのロギングといった、デーモンの実行するすべての基本的動作を実行することを許可します。また、named_exec_tタイプの実行可能ファイルが実行されたときに、unconfined_tからnamed_tにドメインを自動的に移行させるポリシーもあります。

targetedポリシーの目的

targetedポリシーが開発された理由は、strictポリシーが多くのシステム管理者にとって管理しにくいと考えられたことです。SELinuxが最初にFedora Core 2に導入されたとき、その使いやすさについて否定的なフィードバックが寄せられました。Fedora Core 3のリリースではtargetedポリシーがデフォルトとなり、不満はほとんど聞かれません。一般的な評価では、200万人以上がSELinuxを使用していることに気付くことさえなく、Fedora Core 3を使用していると考えられます。それらのマシンはユーザが望むとおりの作業を実行するため、ユーザはデーモンが一部の動作の実行を許可されていないことに気付きません。それらの動作は、標準的な設定を持つシステムの通常の動作では、デーモンによって実行されません。

ポリシー開発の一般的目的は、strictポリシーの設定を容易にし、デフォルト設定向けに調整すると同時に、targetedポリシーで増加するターゲットがより多くのデーモンをサポートするようにすることです。こうした開発を通じて、strictポリシーが使いやすくなり、targetedポリシーがより厳格になるにつれて、targetedポリシーとstrictポリシーは集約されていくと考えられます。しかし、近い将来にこれらのポリシーを統合できるとはあまり考えられません。strictポリシーとtargetedポリシーの基本的な違いは、strictポリシーがSELinuxのIDおよびロールの機能を使用するのに対して、targetedポリシーがそれらを使用しないことにあります。

targetedポリシーのユーザビリティ機能の一部は、unconfined_tドメインで動作するデーモンの多くに由来します。最終的には、大部分の対象となるデーモンがより制限的なドメインで機能することが望まれます。ただし、targetedポリシーのユーザビリティに関する主な利点は、ユーザセッションの制限的なドメインが欠如していることにあります。この機能は長期にわたって必要になると考えられます。そのため、strictポリシーとtargetedポリシーを統合することは不可能です。

サポートされている設定変更

targetedポリシー内で大幅な変更を行うと、Red Hat Enterprise Linuxのサポート契約は破棄されます。これは、デーモンのポリシーに変更を加えること（特にそれらの変更がアクセスの限定に関係する場合）、およびRed Hat Enterprise Linuxの一部であるプログラム用に新しいドメインを追加することを指します。Red Hat Enterprise Linuxの一部ではないプログラムに新しい変更を加えることは、報告されているバグが対象のプログラムと無関係であるかぎり許可されます。

targetedポリシーに過剰な変更を加えるか、strictポリシーを使用することによって、サポート対象の設定から外れた場合は、SELinux機能のサポートはGPS（レッドハットのコンサルティング）を通じて提供されます。SELinuxに無関係の問題に対するサポートでは、問題を報告する際にSELinuxをpermissiveモードにすることが必要な場合があります。

strictポリシーのサポート

Global Support Servicesを通じてサポートされるポリシーはtargetedポリシーだけであるため、Red Hat Enterprise Linux 4リリースには、targetedポリシーのポリシーパッケージしか含まれていません。

strictポリシーのパッケージは、自社のシステムソフトウェアをすべて1つのソースから用意するポリシーを持つ組織のために、レッドハットのWebサイトで提供されます。それらの組織はstrictポリシーをレッドハットから取得できますが、それは通常のサポートプロセスではサポートされません。Red Hat Enterprise Linux 4システムでSELinuxを実行するユーザは、誰でもselinux-policy-strictパッケージ（およびポリシーソースを変更する場合はselinux-policy-strict-sourcesパッケージ）をダウンロードし、システムをstrictポリシーに変換できます。

FedoraまたはRed Hat Enterprise Linux 4システムをstrictポリシーに変換するには、strictポリシーパッケージをインストールし、Xセッションでsystem-config-securitylevelを実行する必要があるだけです。これによって、SELinuxを設定するタブが表示されます。SELinuxタブにはドロップダウンリストボックスがあり、それを使用してインストールされたポリシーを選択できます（「図2. インストール済みポリシーの選択」を参照）。


図2. インストール済みポリシーの選択

ポリシーを変更するために選択すると、その選択を確認するダイアログボックスが表示されます（「図3. 選択の確認」を参照）。


図3. 選択の確認

このオプションを選択したあと、可能なタイミングでできるけ早くマシンをリブートする必要があります。ブートプロセスの初期に、/etc/rc.sysinitスクリプトによってファイルシステムが新しいポリシータイプの正しいラベルで再ラベル付けされます。現在のコンフィギュレーションファイル/etc/selinux/configには、使用されているポリシータイプに対して1つのフィールドがあり、ここに次のブートで使用されるポリシータイプが示されています。同じフィールドは、一部のアプリケーションで現在動作しているポリシーを確認するために使用されます。そのため、system-config-securitylevelによってポリシーを変更したあと、リブートしてその変更を適用するまでの間は、実行中のポリシーの認識と現実とが一致しないため、一部のプログラムが期待どおりに動作しない場合があります。これは孤立した障害であるため、セキュリティ問題ではありませんが、ユーザビリティ問題になる場合があります。実行中のポリシーが次のブート用に設定されたポリシーと一致しない場合の影響の1つは、cronジョブが動作しないことです。

ファイルシステムの再ラベル付けプロセスでは、システム上の各ファイルの完全修飾パス名と一連の正規表現との比較が行われ、最もよく一致したものがファイルに割り当てるべきセキュリティコンテキストを示します。そのため、ファイルシステムの再ラベル付けプロセスは、strictポリシーとtargetedポリシー間の変換と関係しています。このプロセスは、少なくともfind /の回数だけ行われ、おそらく正規表現に対して行われる計算量のために、その2倍行われます。現在のハードウェアに普通にインストールされたRed Hat Enterprise LinuxまたはFedoraでは、これは数分で済みます。独自のファイルが数多くインストールされている場合は、それだけ長い時間がかかります。

サーバがそれ自身のファイルシステム上に数百万のファイルを持ち、同一のセキュリティコンテキストを備えている場合は、コンテキストマウントオプションを使用してそれらをラベル付けするのが最良の方法です。これによって、再ラベル付けにかかる時間を節約でき、同時にセキュリティラベルのストレージ要件を緩和できます。たとえば、Squidのキャッシュファイルはsystem_u:object_r:squid_cache_tとラベル付けされます。Squid専用のファイルシステムを備えた大規模なSquidサーバの場合、/etc/fstabファイルのファイルシステムオプションフィールドにfscontext=system_u:object_r:squid_cache_tを指定できます。

strictポリシーを使用するRed Hat Enterprise Linux 4システムは、非SE機能向けにのみサポートされます。システムにそうした変更を加えるお客様は、SELinuxに直接関係しない問題についてサポートを要請するときに、SELinuxをpermissiveモードにして問題を再現することが必要な場合があります。permissiveモードでは、SELinuxはある動作を許可しないと報告する一方で、実際にはその動作の実行を禁止しません。permissiveモードは、SELinuxポリシーの開発や各種のテストに使用します。SELinuxが問題の原因かどうかをすばやく判定するには、setenforce 0コマンドによってSELinuxをpermissiveモードにし、テスト完了後にsetenforce 1によってenforcingモードに戻します。ただし、本稼働中のマシンをpermissiveモードにすることは推奨されません。

現在、strictポリシーのサポートは、GPS（レッドハットのコンサルティング部門）を通じてのみ提供されています。通常のサポートチャネルでは、strictポリシーに関する問い合わせを受け付けないため、対応時間に関する保証も適用されません。strictポリシーはRed Hat Enterprise Linux 4のCDに含まれず、公式にはディストリビューションの一部ではありません。

/etc/selinux/ディレクトリ

Fedora Core 3では、SELinuxのベースディレクトリは/etc/selinux/に変更されました。これはRed Hat Enterprise Linux 4で使用されているディレクトリであり、将来のすべてのリリースで使用されます。/etc/selinux/targeted/ディレクトリには、targetedポリシーのファイルが収められています。strictポリシーを実行している場合は、/etc/selinux/strict/ディレクトリがあります。デフォルトでは、ポリシーのソースはインストールされません。ポリシーのソースをインストールするには、selinux-policy-targeted-sourcesパッケージが必要です（strictポリシーを実行する場合は、selinux-policy-strict-sourcesパッケージが必要）。このパッケージをインストールすると、/etc/selinux/targeted/src/（またはstrict/src/）ディレクトリがインストールされます。このポリシーディレクトリ内に、ポリシーのソースが収められます。

targetedポリシーのユーザロール

targetedポリシーを使用する場合、実際にはユーザロールおよびドメインは使用されません。すべてのユーザIDがsystem_rロールの使用を許可されるため、IDとロールはSELinuxのアクセス制御で何の役割も果たしません。strictポリシーを使用する場合は、システムのセキュリティポリシーに対して重要性を持つユーザ（その1つのカテゴリは管理権限を付与されているユーザ）は、すべてユーザファイル内にエントリを持ち、自分に付与されているロールを指定する必要があります。targetedポリシーでは、ポリシー設定のこの部分は不要です。

その他のポリシーの開発

SELinuxの設計では、設定オプションはすべてSELinuxポリシーに含まれるため、設定オプションがバイナリ内にコンパイルされることはありません。これは、SELinuxの設定全体をプログラムを変更せずに変更できることを意味します。Red Hat Enterprise Linux 4システムの管理者は、strictポリシーとtargetedポリシーのいずれにも基づかない独自のポリシーを自由に構築できます。しかし、この場合もRed Hat Enterprise Linux 4のサポート契約の範囲外となります。

執筆者について

Faye Cokerはパートタイムのシステム管理者です。Russell CokerはレッドハットでSELinuxに関する仕事に携わっています。