Tetsuo Handa
from-****@i-lov*****
2009年 3月 13日 (金) 10:12:17 JST
熊猫です。 hito さんは書きました： > が、ちょっと用語の使い方が誤解を招きそうなので確認させてください。 > LSM版の現状は（多分今後も）↓ですよね？ > ・ビルド時にTOMOYOを有効 ……他のLSMとともに有効化できる > ・利用時にTOMOYOを有効 ……他のLSMとは共存できない その表現だと誤解を招くと思います。 TOMOYO の機能を使うには２段階あります。 １段階目はカーネルコンフィグにおいて「 CONFIG_SECURITY_TOMOYO=y 」を 指定するということです。これは、「有効か無効か」ではなく「組み込むか 組み込まないか」の指定です。 カーネルコンフィグにおいては複数の CONFIG_SECURITY_\* を y にすることが できます。つまり、ビルド時に SELinux SMACK TOMOYO 全てを「組み込む」ことが できるということです。 ２段階目はカーネル起動時のコマンドラインに「 security=tomoyo 」を指定するという ことです。これは、「有効か無効か」（組み込まれたものを使うか使わないか）の 指定です。つまり、起動時に SELinux SMACK TOMOYO のいずれか１つだけを有効に できるということです。 現状の LSM では、起動時に SELinux SMACK TOMOYO のいずれか１つだけを 「有効にする」ことができます。 ですから、 ・ビルド時にTOMOYOを組み込む ……他のLSMとともに組み込める ・利用時にTOMOYOを有効にする ……他のLSMと同時には使えない というのが正しいと思います。 （つまり、「ビルド時に TOMOYO を有効にする」という表現を避け、 「ビルド時に TOMOYO を組み込む」という表現を使うのが適切だと思います。） > # ↓の再チャレンジという禁断コースもあるけど!!（←話を混乱させる奴） > # http://www.selinux.gr.jp/selinux-users-ml/200707.month/1965.html ありえますよ。今後 LSM スタッキングが実装されるかどうか判りませんが、 「 LSM スタッキングは実装しない」という結論になった場合に備えて TOMOYO が security_ops を使わないで済む実装を捨てるべきではありません。 > 言い換えると、ディストリビュータからしてみれば、 > ・「使える」状態でカーネルをconfigすることはできる（ターゲットA）。 はい。 CONFIG_SECURITY_TOMOYO=y で出荷することはできると思います。 > ・「使う」状態でディストリビューションとして出荷することはしない（ターゲットB）。 はい。 security=tomoyo で出荷することはしないと思います。 > ですね？ > > そしてユーザーからすると、ターゲットAさえ達成されていれば、 > ・任意に、比較的簡単な操作で「使う」ことが可能。 > ただし、SELinuxやAppArmorと同時に使い回すことはできない。 > ということになります。 はい。 ただ、コンパイルだけで使えるのなら、ターゲット A が達成されていなくても さほど問題は無いと思います。（ CentOS Plus では RHEL では有効にされていない コンフィグオプションを有効にして作成したパッケージを配布しているようです。 熊猫のほうで CONFIG_SECURITY_TOMOYO=y にして作成したパッケージを配布することも 可能でしょう。） > で、これらの理解が正しいとすると、自分の理解は次の通りです。 > > (1) 結局まだ、ディストリビュータに対してはTOMOYOをデフォルトで > 「使う」状態にしてくれ、というだけの裏付けはない。 はい。 TOMOYO 2.2.0 では SELinux SMACK AppArmor を捨ててまで（即ち security=tomoyo を指定してもらってまで）乗り換えてもらうほどの 価値があることをディストリビュータに対して説得できないと思います。 > (2) Mainline化にこそ成功しているが、LSM版はたいへんに > ぽんこつで、ユーザーやディストリビュータからしてみれば > 「選択肢のひとつ」程度の存在でしかない。 はい。 (1) と同じです。 > (3) SELinuxは現在のLinuxにとっては無視できない機能なので、 > 少なくとも、SELinuxをdisableしてまで上記のターゲットBが > 達成されることはない。 はい。 > (4) しかし、上記ターゲットA、「使える」状態で出荷してもらうことに > デメリットはない。 > はい。 > > 短期的には「メインラインに入っているから気軽に試すことができる」という > > メリットがあっても、長期的には「 TOMOYO 以外の機能を無効にしてまで使う価値の > > あるものではない」というデメリットが上回ると予想しています。 > > 上記理解からすると、この点に確信が持てません。ここでいう > デメリットとは何でしょう？ そしてなにより、このデメリットが > 長期的にも真になるのか、という点がよく分かりません。 TOMOYO はフロントエンド（ユーザから容易に見える範囲、例えばパス名やＩＰアドレス など）を受け持つのに対し、 SELinux はバックエンド（ユーザからは容易には見えない 範囲、例えばバッファオーバーフロー対策として有効なページの実行可否制御や パス名を持たないオブジェクトに対する制御など）を受け持っています。 security=tomoyo を指定することでユーザが SELinux （あるいは SMACK あるいは AppArmor ）の恩恵を受けられなくなるというのがデメリットです。 > おそらく以下の記述が半田さんの考えの一部だと思いますが、 > これが確定的な展開ではないように思います。 > > > TOMOYO は役割的に SELinux や SMACK や AppArmor と相容れないものではないのにも > > かかわらず、 LSM が排他的であるが故に、長期的に TOMOYO は不利な状況に陥る。 > > だから、非 LSM 版の方が長期的に有利だと思う訳です。 > > hito的な表現でこれを示すと、 > ・「TOMOYOはSELinuxをDisableしない限り使えない」 > ため、メジャーな存在になりきれずに終わる可能性が高い。 > SELinuxほどの有効な資産を築けないため、多数派になり > きれずに負けてしまう。 > となりますが、こういう理解で妥当でしょうか？ はい。 > もし上記が真だとしたら、自分は、 > ・「TOMOYOは1.6パッチをわざわざ当てないと使えない」 > | ため、メジャーな存在になりきれずに終わる可能性が高い。 > | SELinuxほどの有効な資産を築けないため、多数派になり > | きれずに負けてしまう。 > でも、結果は等しいと思うのです。ディストリビュータを説得する > ことを考える場合、こうした論理構造を示されたら論破できない > ように思います。 > ディストリビュータカーネルに非 LSM 版が取り込まれることで SELinux などと同時に 使えるようになることで、 security=tomoyo を指定することなく TOMOYO の恩恵も 受けられるのがメリットなのです。 > LSM版がぽんこつな状態であり、また、最終的な帰結として、 > TOMOYO Linuxが一定の地位を獲得するためには現在のLSM版より、 > 非LSM版の方が有利な状態にあることは理解できます。 > > ですが、 > ・過去、どうやってもほとんどのディストリビュータを > 説得できなかった、独自パッチに依存する非LSM > ・少なくとも「使える」状態にはしてもらえそうな > Mainline取り込み済みのLSM > を比較すると、どう考えても長期的な未来がなさそうなのは > 非LSM版のように思います。 それはまだ TOMOYO の役割が認知されていないからです。 LFJ BoF および LCA BoF にて James Morris 、 Paul Moore 、 Casey Schaufler 、 Andrew Morton たちに直接説明するチャンスがあったわけですが、 その説明内容を知っているのはまだまだごく一部です。 http://sourceforge.jp/projects/tomoyo/docs/lca2009-kumaneko.pdf http://sourceforge.jp/projects/tomoyo/docs/lfj2008-bof.pdf http://sourceforge.jp/projects/tomoyo/docs/tlug200805.pdf ディストリビューションのメンテナや多くのユーザ、さらには武田さんまでもが 「ラベル＋パス名→ガチガチ」と誤解しています。 全てのプロセスに対して SELinux の保護が適用されているシステムが どれだけあるのでしょう？ SELinux を有効にしているシステムのほとんどは （ AppArmor を有効にしているシステムと同様に）一部のデーモンプロセスだけを 保護対象にしています。もちろん、 TOMOYO をデーモンプロセスを保護するのに 使うこともできるわけですが、 TOMOYO は他のプロセス（例えばコンソール／ ＳＳＨセッション）を保護対象にすることもできます。しかし、 SELinux は （ TOMOYO ではカバーできない）バックエンドを受け持っているので、 TOMOYO を 使うから SELinux は要らないというものではありません。 「ラベル＋パス名→ガチガチ」というのは TOMOYO の役割を理解していないがために 起きている誤解です。 TOMOYO は SELinux や SMACK の苦手分野を補うことができる ものであり、 SELinux や SMACK と競合するものではないのです。 > 半田さんの思惑としては、非LSM版を広めることでTOMOYOが > 評価を獲得し、LSM版の開発の後押しになることを期待している > のかなぁと思います。思うのですが、現状ではたぶん、 > > 「TOMOYO Linux？ 最近Mainlineに入った奴ね？ え、独自 > パッチいるの？ じゃあ要らない」 > > から踏み出していくことはできないんじゃなかろうかと思います。 > > ここで最初の話まで戻ると、 > > >> c) LSB版のTOMOYOは、「TOMOYO Linuxを今後広める上で」有効である。 > > > LSM 版の TOMOYO は「 TOMOYO Linuxを今後広める上で」有益であり有害でもある > > ということです。 > > このロジックに基づくなら、自分は > ・非LSM版のTOMOYOは「 TOMOYO Linuxを今後広める上で」困難な道であり、 > *無力* である。 > |・LSM 版の TOMOYO は「 TOMOYO Linuxを今後広める上で」有益であり > | 有害でもある。 > という理解をしています。たぶん、原田さんや武田さんも同じ理解かと思います。 > 同時に、少なくとも自分は、有害な点をつぶすにもTOMOYOを広めるのが > 第一義であろう、と考えています。 security=tomoyo を指定しないと使えないことの方が、ユーザにとって大きな損失だと 考えているのです。ディストリビュータカーネルに非 LSM 版が取り込まれれば ユーザにとっての損失はなくなります。 > 半田さんの考えでは、 > ・非LSM版のTOMOYOは「 TOMOYO Linuxを今後広める上で」困難な道では > あるが、*有効* である。 > |・LSM 版の TOMOYO は「 TOMOYO Linuxを今後広める上で」有益であり > | 有害でもある。 > なのですよね？ > 同時に、TOMOYOを広めなくては話にならない、と考えているのではないかと > 自分は思います。 > > そこでひとまず、同意できている > |・LSM 版の TOMOYO は「 TOMOYO Linuxを今後広める上で」有益であり > | 有害でもある。 > の、有害な点が表出するまでの間、「LSM版を宣伝用に使い、LSMの > 構造変化なり、非LSM版パッチの受け入れをやりやすくするために使う」 > という点で同意することはできないでしょうか？ はい。 LSM 版は「 TOMOYO を宣伝」し、「 LSM スタッキングを実現する」あるいは 「非 LSM 版パッチを受け入れやすくさせる」ためのデモ実装です。 だから、非 LSM 版はまだ捨てません。 > それとも、一時的にせよLSM版を広めていく戦術には同意できませんか？ security=tomoyo を指定しないと使えない限り、一時的には広まっても 長期的に広まることは無いと考えているのです。
TOMOYO
Fork