間違いだらけの備忘録

このページの内容は無保証でありこのページの内容によって直接、または間接に損害を受けられたとしても私は責任を取りません。

SELinuxの方向性

http://www.selinux.gr.jp/selinux-users-ml/200602.month/1444.html

私の感想としては SELinux が目指しているものと
SELinux 以外が目指しているものがずいぶん異なると感じました。
(以下は、私の感想であって、スレッド内に登場した文章ではありません。)

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

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

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

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

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

だから、システム管理者は「最大の保証」と「最小の負担」のどちらを望むかで
選ぶことになるでしょう。

うーむSELinuxに感じていた違和感の元はここか..

参考
http://www.selinux.gr.jp/selinux-users-ml/200602.month/1441.html

このページにはhatena以外のサービスからのコンテンツが埋め込まれています。 hatenaによりGoogle AdSense 広告が埋め込まれています。