Linux OS のセキュリティ-2
こんにちは、ニックネーム たいちょう です。
前回は、GnuPG についてやってみましたね。
今日は、SELinux ユーザーについて考えてみます。実際にもやってみます。
SELinux ユーザーの詳細な説明は省略しますが、実際に手を動かしていくと、分かってきますよ。
従来の Linux ユーザーとは別に、SELinux ユーザーがいる、と思っていてください。
今、Red Hat 系のOSでは、targeted ポリシーというのがデフォルトで有効になっています。
このセキュリティ機能は、大変有益です。最近、Linux関連の脆弱性が多く出てきました。そのたびに、サーバ管理者はヒヤヒヤしたり、対応に追われていると思います。
SELinuxを有効にしていれば、従来のアクセス制御(DAC)、の上に、強制アクセス制御(MAC)が効くので、枕を高くして寝られます。インターネットに開かれたサーバを立てている場合は必須だと思っています。
私も、プライベートで立てているサーバで有効にしています。
SELinuxは有効だと思いますが、日本では積極的に使われていないようです。なぜでしょう。
歴史的には、strict ポリシーというのがありました(15年くらい前から)。
この頃から、SELinuxを有効にすると何もできないので、disable にしよう、というのが特に日本で広まったという印象を持っています。それは、このときの、strict ポリシが厳格すぎて、確かに手も足も出ない、許可をするのもどうしたらいいかわからない、できても膨大な時間がとられる、ということだったからと思っています。あと、日本人の気質として、みんなそう言っているからからそうする、というのもあると思います。
私は、その時代に、strict ポリシに挑戦していた時期があります。
ポリシー作成の実験をしていたのですが、1日にシステムを再起動すること 100回以上なんて当たり前、その都度何かしらを許可していって疲れ果てた、という記憶があります。もちろん、それを私自身はとても楽しんでいたのですが。
この strict ポリシーは、開発者も実用的ではないと考えたのか、数年前に、targeted ポリシーに統合されています。
targeted ポリシーは、守るべきものだけ守って、その他は unconfined ドメインとして、confine しない、やりたいようにやらせる、という理想と現実との妥協案のようなポリシーです。
targeted ポリシーを実装するために、最初、example ポリシーというのが考えられ、すぐに reference ポリシーとなりました。この reference ポリシーは、モジュールとして、コマンドでロード・アンロードができます。
strict ポリシーは monolithic ポリシーでしたので、strict ポリシーを経験した者からすると、reference ポリシーはかなり使いやすくなっている感じです。monolithicポリシー方式は無くなっていなくて、使われる場面もあります。reference ポリシーはもちろんオープンソースで、私の出したなんちゃってなパッチも採用されるぐらいオープンです。新しいパッケージで、そのパッケージに関わるオブジェクトを confine したいと思う場合は、この reference ポリシーのモジュールを作る必要がありますしね。
今、CentOS 等でSELinuxを有効にしても、confine していないプログラムは、unconfined_t ドメインで動きますので、何も制約を感じないでしょう。また、ログインユーザーも、unconfined_u:unconfined_r:unconfined_t というセキュリティコンテキストがつくので、ほぼ制約はないと言ってもいいのではないでしょうか。
しかし、このような設定は、SELinux の機能自体を使ってもらおう、というための設定であり、SELinux の素晴らしい機能を享受できているとは言い難いです。やはりSELinux の真骨頂は必要な設定を施して利用するところかと思います。どんな設定をしたらいいのかを一言で述べるのは難しいです。それぞれの要件に応じて、としか言いようがありません。
今日は、system が必要とする設定は refpolicy に任せて、ユーザ周りの設定をやってみたいと思います。
やることは、SELinux ユーザーの設定について試してみる、です。
CentOS-minimal をインストールします。
vim が入っていないので入れます。
# yum install vim
SELinux 関連のオブジェクトを操るのに必要な semanage も入っていないので、どのパッケージに入ってい
るのかを調べます。
# yum provides semanage
その結果から、以下のパッケージを入れます。
# yum install policycoreutils-python
semanage login で、Linux ユーザーと SELinux ユーザーをマッピングしてみます。
Linux ユーザーを作成します。
# useradd hoge
# password hoge
# su - hoge
セキュリティコンテキストを確認します。
SELinux が有効になったシステムでは、-Z により、セキュリティコンテキストを確認できます。
$ id -Z
Linux ユーザー hoge は、unconfined_u という、SELinux ユーザーにマッピングされています。
Linux ユーザー hoge は、デフォルトマッピングを使用してるため、以下のように semanage login -l 出力には表示されません。__default__ にマッピングされたということです。
# semanage login -l
__default__ unconfined_u s0-s0:c0.c1023
root unconfined_u s0-s0:c0.c1023
system_u system_u s0-s0:c0.c1023
semanage login コマンドにより、既存のマッピングを変更できます。
Linux ユーザ hoge を、SELinux ユーザー user_u にマッピングし直してみます。
# semanage login -a -s user_u hoge
-a オプションは新規レコードを追加し、-s オプションは Linux ユーザーがマッピングされる SELinux ユーザーを指定します。
もう一度、semanage login -l を実行します。
# semanage login -l
__default__ unconfined_u s0-s0:c0.c1023
root unconfined_u s0-s0:c0.c1023
hoge user_u s0
system_u system_u s0-s0:c0.c1023
root からログアウトして、hoge ユーザーでログインし直します。
$ id -Z
このままだと、hoge のホームディレクトリは、unconfined_home_t のままです。
root でログインし直します。
SELinux にとって、restorecon でラベルを貼り直すのは基本です。
# restorecon -RFv /home/hoge
ラベルが付け変わったか確認します。unconfined_home_t からuser_home_t に変わっていればいいです。
# ls -laZ /home/hoge
user_u:object_r:user_home_t:s0 .bash_logout
user_u:object_r:user_home_t:s0 .bash_profile
user_u:object_r:user_home_t:s0 .bashrc
もし、hoge ユーザーを、デフォルトの設定(この場合は、unconfined_u)に戻したいのなら、次を実行します。
# semanage login -d hoge
# restorecon -RFv /home/hoge
次の実験です。
semanage user コマンドで、新たに SELinux ユーザーを作成してみます。
この場合は、hoge_u というSELinux ユーザーを作成します。
# semanage user -a -r s0-s0:c0.c1023 -R "staff_r unconfined_r webadm_r sysadm_r system_r" hoge_u
この場合は、foo_u というSELinux ユーザーを作成します。
＃semanage user -a -R "staff_r dbadm_r" foo_u
MLS が有効になったシステムですと、次の例のようにできます。
# semanage user -a -R "staff_r dbadm_r" -r s0-s0:c0.c100,c201 foo_u
SELinux ユーザーが、おおまか何が許されているかを知りたいです。
調査のためには、seinfo を入れなければいけません。
# yum provides seinfo
setools-console というパッケージのようです。
では、インストールします。
# yum install setools-console
この seinfo というツールを使えば、ロールに対してどんなドメインが許可されているかがわかります。
$seinfo -ruser_r -x
Dominated Roles:
user_r
Types:
git_session_t
sandbox_x_client_t
git_user_content_t
virt_content_t
policykit_grant_t
httpd_user_htaccess_t
telepathy_mission_control_home_t
qmail_inject_t
gnome_home_t
...(snip)...
以下のコマンドにより、確かめてみます。
#semanage user -l
SELinux User Prefix MCS Level MCS Range SELinux Roles
guest_u user s0 s0 guest_r
root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
sysadm_u user s0 s0-s0:c0.c1023 sysadm_r
system_u user s0 s0-s0:c0.c1023 system_r unconfined_r
unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r
user_u user s0 s0 user_r
xguest_u user s0 s0 xguest_r
SELinux ユーザーが、root だと(Linux ユーザーでないことに注意)、sutaff_r sysadm_r system_r unconfined_r になれます。
デフォルトのロールをもう一度確認します。
# semanage login -l
__default__ unconfined_u s0-s0:c0.c1023 *
root unconfined_u s0-s0:c0.c1023 *
system_u system_u s0-s0:c0.c1023 *
では、デフォルトのロールを現在、unconfined_u になっているのを、user_u に変更しておきます。
# semanage login -a -s user_u __default__
__default__ user_u s0 *
root unconfined_u s0-s0:c0.c1023 *
system_u system_u s0-s0:c0.c1023 *
Linux ユーザー hoge2 を作成します。
# useradd hoge2
# passwd hoge2
hoge2 ユーザーでログインし直します。
# exit
$ id -Z
su コマンドを発行してみます。
$ su
su: Authentication failure
root になれません。
ホームディレクトリには、以下のようなセキュリティコンテキストがついていました。
$ ls -laZ
drwxr-xr-x. root root system_u:object_r:home_root_t:s0 ..
-rw-r--r--. hoge2 hoge2 user_u:object_r:user_home_t:s0 .bash_logout
-rw-r--r--. hoge2 hoge2 user_u:object_r:user_home_t:s0 .bash_profile
-rw-r--r--. hoge2 hoge2 user_u:object_r:user_home_t:s0 .bashrc
制限ユーザーは root になれない、というシステムをつくることができました。
お疲れさまです、今日はこの辺で。 ニックネーム たいちょう でした。
次回もお楽しみに。
(参考)
http://danwalsh.livejournal.com/66587.html
https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Confining_Users-Confining_Existing_Linux_Users_semanage_login.html
https://wiki.gentoo.org/wiki/SELinux/Tutorials/The_purpose_of_SELinux_roles
https://wiki.gentoo.org/wiki/SELinux/Users_and_logins
