SELinuxのアクセス制御をデーモン単位に停止

SELinuxをすべて停止してしまう方法は、前の記事に書いた。では、デーモン毎にSELinuxのアクセス制御の有効・無効を変更するにはどうすればよいか？
コマンドsetsebool(8)を使用して、該当するブーリアン変数を適宜変更すればよい。例えば、httpdに関してSELinuxのアクセス制御を変更するには、以下の通り実行する(環境にもよるが、実行には数秒かかる)

# setsebool -P httpd_disable_trans=1
#

なお、-Pオプションは、再起動後もこの設定を保持せよ(persistant)、といことを指定するためのもの。
これ以外のデーモンについては、getsebool(8)コマンドを使って調査する。

# getsebool -a
NetworkManager_disable_trans --> off
allow_cvs_read_shadow --> off
＜＜略＞＞
oddjob_disable_trans --> off
oddjob_mkhomedir_disable_trans --> off
＜＜略＞＞
ypxfr_disable_trans --> off
zebra_disable_trans --> off
#

例えば、oddjobに関してはoddjob_disable_transおよびoddjob_mkhomedir_disable_transが関係しているだろうことが判る。

Google Analyticsをつらつらと眺めていると、検索語順位に『selinux 停止』というのが割と上位に来ている。これはおそらく、『Red Hat Cluster: SELinuxを停止』にヒットしているんだろうと思うが、需要が多いようなので、これ関連で一本書いてみた、というわけだ。

Red Hat Cluster: SELinuxを停止

前回に引き続き、RHCSをCongaで構成してみる話。
前回に述べた通りに/etc/redhat-releaseを詐称してCongaでクラスタを構成しようとしても、メンバはluciの管理下に入るものの、新規クラスタを作成できない、という現象が発生する場合がある。
これは、メンバ側でSELinuxが動いている場合に起こる現象のようだ。これを回避するためには、SELinuxを止めてしまう(disabled)か、警告のみ(permissive)に設定変更すればよい。これは、system-config-securitylevelもしくはsystem-config-securitylevel-tuiを使って設定変更すればよい。テキストエディタを使って、/etc/sysconfig/selinuxの中を、

SELINUX=disabled

もしくは

SELINUX=permissive

に変更してもOKだ。

前回提示した図(Congaのホームページから借用)

を見て欲しい。ここでricciは一般ユーザ権限で動作している。しかしながら、ricciは、luciからの要求に従ってシステムの設定を変更しなければならない。この権限問題を解決するために、ricciはdbus(messagebus)を通じてoddjobdへ設定変更を命令する。このoddjobdは、適切な権限をもって予め定められたジョブを実行する。

従って、SELinuxでricciからdbus経由でoddjobが実行するジョブに対するアクセス制御を適切に書いてあげればよいのだが、これがまだ不十分のようだ。将来的には修正されるのだろうと思う。

2007/10/31追記:
SELinuxをすべて停止するのではなく、デーモン単位に制御する方法について追記した。
『SELinuxのアクセス制御をデーモン単位に停止』

XenのDomUで、仮想コンソールにログインプロンプトが出ない・訂正

前の記事に嘘があったので訂正。

FC5でDomUをyum updateすると、仮想コンソールからログインできなくなる問題に対して、chcon -t tty_device_t /dev/xvc0(あるいは、chcon --reference=/dev/tty1 /dev/xvc0)とすればよい、と書いた。これは嘘ではないが、その後が嘘。というのは、再起動すると、この効果はなくなってしまうのだ。

で、解決篇。次のように実行する。

# ls -lZ /dev/xvc0
crw-------  root root system_u:object_r:device_t       /dev/xvc0
# semanage fcontext -a -t tty_device_t -f -c /dev/xvc0
# restorecon /dev/xvc0
# ls -lZ /dev/xvc0
crw-------  root root system_u:object_r:tty_device_t   /dev/xvc0
#

この内、semanageで若干時間がかかる。

なお、この情報源はこれ。BugzillaでBug 213277として扱われている。

XenのDomUで、仮想コンソールにログインプロンプトが出ない

Fedora Core 5でXenを使っていて、うまく動いていたDomUが、yum updateをした後、システムを再起動すると、仮想コンソールにログインプロンプトが表示されず、代わりに以下のようなSELinux(auditd)のメッセージが表示され続ける、という問題に出くわした。

audit(XXXXXXXXXX.XXX:X): avc:  denied  { getattr } for  pid=XXXX comm="agetty" name="xvc0" dev=tmpfs ino=XXXX scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file

よくよく調べてみると、yum update以前は、仮想コンソールは、普通のマシンと同じく

1:2345:respawn:/sbin/mingetty tty1
＜＜略＞＞
6:2345:respawn:/sbin/mingetty tty6

のようになっていたが、yum update以後は、

co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav

となっていて、デバイスが/dev/tty[1-6]から/dev/tty/xvc0に変更になっている。SELinux的にはどうなっているかというと、

# cd /dev
# ls -lZ xvc0 tty1
crw-rw----  root tty  system_u:object_r:tty_device_t   tty1
crw-------  root root system_u:object_r:device_t       xvc0
#

と、違っていることが解る。問題解決には、これを合わせてやればいいわけだ。

# chcon -t tty_device_t /dev/xvc0
#

この後、再起動するか、init 5などを実行する。

訂正記事を公開しました。