generic fallbacks of getpeercon()

追記:スレッドのアーカイブは↓
http://marc.info/?t=118080693400002&r=1&w=2

数日前にredhat-lsppでgetpeercon()が失敗した際の動作について「それはアプリが対処すべき」というやり取りがあった。
SE-PostgreSQLにも関わる部分なので、「unlabeled networkから接続があった時のgetpeercon()のフォールバック処理の標準的な手法ってどうなのよ?」と、SELinux-MLに投げてみた。

ちなみに、getpeercon()はSELinuxAPIで、ソケットの反対側のプロセスのセキュリティコンテキストを取得する。UNIXドメインソケットなら特別な設定は不要だが、TCP/IP経由で接続する場合にはLabeled Networkと呼ばれる、IPsec又はCIPSOの設定が必要になる。

Unlabeled Networkからのコネクションに対して、getpeercon()がどのようなフォールバック処理を行うかについて、いくつかの意見が出された。結局、何か「ドメイン」のセキュリティコンテキストを返すことが必要なのだ。
1. 設定ファイルに書いておく(XACE/SELinux)
2. コネクションを切って終了する(SE-PostgreSQL)
3. SECMARKのセキュリティコンテキストをエントリポイントとして、サーバのセキュリティコンテキストからドメイン遷移することで、代替コンテキストを生成(KaiGai, Venkat)
4. NIC又は(接続元)IPアドレス単位で代替コンテキストを持っておく(Paul Moore)

1と2は基本的に現状追認。そもそも、私は強制切断するような真似はしたくないから、この議論を持ちかけたのだ。

3.に関しては、サーバ毎に代替セキュリティコンテキストを分離できるメリットがある一方、強烈に理解しにくいというデメリットがある。
4.に関しては、直感的に設定しやすいというメリットがある一方、NICやアドレス単位で代替コンテキストを設定するので、サーバ毎に異なった代替コンテキストを設定できないというデメリットがある。

私としては、この議論を通じてgetpeercon()のフォールバック処理の標準的な方法に関するコミットメントが出来ればOKなので、サーバ毎の代替コンテキストを用意するなら、システム共通の(そしてNIC/IPアドレスに関連付けられた)代替コンテキストからさらにドメイン遷移を行えばよいという見解に同意。
Paulの方法が直感的であることは自明なので、最終的にこの方法で落ち着くだろう。
netlabel-toolsを使って、NIC/IPアドレスの組み合わせと代替コンテキストを設定することになる。代替コンテキストが設定されていれば、getpeercon()はunlabeled networkからのコネクションに対しても代替セキュリティコンテキストを返却することができる。
素晴らしい。

それともう一つ。
こうした議論をオープンなコミュニティで行うことで、間違いなくアイデアがブラッシュアップされてより洗練されたものになる。
さらに、その道のスペシャリストの力を借りることができるというメリットもある。
PaulはLinuxにCIPSOを移植した本人だし、自分にしてもSE-PostgreSQLの作業に専念できるのは大きい。

国家や企業の枠組みを超えて、皆で共有している技術を改善していく事こそ、オープンソースソフトウェア開発の醍醐味である。