2006年2月23日

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

 半田@(CCさくらの再放送が始まったので)「はにゃ〜ん♪」状態です。

> 「Multiple contexts」というスレッドがその議論になります。
読みました。私の感想としては SELinux が目指しているものと
SELinux 以外が目指しているものがずいぶん異なると感じました。
(以下は、私の感想であって、スレッド内に登場した文章ではありません。)

AppArmor 等の目標は「ユーザランドアプリケーションの欠陥により

発生する被害を最小限に抑えるための保険となること」であり、
SELinux の目標は「ユーザランドアプリケーションの欠陥により発生する被害を最小限に
抑えるための保険となること」ではなく「許可されていない情報の漏洩・改ざんが
絶対に発生しないことを保証できるアクセス制御を実現するための機構となること」だと思いました。

だから、 SELinux はパス名を嫌い、 AppArmor 等はパス名を好んでいるのでしょう。

OSレベルでのセキュリティ強化は前者を実現するためにあると私は考えているので、
このスレッドを読んで方向性の違いに驚きました。

SELinux はユーザランドアプリケーションを尊重せず、全てラベルを中心に考えるので、
アプリケーションの振る舞いからラベルを割り当てようとすると壁にぶつかります。
SELinux が絶対に譲れない条件は「どんなにシステム管理者に負担を強いることになっても、
情報フローの保証を行うために解析可能なポリシー構造であり続けること」です。

AppArmor 等はユーザランドアプリケーションを尊重しており、
全てユーザランドアプリケーションを中心に考えるので、
アプリケーションの振る舞いから識別子(ラベル)を割り当てることができます。
AppArmor 等が絶対に譲れない条件は「情報フローの保証は行えないけれど、
システム管理者への負担を最小限に抑えられるポリシー構造であり続けること」です。

だから、システム管理者は「最大の保証」と「最小の負担」のどちらを望むかで
選ぶことになるでしょう。情報フローの保証まで考慮して SELinux のポリシーを
策定できるシステム管理者がどれくらい存在するか気になるところです。
ほとんどのシステム管理者は情報フローを考慮せずに使っているのではないでしょうか?
そして、情報フローを確認しないままアクセス許可を付与することは、
パス名ベースのアクセス許可よりも大きな落とし穴(予期せぬプログラムの実行や
予期せぬ重要なファイルへのアクセス)に遭遇しそうです。
「audit2allow を使うな」とも言われていますし、 SELinux を正しく使うには
情報フローの分析が必須なんでしょうね。

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




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