アカウント名:
パスワード:
以下のリンクは、lkmlでKyleという方が私のメッセージに返信してくれたものです。
Kyle氏が書いているように、SELinuxの開発サイドの基本的なスタンスは、「ポリシーはプロが書いて提供する」というものです。私は最初その考え方に抵抗がありましたが、色々やりとりをしながら次第にその考えに納得できるようになりました。それぞれのモジュール（パッケージ）を熟知したエキスパートが、対応するSELinuxの設定（ポリシー）を作成し、それが提供されていれば、ユーザはポリシーのことを気にせずに安心してシステムを使えるわけです。そうした考え方からは、「ユーザはポリシーを書くな」「ポリシーは（ソースでなく）バイナ
「中身を理解していなくても正しいポリシーには到達が可能」と私は思っています。
計測を繰り返し到達するというアプローチも存在するはずです。
Juliさん、
コメントありがとうございました。
> 「中身を理解していない」で「到達」と仰るところには違和感があります。 > 「到達」したか否かの判断を、「中身を理解していなくても」できるとお考えなのでしょうか？
自分の書いたものを読み直してみましたが、言葉足らずでした。まず使っている言葉について補足します。ここでいう「中身」はそれぞれのソフトウェア（パッケージ）の動作詳細を意味します。私は、Kyle氏やRussellが言うプロのポリシーとは、ApacheならApacheの開発者かそれに準じるレベルで動作を理解する者がポリシーを書く（書ける）という意味だと理解しています。次に「到達」ですが、「到達する状態」とは、必要なものが許可されて不必要なものは許可されないというポリシーです。
このような言葉の定義のもとで、私はあるソフトウェア（パッケージ）について、その開発者でなくても、あるいはそのソースコードを完全に掌握していなくても、それを用途に応じて動作させるためのポリシーを得ることが可能だと思っています。それを行えるかというのは要するに、動作を網羅した試験を行えるかということです（勿論、特定の状況（OSおよび他のパッケージのバージョン、それらの設定、コンテンツ等）が定められているというのは前提です）。
> そこに適度な透明性があり、ポリシーの妥当性を監査、検証できる第三者が居さえすれば、 > 問題視することではないと思えます。
逆に質問します。ここで書かれている「透明性」とは何ですか？バイナリで配布されるモジュールのポリシーについて、ユーザができることはそれを「信じる」しかない気がします。妥当性も同様です。そう考えると、結局SELinux陣営の言っていることは、「俺たちを信じろ」ということではないかと私は思っています。で、今まではあまり信じられないし信じたくないと思っていたのですが、少なくともKyle氏の作成したポリシーは信じられると思いました。ところで、「問題視することではない」と書かれていますが、私は「問題視していません」のでその点誤解なきようにお願いします。ただ、誰かが作ったポリシーを信じる以外に、自分で試行錯誤するのもありでしょ？と思っているだけです。それだけにすべきとは思いません。
> ここで言う計測をエキスパートがやらずにアマチュアである利用者が行うと > いうことになると、折角苦労して作成した強制アクセス制御の機構が有効に > 機能できないことになってしまわないかと危惧してしまいます。
言われている観点は理解できるのですが、網羅的な試験はソフトウェアの作成者でなくても行えるわけです。あなたが、Apacheのサーバを立てたとして、httpデーモン（のドメイン）を自動学習モードで動かせば、pngひとつから全てのコンテンツへのアクセスとドメインの遷移を忠実に洗い出すことができます。それはApacheのエキスパートが行う必要はなく、コンテンツの作成者である必要もないでしょう。逆に、SELinuxで配布されるApacheのポリシーは、一種平均的かつ特定の設定を想定したもので丸められたものになります。
以上ですが、ここで書いたことは一度実際にTOMOYO Linuxを使ってポリシーの自動学習を行っていただくとよく理解いただけるかもしれません。
動作を網羅した試験を行えるか
TOMOYO Linuxで作成するポリシーは彼らに言わせれば「アマチュア」のポリシーになります。
逆に質問します。ここで書かれている「透明性」とは何ですか？
言われている観点は理解できるのですが、網羅的な試験はソフトウェアの作成者でなくても行えるわけです。
SELinuxであれTOMOYO Linuxであれ、セキュリティを強化したLinux=強制アクセス制御を導入したLinuxが目指しているのは結局、「不適切なシステムコールの実行を、必要なシステムコールの実行を妨げずにいかにはじくか」になります。個々のシステムコールの処理内容自体にバグがあればそれに対しては効力を持ちませんし、意味的にセキュリティに関する脅威を理解したり対処するわけではありません。ただ、この「不適切」を切り分けて、「適切」を残しながらはじくのが難しいわけです。
はじく範囲をうすくすれば「適切」を損なうリスクは減り、SELinuxのtargetedはそれに分類されるでしょう。実際、targetedだと、大半の人はそれが有効になっていても気づかない（困らない）わけです。strictは細かくなる分、不具合が発生します。でも、そもそもあらゆるシステムに共通で使えるということは、それだけ粗いわけです。それは既製服で自分に近いサイズを選ぶようなものです。それに対して、TOMOYO Linuxは実際の環境で測定してポリシーを作り上げます。オーダーメイドです。strictとtargetedの2種類が、モジュールの概念を導入してReference Policyとなりましたが、それは標準的な構成と設定のもとの組み合わせであり、利用する一人一人の環境に関係なく作られたものです。それに対してTOMOYO Linuxは「その人の環境」でポリシーを測定（実測）し作成します。基本的な考え方が違うのです。だからTOMOYO Linuxでは標準（デフォルト）のポリシーがありません。
「プロ」と「アマチュア」ですが、TOMOYO Linuxでポリシーを作る人は、無論セキュリティに詳しい人であれば望ましいですが、単純に必要なシステムコールをトレースするだけであれば、システムを知る人＝全ての機能を実行させる術がわかる人であれば良いです。その場合、全てのプロセス実行(execve)は異なるドメインとなり、ひとつひとつのファイルへのアクセスが区別され学習されます。「べた」なポリシーです。ただ、ドメイン遷移を統合したり、ファイルのパターンをまとめたりすることによって、ポリシーはより小さく、見やすくなります（この作業をチューニングと呼んでいます）。それについては、ある程度Linuxに熟練している必要があるかもしれません。
ということで、Juliさんが言われているところの「セキュリティ」については勿論重要だと思っていますが、こと強制アクセス制御（ポリシーの設定）という観点からはそれほど関係はタイトではないように思います。少なくともTOMOYO Linuxを使う上で必須ではありません。
不適切なシステムコールの実行を、必要なシステムコールの実行を妨げずにいかにはじくか
「不適切」を切り分けて、「適切」を残しながらはじくのが難しい
こと強制アクセス制御（ポリシーの設定）という観点からはそれほど関係はタイトではないように思います。
ここで書いたことは一度実際にTOMOYO Linuxを使ってポリシーの自動学習を行っていただくとよく理解いただけるかもしれません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
これ入れるとSELinuxはいらなくなるのかしら？ (スコア:1)
この状態でネットワークを使ったサービスが動かすことができているなら、他にアクセス制御入れる必要性はあんまりないように思う。
なんかわからないけどSELinux使うとアクセスできなくなるから切っておけ～ という人にはSELinuxより簡単に同じ効果が得られるソフトはほしいと思う。
恥ずかしながら自分は後者なのだけれど、そこんとこどうなんだろう？
Re:これ入れるとSELinuxはいらなくなるのかしら？ (スコア:5, 興味深い)
以下のリンクは、lkmlでKyleという方が私のメッセージに返信してくれたものです。
Kyle氏が書いているように、SELinuxの開発サイドの基本的なスタンスは、「ポリシーはプロが書いて提供する」というものです。私は最初その考え方に抵抗がありましたが、色々やりとりをしながら次第にその考えに納得できるようになりました。それぞれのモジュール（パッケージ）を熟知したエキスパートが、対応するSELinuxの設定（ポリシー）を作成し、それが提供されていれば、ユーザはポリシーのことを気にせずに安心してシステムを使えるわけです。そうした考え方からは、「ユーザはポリシーを書くな」「ポリシーは（ソースでなく）バイナ
tsh
Re:これ入れるとSELinuxはいらなくなるのかしら？ (スコア:1)
「中身を理解していない」で「到達」と仰るところには違和感があります。
「到達」したか否かの判断を、「中身を理解していなくても」できるとお考えなのでしょうか？
TOMOYO Linux は存知ませんが、SELinux のポリシーはやはり難解だと思っています。プロが作ったものを受け取るだけで利用者は中身を知る必要がないという考え方に釈然としない部分が無い訳ではないですが、そこに適度な透明性があり、ポリシーの妥当性を監査、検証できる第三者が居さえすれば、問題視することではないと思えます。
はその通りだと思うのですが、ここで言う計測をエキスパートがやらずにアマチュアである利用者が行うということになると、折角苦労して作成した強制アクセス制御の機構が有効に機能できないことになってしまわないかと危惧してしまいます。
これらはポリシーの粒度や、強制アクセス制御機構そのものの柔軟性などに依存するだと思いますので、見当外れの意見かもしれません。
Re:これ入れるとSELinuxはいらなくなるのかしら？ (スコア:1)
Juliさん、
コメントありがとうございました。
> 「中身を理解していない」で「到達」と仰るところには違和感があります。
> 「到達」したか否かの判断を、「中身を理解していなくても」できるとお考えなのでしょうか？
自分の書いたものを読み直してみましたが、言葉足らずでした。まず使っている言葉について補足します。ここでいう「中身」はそれぞれのソフトウェア（パッケージ）の動作詳細を意味します。私は、Kyle氏やRussellが言うプロのポリシーとは、ApacheならApacheの開発者かそれに準じるレベルで動作を理解する者がポリシーを書く（書ける）という意味だと理解しています。次に「到達」ですが、「到達する状態」とは、必要なものが許可されて不必要なものは許可されないというポリシーです。
このような言葉の定義のもとで、私はあるソフトウェア（パッケージ）について、その開発者でなくても、あるいはそのソースコードを完全に掌握していなくても、それを用途に応じて動作させるためのポリシーを得ることが可能だと思っています。それを行えるかというのは要するに、動作を網羅した試験を行えるかということです（勿論、特定の状況（OSおよび他のパッケージのバージョン、それらの設定、コンテンツ等）が定められているというのは前提です）。
> そこに適度な透明性があり、ポリシーの妥当性を監査、検証できる第三者が居さえすれば、
> 問題視することではないと思えます。
逆に質問します。ここで書かれている「透明性」とは何ですか？バイナリで配布されるモジュールのポリシーについて、ユーザができることはそれを「信じる」しかない気がします。妥当性も同様です。そう考えると、結局SELinux陣営の言っていることは、「俺たちを信じろ」ということではないかと私は思っています。で、今まではあまり信じられないし信じたくないと思っていたのですが、少なくともKyle氏の作成したポリシーは信じられると思いました。ところで、「問題視することではない」と書かれていますが、私は「問題視していません」のでその点誤解なきようにお願いします。ただ、誰かが作ったポリシーを信じる以外に、自分で試行錯誤するのもありでしょ？と思っているだけです。それだけにすべきとは思いません。
> ここで言う計測をエキスパートがやらずにアマチュアである利用者が行うと
> いうことになると、折角苦労して作成した強制アクセス制御の機構が有効に
> 機能できないことになってしまわないかと危惧してしまいます。
言われている観点は理解できるのですが、網羅的な試験はソフトウェアの作成者でなくても行えるわけです。あなたが、Apacheのサーバを立てたとして、httpデーモン（のドメイン）を自動学習モードで動かせば、pngひとつから全てのコンテンツへのアクセスとドメインの遷移を忠実に洗い出すことができます。それはApacheのエキスパートが行う必要はなく、コンテンツの作成者である必要もないでしょう。逆に、SELinuxで配布されるApacheのポリシーは、一種平均的かつ特定の設定を想定したもので丸められたものになります。
以上ですが、ここで書いたことは一度実際にTOMOYO Linuxを使ってポリシーの自動学習を行っていただくとよく理解いただけるかもしれません。
tsh
Re:これ入れるとSELinuxはいらなくなるのかしら？ (スコア:1)
すみません、時間がないのでちょっと明確な応答になるか判らないのですが…
言葉の定義についてですが、「中身」、「プロのポリシー」、「到達する状態」の何れとも、多分、定義して頂いた様な意味で使われているのだろうな、とは思っていました。ただ、私の方では、定義して頂いた内容に更に、セキュリティの概念を含んでしまっている様です。
私はセキュリティ関連について門外漢なので、そこもブラックボックスになってしまいます。そして、私が書いた「利用者」とは、その様な人々を表しています。
その結果として、
に関して言えば、ソフトウェアの動作そのものだけでなく、それを利用するに当たって必要な「セキュアな振る舞い」についても妥当な判断をしなければならないと捉えています。
で、多分、私が誤解してしまっている部分がある様に思いました。先のコメントで、
と仰っているのは、(Apache などの) ソフトウェアのプロではないけれども、セキュリティに関してはプロである「アマチュア」（つまり TOMOYO Linux の開発に関係しておられる方々）を指しておられるのでしょうか？
ここの「アマチュア」を、私の様な一利用者と捉えてしまったところに問題があった様に思います。
「適度な透明性」と書いたのは、実はバイナリ *のみ* の配布に条件を付けることを指しています。こちらこそ言葉足らずですみません。
一般の利用者にとってはバイナリしか見えないけれども、例えば、SELinux 開発コミュニティ以外のセキュリティに関する有識者に対し、ポリシーの内容が公開されている、というような状況を想定しています。暗号化アルゴリズムは完全に公開されているものがあるので、そのまま例としては不適当かもしれませんが、一般の利用者がアルゴリズム自体を理解せずに利用していて、有識者には様々な形で検証されている、という状況だけを考えて貰うとイメージし易いかもしれません。
セキュアな観点までも網羅した試験は一般の利用者には難しいと考えている訳なのですが、これは現状でも同じなのは承知しています。
サーバを管理するのであれば、セキュリティに関連するスキルを保有していて然るべきというのが現状でしょう。
ただ、将来的にはその様な観点でもハードルが下げられるようになると、よりセキュア OS の普及率も上がるのでは、という期待を持っています。
;; すみません、本当に時間が無くて書きっぱなしになってしまいました。判り難くて申し訳ないです。
Re:これ入れるとSELinuxはいらなくなるのかしら？ (スコア:1)
SELinuxであれTOMOYO Linuxであれ、セキュリティを強化したLinux=強制アクセス制御を導入したLinuxが目指しているのは結局、「不適切なシステムコールの実行を、必要なシステムコールの実行を妨げずにいかにはじくか」になります。個々のシステムコールの処理内容自体にバグがあればそれに対しては効力を持ちませんし、意味的にセキュリティに関する脅威を理解したり対処するわけではありません。ただ、この「不適切」を切り分けて、「適切」を残しながらはじくのが難しいわけです。
はじく範囲をうすくすれば「適切」を損なうリスクは減り、SELinuxのtargetedはそれに分類されるでしょう。実際、targetedだと、大半の人はそれが有効になっていても気づかない（困らない）わけです。strictは細かくなる分、不具合が発生します。でも、そもそもあらゆるシステムに共通で使えるということは、それだけ粗いわけです。それは既製服で自分に近いサイズを選ぶようなものです。それに対して、TOMOYO Linuxは実際の環境で測定してポリシーを作り上げます。オーダーメイドです。strictとtargetedの2種類が、モジュールの概念を導入してReference Policyとなりましたが、それは標準的な構成と設定のもとの組み合わせであり、利用する一人一人の環境に関係なく作られたものです。それに対してTOMOYO Linuxは「その人の環境」でポリシーを測定（実測）し作成します。基本的な考え方が違うのです。だからTOMOYO Linuxでは標準（デフォルト）のポリシーがありません。
「プロ」と「アマチュア」ですが、TOMOYO Linuxでポリシーを作る人は、無論セキュリティに詳しい人であれば望ましいですが、単純に必要なシステムコールをトレースするだけであれば、システムを知る人＝全ての機能を実行させる術がわかる人であれば良いです。その場合、全てのプロセス実行(execve)は異なるドメインとなり、ひとつひとつのファイルへのアクセスが区別され学習されます。「べた」なポリシーです。ただ、ドメイン遷移を統合したり、ファイルのパターンをまとめたりすることによって、ポリシーはより小さく、見やすくなります（この作業をチューニングと呼んでいます）。それについては、ある程度Linuxに熟練している必要があるかもしれません。
ということで、Juliさんが言われているところの「セキュリティ」については勿論重要だと思っていますが、こと強制アクセス制御（ポリシーの設定）という観点からはそれほど関係はタイトではないように思います。少なくともTOMOYO Linuxを使う上で必須ではありません。
tsh
Re:これ入れるとSELinuxはいらなくなるのかしら？ (スコア:1)
もう反応して頂けないかもしれませんが。
仰ることは大枠では理解してきたと思うのですが、個人的にはどうしても、
の部分には、セキュリティ要件が絡む様に読めてしまうのです。
そのため、
とは思えない、というところなのです、しつこいですね……すみません。
また、システムコール単位での切り分けが開発者でなくても可能という考え方は、完全性という面では厳しそうな感覚もあります。ただ、これは、リソースへのアクセスに限定して考えるという側面では、十分許容できる範囲なのでしょうね。
仰る通り、「先ずは使ってみろ、話はそれからだ」という事なのでしょう。
何れ利用させて頂きたいと思います。
Re:これ入れるとSELinuxはいらなくなるのかしら？ (スコア:1)
> 随分と時間が空いてしまいました、すみません。
> もう反応して頂けないかもしれませんが。
そんなことはありません。:-)
> 仰ることは大枠では理解してきたと思うのですが、個人的にはどうしても、
> 不適切なシステムコールの実行を、必要なシステムコールの実行を
> 妨げずにいかにはじくか「不適切」を切り分けて、「適切」を残しながら
> はじくのが難しいの部分には、セキュリティ要件が絡む様に読めてしまうのです。
> そのため、
>> こと強制アクセス制御（ポリシーの設定）という観点からはそれほど
>> 関係はタイトではないように思います。
> とは思えない、というところなのです、しつこいですね……すみません。
いえ、こうしたやりとりを通じて自分自身の考えを整理できますし、
何より意見を聞かせていただけるのはとてもありがたいです。
感謝しています。
内容についてですが、ではこう言い直したらいかがでしょうか？
「システムの挙動をトレースするのには、必ずしも
セキュリティの知識は前提とはならない」
実際、TOMOYO Linuxで行うのは、「実施した内容を実現する上で
生じたシステムコール（全てではありません）をトレース」
しているわけであって、それを保存、編集してから「強制」すると
強制アクセス制御になるだけです。「強制」するかどうかは
使い方次第ですが、それこそ強制されるものではありません。:-)
> また、システムコール単位での切り分けが開発者でなくても可能と
> いう考え方は、完全性という面では厳しそうな感覚もあります。
> ただ、これは、リソースへのアクセスに限定して考えるという側面では、
> 十分許容できる範囲なのでしょうね。
ここについては意見は書けるのですが、主観になってしまいます。
可能であれば実際にTOMOYO Linuxでご体験いただけると
良いかと思います。TOMOYO Linuxの機能は同じでも、それを
利用する人、利用する内容によっては異なる解釈があるかもしれません。
>> ここで書いたことは一度実際にTOMOYO Linuxを使ってポリシーの自動学習を
>> 行っていただくとよく理解いただけるかもしれません。
> 仰る通り、「先ずは使ってみろ、話はそれからだ」という事なのでしょう。
> 何れ利用させて頂きたいと思います。
「まず使ってみて下さい」というのは、説明を放棄しているようで
普段はあまり言わないのですが、TOMOYO Linuxの場合は、これまで他で
見たことがないようなものなので、言葉で説明するよりも
体験いただくのが正確ですし、早いです。バイナリパッケージを用意しており、
http://osdn.jp/projects/tomoyo/files/ [osdn.jp]
15分もあれば「自動学習」とは何かを「juliさんご自身の環境で」
確かめていただくことができます。TOMOYO Linuxを使うか使わないかに
かかわらず、表示される内容はJuliさんにとって参考になると
思うのでお勧めしている次第です。
tsh