【セキュアOS SELinux入門】第5回設定に関する基礎知識をマスターする

機能なセキュアOSを使用していても，その設定が不十分だったら意味がない。セキュリティ管理者にとっては，きちんとした設定を施すことがシステムの安全性を確保するための第一歩となる。今回は，SELinuxを設定するときに必要な基礎知識を説明する。

Fedora Core 2に用意されているポリシー･ファイル

　SELinuxを導入したシステムのTEやRBAC（連載第2回参照）の動作は，「ポリシー・ファイル」と呼ばれる設定ファイル群の内容で決まる。

　表1にFedora Core 2に含まれるポリシー・ファイルを示す。表から分かるように，ポリシー・ファイルは，「policy.17」「file_contexts」「policy」という3種類のファイルまたはディレクトリで構成される＊1。

表1●Fedora Core 2に含まれるポリシー・ファイル

/etc/security/selinux/policy.17	カーネルが読み込む，バイナリ形式のポリシー・ファイル
/etc/security/selinux/file_contexts	ファイルとタイプの関連付けを記述したファイル
/etc/security/selinux/src/policy	ポリシーのソース・ファイルが格納されたディレクトリ。複数のファイルで構成される。設定を編集する場合はこれらのファイルを編集する。makeコマンドによりpolicy.17とfile_contextsに変換する

　policy.17がポリシー・ファイルの要（かなめ）となるもので，このファイルにおいて，ドメインがアクセスできるタイプの設定と，ドメイン遷移の設定がなされている。これはバイナリ形式のファイルである。file_contextsは，ファイルに付加するタイプを設定したものである。

　policyディレクトリにあるファイル群は，「ポリシーのソース・ファイル」と呼ばれ，SELinuxの設定を変更するときに利用する。セキュリティ管理者は，policy.17とfile_contextsを直接編集することはない。これらのファイルは編集に適さない形式であるからだ。設定を変更する際は，policyディレクトリに存在するポリシーのソース・ファイルをテキスト・エディタで編集した後，これをpolicy.17とfile_contextsに変換する。このpolicyディレクトリ（およびその中のファイル群）は，Fedora Core 2のSELinuxではインストールされない。インストール方法については，次回の連載で説明する。

ポリシー・ファイルの根幹をなすドメイン遷移の設定

図1●システム起動時からのドメイン遷移の流れ

　ポリシー・ファイルの根幹をなすのが，policy.17に記載されている，ドメイン遷移の設定である。このドメイン遷移を設定するにあたっては，まず最初に，プロセスが起動したときのドメインの割り当ての“大まかな流れ”を把握しておくことが大切である。

　一般的なドメイン遷移では，システムの起動とともに各プロセスに対して次々とドメインが割り当てられていく（図1[拡大表示]）。このなかで特に重要なのが，デーモンとユーザーに対する権限の割り当てに関連した，図中の(1)，(2)，(3)の処理である。

　(1)は，デーモン・プロセスにドメインを割り当てるときのドメイン遷移である。起動スクリプトからデーモンが起動するタイミングでドメインを割り当てる。(2)は，ログインしたユーザーのシェルにロールに応じたドメインを割り当てるときのドメイン遷移である。(3)は，コマンドラインから起動されたデーモンに適切なドメインを割り当てるときのドメイン遷移である。

Fedora Core 2のSELinuxで設定が必要な場合

　従来のSELinuxの難点は，導入時の設定が面倒なことだった。Fedora Core 2のSELinuxでは，特定のアプリケーションに対応した設定が含まれる（Fedora Core 2のSELinuxをインストールするとその設定も同時にインストールされる）ので，そのアプリケーションを使う限りでは改めて設定しなくて済む。

　ただし，次のような場合には，セキュリティ管理者が設定を施す必要がある。

(1) 設定は用意されているものの権限が足りない

　アプリケーションに対応した設定が用意されていても，設定中のアクセス権が不十分なために，アプリケーションのプロセスがうまく動作しないことがある。このような場合は，足りないアクセス権をポリシー・ファイルに追加する必要がある。

　ちなみに，アプリケーションに対応した設定が用意されているか否かは，psコマンドの-Zオプションでプロセスのドメインを確認すれば分かる。設定が用意されている場合は「httpd_t」や「sendmail_t」のようにアプリケーションに関連した名前のドメインが付与されている。

(2) 設定を修正してセキュリティ強度を高める

　Fedora Core 2での設定は，使いやすさを優先するあまり，“甘く”なっている場合がある。安全性をより高めるには，セキュリティ管理者が設定を強化する必要がある。

