思考の道具箱

Permissive Domainsによって、SELinuxはまたひとつ大きな進歩を遂げたと言える。
元記事 http://danwalsh.livejournal.com/24537.html

このブログの読者なら、マシンをpermissive、もしくはenforcingのモードに設定することについてはいろいろと読んだことだろう。Permissiveモードでは、すべてのチェックを行い、AVCメッセージを記録するが、アクセスは拒否しない。Fedora10およびFedora9の最新版では、SELinuxに新たな機能が追加されている。それは、管理者が、特定のプロセス(domain)をpermissiveに設定する機能だ。
permissiveに指定されたdomain(プロセス)は、SELinuxによるチェックを受け、AVCメッセージを記録されるが、アクセスは拒絶されない。ドメインの遷移のルールや、作成したファイルなどのタイプ付けなどは通常通り行われる。

これによって、SELinuxの大きな問題が解決される。

Redhat Enterpirse Linux4と5では、ある特定のプロセスについては、SELinuxによるアクセス制限を解除したい場合があった。SELinuxのpolicyを強制してしまうと、アプリケーションが動かないので、SELinux自体を止めてしまおうという管理者が多かった。
そこで、DOMAIN_disable_transというスイッチ(boolean)を持つpolicyを作った。このbooleanによって、initから起動されるスクリプトが、制限つきのドメインに遷移してしまうことを止めることができる。
例えば、 httpd_disable_trans というbooleanを設定すると、initから /usr/sbin/httpd を起動した場合に、initと同じ initrc_t のドメインのまま実行されるようにできる。通常、httpdが実行されるhttpd_t のドメインと違って、initrc_tのドメインなら、アクセスに制限は無い。httpdのサーバはSELinuxに邪魔されることはない。
しかし、一つ問題がある。initrc_tのドメインで実行されているプロセスによって作成されたファイルのラベル付けが、本来のhttpd_tのドメインの場合と異なってしまうのだ。
また、せっかくhttpd_tのドメインとアクセスできるようにしたほかの制限付きのドメインの設定が、initrc_tのドメイン相手だと無駄になってしまう。
このため、Fedora7では、disabled_transのbooleanは削除されてしまった。しかし、その代用品が無かった。

これまでは、そうだった。今やPermissive domainがある。

もう一つ別のSELinuxの問題として、サードパーティのソフト会社がSELinuxのポリシー付きでソフトウェアを出荷したいが、enforcingモードでのテストに自信がもてない、という点がある。
私のアドバイスはこうだ、まず、数百の実際の環境で実行してもらい、AVCメッセージを収集して、ポリシーを洗練させていけば良いだろう。長期間にわたってAVCメッセージが出なくなれば、その時点でenforcingモードに移行すれば良い。ただし、RHEL5の場合、マシン全体をpermissiveモードにする必要があった。
Permissive domainが使えれば、この問題も解決する。

つまり、新しいアプリケーション(ドメイン)のためにポリシーを書く場合には、まずはsystem-config-selinxのようなツールで最小限度のポリシーを作成する。そして、permissiveモードのマシン上でアプリケーションを実行し、AVCメッセージを集め、audit2allowなどのツールを使ってポリシーを拡張し、さらにテストする。この繰り返しだ。ただし、マシン全体をpermissiveモードにすることは、マシンを危険に晒すことになる。
Permissive domainが使えるならば、テストを行うアプリケーションだけをpermissiveにすることができる。