「ユーザスペース・オブジェクト・マネージャーの実装方法」（いくつか修正と追記あり）
jsossugのＭＬに和訳が流れていた。ありがたい。
Re: SELinux を用いたアプリケーションの作成についてよい参考資料は無いでしょうか？ (jsosug:00048) - 日本セキュアOSユーザ会 - SourceForge.JP
「ユーザスペース・オブジェクト・マネージャー」って何？というところが一般にはとっつきにくいかもしれないが、ようするにユーザが実行する大抵のアプリケーションが本当はこれに相当するのです。でも、アプリケーション自体が主体となってSELinuxのポリシーを利用するケースは少ない。大抵は、システムのセキュリティポリシーが、アプリケーションのできることに枠を嵌めて、それで済んでしまう。
アプリケーションが何をアクセスできて、何ができないか、その枠組みを決める手立てとして、従来のowner, group, otherのパーミッション以外に、SELinuxが使えるのは知ってるし、普通のポリシーで切り分けできる以上に細かいこともできるのは知ってるけど、具体的にはどうすんの？というお話。
上記の記事にも紹介されている以下の3文献、読んでみよう＞俺
- Using GConf as an Example of How to Create an Userspace Object Manager
- Application of the Flask Architecture to the X Window System Server
- Using the Flask Security Architecture to Facilitate Risk Adaptable Access Controls
追記：具体的にはどうすべきか？セキュリティを設計に組み込む
ＭＬの記事をちょっと読んでみたが、ポリシーの定義がいろんな切り口から考えられることはわかった。でも、「いろいろあります」のままではソフトウェアの開発の現場は困ってしまうだろう。
実際にアプリケーション自体がオブジェクトマネージャとしてダイナミックにアクセス権を制御することの有無にかかわらず、ここは一つ、開発手法の一部として、機能要件からセキュリティポリシーが（最適ではないにせよ）自動的に決定できるようなパターン化は必要だと思われる。（すでにそういう論文はあるに違いない）
その際、現在SELinuxで自明かつ最適とされているようなパターンをちょっと変えないといけないかもしれない。しかし、基本となるreference policyはたぶんいじらなくて済むはずだ。
おそらく、設計支援ツールに、ポリシーを明確に決定するためのパラメータ（資源をアクセスする権限のレベル、roleや、資源やアクセスの主体が有効である期間（初期化、遷移、destructor）の定義）の設定項目が多少増えることだろう。その後は、開発者はセキュリティポリシーの詳細を見ることは無くなるのが望ましい。実際にどのようなポリシーが作成されるのかは、初期設定されたセキュリティモデルと、コードの設計モデルから(最適でなくても良いから）形式的に決まるべきなのだ。
そうでなければ、アプリケーションをインストールする際に、実際のサーバ環境を ./configureでチェックし、必要なら適切にマージすることもできないだろう。
さて、そういう論文を探さねば＞自分
追記：SELinuxのツール作っているといえばTresys社
そこのEducationのサイトにあるドキュメントも読んでおくこと＞自分