(3) 設定が用意されていないデーモンを動作させる

　設定が用意されていないデーモンを動作させると，図1の(1)と(3)のドメイン遷移が起こらず，起動スクリプトのドメインであるinitrc_t，あるいはユーザー・シェルのドメインであるsysadm_tを引き継いで動作する。initrc_tとsysadm_tは非常に大きな権限を持つため，この権限でデーモンを動作させるのは危険である。この場合は，デーモンをより小さな権限で動作させるために，新たなドメインを定義することが望ましい。

　設定が用意されているデーモンでも，ソース・コードからコンパイルしてインストールした場合には，Fedora Core 2に含まれるものとはパスが異なることがある。この場合も，デーモンがinitrc_tまたはsysadm_tで動作してしまうことがあるので，新たな設定を用意する必要がある。

(4) 新たなロールを作成する

　Fedora Core 2で用意されているロールは，sysadm_r，staff_r，user_rの3種類である。このほかのロールが必要な場合は，セキュリティ管理者が設定を追加する必要がある。

　Fedora Core 2のSELinuxを用いて，Webサーバー機能などを有したインターネット・サーバーを立ち上げるときには，主に（1）と（2）のケースが当てはまる。そのため，本連載では，権限を追加したり，修正したりする事例を次回以降で紹介する予定である。

permissiveモードとenforcingモードの違い

　SELinuxは，「enforcingモード」と「permissiveモード」という2種類のモードを持つ。

　enforcingは，通常運用時のSELinuxのモード，つまり，「SELinuxによるアクセス制御が有効になった状態」のモードである。このモードではアクセス制御が働くため，きちんと設定されていないアプリケーションは動作しない。アプリケーションを起動しようとしても，アクセスが拒否されたことがログに記録されるだけで，何も起こらないわけだ。

　一方，permissiveは，（例え設定が不十分であっても）一切アクセス拒否されずに，言い換えれば通常のLinuxと同じようにアプリケーションは動作する。ただし，本来はアクセスが拒否されるべきであり，その事実はログに記録される。つまり，アクセスが拒否されたことはログに記録されるが，アプリケーションは普通に動作する。

　このpermissiveモードは，アプリケーションの設定を施していく際に用いられる。セキュリティ管理者は，ログに記録された「足りない権限」を設定に追加しながら，アプリケーションのアクセス制御の設定を詰めていくことになる。また，システムに障害が発生したときの原因究明にも用いられる。

モードの確認と切り換え

　SELinuxを導入したシステムが，どのモードで動作しているかは，getenforceコマンドで確認できる。
次のようにコマンドを実行すると，現在の動作モードが出力される。


# getenforce
enforcing

　モードの切り替えには，setenforceコマンドを使う。


# setenforce  0     →permissiveモードに切り替える
# setenforce  1     →enforcingモードに切り替える

　permissiveモードの動作の例を以下に示す。


# setenforce  0                 →(1) permissiveモードへの切り替え 
# getenforce                    → モードの確認 
permissive 
# newrole -r staff_r            →(2) staff_rロールへの切り替え 
# getcon                        → ロールの確認 
root:staff_r:staff_t 
# cat /etc/shadow               →(3) アクセス権限のないファイルの閲覧
                                    (permissiveモードなのでアクセスが行える)
root:$1$cxxxxxx:12539:0:99999:7::: 
bin:*:12539:0:99999:7::: 
# dmesg                         →(4) ログを確認
                                    (/etc/shadowファイルへの
                                     アクセス拒否が記録されている)
･･･省略･･･
audit(1083415117.963:0): avc:  denied  { read } for  pid=8335 exe=/bin/cat
 name=shadow dev=hda6 ino=2612073 scontext=root:staff_r:staff_t tcontext=
system_u:object_r:shadow_t tclass=file
･･･省略･･･

　このように権限が足りない場合には，アクセス拒否のログが出力される。ただし，ログは記録されるものの，アクセス制御そのものは実行されないことに注意する。permissiveモードで動作させているシステムのセキュリティ強度は通常のLinuxと同じである。そのため，実運用しているシステムをpermissiveモードで稼働させるときは，外部から切断されているかなどを十分に気を付ける必要がある。

　そのため，実運用しているシステムでは，permissiveモードの動作確認や設定作業が終わったら，


# setenforce 1

を実行してenforcingモードに戻すことを忘れないようにする。

　次回（7月13日公開予定）は，ポリシーのソース・ファイルをインストールして設定を追加する方法を解説する。