Toshiharu Harada
harad****@nttda*****
2009年 3月 16日 (月) 11:13:19 JST
原田です。 On 2009/03/13, at 10:12, Tetsuo Handa wrote: > 熊猫です。 > > 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 ここが一番重要だと思っています。 週末ずっと考えていて、TOMOYOの役割は「認知されていな い」最大の要因は、実は 「プロジェクトとしてそれを説明していない」ことにあるのではな いかと思いました。 そして、今こそそれを説明すべきなのではないかと思います。 一人一人、あるいはLinuxのコア開発者「だけ」でなく、 広く、誰でもわかるように。 日本だけでなく、海外のユーザにも向けて。 それはマージされたことによるひとつの責任でもあると思います。 その責任を果たさずして、焦って動いても納得してもらえないし、 うまくいかないと思います。 半田さんのもどかしさと情熱を今こそ違う方向に向けるべきです。 > ディストリビューションのメンテナや多くのユーザ、さらには武 > 田さんまでもが > 「ラベル＋パス名→ガチガチ」と誤解しています。 いや、そんなことないと思いますよ。 ただ、ラベルとパス名の協調の内容やその意義、必要性は まだ誰もが参照できるようになっていませんし、ごく限られた場でしか 説明もしていません。 > 全てのプロセスに対して SELinux の保護が適用されている > システムが > どれだけあるのでしょう？ SELinux を有効にしているシス > テムのほとんどは > （ AppArmor を有効にしているシステムと同様に）一部の > デーモンプロセスだけを > 保護対象にしています。もちろん、 TOMOYO をデーモンプ > ロセスを保護するのに 上記は実際と違う可能性があります。セキュアOS塾でも、 「自分はSELinuxを使いこなしている」という方がありました。 問題なく使われていてもそのことが表面に出ていないケースは 確実に存在するはずです。 > 使うこともできるわけですが、 TOMOYO は他のプロセス > （例えばコンソール／ > ＳＳＨセッション）を保護対象にすることもできます。しかし、 > SELinux は > （ TOMOYO ではカバーできない）バックエンドを受け持っ > ているので、 TOMOYO を > 使うから SELinux は要らないというものではありません。 > > 「ラベル＋パス名→ガチガチ」というのは TOMOYO の役割 > を理解していないがために > 起きている誤解です。 TOMOYO は SELinux や > SMACK の苦手分野を補うことができる > ものであり、 SELinux や SMACK と競合するもので > はないのです。 昨年は、TOMOYO自体を広げるためにずいぶんと活動しましたが、 振り返ってみると、今の実装や機能について十分な技術的説明がな いことに 気がつきました。 >> 半田さんの思惑としては、非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 > 版が取り込まれれば > ユーザにとっての損失はなくなります。 半田さんが損失だと考えることは僕は理解できますし、おそらく 正しいのだとも思います（TOMOYOについて半田さんが語る言葉に 間違いはないと思っています）。でも、その認識を共有しなければ 誰も共感しないし、賛同もしません。気持ちはわかりますが、 説明してわかってもらう努力をしなければならないと思います。 わかってもらうのは難しいし、準備は面倒です。でもそれは 外せないステップではないでしょうか？ >> 半田さんの考えでは、 >> ・非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 Linuxの 進化を支援してくれるはずです。 -- 原田季栄 harad****@nttda*****
TOMOYO
Fork