The Linux Foundation Japan Symposium#8

昨日/今日と、The Linux Foundation Japan Symposium#8 に出かけてきた。
今回のテーマは『カーネル開発とセキュリティ』という事で、SELinux開発の中心人物である James Morris や Paul Moore を招いて、SELinuxプロジェクトの全体像と、最新のトピックについて話してもらう他、日本からはTOMOYO Linuxの原田さんの講演があった。

資料は下記のURLで参照できるほか、後日、VTRも公開されるので、ぜひ見てもらいたい。
http://www.linux-foundation.jp/modules/eguide/event.php?eid=10

で、実はLFのシンポジウムには併設BoFというものがあり、要は、国内の開発者にカーネルメンテナーとサシで議論する場を提供するというのが趣旨である。
今回は、JameやPaulが来日するという事で、午前中をセキュリティ関連のトピックに割り当ててもらった。

私のネタは『Network Application and SELinux』だが、話はもっと哲学的な所から始まる。

本質的に、人間とプログラムはどの様な関係にあるべきか?

計算機の上で動作するプログラムは、全て、人間(ユーザ)の代行として動作している。OS上では、プロセスが"代行者"であり、認証メカニズムによって、システムはユーザとプロセスを関連付けている(例えばuid)。
システム内のアクセス制御は、プロセスに関連付けられた属性に基づいて行われる。FilesystemではuidやgidとUNIX Permissionが、SELinuxではsecurity contextが、RDBMSではDatabase Roleに基づいてアクセス制御が実施される。

SELinuxに関して言えば、"代行者"とsecurity contextを関連付ける方法は3つしかない。
1.Authentication ... Operating System
2.Labeled Networking ... SE-PostgreSQL, X/SELinux, Xinetd
3.Do nothing ... Apache, Samba, など

このうち、"Do nothing"はタチが悪い。
例えば、Apacheがクライアントからの要求を処理する時、リクエスト処理プロセスはユーザの"代行者"であるにも関わらず、サーバプロセスの権限で動いてしまっている。これって、アクセス制御の一貫性の観点からはどうなのよ?

望ましいのは、Apacheがクライアントの処理を実行する間は、そのユーザ(又は Anonymous)の権限に化ける事。で、終わったら元に戻る。

ただ、ApacheだのTomcatだのその辺は、バックエンドのスレッドがリクエストを処理するというモデルになっており、容易にはSELinuxのモデルとはマッピングできないのだ。
SELinuxは1プロセス=1ドメインを強制する)

スレッドはメモリ空間を共有しているため、個々のスレッドが別々のドメインで動作すると、ドメイン分離に反してしまう。困った困ったクマー

ただ、一つ考慮に値するアイデアを思い付いた。
例えばスレッドが httpd_t → httpd_t.guest というようなドメイン遷移を行うモデルならどうだろう。3年前に議論された階層化ドメインを使っているのだが、子ドメインは常に親ドメインよりも制約された権限の下で動作するという特性がある。

子ドメインへの遷移に限り、スレッドにドメイン遷移を認めたとしよう。それは何を意味するのか?

少なくとも、単純なドメイン分離の崩壊を意味するというワケではない。なぜなら、全てのスレッドのプロセス空間に存在するのは、高々 httpd_t ドメインから参照できるものに過ぎないから。

つまり、httpd_t.guest ドメインは、httpd_tドメインの一部であると考えれば辻褄が合う。一時的に権限を制約されたモードだと考えるのだ。

Paulによると、この手の議論は10年前から繰り返されてきているものだが、少なくとも上のロジックに穴は無いし、selinux-mlで議論する価値のあるものではないかとの事。

確実なモデルとしては、mod_selinuxの様に setexeccon() + ExecCGIというのが一番確かなのだが、Webアプリケーションのソフトウェア資産を活用するという観点からは、そうそう安易な道に流れる訳にもいかんだろう。

JamesがOttawaでのSELinux summitには来ないの?ぜひ議論すべきテーマでないか?と言っていたが、残念ながら今回はパス。
近いうちに SELinux-ml で議論を呼びかけてみたい。

この機能が実現できれば、LAPPスタックの上から下までを SELinuxカバレッジに含める事ができる。このインパクトは大きい。

発表はこれで終わりで、お役御免と思っていたら・・・(続くらしい)