第3回 セキュアOS論争から見える「カジュアル」なセキュアOS

中村　雄一
日本SELinuxユーザ会
2007/8/8

---

　「至上主義」と「カジュアル派」は統合できるか？

　セキュアOSには、2つの対立する発想があることが分かりました。これに対応して、さまざまなセキュアOSにもそれぞれの思想が機能化され、実装されてきています。これらのセキュアOSを1つに統合できないものでしょうか？ Linuxの場合、標準のセキュアOSとしてSELinuxが採用されています。カジュアル派のセキュアOSを、SELinuxの機能を使って実装できれば、Linux用のセキュアOSはSELinuxに一本化できます。このようなことが可能なのでしょうか？

　カジュアル派の特徴の1つである「部分的なアクセス制御」については、SELinuxの上で実装可能です。例えば、SELinuxのtargetedポリシーでは、「すべての操作を許可するドメイン：unconfined_t」を用意し、アプリケーションにはデフォルトで、unconfined_tドメインが割り当てられるようにしています。そして、動作を制限したいアプリケーションにだけ、独自のドメインが付与されるようにしています。

　ただし、もう1つのカジュアル派の特徴「パス名ベースのアクセス制御」は、SELinuxの上で実装することは困難です。SELinuxの上で、パス名ベースのアクセス制御を疑似的に実現しているのが、SELinux Policy Editorです。つまり、設定をパス名ベースで行い、その設定をSELinuxのラベルベースの設定に変換します。こうすることで、ユーザーからは、パス名ベースのセキュアOSの使い勝手と同じように見えます。

（1）パス名ベースの設定書式 　domain httpd_t 　program /usr/sbin/httpd; 　allow /usr/sbin/httpd /var/www/** r; 　　　　　　　↓ファイル名から、ラベルを生成し変換 （2）SELinux（ラベルベース）の設定書式 ・/var/wwwにvar_www_t付与 　/var/www/(.*)?　　　　system_u:object_r:var_www_t ・http_tドメインにvar_www_tへのアクセス許可 　allow httpd_t var_www_t;file read; ・/usr/sbin/httpdにhttpd_tドメインを付与する設定   （今回は省略）

リスト3　パス名ベースのアクセス制御書式で設定

　単純な例を見てみましょう。リスト3の（1）は、SELinux Policy Editorの設定書式です。/usr/sbin/httpd（httpd_tドメインで動作）に、/var/www/html以下への読み込み許可を与えています。「/var/www/**」のように、パス名を使って設定しています。これを、SELinuxのラベルベースの設定書式に変換します。「/var/www」というファイル名から「var_www_t」というラベルを生成し、/var/www以下にvar_www_tというラベルを付与します。そして、httpd_tドメインがvar_www_tに読み込み、アクセスできる設定を生成しています。

　しかし、完全にパス名ベースのセキュアOSと同じ使い勝手にはなりません。例えば、ファイルの移動の問題があります。リスト3の例で、/var/www/index.htmlを、/opt/index.htmlに移動したとします。/opt/index.htmlのラベルはvar_www_tのように移動元のラベルが保持されます。これは、ラベルベースのセキュアOSのセキュリティを維持するため、必須の振る舞いです。すると、/usr/sbin/httpは、/opt/index.htmlにアクセスできます。

　一方、パス名ベースのセキュアOSの場合では、/opt以下にアクセス許可を別途与えない限り、httpdは、/opt/index.htmlにアクセスできません。このように、SELinux上でパス名ベースのセキュアOSのように設定した場合と、パス名ベースのセキュアOSを使った場合とで振る舞いが違います。

　このように、あくまで、SELinux Policy Editorは、SELinuxを簡単にするものであって、AppArmorを置き換えるものではないことが分かります。

　Linuxカーネルメーリングリストでも、「AppArmorをSELinuxの上で実装できるか？」という話題になったことがあります。しかし、

“Forcing AA to sit on top of SELinux would harm both AA and SELinux.” ――AppArmorをSELinuxの上に無理に実装すると SELinux、AppArmor双方に悪い結果をもたらす。 （AppArmorリーダーのCrispin Cowan氏の発言を引用）

という発言が出るなど、前向きな意見は出ていません。

　このように、2つの思想を1つのセキュアOSの中にまとめきれるものではありませんので、セキュアOSが1つに統一される可能性は低いと考えています。

　論争がいい物を育てると信じて

　今後も両陣営の論戦は続くことでしょう。セキュリティ至上主義派とカジュアル派に限らず、コミュニティで論戦があると「荒れた」イメージを持たれるかもしれません。しかし、論戦の中で切磋琢磨し、いい物が作られるものです。互いが持つ欠点も徐々に克服されていくことでしょう。

---

【息抜きコラム：第3回「最小特権」 〜 7人の強化超人編】 Linuxコンソーシアムセキュリティ部会 田口裕也 【前回までのあらすじ】 あまりにも強すぎるがゆえに取り扱いが難しかったため、システムから追い出され天上界に潜んでいた高信頼超人（トラステッドOS）の逆襲が始まる。rootユーザーのすべての権限を自在に操るシステム管理者に対し、7人の強化超人（セキュアOS）が刺客として送り込まれたのだ！ システム管理者の運命やいかに。 　絶大なる力を保持しているrootユーザーを操ることによってシステム管理者は正義超人（普通のOS）のチャンピオンベルトを腰に巻き、一時代を築いていました。 　と、そのとき突如黒い影が現れたのです。 強化超人 「ちょっと待ったあああっっっ」 　システム管理者の前に立ちはだかる、7人の強化超人！ 強化超人 「セキュアOSの強じんさを世に認知させるため、OSの支配者であるシステム管理者に試合を挑む！」 　OSの世界ではシステム全体を管理することができるroot権限さえ奪取できれば、すべての動作を行うことができてしまいます。この仕組みを解決することができなければ、信頼性の高いシステムを構築することはできません。 　管理作業を行うためになんでもできるroot権限を許可してしまうのではなく、必要な権限のみを割り当てる最小特権の仕組みが必要なのです。 　しかし、システム管理者はセキュアOSの慣れない仕様からか対戦を拒んでいます。 強化超人 「セキュアOSを導入させるためにはどんな手段でも選ばない。ハリケーンミキサーーー！」 システム管理者 「rootユーザーッ！！！」 　突然rootユーザーはバラバラにされ、いくつかの権限に分断されてしまいました。 図1　バラバラにされたroot権限 強化超人 「それぞれの権限は強化超人が1権限づつ預かっている。root権限を再び取り戻したければ、10日以内にすべてのセキュアOSを使いこなすことだ。」 システム管理者 「うぬぬ……」 T氏 「セキュアOSをかたくなにOFFにしてきたシステム管理者は挑戦状を受けざるをえない状況になったのだ。そしてここからシステム管理者の長い戦いが始まるのである！」 A君 「……先輩、今回のはさすがに無理がないっすか？」

3/3

Index
セキュアOS論争から見える「カジュアル」なセキュアOS
	Page1 セキュリティを数学的に証明できるラベル、実は使いづらい？ もうちょっと手軽にしてもいいんじゃない？
	Page2 「カジュアル派」の妥協点
	Page3 「至上主義」と「カジュアル派」は統合できるか？ 論争がいい物を育てると信じて 息抜きコラム：第3回「最小特権」

Profile

中村　雄一（なかむら　ゆういち） 日本SELinuxユーザ会 学生時代に情報処理の単位を落としたことがきっかけで、コンピュータに興味を持つ。 セキュアＯＳの布教活動、開発活動を日課としている。最近の興味は組み込み分野。

Security&Trust記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）