2006年2月24日

[selinux-users:01446] Re: ラベルvsパス名


中村です。

On Thu, 23 Feb 2006 20:00:35 +0900
Tetsuo Handa wrote:
> > 「Multiple contexts」というスレッドがその議論になります。
> 読みました。私の感想としては SELinux が目指しているものと
> SELinux 以外が目指しているものがずいぶん異なると感じました。

> (以下は、私の感想であって、スレッド内に登場した文章ではありません。)
> AppArmor 等の目標は「ユーザランドアプリケーションの欠陥により
> 発生する被害を最小限に抑えるための保険となること」であり、
> SELinux の目標は「ユーザランドアプリケーションの欠陥により発生する被害を最小限に
> 抑えるための保険となること」ではなく「許可されていない情報の漏洩・改ざんが
> 絶対に発生しないことを保証できるアクセス制御を実現するための機構となること」だと思いました。
> だから、 SELinux はパス名を嫌い、 AppArmor 等はパス名を好んでいるのでしょう。
> OSレベルでのセキュリティ強化は前者を実現するためにあると私は考えているので、
> このスレッドを読んで方向性の違いに驚きました。

なるほど。すばらしいまとめです。
NSAの人と話したりML見た感じだと、
その感想は、NSAの考えに近いかと思います。

なので、NSAはポリシーについては意外と寛容ですよね
targeted policyなんてものがあるし。
ポリシーは他の人に任せて、自分達は、プラットフォームを作ることに集中したいようです。
だからこそ、ポリシーのメンテがTresysに移ったのでしょう。

けど、情報フロー分析って本当に難しいでしょうね。
covert channelまで考え出すと、死にそう。
#SELinuxで制限されてないOSの操作からの情報フローはどうするつもりなんだろ

> だから、システム管理者は「最大の保証」と「最小の負担」のどちらを望むかで
> 選ぶことになるでしょう。情報フローの保証まで考慮して SELinux のポリシーを
> 策定できるシステム管理者がどれくらい存在するか気になるところです。
これって、軍隊の一部ぐらいしかいないんじゃ?
とか思っちゃいます。
SELinuxの情報フロー分析ツール、ありますけど、使う気が起きない…
けど、情報フローの定式化って、TCSECの上のほうのレベルに確かありましたよね。
それを意識してるんでしょうかね。

> 「audit2allow を使うな」とも言われていますし、 SELinux を正しく使うには
> 情報フローの分析が必須なんでしょうね。
本当の意味で「正しく」使うには、そうなんでしょうね…
そこまではほとんど誰もやれないので、
現実的な解を、Fedoraを使って実験している、というところでしょう。

来週のSELinux Symopsium/Developer Summitで、
方向性がある程度明らかになるのでしょう。楽しみです。

Fedoraで思い出したのですが、
FC5-test3が出てますが、大実験が行われてます。
3つの新機能がありますが、個人的な感想。
1) Policy Module機能
 ポリシーをモジュールパッケージという単位で分割管理する機能。
 これは非常に使える。
違った書式(マクロのセット)で作ったポリシーをも追加できるようになるので。
2) Reference Policy(refpolicy)
 今のところ、相当上位レベルの開発者(下手するとTresys,Redhat)にしか役に立たない。
 これによって明らかによくなった、という気がしない…
 が、まだできたてなので今後に期待。
3) MCS/MLS
用途が謎。CC対応専用機能?

----
Yuichi Nakamura

投稿者 xml-rpc : 2006年2月24日 02:19
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/32165
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。