Tetsuo Handa
from-****@i-lov*****
2009年 3月 11日 (水) 17:26:55 JST
熊猫です。 hito さんは書きました： > まだ提案は1.6/2.0ともに進んでいません。 > が、少なくとも1.6系を入れるには誰かにper-package uploaders > という権限を取得してもらう必要があると思われます。これは超絶 > 大変なので（おおむねLKMLでmainline化するバトルと同程度）、 > 無理だと考えてください。 > > それだけのリソースがあるなら、mainlineの2.xを1.6相当にした > 方がいいです。 In-tree だからといって好き勝手フックの追加ができるわけでは無いのですから、 2.x を 1.6 相当にするのは LKML で mainline 化するバトルと同程度のリソースが 必要だと思っています。 2.x が 1.6 相当になるのを待っていたら次の LTS にさえ間に合わないでしょう。 次の LTS までに 2.x で 1.6 相当の機能を実現するには独自パッチが不可欠に なってしまいます。（ 2.2.0 は LSM を使っていますが、 MAC_FOR_FILE に関する フックの挿入箇所は 1.6.x とほぼ同じです。 2.6.29 で MAC_FOR_FILE のための フックが承認されたものの、まだまだフックが足りません。） > ・TOMOYOをenableしても副作用がないとkernel-team/server-teamに > 納得してもらう 何を以って「副作用が無い」と言えるのでしょう？ Turbolinux さんと Mandriva さんはカーネルコンフィグで TOMOYO を enable した 状態で出荷しておりますが、 TOMOYO に起因する問題は起きていません。 Mandriva さんのカーネルコンフィグは AppArmor と TOMOYO を”両方同時に使える” 設定です。 2.x で TOMOYO を有効にしただけでは生じなくて、 1.6.x で TOMOYO を有効にすると 生じる「副作用」とは何でしょう？ TOMOYO のコア（ドメイン遷移と MAC_FOR_FILE ）機能は 1.6.x と 2.x で同等です。 そして、 2.x がメインラインに入る以上、コア機能が使えなくなる心配は不要です。 1.6.x にはその他の機能がありますが、ある日メインラインのソースコードに大変更が 生じて 1.6.x が追随できなくなったら、 1.6.x の機能を切り落とせば済みます。 1.6.x も 2.x もメンテナンスするのは同一人物なので、メンテナンスされなくなる リスクも同等です。何故そんなに 1.6.x を敬遠するのか不思議です。 > このために必要なのは、 > a) =yで副作用がないという、理論的裏付けがある。 > b) 「スジの悪い」ものでない、という気分;)になってもらう > です。a,bともに満たせれば良いはずなので、そのためには > 1.6系を押すのは後回し（無理に押すと b)が満たせなくなる）というのが > 戦術的にはベターそうです。 2.2.0 を「 TOMOYO を試してもらうためのデモ用実装」として提案してから 1.6.x を「 TOMOYO を使ってもらうための本番用実装」として提案するという 戦術なのでしょうか？最終的に 1.6.x を採用してもらう戦術なら、 2.x を 1.6.x 相当にしていくためにリソースを割く必要は無いのでは？ 2.2.0 はまだまだ不十分で使い物にならない（ AppAmor を捨てて TOMOYO に乗り換える ほどの機能を備えていない、 SELinux や SMACK などとの併用もできない、現在 ディストリビュータカーネルに含まれている AppArmor や SELinux や SMACK などと 比較して「低いセキュリティ」しか実現できない）と考えているから、 2.x が 使い物になる（ AppArmor を捨ててTOMOYO に乗り換えるほどの機能を備え、 SELinux や SMACK などとの併用ができるようになる）までは、 1.6.x の方が 適していると思います。 > # TOMOYOをserver teamの人たちに布教するための計画は、また別の話。 1.6.x か 2.2.0 かの話の前に、 server team の人たちに TOMOYO を紹介するのが 先な気がします。
TOMOYO
Fork