From haradats ＠ nttdata.co.jp Wed Aug 1 00:17:36 2007 From: haradats ＠ nttdata.co.jp (Toshiharu Harada) Date: Wed, 01 Aug 2007 00:17:36 +0900 Subject: [Tomoyo-dev 408] Re: =?iso-2022-jp?b?GyRCJUQhPCVrJE4lVyVtJTAlaSVgTD4kSCVdJWobKEI=?= =?iso-2022-jp?b?GyRCJTchPCROTD5BMCROSlE5OSRLJEQkJCRGGyhC?= In-Reply-To: <46AF43AD.3000702@samba.gr.jp> References: <200707300619.l6U6JAYh063923@www262.sakura.ne.jp> <61511.163.135.10.36.1185783503.squirrel@webmail.knlab.com> <200707302110.GIF12208.PFEPPGNSNPUWtZt@I-love.SAKURA.ne.jp> <46AE0928.6010006@samba.gr.jp> <9d732d950707301525md1cbcd7yda7679a5e30d026e@mail.gmail.com> <200707312027.JIE09834.tPPFNZtUNPEGWPS@I-love.SAKURA.ne.jp> <46AF34B7.9050808@nttdata.co.jp> <46AF43AD.3000702@samba.gr.jp> Message-ID: <46AF5290.8060602@nttdata.co.jp> 原田です。 Kensuke Nezu さんは書きました: > これは、今回は1.xについて「のみ」の話です。 > 2.xではもっときれいにしてほしいと「強く」希望します。 2.xでは1.xの整理を待って合わせる予定なのですが、 1.xの整理が予定より時間がかかりそうですね。 あまりに時間がかかるなら、考えないといけないかも しれません。 > ＃コマンドが沢山あるのはSELinuxと比較して弱点だと思う。 > ＃boot等で/ fsに絶対に必要・・・と半田さんが主張する様子をみると、 > ＃そんなに沢山のユーザランドに依存しないと動けないのか？と > ＃弱点にしか見えなくなるデスヨ。 すんなりいかないひとつの理由は、半田さんが 「こうでなければいけない」と考えている内容とその理由が 現状半田さんの頭の中にしかないことにある気がします。 開発会議やtomoyo-devでプロジェクトとしての方向性は 出ているので、可能な限りそれに合わせた案を 半田さんがまとめてもらって、合わせられなかった部分の 妥当性と対応をtomoyo-devで議論するのが効率的と 思いますがどうでしょうか。 > 問題を混同してはいけないと思う。 > エマージェンシーの時にはTOMOYOをオフにしてブートしてコマンドをつかえれば > いいのですから、手動で/usr/をmountして作業すればいいだけです。 > >>> savepolicy を / パーティション以外に置いてしまうと >>> /etc/rc.d/init.d/halt の中から呼ぼうとしてもアンマウント済みということに >>> なってしまいます。 > > おっと。haltに手が入っているんですか？ > haltの中からユーザランドのヘルパーアプリを呼んでる？？ > > そりゃーやっちゃいけないことやってる希ガス。 > > ・mountより前にはsavepolicyは絶対に実行できない？ > ・umount後に何とかしよう・・・というパターンは、knnopixとかでも > 　やっているやり方でできない？（←どーしてもやるっつーなら・・・） > > いずれにしても仕組み的にどこかおかしいので整理しないといけないなぁ。 > >>> editpolicy や savepolicy などほとんどのコマンドはハードリンクなので、 >>> /usr/sbin/ や /usr/bin/ に分けるのは難しいと思います。 > > これ、ハードリンクでいいの？セキュリティ的に。 「ハードリンクなのは組み込み系を意識してで、 組み込みとそれ以外を分けるとソースが2系統になるから、 ハードリンク」ということだと理解していますが、 全体を組み込みに合わせるのは良くないし、 コマンドの統合は検討の余地がありそうですね。 >> /sbin に置くものを厳選して、あとはちょっと変態っぽく、 >> /sbin/tomoyo にひとまとめ、ってことかな？（/sbinの下に >> ディレクトリを掘ってるから使わない！という人が >> 多くなければ良いのですが） > > 起動/シャットダウンに直接的に不要なものを/sbin/に置くのは反対です。 > / fsはできるだけコンパクトにするべきです。 > > ＃/ fsがおかしくなったときにはfsckを正常終了しないと何もできない > ＃ので、まともなシステムは/ fsは必要最小限にするからです。 > ＃あと、既存の / fsがあったときにそこに必要以上に圧迫するバイナリ > ＃のインストールを強制するのはそれだけでTOMOYOを嫌悪する理由に > ＃十分すぎる理由になると思います。 > ＃（/ fsのオーバフローによる破壊はシステムに壊滅的なダメージを > ＃与える可能性が高いため） > >> /sbin/tomoyoの下にさらにsakura, syaoran, cerberusを掘りたいと >> したら私はとめません。 > > /usr/sbin/tomoyo/　の下なら止めませんｗ 起動/シャットダウンに必要なもののみを /sbin、 それ以外は/usr/sbin/tomoyo ですね。私は、根津さんの提案はリーズナブルだと思いますが、 半田さんや他の方はいかがでしょうか？ -- 原田季栄 (Toshiharu Harada) haradats ＠ nttdata.co.jp From yocto1 ＠ gmail.com Wed Aug 1 00:18:24 2007 From: yocto1 ＠ gmail.com (yocto) Date: Wed, 1 Aug 2007 00:18:24 +0900 Subject: [Tomoyo-dev 409] Re: =?iso-2022-jp?b?dG9tb3lvbGludXgue2NvbSwgbmV0LCBvcmcsIGpwfSA=?= =?iso-2022-jp?b?GyRCJUklYSUkJXMkciUtITwlVyQ3JF4kNyQ/ISMbKEI=?= In-Reply-To: <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <9d732d950707301536ib067596v7509cd8c95969267@mail.gmail.com> <53275.163.135.10.34.1185849256.squirrel@webmail.knlab.com> <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> Message-ID: <8f3c749a0707310818g2b55e56bgb31c3458e675a6aa@mail.gmail.com> クスノです。 私も tomoyo に一票 07/07/31 に Tetsuo Handa さんは書きました: > > > この際、名称からツールのディレクトリからパッケージ名から、あらゆるものを > > > 統一していただくとすっきりします(^^) > > > > そう言えば、ccsをtomoyoに統一しよう。 > > tomoyoはキーボードの右側ばかり使う（笑）。 > > tmyに略す？ > > > > のような話もありましたね。 > > 名前をどうするかの話が止まっているようですが、 > 他にご意見はありませんか？ > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > From yocto1 ＠ gmail.com Wed Aug 1 00:25:28 2007 From: yocto1 ＠ gmail.com (yocto) Date: Wed, 1 Aug 2007 00:25:28 +0900 Subject: [Tomoyo-dev 410] Re: =?iso-2022-jp?b?dG9tb3lvbGludXgue2NvbSwgbmV0LCBvcmcsIGpwfSA=?= =?iso-2022-jp?b?GyRCJUklYSUkJXMkciUtITwlVyQ3JF4kNyQ/ISMbKEI=?= In-Reply-To: <53275.163.135.10.34.1185849256.squirrel@webmail.knlab.com> References: <46ACBC89.2030604@samba.gr.jp> <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <9d732d950707301536ib067596v7509cd8c95969267@mail.gmail.com> <53275.163.135.10.34.1185849256.squirrel@webmail.knlab.com> Message-ID: <8f3c749a0707310825h69145f78i478a136cb11e3355@mail.gmail.com> クスノです。 ハイフン付はやめましょう。 開発会議では、ハイフン無しとハイフン付の両方とった方が良いという話だった 気がしたので、だったら取りましょう位の発想でした。 今回は根津さんにオンブしますm(__)m 07/07/31 に Kensuke Nezu さんは書きました: > 根津です。 > > On 2007年 7月 31日 (火) 7:36, Toshiharu Harada wrote: > > 07/07/31 に yocto さんは書きました: > >> クスノです。 > >> > >> おおっ、すばやいですね。 > >> > >> え~と、提案なのですが、何人かでカンパしませんか　＞皆さん > > > > メールを読んでいて、「カンパ」という扱いにするなら、 > > いっそこの機会にユーザ会を作り、ユーザ会としてドメインを > > 維持し、トレーナー（実は以前から作りたいと思っていましたw）を > > 作ったりするのが良いのではないかと思いました。 > > ユーザ会作るのはいいと思います。トレーナーも欲しいし（何？ > > > どうしてもユーザ会、という理由はないですが、お金を > > 集めるなら、メンバーと会計を明確にする必要があり、それなら > > ユーザ会にしては、というぐらいの発想ですが。 > > お金は会計するのが大変なので、できるだけ持たない方がいいですねぇ・・・。 > ドメインについては、私が取得した以上、おこずかいで運用できる範囲ですので > 今回取得した分については、私の持ち出しで寄付（物納）しますｗ > > ＃.com/.net/.orgを10年とかとらずに2年にしたのは、ドメインどこまで > ＃個人名義で取得しておくべきかわからなかったのと、皆さんに負担を > ＃感じさせずに持ち出せる範囲で・・・というのがあったためです。 > > 今回の.jpドメイン1年分と、.com/.net/.org2年分であわせても大体1万円 > くらいですので、これくらいの寄付なら安いもんですｗ > > >> で、出来ればハイフン付も取得してはいかがかと... > > で、本題ですが、本当にハイフンつき必要だと思いますか？＞皆さん > > > -- > ------ > 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） > Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) > 802.11セキュリティサイト：http://www.famm.jp/wireless > ※「SELinuxシステム管理―セキュアOSの基礎と運用」 > http://www.oreilly.co.jp/books/4873112257/ > ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 > http://www.oreilly.co.jp/books/4873112877/ > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > From yocto1 ＠ gmail.com Wed Aug 1 00:37:13 2007 From: yocto1 ＠ gmail.com (yocto) Date: Wed, 1 Aug 2007 00:37:13 +0900 Subject: [Tomoyo-dev 411] Re: =?iso-2022-jp?b?GyRCJUQhPCVrJE4lVyVtJTAlaSVgTD4kSCVdJWobKEI=?= =?iso-2022-jp?b?GyRCJTchPCROTD5BMCROSlE5OSRLJEQkJCRGGyhC?= In-Reply-To: <46AF5290.8060602@nttdata.co.jp> References: <200707300619.l6U6JAYh063923@www262.sakura.ne.jp> <61511.163.135.10.36.1185783503.squirrel@webmail.knlab.com> <200707302110.GIF12208.PFEPPGNSNPUWtZt@I-love.SAKURA.ne.jp> <46AE0928.6010006@samba.gr.jp> <9d732d950707301525md1cbcd7yda7679a5e30d026e@mail.gmail.com> <200707312027.JIE09834.tPPFNZtUNPEGWPS@I-love.SAKURA.ne.jp> <46AF34B7.9050808@nttdata.co.jp> <46AF43AD.3000702@samba.gr.jp> <46AF5290.8060602@nttdata.co.jp> Message-ID: <8f3c749a0707310837k3e39c38ev1048514c4d236326@mail.gmail.com> クスノです。 とりあえず、一番下だけ 07/08/01 に Toshiharu Harada さんは書きました: > 原田です。 ... > >> /sbin/tomoyoの下にさらにsakura, syaoran, cerberusを掘りたいと > >> したら私はとめません。 > > > > /usr/sbin/tomoyo/　の下なら止めませんｗ > > 起動/シャットダウンに必要なもののみを /sbin、 > それ以外は/usr/sbin/tomoyo > ですね。私は、根津さんの提案はリーズナブルだと思いますが、 > 半田さんや他の方はいかがでしょうか？ /sbin については賛成 その他については、 /usr/lib/tomoyo/ に一票 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Wed Aug 1 00:42:38 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Wed, 1 Aug 2007 00:42:38 +0900 Subject: [Tomoyo-dev 412] Re: =?iso-2022-jp?b?GyRCJUQhPCVrJE4lVyVtJTAlaSVgTD4kSCVdJWobKEI=?= =?iso-2022-jp?b?GyRCJTchPCROTD5BMCROSlE5OSRLJEQkJCRGGyhC?= In-Reply-To: <46AF43AD.3000702@samba.gr.jp> References: <46AE0928.6010006@samba.gr.jp> <9d732d950707301525md1cbcd7yda7679a5e30d026e@mail.gmail.com> <200707312027.JIE09834.tPPFNZtUNPEGWPS@I-love.SAKURA.ne.jp> <46AF34B7.9050808@nttdata.co.jp> <46AF43AD.3000702@samba.gr.jp> Message-ID: <200708010042.CFG94566.EWZttPGSPFPNPUN@I-love.SAKURA.ne.jp> > ＃コマンドが沢山あるのはSELinuxと比較して弱点だと思う。 多くはポリシーの作成を支援するために使われるコマンドですね。 > おっと。haltに手が入っているんですか？ > haltの中からユーザランドのヘルパーアプリを呼んでる？？ デフォルトでは手を入れる必要はありません。ただ、 /sbin/init 開始時から /sbin/poweroff による電源断の直前までアクセス制御を適用するのであれば savepolicy を /etc/rc.d/init.d/halt の中から呼びだすために手を加える必要が発生します。 また、 /etc/rc.d/init.d/halt の中の /sbin/poweroff が呼ばれる直前の時点では 既に / 以外のパーティションはアンマウントされてしまっています。 > これ、ハードリンクでいいの？セキュリティ的に。 どういう問題があるとお考えですか？ busybox のように argv[1] を参照しないようになってますから、 argv[0] を改ざんされない限り大丈夫です。 MAC_FOR_FILE=3 かつ MAC_FOR_ARGV0=3 （ SELinux でいう enforcing モード）が 指定されていない場合にはバイナリの改ざんや argv[0] の改ざんを 防止することはできないですが、それは SELinux と同じ事情でしょう。 > 起動/シャットダウンに直接的に不要なものを/sbin/に置くのは反対です。 > / fsはできるだけコンパクトにするべきです。 init_policy.sh などは / パーティションでなくても構いませんが、 ファイルサイズ的には微々たるものです。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Wed Aug 1 00:43:28 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Wed, 1 Aug 2007 00:43:28 +0900 Subject: [Tomoyo-dev 413] ccs -> tomoyo ? In-Reply-To: <46AF3239.70500@nttdata.co.jp> References: <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <9292c1390707310544kd3117fch90059552c96f2250@mail.gmail.com> <46AF3239.70500@nttdata.co.jp> Message-ID: <200708010043.JBI11861.ZPNPtPtPENFWGUS@I-love.SAKURA.ne.jp> > 今までの議論をまとめると、ccsもやめて全部tomoyoということですね。 　私が ccs をディレクトリ名やパッケージ名などで使っているのは、 ccs というキーワードに私の願いを込めているからなんです。 　名前の由来（プロジェクトとして承認されているものではなく 熊猫さくらが頭の中に描いていたものです）が http://I-love.SAKURA.ne.jp/tomoyo/ にあります。 ccs とは「カードキャプターさくら」の頭文字なのですが、 単に好きだからという理由だけで付けているのではありません。 　熊猫さくらが TOMOYO プロジェクトを通じて世の中に残したいと願っていることが http://hp.vector.co.jp/authors/VA022513/guchi.html#88 にあります。 （↑は近未来に起こることを予測し、愚痴るためのページです。） TOMOYO プロジェクトは２００３年の春に始まりました。 それは、長い長いイラク戦争の開始時期と重なるものです。 相次ぐテロなどで心の余裕が失われていく中、人々がカードキャプターさくらのことを知って 「思いやりを大切にする」「軍事力だけがセキュリティなのではない」ということを 思い出して欲しいという願いを ccs というキーワードに託しています。 ２ちゃんねるなどでは「今時カードキャプターなんて古いから改名しろ」とか 叩かれましたが、私にとってはジョンレノンのイマジンみたいな夢なのです。 　プロジェクト名としては（商標取得上の理由から） SAKURA でも CCS でもなく TOMOYO を使っていますが、 TOMOYO Linux だからという理由で ccs から tomoyo になり、 私が ccs というキーワードに託した願いが忘れられていくというのが私には辛いのです。 ccs ならば「何故？」と思うことはあっても、 tomoyo だと「原田知世？」で終わってしまうでしょう。 でも、 ccs から tomoyo に変更しなければせっかくの灯火が消えてしまうのでは仕方がありません。 いつまで私が TOMOYO プロジェクトに参加できるか判りませんし、 理由を知ってもなお ccs を完全排除して tomoyo に統一すべきであると TOMOYO-dev の皆様が考えているのならそうなるのでしょう。 From nez ＠ samba.gr.jp Wed Aug 1 06:02:42 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Wed, 01 Aug 2007 06:02:42 +0900 Subject: [Tomoyo-dev 414] =?iso-2022-jp?b?WzIuWF0bJEIlMyE8JUklLyVqITwlcyVKJUMlVyVYJWsbKEI=?= =?iso-2022-jp?b?GyRCJVcbKEI=?= In-Reply-To: <5fb14edc0707301844k637d8eeaj329baaeb81777cce@mail.gmail.com> References: <46AE8DB0.9020306@nttdata.co.jp> <5fb14edc0707301844k637d8eeaj329baaeb81777cce@mail.gmail.com> Message-ID: <46AFA372.1020600@samba.gr.jp> 根津です。 Kentaro Takeda wrote: > 再投稿へ向けての残作業は、 > ・機能の実装 > ・コードのクリーンアップ > です。実装は武田と半田さんで一気にやってしまい、一番時間のかかるコードの > クリーンアップ作業をtomoyo-devの皆さんに手伝っていただきたいと思っています。 > 方法についてはまた別途ご連絡しますが、協力したいという方は、vanillaカーネルの > 最新版が動作する環境の準備に加え、以下のドキュメントを読んでおいて > いただけるとスムーズに作業に入れると思います。 時期的にちょっとキビシい時期（色々と所用で着手できない可能性もある） なんですが、まずは、できるだけお手伝いしたいというレベルで手をあげて おきます。 ヘルプ挙手： ・根津（ちょっと期間的にキビシい可能性あります） > Linuxカーネルコーディング規約 > (en) http://lxr.linux.no/source/Documentation/CodingStyle > (ja) http://www.linux.or.jp/JF/JFdocs/kernel-docs-2.6/CodingStyle.html > Quiltコマンドのmanpage > http://linux.die.net/man/1/quilt > > 作業を手伝っていただいたことで実質的な報酬は出ませんが、 > コードの動作が変わらないように編集することで、 > TOMOYOがどのように動いているのかを深く理解できること請け合いです。 > > 以上、何かご意見、コメントなどありましたらお願いします。 -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From nez ＠ samba.gr.jp Wed Aug 1 06:18:34 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Wed, 01 Aug 2007 06:18:34 +0900 Subject: [Tomoyo-dev 415] Re: =?iso-2022-jp?b?GyRCJUQhPCVrJE4lVyVtJTAlaSVgTD4kSCVdJWobKEI=?= =?iso-2022-jp?b?GyRCJTchPCROTD5BMCROSlE5OSRLJEQkJCRGGyhC?= In-Reply-To: <200708010042.CFG94566.EWZttPGSPFPNPUN@I-love.SAKURA.ne.jp> References: <46AE0928.6010006@samba.gr.jp> <9d732d950707301525md1cbcd7yda7679a5e30d026e@mail.gmail.com> <200707312027.JIE09834.tPPFNZtUNPEGWPS@I-love.SAKURA.ne.jp> <46AF34B7.9050808@nttdata.co.jp> <46AF43AD.3000702@samba.gr.jp> <200708010042.CFG94566.EWZttPGSPFPNPUN@I-love.SAKURA.ne.jp> Message-ID: <46AFA72A.6000801@samba.gr.jp> 根津です。 Tetsuo Handa wrote: >> ＃コマンドが沢山あるのはSELinuxと比較して弱点だと思う。 > 多くはポリシーの作成を支援するために使われるコマンドですね。 どこまでが「必須」でどれが「必須」でないのか、一覧を作って 置く場所とセットできちんと分類する必要があります。 >> おっと。haltに手が入っているんですか？ >> haltの中からユーザランドのヘルパーアプリを呼んでる？？ > デフォルトでは手を入れる必要はありません。ただ、 /sbin/init 開始時から > /sbin/poweroff による電源断の直前までアクセス制御を適用するのであれば > savepolicy を /etc/rc.d/init.d/halt の中から呼びだすために手を加える必要が発生します。 これは必要性とリスクをきちんと考慮して、デフォルトをどちらかに 倒すべき部分ですね。どっちでもいいよ・・・というのはセキュアOS としての正しい判断ではない気がします。 > また、 /etc/rc.d/init.d/halt の中の /sbin/poweroff が呼ばれる直前の時点では > 既に / 以外のパーティションはアンマウントされてしまっています。 poweroffですからね。 >> これ、ハードリンクでいいの？セキュリティ的に。 > どういう問題があるとお考えですか？ > busybox のように argv[1] を参照しないようになってますから、 > argv[0] を改ざんされない限り大丈夫です。 > MAC_FOR_FILE=3 かつ MAC_FOR_ARGV0=3 （ SELinux でいう enforcing モード）が > 指定されていない場合にはバイナリの改ざんや argv[0] の改ざんを > 防止することはできないですが、それは SELinux と同じ事情でしょう。 どの機能がハードリンクなのか書き出せますか？ 改ざんされなければ大丈夫・・・という問題じゃあなくて、busyboxの 弱点は「異なるセキュリティレベルのデータへのアクセスが混在していること」 なのですが、 ・busyboxと同じような混在したアクセス ・（セキュリティ的に）異なる挙動を指示するコマンドの混在 などということがあったら、それは弱点です。 それはなぜかというと、「それぞれの機能や挙動」がきちっと分離されている ということが基本的に証明できないからです。 ＃プログラムのバグはいうに及ばず・・・。 もし、組み込みをターゲットにしたというのであれば、ヘルパアプリは 通常開発中システムにあるだけで本当のターゲットからは抜けると思う ので、サイズをハードリンクの理由にするのはヘンです。 busyboxは、起動時のシェルプログラムなどを動かすのに必要なヘルパ アプリケーションを一緒のバイナリにごった煮にしただけのものです。 なので、正直、たとえば"busybox passwd"機能などは組み込みの本番では 基本的に不要なものだと言えます。 （”おまけ”ですね） >> 起動/シャットダウンに直接的に不要なものを/sbin/に置くのは反対です。 >> / fsはできるだけコンパクトにするべきです。 > init_policy.sh などは / パーティションでなくても構いませんが、 > ファイルサイズ的には微々たるものです。 ファイルサイズが微々たるものだとすると、逆に無駄なディスク領域を 消費し、ムダにinodeエントリを消費するということになります。 / fsは特に拡張不可能なfsですから、「永続的に」消費するのはよくない ことだと思います。 -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From haradats ＠ gmail.com Wed Aug 1 06:31:47 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Wed, 1 Aug 2007 06:31:47 +0900 Subject: [Tomoyo-dev 416] Re: ccs -> tomoyo ? In-Reply-To: <200708010043.JBI11861.ZPNPtPtPENFWGUS@I-love.SAKURA.ne.jp> References: <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <9292c1390707310544kd3117fch90059552c96f2250@mail.gmail.com> <46AF3239.70500@nttdata.co.jp> <200708010043.JBI11861.ZPNPtPtPENFWGUS@I-love.SAKURA.ne.jp> Message-ID: <9d732d950707311431h4748bcf5kdfd0167acdc78118@mail.gmail.com> 07/08/01 に Tetsuo Handa さんは書きました: > > 今までの議論をまとめると、ccsもやめて全部tomoyoということですね。 > > 私が ccs をディレクトリ名やパッケージ名などで使っているのは、 > ccs というキーワードに私の願いを込めているからなんです。 > > 名前の由来（プロジェクトとして承認されているものではなく > 熊猫さくらが頭の中に描いていたものです）が > http://I-love.SAKURA.ne.jp/tomoyo/ にあります。 > ccs とは「カードキャプターさくら」の頭文字なのですが、 > 単に好きだからという理由だけで付けているのではありません。 > > 熊猫さくらが TOMOYO プロジェクトを通じて世の中に残したいと願っていることが > http://hp.vector.co.jp/authors/VA022513/guchi.html#88 にあります。 > （↑は近未来に起こることを予測し、愚痴るためのページです。） > TOMOYO プロジェクトは２００３年の春に始まりました。 > それは、長い長いイラク戦争の開始時期と重なるものです。 > 相次ぐテロなどで心の余裕が失われていく中、人々がカードキャプターさくらのことを知って > 「思いやりを大切にする」「軍事力だけがセキュリティなのではない」ということを > 思い出して欲しいという願いを ccs というキーワードに託しています。 > ２ちゃんねるなどでは「今時カードキャプターなんて古いから改名しろ」とか > 叩かれましたが、私にとってはジョンレノンのイマジンみたいな夢なのです。 > > プロジェクト名としては（商標取得上の理由から） SAKURA でも CCS でもなく TOMOYO を使っていますが、 > TOMOYO Linux だからという理由で ccs から tomoyo になり、 > 私が ccs というキーワードに託した願いが忘れられていくというのが私には辛いのです。 > ccs ならば「何故？」と思うことはあっても、 tomoyo だと「原田知世？」で終わってしまうでしょう。 > でも、 ccs から tomoyo に変更しなければせっかくの灯火が消えてしまうのでは仕方がありません。 > いつまで私が TOMOYO プロジェクトに参加できるか判りませんし、 > 理由を知ってもなお ccs を完全排除して tomoyo に統一すべきであると > TOMOYO-dev の皆様が考えているのならそうなるのでしょう。 プロジェクトが半田さん個人のもの、個人としての活動であるならば その名前や命名規則は半田さんが好きなように行えば良いと思います。 そうでなければ、名前や命名規則はプロジェクトとしての利益を 優先して（基準に）考えるべきです。 名前や命名規則の見直しは、プロジェクトとしての利益の観点から、 提案されたものであり、このプロジェクト（の成果）を自分たちだけの ものでなく、世界の人々のものにするため、今メンバーとして 関わっている我々がいなくなっても残るものとするために良いと 考えられているから提案されています。 私は本心からTOMOYO Linuxをメインラインにいれたいと 思っています。それ以外に開発の終わりはないことを知ったからです。 これまで行った作業のひとつひとつ、かけた時間を意味あるものに するためには、メインラインにいれるしかありません。 そうでなければ、それはいつか消え、忘れられるでしょう。 私にも夢や願いがある、と言うと半田さんは驚きますか？ 多分誰にもあると思いますよ。私がその夢のために、プロジェクトの 名前を変えたいと言ったら半田さんはどう思うのでしょう。 半田さんの夢や願いについてあれこれ言うつもりはありませんが、 その思いが本物なら形にこだわらなくても良いのではないかと 思います。また「形」として残すことにこだわるのなら、 まずは、TOMOYO Linuxが残ることを目指すべきではないかとも 思います。 半田さんは多分、これまで仕事としてではなく、プロジェクトの ためでもなく、自分のために（自分の夢や希望のために）TOMOYO Linuxを 開発してきたのですよね。でも、「自分のために」を最優先すると、 プロジェクトとしてはうまくいきません。半田さんは今後 どのようにこのプロジェクトに関わりたいですか？ -- Toshiharu Harada haradats ＠ gmail.com From nez ＠ samba.gr.jp Wed Aug 1 06:49:51 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Wed, 01 Aug 2007 06:49:51 +0900 Subject: [Tomoyo-dev 417] Re: ccs -> tomoyo ? In-Reply-To: <200708010043.JBI11861.ZPNPtPtPENFWGUS@I-love.SAKURA.ne.jp> References: <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <9292c1390707310544kd3117fch90059552c96f2250@mail.gmail.com> <46AF3239.70500@nttdata.co.jp> <200708010043.JBI11861.ZPNPtPtPENFWGUS@I-love.SAKURA.ne.jp> Message-ID: <46AFAE7F.1010103@samba.gr.jp> 根津です。 Tetsuo Handa wrote: >> 今までの議論をまとめると、ccsもやめて全部tomoyoということですね。 > > 　私が ccs をディレクトリ名やパッケージ名などで使っているのは、 > ccs というキーワードに私の願いを込めているからなんです。 ここでいう願いというのは、「思想」です。 どんなにすばらしい思想であっても思想は思想であり、物事に対する 「フィルタ」の存在を意味します。 今までいくつかフリーソフトウェアやPDSの類で、そのように「作者」の 思想が色濃く主張されているものを見てきていますが、みんなが利用する ときにその「思想」に賛同しなければ使うな・・・というおつもりでしょうか？ ＃名前に願いを入れているのだから勝手にいじるな・・・というのは、 ＃それと同じです。 ＃たとえば、これがTOMOYOじゃなくて、「ジハード」という名前であり、 ＃アッラーへの信仰を示すものなのだから信仰に帰依して使え・・・とか ＃言われたらふつー引くでしょ？ ＃（実際はそこまでひどいのは見たことないですが、ソフトウェア名に ＃WW3というのは見たことがありますね。何のつもりかWorld War IIIらしい ＃んですけどね） > 　名前の由来（プロジェクトとして承認されているものではなく > 熊猫さくらが頭の中に描いていたものです）が > http://I-love.SAKURA.ne.jp/tomoyo/ にあります。 > ccs とは「カードキャプターさくら」の頭文字なのですが、 > 単に好きだからという理由だけで付けているのではありません。 名称が変わったからといって、（しかもセキュアOSとしての名前はすでに 通り名が変わっているのに）、ccsにこだわり続けるのはどうでしょうか？ OSがTOMOYOで統一されたからといって、半田さんが込めた思いが変わる わけではないでしょう？ みんながそれに気付いて配慮して、尊敬して使わなければダメだというんで あれば、GPL捨ててそういうライセンシーにしたらいかがですか？ 名前にしばりを入れたい・・・というのはそれくらいに強いものですか？ ＃路傍の小さな華でもいいじゃないですか。半田さんが秘めた思いは ＃ちゃんと生きていくんですから。それじゃーだめなん？ ＃そんな風に「おまいら勝手にやりやがって」ノリで文句ぶーたれてたら ＃誰も結局使ってくれなくなって、半田さんが秘めた思いはそのまま ＃消えてなくなっちゃいませんか？ ボクらは「せっかく半田さんが作ったもの」が良いものなのでできるだけ 多くの人に使ってもらうためにはどうしたらよいか・・・ということを 考えたときに、統一された「名称」（お金と時間をかけて認知してもらった ものです）で推した方がよりよいだろうという判断をしているだけです。 ＃より多くの人に使ってもらうのと、半田さんの思いのある名前にした ＃ことで、「なんのこっちゃかよくわからん」と認知に誤認が発生して ＃より多くの人に使ってもらうのに齟齬があるのと、半田さんは個人的に ＃どちらがより「よい」と感じるのですか？ さらに、それだけの思いをもってネーミングしているとして、 もし、CCSは登録商標なのだから使うな・・・といわれたら、 TOMOYO Linux捨ててもいいと思うくらいに重要な「機能」なんで しょうか？ ＃ボクだったらより多くの人に使ってもらいやすい方を選びますけどねｗ ＃ま、ボクが作ったもんではないのでボクがどーこーいうもんじゃない ＃ですけどねｗ -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From matthew0115 ＠ gmail.com Wed Aug 1 07:00:39 2007 From: matthew0115 ＠ gmail.com (matthew.szulik@gmail.com) Date: Wed, 01 Aug 2007 07:00:39 +0900 Subject: [Tomoyo-dev 418] Re: =?iso-2022-jp?b?dG9tb3lvbGludXgue2NvbSwgbmV0LCBvcmcsIGpwfSA=?= =?iso-2022-jp?b?GyRCJUklYSUkJXMkciUtITwlVyQ3JF4kNyQ/ISMbKEI=?= In-Reply-To: <46AF3239.70500@nttdata.co.jp> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <9d732d950707301536ib067596v7509cd8c95969267@mail.gmail.com> <53275.163.135.10.34.1185849256.squirrel@webmail.knlab.com> <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <9292c1390707310544kd3117fch90059552c96f2250@mail.gmail.com> <46AF3239.70500@nttdata.co.jp> Message-ID: <46AFB107.7050802@gmail.com> おはようございます。Matthew/秋元です。 Toshiharu Harada さんは書きました: > hito さんは書きました: >>>> そう言えば、ccsをtomoyoに統一しよう。 >>>> tomoyoはキーボードの右側ばかり使う（笑）。 >>>> tmyに略す？ >>>> >>>> のような話もありましたね。 >>> 名前をどうするかの話が止まっているようですが、 >>> 他にご意見はありませんか？ >> きわめて個人的にはtmyを支持したいのですが（コマンドラインだと脳と指が >> 英語モードになっているので、母音を打ちにくい）、ccsよりはtomoyoの方が >> 良いと思います。 >> >> で、この理論を援用すると、tmyは直感的でないので、tomoyoで良いと >> 思います。 >> どこにフォーカスするべきなのか、は議論が必要な気がするのですが、 >> 慣れたユーザにとっての楽さより、敷居の低さの方が重要な気がしてきました。 > > 今まで使っていないtmyは新たな問題をはらんでいるかもしれず、 > 余計なことに労力を使わないという意味ではやはりtomoyoだと > 思います。 > > 今までの議論をまとめると、ccsもやめて全部tomoyoということですね。 個人的には統一して欲しいだけなのですが、tomoyoを支持します。 From dai-yamato-zero ＠ gaea.ocn.ne.jp Wed Aug 1 07:36:54 2007 From: dai-yamato-zero ＠ gaea.ocn.ne.jp (=?iso-2022-jp?B?GyRCPi41V0pdT0I5KBsoQg==?=) Date: Wed, 1 Aug 2007 07:36:54 +0900 Subject: [Tomoyo-dev 419] Re: =?iso-2022-jp?b?dG9tb3lvbGludXgue2NvbSwgbmV0LCBvcmcsIGpwfSA=?= =?iso-2022-jp?b?GyRCJUklYSUkJXMkciUtITwlVyQ3JF4kNyQ/ISMbKEI=?= References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com><9d732d950707301536ib067596v7509cd8c95969267@mail.gmail.com><53275.163.135.10.34.1185849256.squirrel@webmail.knlab.com><46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp><200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <9292c1390707310544kd3117fch90059552c96f2250@mail.gmail.com> Message-ID: <015f01c7d3c3$4c2a6a00$0203a8c0@yamato> おはようございます。 メーリングリストの処理に追いつけなくなりそうな消化不良の小久保です。 >> > そう言えば、ccsをtomoyoに統一しよう。 >> > tomoyoはキーボードの右側ばかり使う（笑）。 >> > tmyに略す？ >> > >> > のような話もありましたね。 >> >> 名前をどうするかの話が止まっているようですが、 >> 他にご意見はありませんか？ > > きわめて個人的にはtmyを支持したいのですが（コマンドラインだと脳と指が > 英語モードになっているので、母音を打ちにくい）、ccsよりはtomoyoの方が > 良いと思います。 > > で、この理論を援用すると、tmyは直感的でないので、tomoyoで良いと > 思います。 > どこにフォーカスするべきなのか、は議論が必要な気がするのですが、 > 慣れたユーザにとっての楽さより、敷居の低さの方が重要な気がしてきました。 > 個人的にはtomoyoで良いと思います。 私も今後使われていくことを目指すならば名称の統一は必要と考えています。 ちなみにccs->tomoyoで白熱の議論がされています。 ただ、議論している方々が開発の中心で毎日顔をあわせる方々で できますれば、メーリングリスト上でなく 対面での一度意見のすりあわせをした方が良いのではないでしょうか。 その上で名称議論を再開した方が良いと思います。 もともとの議論はtmy等の略称についてどうするか、 ハイフン付のものはどうするべきかだったように思います。 この件については過去の経緯もあるようですし、 少し議論の方向性が本来あるべき姿ではないところに 向かおうとしていそうで少し心配しております。 #ccsの由来ってそういうことだったんですね。 #うすうす気がついていたんですが聞くに聞けませんでした。。。 #個人的には自分がシステム提案でお客さんに説明に行くことを想定するとccsは少し説明しにくいです。。。 From matthew0115 ＠ gmail.com Wed Aug 1 09:16:11 2007 From: matthew0115 ＠ gmail.com (matthew.szulik@gmail.com) Date: Wed, 01 Aug 2007 09:16:11 +0900 Subject: [Tomoyo-dev 420] Re: =?iso-2022-jp?b?WzIuWF0bJEIlMyE8JUklLyVqITwlcyVKJUMlVyVYGyhC?= =?iso-2022-jp?b?GyRCJWslVxsoQg==?= In-Reply-To: <46AFA372.1020600@samba.gr.jp> References: <46AE8DB0.9020306@nttdata.co.jp> <5fb14edc0707301844k637d8eeaj329baaeb81777cce@mail.gmail.com> <46AFA372.1020600@samba.gr.jp> Message-ID: <46AFD0CB.2010808@gmail.com> Matthew/秋元です。 Kensuke Nezu さんは書きました: > 根津です。 > > Kentaro Takeda wrote: >> 再投稿へ向けての残作業は、 >> ・機能の実装 >> ・コードのクリーンアップ >> です。実装は武田と半田さんで一気にやってしまい、一番時間のかかるコードの >> クリーンアップ作業をtomoyo-devの皆さんに手伝っていただきたいと思っています。 >> 方法についてはまた別途ご連絡しますが、協力したいという方は、vanillaカーネルの >> 最新版が動作する環境の準備に加え、以下のドキュメントを読んでおいて >> いただけるとスムーズに作業に入れると思います。 > > 時期的にちょっとキビシい時期（色々と所用で着手できない可能性もある） > なんですが、まずは、できるだけお手伝いしたいというレベルで手をあげて > おきます。 > > ヘルプ挙手： > ・根津（ちょっと期間的にキビシい可能性あります） 私も微力ながら早朝のお時間にお手伝いできます。 >> Linuxカーネルコーディング規約 >> (en) http://lxr.linux.no/source/Documentation/CodingStyle >> (ja) http://www.linux.or.jp/JF/JFdocs/kernel-docs-2.6/CodingStyle.html 皆さんご存知だとはおもいますが、今回にの件に関係するところを抽出してみま した： - タビングが８文字 - 一行に複数の文を書かない - 行の最後に空白を置かない - 行の長さは80カラム以内 - 制御文などのブロックではブロック開始行に開始括弧を置く(K&R) - 関数定義では次の行に開始括弧を置く(K&R) - else や do while のwhileの場合は終了括弧の隣に書く(K&R) - 関数の長さは80x24で2画面以内がのぞましい - case文があって長くなるのはかまわない - ローカル変数は５から１０個程度がのぞましい Emacs を利用している場合は上記のドキュメントどおりに .emacs にlinux-c- modeの設定を適切にした上で編集することでよろしいですよね。 >> Quiltコマンドのmanpage >> http://linux.die.net/man/1/quilt >> >> 作業を手伝っていただいたことで実質的な報酬は出ませんが、 >> コードの動作が変わらないように編集することで、 >> TOMOYOがどのように動いているのかを深く理解できること請け合いです。 >> >> 以上、何かご意見、コメントなどありましたらお願いします。 リグレッションテスト・動作検証は誰がするんでしょう、どうやって行ったらよ いのでしょう・・・ From nez ＠ samba.gr.jp Wed Aug 1 10:02:19 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Wed, 1 Aug 2007 10:02:19 +0900 (JST) Subject: [Tomoyo-dev 421] Re: =?iso-2022-jp?b?WzIuWF0gGyRCJTMhPCVJJS8laiE8JXMlSiVDJVcbKEI=?= =?iso-2022-jp?b?GyRCJVglayVXGyhC?= In-Reply-To: <46AFD0CB.2010808@gmail.com> References: <46AE8DB0.9020306@nttdata.co.jp> <5fb14edc0707301844k637d8eeaj329baaeb81777cce@mail.gmail.com><46AFA372.1020600@samba.gr.jp> <46AFD0CB.2010808@gmail.com> Message-ID: <41029.163.135.10.36.1185930139.squirrel@webmail.knlab.com> 根津です。 On 2007年 8月 1日 (水) 9:16, matthew.szulik ＠ gmail.com wrote: > リグレッションテスト・動作検証は誰がするんでしょう、どうやって行ったらよ > いのでしょう・・・ ルール変形のうち、 > - 関数の長さは80x24で2画面以内がのぞましい > - case文があって長くなるのはかまわない > - ローカル変数は５から１０個程度がのぞましい を除けば整形にすぎないので、このレベルのクリーンアップであれば、一度、 コンパイラでバイナリを作成して、.text部分のみ取り出してバイナリ比較 すればいいのではないでしょうか？ 上記のルール変更が必要になる場合は、コードロジックの変更になるので、 ソースコードレビューとテストが必要な気がします。 -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From k.takeda26 ＠ gmail.com Wed Aug 1 11:50:34 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Wed, 1 Aug 2007 11:50:34 +0900 Subject: [Tomoyo-dev 422] Re: =?iso-2022-jp?b?WzIuWF0gGyRCJTMhPCVJJS8laiE8JXMlSiVDJVcbKEI=?= =?iso-2022-jp?b?GyRCJVglayVXGyhC?= In-Reply-To: <41029.163.135.10.36.1185930139.squirrel@webmail.knlab.com> References: <46AE8DB0.9020306@nttdata.co.jp> <5fb14edc0707301844k637d8eeaj329baaeb81777cce@mail.gmail.com> <46AFA372.1020600@samba.gr.jp> <46AFD0CB.2010808@gmail.com> <41029.163.135.10.36.1185930139.squirrel@webmail.knlab.com> Message-ID: <5fb14edc0707311950h457750f8ha7929dc2ae9aed3@mail.gmail.com> たけだです。 協力の意思表示、ありがとうございます。m(_ _)m 作業をしていただくときにまた説明しますが、 最近のカーネルに付属しているscripts/checkpatch.plにパッチを食わせれば、 スタイルのチェックを行ってくれます。 これの出力をベースにクリーンアップ作業を行っていただければと思います。 たとえばこんな感じの出力が得られます。 ----- [root ＠ etch]# checkpatch.pl patches/tomoyo-mount.diff WARNING: externs should be avoided in .c files #24: FILE: security/tomoyo/mount.c:15: +extern const char *ccs_log_level; ERROR: do not initialise statics to 0 or NULL #54: FILE: security/tomoyo/mount.c:45: +static struct mount_entry *mount_list = NULL; ----- ある程度機会的にスタイルを修正できます。 実際にTOMOYOのコードのスタイルをチェックして修正してみるとわかるのですが、 > - 行の長さは80カラム以内 を達成するのが一番難しいです。インデントが深いのが主な原因ですので、 ロジックの変更、関数の切り出しなどが必要になります。 また、関数の切り出しという意味では、 > - 関数の長さは80x24で2画面以内がのぞましい > - case文があって長くなるのはかまわない > - ローカル変数は５から１０個程度がのぞましい これらは現在のcheckpatch.plでは検出されませんし、 たけだがすでにやったファイルでもこれらは修正しきれていません orz #この辺がけっこうタイヘンです。 また、たけだがやってきたクリーンアップ後のテストは地道です。 ・ccstools/kernel_test以下のツールで学習とアクセス制御が動くことを確認 ・修正箇所が影響を与えうるロジックを走してみる ・/proc/slabinfoを見て単調増加してないかチェック クリーンアップやテスト方法でいいアイディアをお持ちの方が いればぜひお知らせください。m(_ _)m From haradats ＠ gmail.com Wed Aug 1 12:36:52 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Wed, 1 Aug 2007 12:36:52 +0900 Subject: [Tomoyo-dev 423] Re: =?iso-2022-jp?b?dG9tb3lvbGludXgue2NvbSwgbmV0LCBvcmcsIGpwfSA=?= =?iso-2022-jp?b?GyRCJUklYSUkJXMkciUtITwlVyQ3JF4kNyQ/ISMbKEI=?= In-Reply-To: <015f01c7d3c3$4c2a6a00$0203a8c0@yamato> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <9d732d950707301536ib067596v7509cd8c95969267@mail.gmail.com> <53275.163.135.10.34.1185849256.squirrel@webmail.knlab.com> <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <9292c1390707310544kd3117fch90059552c96f2250@mail.gmail.com> <015f01c7d3c3$4c2a6a00$0203a8c0@yamato> Message-ID: <9d732d950707312036y29d8a5doe7b58cff9167495f@mail.gmail.com> 原田です。今日は朝からずっと打ち合わせで、今自分の席に 戻りました。(=_=; 長時間打ち合わせ反対！ 07/08/01 に 小久保和宏 さんは書きました: > 個人的にはtomoyoで良いと思います。 > 私も今後使われていくことを目指すならば名称の統一は必要と考えています。 > > ちなみにccs->tomoyoで白熱の議論がされています。 議論というよりは意見や見解の表明かもしれません。 > ただ、議論している方々が開発の中心で毎日顔をあわせる方々で > できますれば、メーリングリスト上でなく > 対面での一度意見のすりあわせをした方が良いのではないでしょうか。 > その上で名称議論を再開した方が良いと思います。 名前については（今や）tomoyo-devで議論すべき話題であると 思いますが、ご助言に従い、このあと原田、半田、武田、平坂の 4名で対面で話し合いを持つ予定です。 > もともとの議論はtmy等の略称についてどうするか、 > ハイフン付のものはどうするべきかだったように思います。 > この件については過去の経緯もあるようですし、 > 少し議論の方向性が本来あるべき姿ではないところに > 向かおうとしていそうで少し心配しております。 本来、メインライン化に向けた作業や開発が議論の 対象だったのですが、そこが止まってしまうと問題です。 > #ccsの由来ってそういうことだったんですね。 > #うすうす気がついていたんですが聞くに聞けませんでした。。。 かなりあからさまかつオープンなような気がしますが、 小久保さんはご存じなかったのですね。 「はにゃ〜ん化計画」は検索で常に上位にヒットします。 > #個人的には自分がシステム提案でお客さんに説明に行くことを想定するとccsは少し説明しにくいです。。。 名前にしても仕様にしても、多分半田さんが本当にやりたいのは、 ccsあるいはccsという思想であり、半田さんのTOMOYO Linux なのだと思います。 でも開発に協力しようと言って集まっていただいた方々に とっての対象はccsではないでしょうから、そこは区別しなければ いけません。その意味でccsについて、半田さんから直接 説明してもらったのは良かったです。 ひとつの考え方として、"ccs"という文字列自体をなくそうと いう声は出ていないですから、ディレクトリ名等は tomoyoに統一して、README.ccsのようなものは 残すというのはありだと私は思っています。 また、もしかしたら半田さんが本当に作りたい半田さんの TOMOYO Linuxは、結局共同では作れずあくまで 半田さんが自分で作るものかもしれません。そのときは、 コミュニティ版のTOMOYO Linuxの横に、ccs TOMOYO Linuxが あって、半田さんはその両方に関わる形なのかなと 思っています。 -- Toshiharu Harada haradats ＠ gmail.com From from-tomoyo-dev ＠ i-love.sakura.ne.jp Wed Aug 1 12:37:32 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Wed, 01 Aug 2007 12:37:32 +0900 Subject: [Tomoyo-dev 424] Re: ccs -> tomoyo ? In-Reply-To: <9d732d950707311431h4748bcf5kdfd0167acdc78118@mail.gmail.com> References: <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <9292c1390707310544kd3117fch90059552c96f2250@mail.gmail.com> <46AF3239.70500@nttdata.co.jp> <200708010043.JBI11861.ZPNPtPtPENFWGUS@I-love.SAKURA.ne.jp> <9d732d950707311431h4748bcf5kdfd0167acdc78118@mail.gmail.com> Message-ID: <200708010337.l713bWme043627@www262.sakura.ne.jp> > 半田さんは多分、これまで仕事としてではなく、プロジェクトの > ためでもなく、自分のために（自分の夢や希望のために）TOMOYO Linuxを > 開発してきたのですよね。 　「仕事としてではなく」と書かれると まるで私利私欲のためだけに開発しているように聞こえます。 TOMOYO Linux は名前こそ遊んでいますが、内容はとても真面目です。 サーバ管理者のセキュリティ維持のための負担を減らし、 （実際にはセキュリティホールを根絶できていませんが） セキュリティホールの心配を２度としないで済むようにしてあげたいと真剣に考え、 （原田さんと私という２人で始まったプロジェクトの中で）その開発を行うことが 高校生のときからプログラミングに携わってきた私にしかできない任務として 続けてきました。（カーネル開発は入社後に初めてパソコンに触れたり プログラミングを経験するような人にとっては過酷な作業です。 同期入社のほとんどが Java や VB などミスをしてもエラー処理が可能な環境で プログラミングをしている中、私だけがミスをしたら即死するカーネル世界での 作業をしてきました。）その中で、名前の部分に願いを込めているのです。 > でも、「自分のために」を最優先すると、 > プロジェクトとしてはうまくいきません。半田さんは今後 > どのようにこのプロジェクトに関わりたいですか？ 　私が一切の決定を行うことを放棄します。 私が最後の足枷になっているからです。 　今まではＮＴＴデータとして承認を経ないと ユーザの元に届けられないという足枷がありましたが、 コミュニティの意思で subversion の tags に コピーしてバイナリパッケージを作って配布することを 禁止しないということになったので、その足枷は無くなりました。 ソースコードが公開されているだけだったプロジェクトから、 オープンソースのプロジェクトとして動き出す準備が整いつつあるわけです。 　残る足枷は、「頭が固く、思い込みが激しく、ワガママで、 コミュニケーション能力が低く、共同作業を苦手とする熊猫さくらの存在」です。 共同開発者の募集は、ＮＴＴデータとして TOMOYO プロジェクトが打ち切りになっても TOMOYO Linux が滅ばないようにスキルを伝承していくためでもあります。 私が足枷となって TOMOYO Linux が滅んでは意味がありません。 （原田さんはメインラインに入らなかったら必ず滅ぶと既に決め付けているように見えますが、私はそうは思いません。） 　TOMOYO Linux は私の手に負えない段階に突入しました。 私の書くコードは１人で開発するようにひどく最適化されていて、共同作業をするのには向いていません。 試行錯誤を繰り返しながら私が書いたプロトタイプはその役目を終えました。 TOMOYO Linux はあるべき姿を議論して メンテナンスが可能な形で一から再構築する時期に来ていると感じています。 ただ、残念なことに私の能力不足で議論の叩き台を用意することができず、 議論やレビューが行えない状態のまま、延び延びになってしまいました。 　TOMOYO Linux はアイデアとしては成功していますが、ネーミングでは大失敗しています。 tomoyo という名前がカードキャプターさくらの大道寺知世に由来していることが システム提案でお客さんに説明に行く場合に説明しにくいという声が複数あがっています。 「カードキャプターさくらを説明するのは恥ずかしいこと」と思われているのは悲しいです。 カードキャプターさくらであることが既に普及の妨げの一因になっているのですから、 この際 ccs というキーワードを完全に排除するだけでなく プロジェクト名を変更して tomoyo というキーワードも完全に排除することだってありえるでしょう。 プロジェクト名の変更でもパッケージ名の変更でもバージョン名の付与規則の変更でも パス名やファイル名の変更でも、私の願いを無視して自由にやってください。 私に決定させないでください。私に指示を求めないでください。 私が最後の足枷になっているからです。 From haradats ＠ nttdata.co.jp Wed Aug 1 12:58:32 2007 From: haradats ＠ nttdata.co.jp (Toshiharu Harada) Date: Wed, 01 Aug 2007 12:58:32 +0900 Subject: [Tomoyo-dev 425] Re: ccs -> tomoyo ? In-Reply-To: <200708010337.l713bWme043627@www262.sakura.ne.jp> References: <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <9292c1390707310544kd3117fch90059552c96f2250@mail.gmail.com> <46AF3239.70500@nttdata.co.jp> <200708010043.JBI11861.ZPNPtPtPENFWGUS@I-love.SAKURA.ne.jp> <9d732d950707311431h4748bcf5kdfd0167acdc78118@mail.gmail.com> <200708010337.l713bWme043627@www262.sakura.ne.jp> Message-ID: <46B004E8.6050303@nttdata.co.jp> from-tomoyo-dev ＠ i-love.sakura.ne.jp さんは書きました: >> 半田さんは多分、これまで仕事としてではなく、プロジェクトの >> ためでもなく、自分のために（自分の夢や希望のために）TOMOYO Linuxを >> 開発してきたのですよね。 > 　「仕事としてではなく」と書かれると > まるで私利私欲のためだけに開発しているように聞こえます。 > TOMOYO Linux は名前こそ遊んでいますが、内容はとても真面目です。 > サーバ管理者のセキュリティ維持のための負担を減らし、 > （実際にはセキュリティホールを根絶できていませんが） > セキュリティホールの心配を２度としないで済むようにしてあげたいと真剣に考え、 > （原田さんと私という２人で始まったプロジェクトの中で）その開発を行うことが > 高校生のときからプログラミングに携わってきた私にしかできない任務として > 続けてきました。（カーネル開発は入社後に初めてパソコンに触れたり > プログラミングを経験するような人にとっては過酷な作業です。 > 同期入社のほとんどが Java や VB などミスをしてもエラー処理が可能な環境で > プログラミングをしている中、私だけがミスをしたら即死するカーネル世界での > 作業をしてきました。）その中で、名前の部分に願いを込めているのです。 言葉が不足していました。「自分のためにを優先して」と いうことであって、仕事やプロジェクトのためがゼロとは 勿論思っていません。すみません。 >> でも、「自分のために」を最優先すると、 >> プロジェクトとしてはうまくいきません。半田さんは今後 >> どのようにこのプロジェクトに関わりたいですか？ > 　私が一切の決定を行うことを放棄します。 > 私が最後の足枷になっているからです。 TOMOYO Linuxの全てを知る人間は現状半田さんしか いません。共同開発なので、決めるのは話し合いですが、 プランを考えるために半田さんは不可欠ですし、 半田さんとしての意見は持って、伝えて下さい。 > 　今まではＮＴＴデータとして承認を経ないと > ユーザの元に届けられないという足枷がありましたが、 > コミュニティの意思で subversion の tags に > コピーしてバイナリパッケージを作って配布することを > 禁止しないということになったので、その足枷は無くなりました。 > ソースコードが公開されているだけだったプロジェクトから、 > オープンソースのプロジェクトとして動き出す準備が整いつつあるわけです。 昨日、会社の知財に正式に相談を依頼しました。内容は、 「そもそも会社としてオープンソースのプロジェクトの リリースに決裁はいらないのではないか？」という内容です。 開発会議を終わってからずっと考えていたのですが、 NTTデータの社員が勝手にオープンソースのプロジェクトに 参加し、活動している、そう考えるのが自然な気がしています。 打ち合わせは一度では終わらないと思いますが、 経過について今後このmlで報告します。 当面の間は、SourceForge.jpのリリース置き場へのリリースは 会社の決裁を行いますが、それも不要というか しないほうが良いと思っています。 > 　残る足枷は、「頭が固く、思い込みが激しく、ワガママで、 > コミュニケーション能力が低く、共同作業を苦手とする熊猫さくらの存在」です。 > 共同開発者の募集は、ＮＴＴデータとして TOMOYO プロジェクトが打ち切りになっても > TOMOYO Linux が滅ばないようにスキルを伝承していくためでもあります。 > 私が足枷となって TOMOYO Linux が滅んでは意味がありません。 > （原田さんはメインラインに入らなかったら必ず滅ぶと既に決め付けているように見えますが、私はそうは思いません。） 決めつけているかはわかりませんが、メインラインにはいらず 例えば10年後も更新され使われていて、かつその状況が維持されている 状態は想像しにくいです。 > 　TOMOYO Linux は私の手に負えない段階に突入しました。 > 私の書くコードは１人で開発するようにひどく最適化されていて、共同作業をするのには向いていません。 > 試行錯誤を繰り返しながら私が書いたプロトタイプはその役目を終えました。 > TOMOYO Linux はあるべき姿を議論して > メンテナンスが可能な形で一から再構築する時期に来ていると感じています。 > ただ、残念なことに私の能力不足で議論の叩き台を用意することができず、 > 議論やレビューが行えない状態のまま、延び延びになってしまいました。 今、その時期がきたのだと思っています。 > 　TOMOYO Linux はアイデアとしては成功していますが、ネーミングでは大失敗しています。 > tomoyo という名前がカードキャプターさくらの大道寺知世に由来していることが > システム提案でお客さんに説明に行く場合に説明しにくいという声が複数あがっています。 そうでしょうか？ 私はネーミングはむしろ成功だと思いますよ。 悪い名前ではありませんし、問題もありません。むしろ良い名前だと思っています。 「名前（だけ）が理由で説明に行けず、提案されていない」例も あるのかもしれませんが、違う（地味な）名前だったら、今の 状態もなかったかもしれませんよね。 > 「カードキャプターさくらを説明するのは恥ずかしいこと」と思われているのは悲しいです。 私はそうは思っていません。 > カードキャプターさくらであることが既に普及の妨げの一因になっているのですから、 そんなことはないと思います。 > この際 ccs というキーワードを完全に排除するだけでなく > プロジェクト名を変更して tomoyo というキーワードも完全に排除することだってありえるでしょう。 > プロジェクト名の変更でもパッケージ名の変更でもバージョン名の付与規則の変更でも > パス名やファイル名の変更でも、私の願いを無視して自由にやってください。 > 私に決定させないでください。私に指示を求めないでください。 > 私が最後の足枷になっているからです。 プロジェクト名の変更や"ccs", "tomoyo"の完全排除は 少なくとも今のところ誰からもあがっていません。 -- 原田季栄 (Toshiharu Harada) haradats ＠ nttdata.co.jp From dai-yamato-zero ＠ gaea.ocn.ne.jp Wed Aug 1 13:45:42 2007 From: dai-yamato-zero ＠ gaea.ocn.ne.jp (=?iso-2022-jp?B?GyRCPi41V0pdT0I5KBsoQg==?=) Date: Wed, 1 Aug 2007 13:45:42 +0900 Subject: [Tomoyo-dev 426] Re: =?iso-2022-jp?b?WzIuWF0gGyRCJTMhPCVJJS8laiE8JXMlSiVDJVcbKEI=?= =?iso-2022-jp?b?GyRCJVglayVXGyhC?= References: <46AE8DB0.9020306@nttdata.co.jp><5fb14edc0707301844k637d8eeaj329baaeb81777cce@mail.gmail.com><46AFA372.1020600@samba.gr.jp> <46AFD0CB.2010808@gmail.com><41029.163.135.10.36.1185930139.squirrel@webmail.knlab.com> <5fb14edc0707311950h457750f8ha7929dc2ae9aed3@mail.gmail.com> Message-ID: <004801c7d3f6$d1124700$0203a8c0@yamato> こんにちは。小久保です。 私も参加したいと思います。 どの程度お役に立てるかは未知数ですが・・・。 > たけだです。 > > 協力の意思表示、ありがとうございます。m(_ _)m > > 作業をしていただくときにまた説明しますが、 > 最近のカーネルに付属しているscripts/checkpatch.plにパッチを食わせれば、 > スタイルのチェックを行ってくれます。 > これの出力をベースにクリーンアップ作業を行っていただければと思います。 > > たとえばこんな感じの出力が得られます。 > ----- > [root ＠ etch]# checkpatch.pl patches/tomoyo-mount.diff > WARNING: externs should be avoided in .c files > #24: FILE: security/tomoyo/mount.c:15: > +extern const char *ccs_log_level; > > ERROR: do not initialise statics to 0 or NULL > #54: FILE: security/tomoyo/mount.c:45: > +static struct mount_entry *mount_list = NULL; > ----- > ある程度機会的にスタイルを修正できます。 > > 実際にTOMOYOのコードのスタイルをチェックして修正してみるとわかるのですが、 >> - 行の長さは80カラム以内 > を達成するのが一番難しいです。インデントが深いのが主な原因ですので、 > ロジックの変更、関数の切り出しなどが必要になります。 > > また、関数の切り出しという意味では、 >> - 関数の長さは80x24で2画面以内がのぞましい >> - case文があって長くなるのはかまわない >> - ローカル変数は５から１０個程度がのぞましい > これらは現在のcheckpatch.plでは検出されませんし、 > たけだがすでにやったファイルでもこれらは修正しきれていません orz > #この辺がけっこうタイヘンです。 > > また、たけだがやってきたクリーンアップ後のテストは地道です。 > ・ccstools/kernel_test以下のツールで学習とアクセス制御が動くことを確認 > ・修正箇所が影響を与えうるロジックを走してみる > ・/proc/slabinfoを見て単調増加してないかチェック > > クリーンアップやテスト方法でいいアイディアをお持ちの方が > いればぜひお知らせください。m(_ _)m > #過去にはソース資産が膨れ上がって身動きの取れなくなった開発の #建て直し専門チームのリーダをしてたので、クリーン化、作り直しなど #個人的にはこういうのは得意だったりします。 #まだ対象となるソースを見ていないのでなんともいえないですが、 #たけださんの行ってきた機能レベル確認と言った視点と #機械的な方法としては純粋に影響関数下のインタフェースを切り出しての #関数レベルでのインタフェースイベントの網羅確認など手法があると思います。 #作業着手段階になったら(すでにその段階?)スケジュール、方法、分担を皆さんと議論したいと思ってます。 #その前に、私自身の作業をするマシン環境を確保しないと。もう１台PC買うか・・・ From k.takeda26 ＠ gmail.com Wed Aug 1 14:17:19 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Wed, 1 Aug 2007 14:17:19 +0900 Subject: [Tomoyo-dev 427] Re: =?iso-2022-jp?b?WzIuWF0gGyRCJTMhPCVJJS8laiE8JXMlSiVDJVcbKEI=?= =?iso-2022-jp?b?GyRCJVglayVXGyhC?= In-Reply-To: <004801c7d3f6$d1124700$0203a8c0@yamato> References: <46AE8DB0.9020306@nttdata.co.jp> <5fb14edc0707301844k637d8eeaj329baaeb81777cce@mail.gmail.com> <46AFA372.1020600@samba.gr.jp> <46AFD0CB.2010808@gmail.com> <41029.163.135.10.36.1185930139.squirrel@webmail.knlab.com> <5fb14edc0707311950h457750f8ha7929dc2ae9aed3@mail.gmail.com> <004801c7d3f6$d1124700$0203a8c0@yamato> Message-ID: <5fb14edc0707312217q471cb814kdb35352eace67f3a@mail.gmail.com> たけだです。 >#過去にはソース資産が膨れ上がって身動きの取れなくなった開発の >#建て直し専門チームのリーダをしてたので、クリーン化、作り直しなど >#個人的にはこういうのは得意だったりします。 おぉぉ、よろしくお願いいたします。艦長。 現在マウント制限を鋭意実装中です。 From matthew0115 ＠ gmail.com Wed Aug 1 15:14:13 2007 From: matthew0115 ＠ gmail.com (matthew.szulik@gmail.com) Date: Wed, 01 Aug 2007 15:14:13 +0900 Subject: [Tomoyo-dev 428] Re: =?iso-2022-jp?b?GyRCQmgbKEIxGyRCMnMzK0gvMnE1RCU1JV4laiE8GyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <5fb14edc0707301844k637d8eeaj329baaeb81777cce@mail.gmail.com> References: <46AE8DB0.9020306@nttdata.co.jp> <5fb14edc0707301844k637d8eeaj329baaeb81777cce@mail.gmail.com> Message-ID: <46B024B5.8000906@gmail.com> Matthew/秋元です。 LSMは実は概要程度しか理解していないのですが、そのまえにLSMのフックポイン トを把握しているサイト、フックポイント箇所（システムコール単位）の一覧な どが掲載されているサイトはあるでしょうか？ Stephen Smalley氏も当然関わっている "Linux Security Modules: General Security Support for the Linux Kernel" http://www.usenix.org/events/sec02/full_papers/wright/wright_html/index.html という文書がありますが、網羅したものを見つけたことがありません。 security_*などの関数がコーディングされている関数を抜き出すスクリプトを書 けばよいだけですが、すでにあるのならちょっと俯瞰してみたいと思いました。 Kentaro Takeda さんは書きました: > たけだです。 > > 開発会議から、今後2.x系がどのように進むかを考えた結果をご説明します。 > > 2.x系は「メインラインへ向けて機能拡張」という方向へ進みます。 > 現在LKMLに投稿済みの2.0はファイルに対するアクセス制御機能しか > 搭載していませんが、1.x系の持つ他の機能の移植を行い、 > 8月中にLKMLに再投稿します。 > > 開発会議では、LKMLに小出しする必要はない、という意見が得られました。 > 現在のLSMの仕様では実現できない1.xの機能がいくつかありますが、 > それを実現するためのLSMの拡張も含めた形で、すなわち、 > (1) 現状のLSMの仕様でできるTOMOYO本体 > (2) LSMの拡張とそれを利用したTOMOYO本体 > という2本立てをまとめて出そうと思っています。 > > 機能の取捨選択は以下のように考えています。 > > (1)に関しては、以下の機能が候補です > ・ファイル > ・ネットワーク（受信系以外） > ・マウント > これらは全て実装して投稿します。 > > (2)に関しては、以下の機能が候補です > ・ネットワーク（受信系） > ・ケイパビリティ > ・シグナル > この中で、ケイパビリティは次回の投稿からははずすことにします。 > POSIXではなく独自ケイパビリティを使用していることでTOMOYOの本質とは > 別のところで議論が生じてしまうこと、 > 必要となるLSMの拡張が多いことがその理由です。 From k.takeda26 ＠ gmail.com Wed Aug 1 15:34:01 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Wed, 1 Aug 2007 15:34:01 +0900 Subject: [Tomoyo-dev 429] Re: =?iso-2022-jp?b?GyRCQmgbKEIxGyRCMnMzK0gvMnE1RCU1JV4laiE8GyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <46B024B5.8000906@gmail.com> References: <46AE8DB0.9020306@nttdata.co.jp> <5fb14edc0707301844k637d8eeaj329baaeb81777cce@mail.gmail.com> <46B024B5.8000906@gmail.com> Message-ID: <5fb14edc0707312334j43b51a27m4afb0c2d298d8903@mail.gmail.com> たけだです。 > LSMは実は概要程度しか理解していないのですが、そのまえにLSMのフックポイン > トを把握しているサイト、フックポイント箇所（システムコール単位）の一覧な > どが掲載されているサイトはあるでしょうか？ LIDSの面さんが今年4月にまとめられた、 システムコールとLSMフックの対応表がありますよ。 http://www.selinux.gr.jp/LIDS-JP/systemcalls.html LSMのフックの数は多いですが、TOMOYOの機能で使用するのは そのごく一部です。参考までに、たけだが移植に必要そうなLSMのフックを 探す手順をさらしてみます。具体例としてマウント制限を挙げます。 1. TOMOYO 1.xのソースツリーから、CheckMountPermissionを検索 http://tomoyo.sourceforge.jp/cgi-bin/lxr/search?v=linux-2.6.21.3-tomoyo-1.4.1;string=CheckMountPermission 独自フックが挿入されているのはnamespace.cの1426行目のみで あることがわかる。 2. フックが挿入されている付近にある使えそうなLSMのフックを探す http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/fs/namespace.c?v=linux-2.6.21.3-tomoyo-1.4.1#L1426 この場合、namespace.cの1451行目に使えそうなsecurity_sb_mountがある。 フックに渡される引数も充分そう…。 3. security_sb_mountが呼び出されている場所を検索 http://tomoyo.sourceforge.jp/cgi-bin/lxr/ident?v=linux-2.6.21.3-tomoyo-1.4.1;i=security_sb_mount さっき見つけた場所だけっぽい。ということは、 TOMOYO 1.xと比べても過不足がない。 という具合です。 From from-tomoyo-dev ＠ i-love.sakura.ne.jp Wed Aug 1 15:41:51 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Wed, 01 Aug 2007 15:41:51 +0900 Subject: [Tomoyo-dev 430] Re: ccs -> tomoyo ? In-Reply-To: <46B004E8.6050303@nttdata.co.jp> References: <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <9292c1390707310544kd3117fch90059552c96f2250@mail.gmail.com> <46AF3239.70500@nttdata.co.jp> <200708010043.JBI11861.ZPNPtPtPENFWGUS@I-love.SAKURA.ne.jp> <9d732d950707311431h4748bcf5kdfd0167acdc78118@mail.gmail.com> <200708010337.l713bWme043627@www262.sakura.ne.jp> <46B004E8.6050303@nttdata.co.jp> Message-ID: <200708010641.l716fpWr088119@www262.sakura.ne.jp> 　/proc/ccs/ と /etc/ccs/ の由来についてです。 2004/7 頃から /proc/sakura/ と /proc/tomoyo/ という２つに分かれて管理していました。 それぞれのディレクトリ以下に機能毎にインタフェースファイルが提供されており、 機能が追加されるたびにインタフェースファイルを追加していく構造でした。 2005/7 頃に /proc/sakura/ と /proc/tomoyo/ 以下に分散していた多数のインターフェースファイルを見直し、 /proc/ccs/ 以下の数種類のインタフェースファイルに集約しました。 ポリシーファイルも機能毎に分かれたものから数種類のファイルに統合されました。 /proc/tomoyo/ を残すのではなく /proc/ccs/ に変更したのは、 sakura と tomoyo と syaoran と cerberus と yue の機能が出揃い、全てが１箇所に集合することで 「完成形（カードキャプターさくらの世界を再現した状態）に達した」ことを象徴するためです。 2005/11 に TOMOYO Linux 1.0 として公開されました。 /proc/ccs/ というインタフェースディレクトリと /root/security/ というポリシーファイル置き場と /root/ccstools/ というユーティリティ置き場が使われていました。 2006/7 には /root/ ディレクトリが使えない環境もあるのでポリシーファイルの置き場所が /root/security/ じゃない方がいいのではという意見が出ました。 http://lists.sourceforge.jp/mailman/archives/tomoyo-users/2006-July/000090.html http://lists.sourceforge.jp/mailman/archives/tomoyo-users/2006-July/000084.html 2006/10 にポリシーの読み込みを外部プログラムに切り出すことで ポリシーファイルの置き場所をカーネルにハードコーディングしないで済むようにしました。 ポリシーファイルのデフォルトの置き場所は /proc/ccs/ に呼応して /etc/ccs/ としました。 http://lists.sourceforge.jp/mailman/archives/tomoyo-users/2006-November/000125.html 現在でも使われている init=/.init という指定を行うようになったのもこの時です。 そして今、 TOMOYO Linux なのに /proc/tomoyo/ や /etc/tomoyo/ じゃないのは何故だという話が出てきたわけです。 /proc/sakura/ および /proc/tomoyo/ はまだ開発途上で使われていたインタフェースであり、 完成状態である /proc/ccs/ を開発状態である /proc/tomoyo/ に戻したくないというのが （開発者のワガママな）歴史的経緯による理由です。 そのため現在でも、 /proc/ccs/ というインタフェースディレクトリと /etc/ccs/ というポリシーファイル置き場と /root/ccstools/ というユーティリティ置き場が使われています。 それだけでなく、 TOMOYO Linux ではプロジェクト名が TOMOYO である以外は README.ccs やパッチファイル（ ccs-patch-\*.txt の EXTRAVERSION ）や パッケージ名（ ccs-patch ccs-tools ）に至るまで ccs で統一されているのです。 （ただ、今更 TOMOYO Linux を CCS Linux に変更することは不可能でしょう。） /root/ccstools/ が変だというのならば /sbin/ccstools/ や /usr/sbin/ccstools/ に移動するのは全く気にしません。 ただ、 /root/ccstools/ を /sbin/tomoyo/ や /usr/sbin/tomoyo/ 等に移動するのは ccs でなくなるので （開発者のワガママなのですが）乗り気ではないです。 でも、そうしないとユーザが障壁を感じるのであれば仕方が無いでしょう。 From from-tomoyo-dev ＠ i-love.sakura.ne.jp Wed Aug 1 16:17:20 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Wed, 01 Aug 2007 16:17:20 +0900 Subject: [Tomoyo-dev 431] Re: =?iso-2022-jp?b?GyRCQmgbKEIgMSAbJEIyczMrSC8ycTVEJTUlXiVqGyhC?= =?iso-2022-jp?b?GyRCITwkSyREJCQkRhsoQg==?= In-Reply-To: <5fb14edc0707312334j43b51a27m4afb0c2d298d8903@mail.gmail.com> References: <46AE8DB0.9020306@nttdata.co.jp> <5fb14edc0707301844k637d8eeaj329baaeb81777cce@mail.gmail.com> <46B024B5.8000906@gmail.com> <5fb14edc0707312334j43b51a27m4afb0c2d298d8903@mail.gmail.com> Message-ID: <200708010717.l717HKXh096441@www262.sakura.ne.jp> > http://www.selinux.gr.jp/LIDS-JP/systemcalls.html ただ、１００％網羅している保証はありません。 例えばソケットに対して sys_read() を呼び出すと sys_read() → vfs_read() → do_sync_read() → sock_aio_read() → do_sock_read() → __sock_recvmsg() → security_socket_recvmsg() という順番になると思いますが security_socket_recvmsg() という LSM フックが呼ばれます。 （困ったことに msg->msg_name == NULL なので TOMOYO による 制御ができません。） include/linux/security.h の各関数内にスタックトレースを表示する処理を挿入していろいろなケースで走らせてみないと網羅しきれないかも。 （そういうテストケースを作成するだけで大プロジェクトになりそうな気がします。） From haradats ＠ gmail.com Wed Aug 1 16:24:33 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Wed, 1 Aug 2007 16:24:33 +0900 Subject: [Tomoyo-dev 432] Re: ccs -> tomoyo ? In-Reply-To: <200708010641.l716fpWr088119@www262.sakura.ne.jp> References: <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <9292c1390707310544kd3117fch90059552c96f2250@mail.gmail.com> <46AF3239.70500@nttdata.co.jp> <200708010043.JBI11861.ZPNPtPtPENFWGUS@I-love.SAKURA.ne.jp> <9d732d950707311431h4748bcf5kdfd0167acdc78118@mail.gmail.com> <200708010337.l713bWme043627@www262.sakura.ne.jp> <46B004E8.6050303@nttdata.co.jp> <200708010641.l716fpWr088119@www262.sakura.ne.jp> Message-ID: <9d732d950708010024j1a867402i9b5ae9c99c76ef0d@mail.gmail.com> 原田＠自宅です。洗濯機が壊れたので、修理立ち会いのため 会社を早退しました。 小久保さんからの助言もあり、４人で打ち合わせました。 半田さんはメールに書いていたように、「好きなように 決めて欲しい」ということだったのですが、状況について確認し、 互いに意見を言って話し合いました。その際に下記の内容も聞きました。 話し合いが終わった時点でも、半田さんは「もう自分は良いから 決めてください」でしたが、話し合いの内容をふまえて 再度考えて、どうしたいかの意見（希望）をmlに送るように お願いしました。 そうして送られてきたのが下記のメールです。 07/08/01 に from-tomoyo-dev ＠ i-love.sakura.ne.jp さんは書きました: > 　/proc/ccs/ と /etc/ccs/ の由来についてです。 > > 2004/7 頃から /proc/sakura/ と /proc/tomoyo/ という２つに分かれて管理していました。 > それぞれのディレクトリ以下に機能毎にインタフェースファイルが提供されており、 > 機能が追加されるたびにインタフェースファイルを追加していく構造でした。 > > 2005/7 頃に /proc/sakura/ と /proc/tomoyo/ 以下に分散していた多数のインターフェースファイルを見直し、 > /proc/ccs/ 以下の数種類のインタフェースファイルに集約しました。 > ポリシーファイルも機能毎に分かれたものから数種類のファイルに統合されました。 > /proc/tomoyo/ を残すのではなく /proc/ccs/ に変更したのは、 > sakura と tomoyo と syaoran と cerberus と yue の機能が出揃い、全てが１箇所に集合することで > 「完成形（カードキャプターさくらの世界を再現した状態）に達した」ことを象徴するためです。 > > 2005/11 に TOMOYO Linux 1.0 として公開されました。 > /proc/ccs/ というインタフェースディレクトリと > /root/security/ というポリシーファイル置き場と > /root/ccstools/ というユーティリティ置き場が使われていました。 > > 2006/7 には /root/ ディレクトリが使えない環境もあるのでポリシーファイルの置き場所が > /root/security/ じゃない方がいいのではという意見が出ました。 > http://lists.sourceforge.jp/mailman/archives/tomoyo-users/2006-July/000090.html > http://lists.sourceforge.jp/mailman/archives/tomoyo-users/2006-July/000084.html > 2006/10 にポリシーの読み込みを外部プログラムに切り出すことで > ポリシーファイルの置き場所をカーネルにハードコーディングしないで済むようにしました。 > ポリシーファイルのデフォルトの置き場所は /proc/ccs/ に呼応して /etc/ccs/ としました。 > http://lists.sourceforge.jp/mailman/archives/tomoyo-users/2006-November/000125.html > 現在でも使われている init=/.init という指定を行うようになったのもこの時です。 > > そして今、 TOMOYO Linux なのに /proc/tomoyo/ や /etc/tomoyo/ じゃないのは何故だという話が出てきたわけです。 > /proc/sakura/ および /proc/tomoyo/ はまだ開発途上で使われていたインタフェースであり、 > 完成状態である /proc/ccs/ を開発状態である /proc/tomoyo/ に戻したくないというのが > （開発者のワガママな）歴史的経緯による理由です。 > そのため現在でも、 /proc/ccs/ というインタフェースディレクトリと /etc/ccs/ というポリシーファイル置き場と > /root/ccstools/ というユーティリティ置き場が使われています。 > それだけでなく、 TOMOYO Linux ではプロジェクト名が TOMOYO である以外は > README.ccs やパッチファイル（ ccs-patch-\*.txt の EXTRAVERSION ）や > パッケージ名（ ccs-patch ccs-tools ）に至るまで ccs で統一されているのです。 > （ただ、今更 TOMOYO Linux を CCS Linux に変更することは不可能でしょう。） > > > > /root/ccstools/ が変だというのならば /sbin/ccstools/ や /usr/sbin/ccstools/ に移動するのは全く気にしません。 > > ただ、 /root/ccstools/ を /sbin/tomoyo/ や /usr/sbin/tomoyo/ 等に移動するのは ccs でなくなるので > （開発者のワガママなのですが）乗り気ではないです。 > でも、そうしないとユーザが障壁を感じるのであれば仕方が無いでしょう。 このメールを私なりに翻訳してみました。 「実はプロジェクトの名称がccsであるべきはだったが、もろもろの 経緯によりtomoyoになってしまった。なので、本当は統一するならプロジェクト名を ccsにしたいところだがそれはあきらめられている。自分としてはccsは 絶対に変えたくない。ワガママと言われようが何と言われようが、 ccsのままにしたい。ccsのままで続けさせて欲しい」 ということだと思います。 名称は統一したほうが良いのは勿論で、その場合今やプロジェクトの名称が tomoyoなのだから（経緯はともかく）tomoyoにするのが普通でしょう。 ただ、どうしてもそれでなければプロジェクトがたちいかない、メイン ラインに入らない、というほどのこともないと理解しています。 （この部分、違うという意見があればお聞かせ下さい） 半田さんはTOMOYO Linux (CCS Linux?)の生みの親です。 半田さんがいなければTOMOYO Linuxは存在せず、 tomoyo-devも我々も集まっていません。その半田さんが「ここまで」 望むなら、私としては、この際プロジェクト名以外はccsに統一、 ということにしたいと思うのですが皆さんいかがでしょうか？ 一応お願い、相談のような形で書いていますが、多分、そうしないと 半田さんは使い物になりません。半田さんは今朝から魂が 抜けてしまっています（多分さくらワールドに行っています）。 プロジェクトの利益のためにも、ここはひとつccsで 行きましょう！行かせてください。(_ _; -- Toshiharu Harada haradats ＠ gmail.com From haradats ＠ gmail.com Wed Aug 1 16:31:26 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Wed, 1 Aug 2007 16:31:26 +0900 Subject: [Tomoyo-dev 433] Re: =?iso-2022-jp?b?WzIuWF0gGyRCJTMhPCVJJS8laiE8JXMlSiVDJVcbKEI=?= =?iso-2022-jp?b?GyRCJVglayVXGyhC?= In-Reply-To: <5fb14edc0707312217q471cb814kdb35352eace67f3a@mail.gmail.com> References: <46AE8DB0.9020306@nttdata.co.jp> <5fb14edc0707301844k637d8eeaj329baaeb81777cce@mail.gmail.com> <46AFA372.1020600@samba.gr.jp> <46AFD0CB.2010808@gmail.com> <41029.163.135.10.36.1185930139.squirrel@webmail.knlab.com> <5fb14edc0707311950h457750f8ha7929dc2ae9aed3@mail.gmail.com> <004801c7d3f6$d1124700$0203a8c0@yamato> <5fb14edc0707312217q471cb814kdb35352eace67f3a@mail.gmail.com> Message-ID: <9d732d950708010031n11a4a32bg5420a33f679f09a@mail.gmail.com> 07/08/01 に Kentaro Takeda さんは書きました: > >#過去にはソース資産が膨れ上がって身動きの取れなくなった開発の > >#建て直し専門チームのリーダをしてたので、クリーン化、作り直しなど > >#個人的にはこういうのは得意だったりします。 > > おぉぉ、よろしくお願いいたします。艦長。 > 現在マウント制限を鋭意実装中です。 全員、戦闘態勢に入れ！！ 武田君、波動エンジン、スイッチオンじゃ！ -- Toshiharu Harada haradats ＠ gmail.com From hitoht ＠ gmail.com Wed Aug 1 16:35:14 2007 From: hitoht ＠ gmail.com (hito) Date: Wed, 1 Aug 2007 16:35:14 +0900 Subject: [Tomoyo-dev 434] Re: ccs -> tomoyo ? In-Reply-To: <200708010641.l716fpWr088119@www262.sakura.ne.jp> References: <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <9292c1390707310544kd3117fch90059552c96f2250@mail.gmail.com> <46AF3239.70500@nttdata.co.jp> <200708010043.JBI11861.ZPNPtPtPENFWGUS@I-love.SAKURA.ne.jp> <9d732d950707311431h4748bcf5kdfd0167acdc78118@mail.gmail.com> <200708010337.l713bWme043627@www262.sakura.ne.jp> <46B004E8.6050303@nttdata.co.jp> <200708010641.l716fpWr088119@www262.sakura.ne.jp> Message-ID: <9292c1390708010035k7d085c0dpd404f708fca847ba@mail.gmail.com> # 他に反応できていないのにこれだけ反応するのもアレですが…… > （ただ、今更 TOMOYO Linux を CCS Linux に変更することは不可能でしょう。） 実務レベルではそれほど不可能な理由がないような気がします。 自分の認識では、「"TOMOYO Linuxなのに、キーワードとしてCCSが含まれている のが変" という前提で議論が進んでいる」です。 「CCSという文字列が変だからTOMOYOで統一」ではありません。 「TOMOYO LinuxなのにCCSは変」です。 言い換えると、「TOMOYO Linux」という実装名である、という前提が問題なので、 とっても今更ですがCCS Linuxじゃなぜダメなのか、というのを教えてください。 具体的にはCCS Linuxに変えるのに、何が問題なのでしょうか？ # Windowsのクラスタ向け版とコリジョンするとか？ 思いついたのは以下の範囲です。 ・これまでTOMOYOで広めてきた。 とか言っても、広範囲に広まっているわけでもないですから、「改名しました」 のひとことで終わらせれば良いと思います。 Debian方面では商標上の問題でFifefoxをIceweaselという名前に変えたりして いますし、名前を変えるのは良くあることだと思います。1〜2年もすれば普通に 受け入れられるでしょう(Debian方面から見ると、 Phoenix=>Firebird=>Firefox=>Iceweaselと延々と変わっているわけで)。 ・ソースコードにそれなりに密結合していて、名前を変更するのが大変。 TOMOYOにまとめるのもCCSにまとめるのも手間は同等な気がします。 ・NTTデータ社内的事情 それなりに致命的ですが(特に商標を取っている関係で)、「NTTデータで 実装しているのはTOMOYO Linuxです。で、コミュニティ版がCCS Linuxですが そこに何か問題でもあるでしょうか偉い人。コミュニティが勝手に名乗ってる だけなので文句を言うことはできますが強制はできません」と言い切れば 良いと思います。 # そして、TOMOYO Linuxの実装面では /proc/ccs とか ccsキーワードしか # 使ってない、であっても誰も困らないような気が。 少なくとも自分の発想では、core maintenerには哲学や理念を推し進める 権利があると思いますし、熊猫さんの思いがうまく受け入れられない結果に なるのは、コミュニティとしてマイナスだと思います。 From from-tomoyo-dev ＠ i-love.sakura.ne.jp Wed Aug 1 16:39:55 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Wed, 01 Aug 2007 16:39:55 +0900 Subject: [Tomoyo-dev 435] Re: ccs -> tomoyo ? In-Reply-To: <9d732d950708010024j1a867402i9b5ae9c99c76ef0d@mail.gmail.com> References: <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <9292c1390707310544kd3117fch90059552c96f2250@mail.gmail.com> <46AF3239.70500@nttdata.co.jp> <200708010043.JBI11861.ZPNPtPtPENFWGUS@I-love.SAKURA.ne.jp> <9d732d950707311431h4748bcf5kdfd0167acdc78118@mail.gmail.com> <200708010337.l713bWme043627@www262.sakura.ne.jp> <46B004E8.6050303@nttdata.co.jp> <200708010641.l716fpWr088119@www262.sakura.ne.jp> <9d732d950708010024j1a867402i9b5ae9c99c76ef0d@mail.gmail.com> Message-ID: <200708010739.l717dt8Z001755@www262.sakura.ne.jp> > 一応お願い、相談のような形で書いていますが、多分、そうしないと > 半田さんは使い物になりません。半田さんは今朝から魂が > 抜けてしまっています（多分さくらワールドに行っています）。 私はさくらワールドの住人です。 さくらワールドに行っているのではなく、 昨夜から現実世界に呼び戻されているのです。（＾ｘ＾； From haradats ＠ gmail.com Wed Aug 1 16:42:43 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Wed, 1 Aug 2007 16:42:43 +0900 Subject: [Tomoyo-dev 436] Re: ccs -> tomoyo ? In-Reply-To: <9292c1390708010035k7d085c0dpd404f708fca847ba@mail.gmail.com> References: <46AEA4C4.2000600@gmail.com> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <9292c1390707310544kd3117fch90059552c96f2250@mail.gmail.com> <46AF3239.70500@nttdata.co.jp> <200708010043.JBI11861.ZPNPtPtPENFWGUS@I-love.SAKURA.ne.jp> <9d732d950707311431h4748bcf5kdfd0167acdc78118@mail.gmail.com> <200708010337.l713bWme043627@www262.sakura.ne.jp> <46B004E8.6050303@nttdata.co.jp> <200708010641.l716fpWr088119@www262.sakura.ne.jp> <9292c1390708010035k7d085c0dpd404f708fca847ba@mail.gmail.com> Message-ID: <9d732d950708010042tdb79f75pf6a9fa9185ae0f02@mail.gmail.com> 07/08/01 に hito さんは書きました: > # 他に反応できていないのにこれだけ反応するのもアレですが…… アレですねぇ。（笑） さらにhitoさんもやっぱりただ者ではありませんぇ。（泣） ピンポイントでレスしますと、私はたいていのことなら やるつもりですが、会社に対してTOMOYO Linuxを CCS Linuxにするということは、ちょっと言えません・・・。 hitoさんが書いているように、新たに（勝手に？） CCS Linuxというのが生まれているというのは 勿論ありで、何人たりともそれを阻止できないとは 思いますが、でもそれってどれだけ意味があるのか 疑問です。 以上 > > （ただ、今更 TOMOYO Linux を CCS Linux に変更することは不可能でしょう。） > > 実務レベルではそれほど不可能な理由がないような気がします。 > 自分の認識では、「"TOMOYO Linuxなのに、キーワードとしてCCSが含まれている > のが変" という前提で議論が進んでいる」です。 > > 「CCSという文字列が変だからTOMOYOで統一」ではありません。 > 「TOMOYO LinuxなのにCCSは変」です。 > > 言い換えると、「TOMOYO Linux」という実装名である、という前提が問題なので、 > とっても今更ですがCCS Linuxじゃなぜダメなのか、というのを教えてください。 > > 具体的にはCCS Linuxに変えるのに、何が問題なのでしょうか？ > # Windowsのクラスタ向け版とコリジョンするとか？ > > 思いついたのは以下の範囲です。 > > ・これまでTOMOYOで広めてきた。 > とか言っても、広範囲に広まっているわけでもないですから、「改名しました」 > のひとことで終わらせれば良いと思います。 > Debian方面では商標上の問題でFifefoxをIceweaselという名前に変えたりして > いますし、名前を変えるのは良くあることだと思います。1〜2年もすれば普通に > 受け入れられるでしょう(Debian方面から見ると、 > Phoenix=>Firebird=>Firefox=>Iceweaselと延々と変わっているわけで)。 > > ・ソースコードにそれなりに密結合していて、名前を変更するのが大変。 > TOMOYOにまとめるのもCCSにまとめるのも手間は同等な気がします。 > > ・NTTデータ社内的事情 > それなりに致命的ですが(特に商標を取っている関係で)、「NTTデータで > 実装しているのはTOMOYO Linuxです。で、コミュニティ版がCCS Linuxですが > そこに何か問題でもあるでしょうか偉い人。コミュニティが勝手に名乗ってる > だけなので文句を言うことはできますが強制はできません」と言い切れば > 良いと思います。 > # そして、TOMOYO Linuxの実装面では /proc/ccs とか ccsキーワードしか > # 使ってない、であっても誰も困らないような気が。 > > > 少なくとも自分の発想では、core maintenerには哲学や理念を推し進める > 権利があると思いますし、熊猫さんの思いがうまく受け入れられない結果に > なるのは、コミュニティとしてマイナスだと思います。 > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -- Toshiharu Harada haradats ＠ gmail.com From nez ＠ samba.gr.jp Wed Aug 1 16:56:52 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Wed, 1 Aug 2007 16:56:52 +0900 (JST) Subject: [Tomoyo-dev 437] Re: ccs -> tomoyo ? In-Reply-To: <9d732d950708010042tdb79f75pf6a9fa9185ae0f02@mail.gmail.com> References: <46AEA4C4.2000600@gmail.com><200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp><9292c1390707310544kd3117fch90059552c96f2250@mail.gmail.com><46AF3239.70500@nttdata.co.jp><200708010043.JBI11861.ZPNPtPtPENFWGUS@I-love.SAKURA.ne.jp><9d732d950707311431h4748bcf5kdfd0167acdc78118@mail.gmail.com><200708010337.l713bWme043627@www262.sakura.ne.jp><46B004E8.6050303@nttdata.co.jp><200708010641.l716fpWr088119@www262.sakura.ne.jp><9292c1390708010035k7d085c0dpd404f708fca847ba@mail.gmail.com> <9d732d950708010042tdb79f75pf6a9fa9185ae0f02@mail.gmail.com> Message-ID: <1995.163.135.10.34.1185955012.squirrel@webmail.knlab.com> 根津です。 On 2007年 8月 1日 (水) 16:42, Toshiharu Harada wrote: > 07/08/01 に hito さんは書きました: >> # 他に反応できていないのにこれだけ反応するのもアレですが…… > > アレですねぇ。（笑） > さらにhitoさんもやっぱりただ者ではありませんぇ。（泣） > > ピンポイントでレスしますと、私はたいていのことなら > やるつもりですが、会社に対してTOMOYO Linuxを > CCS Linuxにするということは、ちょっと言えません・・・。 > > hitoさんが書いているように、新たに（勝手に？） > CCS Linuxというのが生まれているというのは > 勿論ありで、何人たりともそれを阻止できないとは > 思いますが、でもそれってどれだけ意味があるのか > 疑問です。 コミュニティ開発チーム作って、そこでの配布名称をCCS Linuxに するのはありといえば、ありのような気がしますね。 RHELの商標とisolateするためにCentOSとかあるわけですからね。 ＃理解しやすいフォーマットだとは思います。 もし、将来、商用という道があるかもしれないので、そこにTOMOYOの 商標はとっておく。コミュニティ版は、半田さんに敬意を表して、 CCS Linuxとする・・・。 ありといえば、大いにありだとは思います。 ソースコードの管理も、コミュニティの人間が触れるコードはCCS版、 NTTデータで社内的に管理する版はTOMOYO版とするとか・・・。 ＃コードの行き来は、RHEL/CentOSとかFedora Coreとか見てれば、まぁ、 ＃結構自由でもいいと思うし。 -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From haradats ＠ gmail.com Wed Aug 1 17:00:03 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Wed, 1 Aug 2007 17:00:03 +0900 Subject: [Tomoyo-dev 438] =?iso-2022-jp?b?GyRCJCQkQyQ9JE4kMyRIGyhC?= Message-ID: <9d732d950708010100y2df3d17dk99b84bbc85259fc0@mail.gmail.com> 本当に新規でccs (linux)プロジェクトを起こしますか？ （現在のSourceForge.jpのtomoyoプロジェクトとは完全に別で、 プロジェクトマネージャも私以外で） ドメインはどうする？ (@ @; From nez ＠ samba.gr.jp Wed Aug 1 16:48:23 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Wed, 1 Aug 2007 16:48:23 +0900 (JST) Subject: [Tomoyo-dev 439] Re: ccs -> tomoyo ? In-Reply-To: <9d732d950708010024j1a867402i9b5ae9c99c76ef0d@mail.gmail.com> References: <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp><200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp><9292c1390707310544kd3117fch90059552c96f2250@mail.gmail.com><46AF3239.70500@nttdata.co.jp><200708010043.JBI11861.ZPNPtPtPENFWGUS@I-love.SAKURA.ne.jp><9d732d950707311431h4748bcf5kdfd0167acdc78118@mail.gmail.com><200708010337.l713bWme043627@www262.sakura.ne.jp><46B004E8.6050303@nttdata.co.jp><200708010641.l716fpWr088119@www262.sakura.ne.jp> <9d732d950708010024j1a867402i9b5ae9c99c76ef0d@mail.gmail.com> Message-ID: <35011.163.135.10.34.1185954503.squirrel@webmail.knlab.com> 根津です。 On 2007年 8月 1日 (水) 16:24, Toshiharu Harada wrote: > 「実はプロジェクトの名称がccsであるべきはだったが、もろもろの > 経緯によりtomoyoになってしまった。なので、本当は統一するならプロジェクト名を > ccsにしたいところだがそれはあきらめられている。自分としてはccsは > 絶対に変えたくない。ワガママと言われようが何と言われようが、 > ccsのままにしたい。ccsのままで続けさせて欲しい」 > > ということだと思います。 > > 名称は統一したほうが良いのは勿論で、その場合今やプロジェクトの名称が > tomoyoなのだから（経緯はともかく）tomoyoにするのが普通でしょう。 > ただ、どうしてもそれでなければプロジェクトがたちいかない、メイン > ラインに入らない、というほどのこともないと理解しています。 > （この部分、違うという意見があればお聞かせ下さい） > 半田さんはTOMOYO Linux (CCS Linux?)の生みの親です。 > 半田さんがいなければTOMOYO Linuxは存在せず、 > tomoyo-devも我々も集まっていません。その半田さんが「ここまで」 > 望むなら、私としては、この際プロジェクト名以外はccsに統一、 > ということにしたいと思うのですが皆さんいかがでしょうか？ > > 一応お願い、相談のような形で書いていますが、多分、そうしないと > 半田さんは使い物になりません。半田さんは今朝から魂が > 抜けてしまっています（多分さくらワールドに行っています）。 > プロジェクトの利益のためにも、ここはひとつccsで > 行きましょう！行かせてください。(_ _; 1つだけ確認させてください。 名称やキャラクタには、大抵、Legendが存在するものです。 GNU is Not UNIX. bison a.k.a. YACC から、linuxのペンギンに至るまで・・・。 ＃開発会議でお話しましたがなぜSAMBAがSAMBAなのかの伝説もあります。 TOMOYO Linuxがなぜccsを使うのか、正面切って、半田さんの解説図面 引用して説明してもいいという理解でいいでしょうか？ なんだかわかんないけど、ccsなんだよね・・・というのは説明に困っちゃいます。 それがOKなのであれば、まったく問題ありません。 たとえば解説記事書くにしても、説明するにしても、 「ccsについて： 　TOMOYOという名前から想像がつくように、国産の長有名アニメワールドの 　世界を模してTOMOYO Linuxの世界は構築されている。下記、図面を見てほしい。 　これは、TOMOYOのメインプログラマ熊猫さくら氏が描くccsというセキュア 　ワールドである。。。。。。」 　→ここに、CCSワールドのベン図みたいなのが入る← みたいな感じ？ですｗ -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From nez ＠ samba.gr.jp Wed Aug 1 17:25:07 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Wed, 1 Aug 2007 17:25:07 +0900 (JST) Subject: [Tomoyo-dev 440] Re: =?iso-2022-jp?b?GyRCJCQkQyQ9JE4kMyRIGyhC?= In-Reply-To: <9d732d950708010100y2df3d17dk99b84bbc85259fc0@mail.gmail.com> References: <9d732d950708010100y2df3d17dk99b84bbc85259fc0@mail.gmail.com> Message-ID: <44471.163.135.10.34.1185956707.squirrel@webmail.knlab.com> 根津です。 On 2007年 8月 1日 (水) 17:00, Toshiharu Harada wrote: > 本当に新規でccs (linux)プロジェクトを起こしますか？ > （現在のSourceForge.jpのtomoyoプロジェクトとは完全に別で、 > プロジェクトマネージャも私以外で） > > ドメインはどうする？ (@ @; 取り直せばよいだけではｗ -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From haradats ＠ gmail.com Wed Aug 1 17:50:41 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Wed, 1 Aug 2007 17:50:41 +0900 Subject: [Tomoyo-dev 441] Re: ccs -> tomoyo ? In-Reply-To: <35011.163.135.10.34.1185954503.squirrel@webmail.knlab.com> References: <46AEA4C4.2000600@gmail.com> <9292c1390707310544kd3117fch90059552c96f2250@mail.gmail.com> <46AF3239.70500@nttdata.co.jp> <200708010043.JBI11861.ZPNPtPtPENFWGUS@I-love.SAKURA.ne.jp> <9d732d950707311431h4748bcf5kdfd0167acdc78118@mail.gmail.com> <200708010337.l713bWme043627@www262.sakura.ne.jp> <46B004E8.6050303@nttdata.co.jp> <200708010641.l716fpWr088119@www262.sakura.ne.jp> <9d732d950708010024j1a867402i9b5ae9c99c76ef0d@mail.gmail.com> <35011.163.135.10.34.1185954503.squirrel@webmail.knlab.com> Message-ID: <9d732d950708010150t6946b861n62c06668841bbf75@mail.gmail.com> 原田です。今、洗濯機の修理が終わりました（だから、どうした）。 Legendの説明ですが、データブランドとしての資料や記事は難しいですが、 そうでなければLegendだろうが昔話だろうが、好きなことを書いて もらってかまいません。 ということで、結局オープンソースで何でもありの世界と そうでない世界を明確に分離するのが良いですね。 07/08/01 に Kensuke Nezu さんは書きました: > 根津です。 > > On 2007年 8月 1日 (水) 16:24, Toshiharu Harada wrote: > > 「実はプロジェクトの名称がccsであるべきはだったが、もろもろの > > 経緯によりtomoyoになってしまった。なので、本当は統一するならプロジェクト名を > > ccsにしたいところだがそれはあきらめられている。自分としてはccsは > > 絶対に変えたくない。ワガママと言われようが何と言われようが、 > > ccsのままにしたい。ccsのままで続けさせて欲しい」 > > > > ということだと思います。 > > > > 名称は統一したほうが良いのは勿論で、その場合今やプロジェクトの名称が > > tomoyoなのだから（経緯はともかく）tomoyoにするのが普通でしょう。 > > ただ、どうしてもそれでなければプロジェクトがたちいかない、メイン > > ラインに入らない、というほどのこともないと理解しています。 > > （この部分、違うという意見があればお聞かせ下さい） > > 半田さんはTOMOYO Linux (CCS Linux?)の生みの親です。 > > 半田さんがいなければTOMOYO Linuxは存在せず、 > > tomoyo-devも我々も集まっていません。その半田さんが「ここまで」 > > 望むなら、私としては、この際プロジェクト名以外はccsに統一、 > > ということにしたいと思うのですが皆さんいかがでしょうか？ > > > > 一応お願い、相談のような形で書いていますが、多分、そうしないと > > 半田さんは使い物になりません。半田さんは今朝から魂が > > 抜けてしまっています（多分さくらワールドに行っています）。 > > プロジェクトの利益のためにも、ここはひとつccsで > > 行きましょう！行かせてください。(_ _; > > 1つだけ確認させてください。 > 名称やキャラクタには、大抵、Legendが存在するものです。 > > GNU is Not UNIX. > bison a.k.a. YACC > > から、linuxのペンギンに至るまで・・・。 > > ＃開発会議でお話しましたがなぜSAMBAがSAMBAなのかの伝説もあります。 > > TOMOYO Linuxがなぜccsを使うのか、正面切って、半田さんの解説図面 > 引用して説明してもいいという理解でいいでしょうか？ > なんだかわかんないけど、ccsなんだよね・・・というのは説明に困っちゃいます。 > > それがOKなのであれば、まったく問題ありません。 > たとえば解説記事書くにしても、説明するにしても、 > > 「ccsについて： > TOMOYOという名前から想像がつくように、国産の長有名アニメワールドの > 世界を模してTOMOYO Linuxの世界は構築されている。下記、図面を見てほしい。 > これは、TOMOYOのメインプログラマ熊猫さくら氏が描くccsというセキュア > ワールドである。。。。。。」 > →ここに、CCSワールドのベン図みたいなのが入る← > > みたいな感じ？ですｗ > > -- > ------ > 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） > Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) > 802.11セキュリティサイト：http://www.famm.jp/wireless > ※「SELinuxシステム管理―セキュアOSの基礎と運用」 > http://www.oreilly.co.jp/books/4873112257/ > ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 > http://www.oreilly.co.jp/books/4873112877/ -- Toshiharu Harada haradats ＠ gmail.com From haradats ＠ gmail.com Wed Aug 1 17:58:18 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Wed, 1 Aug 2007 17:58:18 +0900 Subject: [Tomoyo-dev 442] Re: =?iso-2022-jp?b?GyRCJCQkQyQ9JE4kMyRIGyhC?= In-Reply-To: <44471.163.135.10.34.1185956707.squirrel@webmail.knlab.com> References: <9d732d950708010100y2df3d17dk99b84bbc85259fc0@mail.gmail.com> <44471.163.135.10.34.1185956707.squirrel@webmail.knlab.com> Message-ID: <9d732d950708010158q3d28618dqdb39d859435cbb9b@mail.gmail.com> 07/08/01 に Kensuke Nezu さんは書きました: > 根津です。 > > On 2007年 8月 1日 (水) 17:00, Toshiharu Harada wrote: > > 本当に新規でccs (linux)プロジェクトを起こしますか？ > > （現在のSourceForge.jpのtomoyoプロジェクトとは完全に別で、 > > プロジェクトマネージャも私以外で） > > > > ドメインはどうする？ (@ @; > > 取り直せばよいだけではｗ なるほど。(_ _) 多分tomoyolinux.*は使わないってことですよね。 2つのプロジェクトを起こした場合、 ・データ関係のメンバーは会社にいる間は、TOMOYOのほうの作業をして、 　プライベートの部分でCCSのほうの作業をする ・tomoyo-dev（これも引っ越しか？）のメンバーはCCSで作業する ・CCSのプロジェクトはデータ社員以外がプロジェクトを運営する という整理かと思いますが意識合ってますか？ -- Toshiharu Harada haradats ＠ gmail.com From hitoht ＠ gmail.com Wed Aug 1 18:20:36 2007 From: hitoht ＠ gmail.com (hito) Date: Wed, 1 Aug 2007 18:20:36 +0900 Subject: [Tomoyo-dev 443] Re: =?iso-2022-jp?b?GyRCJCQkQyQ9JE4kMyRIGyhC?= In-Reply-To: <9d732d950708010158q3d28618dqdb39d859435cbb9b@mail.gmail.com> References: <9d732d950708010100y2df3d17dk99b84bbc85259fc0@mail.gmail.com> <44471.163.135.10.34.1185956707.squirrel@webmail.knlab.com> <9d732d950708010158q3d28618dqdb39d859435cbb9b@mail.gmail.com> Message-ID: <9292c1390708010220y2d64ff4bo3bb550c2bda3f391@mail.gmail.com> > 2つのプロジェクトを起こした場合、 > > ・データ関係のメンバーは会社にいる間は、TOMOYOのほうの作業をして、 > 　プライベートの部分でCCSのほうの作業をする > ・tomoyo-dev（これも引っ越しか？）のメンバーはCCSで作業する > ・CCSのプロジェクトはデータ社員以外がプロジェクトを運営する > > という整理かと思いますが意識合ってますか？ 自分の意識とは違いはありません。 > ・CCSのプロジェクトはデータ社員以外がプロジェクトを運営する は社内で肩身が狭くならないようにする都合で最初は必須だよなぁ、とか いう部分まで合致していたりします。 Red hatとFedoraの関係のように、後からうまく再定義して近づけていく、 というのはアリだと思います。 ……という政治層とかマネー層の話はどうでもよくて(ぉい 「今すぐ」決めた方がいいのは(コードに大手術が入るので)、 ・実装面で使うキーワードはCCSでGo? No go? だと思います。 ここをまず突き詰めて、フォークする・しないの話は後でまとめた方が 良くないでしょうか？ From nez ＠ samba.gr.jp Wed Aug 1 18:07:42 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Wed, 1 Aug 2007 18:07:42 +0900 (JST) Subject: [Tomoyo-dev 444] Re: =?iso-2022-jp?b?GyRCJCQkQyQ9JE4kMyRIGyhC?= In-Reply-To: <9d732d950708010158q3d28618dqdb39d859435cbb9b@mail.gmail.com> References: <9d732d950708010100y2df3d17dk99b84bbc85259fc0@mail.gmail.com><44471.163.135.10.34.1185956707.squirrel@webmail.knlab.com> <9d732d950708010158q3d28618dqdb39d859435cbb9b@mail.gmail.com> Message-ID: <1059.163.135.10.34.1185959262.squirrel@webmail.knlab.com> $B:,DE$G$9!#(B On 2007$BG/(B 8$B7n(B 1$BF|(B ($B?e(B) 17:58, Toshiharu Harada wrote: > 07/08/01 $B$K(B Kensuke Nezu $B$5$s$O=q$-$^$7$?(B: >> $B:,DE$G$9!#(B >> >> On 2007$BG/(B 8$B7n(B 1$BF|(B ($B?e(B) 17:00, Toshiharu Harada wrote: >> > $BK\Ev$K?75,$G(Bccs (linux)$B%W%m%8%'%/%H$r5/$3$7$^$9$+!)(B >> > $B!J8=:_$N(BSourceForge.jp$B$N(Btomoyo$B%W%m%8%'%/%H$H$O40A4$KJL$G!"(B >> > $B%W%m%8%'%/%H%^%M!<%8%c$b;d0J30$G!K(B >> > >> > $B%I%a%$%s$O$I$&$9$k!)(B (@ @; >> >> $B$;$P$h$$$@$1$G$O#w(B > > $B$J$k$[$I!#(B(_ _) $BB?J,(Btomoyolinux.*$B$O;H$o$J$$$C$F$3$H$G$9$h$M!#(B $B$^!"7k6I!"$=$&$$$&$3$H$K$J$C$?$i$J$C$?$G$=$l$O$=$l$G$$$$$H$f!<$3$H$G!#(B > 2$B$D$N%W%m%8%'%/%H$r5/$3$7$?>l9g!"(B > > $B!&%G!<%?4X78$N%a%s%P!<$O2q $B!!%W%i%$%Y!<%H$NItJ,$G(BCCS$B$N$[$&$N:n6H$r$9$k(B $B$3$l$O!"!V$"$/$^$G$b!W(BNTT$B%G!<%?l!K(BCCS$B$G$N%Y!<%?%F%9%H$N%U%#!<%I%P%C%/$r(B $B!!5[<}$9$k!#0BDjHG5!G=$N$_$r tomoyo ? In-Reply-To: <35011.163.135.10.34.1185954503.squirrel@webmail.knlab.com> References: <200708010337.l713bWme043627@www262.sakura.ne.jp> <46B004E8.6050303@nttdata.co.jp> <200708010641.l716fpWr088119@www262.sakura.ne.jp> <9d732d950708010024j1a867402i9b5ae9c99c76ef0d@mail.gmail.com> <35011.163.135.10.34.1185954503.squirrel@webmail.knlab.com> Message-ID: <200708012334.DBC91178.NEtWNFPPZSGtUPP@I-love.SAKURA.ne.jp> 　なんだか私のダダこねに付き合ってもらっていただいているようで申し訳ないです。＞ａｌｌ > TOMOYO Linuxがなぜccsを使うのか、正面切って、半田さんの解説図面 > 引用して説明してもいいという理解でいいでしょうか？ > なんだかわかんないけど、ccsなんだよね・・・というのは説明に困っちゃいます。 え〜っと、図が古くなってしまってますが、 http://I-love.SAKURA.ne.jp/tomoyo/ の「開発コードの由来について」が解説図面ですねぇ。 「さくら」＋「知世」＋「小狼」＋「ケルベロス」＋「ユエ」＝「ＣＣＳ」という関係です。 なので、「ＣＣＳ」が「知世」を包含しているという関係です。 事情により CCS Linux ではなく TOMOYO Linux というプロジェクト名になってしまったわけですが、 TOMOYO Linux の中には SAKURA TOMOYO SYAORAN CERBERUS YUE が含まれています。 （ CERBERUS と YUE はソフトウェアではなくアイデアです。 TOMOYO Linux に登場するのは 上記の５人だけですが、カードキャプターさくらとしては他にも重要人物が居ます。） 　カードキャプターさくらを知らない人のためにちょこっと紹介したいと思います。 熊猫の説明より Wikipedia の説明を読んだ方が解りやすいんでしょうけど。 カードキャプターさくらはＣＬＡＭＰ先生が創作した魔法少女物の漫画です。 アニメ化もされ、海外でも放映されるなど、一時期大人気を博しました。 主人公であるさくらがクロウカードという魔力を持ったカードを保存している本の 封印を解いてしまったためにカードが飛び散ってしまい、飛び散ったカードを 再び集めるためカードキャプター（カードの捕獲者）に任命されるところから話が始まります。 しかし、開始早々さくらの友達である知世にカードキャプターであることがばれてしまい、 それ以後ずっと行動を共にすることになります。 さくらはふんわりとした性格ですが、偏見にとらわれず、何事にも一生懸命で 絶対に諦めない姿勢が読者の共感を呼び、たくさんのファンを獲得しました。（私もその一人です。） 知世はさくらに適切なアドバイスを与える洞察力だけでなく、 さくらの活躍をひとつ残らず自らビデオに録画して編集し、 （さくらのためにクロウカードと戦うための）バトルコスチュームまで 自ら作製してしまうほどの行動力を備えています。 そのあまりの活躍ぶりに、知世こそがカードキャプターさくらの主役であると 断言するファンも少なくありません。（言うまでも無く、主役はさくらであり、 知世はさくらを手助けする脇役の筈なのですが。） いろいろな事件に巻き込まれますが、最後にはハッピーエンドを迎えることになります。 　カードキャプターさくらの中では 偶然を装った必然の出来事（いつ誰と出会い、どのような行動を起こすのか）が 見えない鎖で繋がれているかのごとく発生していきます。 「物事は偶然ではなく必然で動く」というのがＣＬＡＭＰ先生の世界観だそうです。 　で、 TOMOYO Linux ではどうなっているかというと、実は考え方がそっくりなのです。 TOMOYO Linux では、ビデオに録画することが自動学習機能に、 バトルコスチュームがアクセス制御のポリシーに対応します。 システム管理者はどのような出来事（いつどのようなプログラムを実行し、 どのようなファイルにアクセスするか）がどのような順番で起きて欲しいのかというシステムの振る舞いを 事前にデザインし、自動学習機能の助けを借りながらドメイン遷移という鎖で繋いでいきます。 すると、システムの起動時から電源断までに発生する出来事が ドメイン遷移という鎖でつながれた順番で発生します。 過去に何が起き、次に何が起こるかをシステム管理者が全て理解して納得しておくことで、 予想しなかった事件に巻き込まれることを心配する必要が無くなり、 システム管理者は安心してシステムを稼動させることができるようになります。 　原田さんはいろんなイベントに参加するはめになったことを説明する際に 「できすぎた偶然」という言葉を連発していますが、私から見れば 「 TOMOYO Linux はカードキャプターさくらの世界と同じように推移してきており、 イベントに参加することになったのも必然」ということになります。 まだ答えが出ていないのは、ハッピーエンドはカードキャプターさくらの世界でしか 起こらない話なのか、それとも TOMOYO Linux の世界でも起こる話なのかという点です。 From dai-yamato-zero ＠ gaea.ocn.ne.jp Wed Aug 1 23:34:15 2007 From: dai-yamato-zero ＠ gaea.ocn.ne.jp (=?iso-2022-jp?B?GyRCPi41V0pdT0I5KBsoQg==?=) Date: Wed, 1 Aug 2007 23:34:15 +0900 Subject: [Tomoyo-dev 446] Re: =?iso-2022-jp?b?GyRCJCQkQyQ9JE4kMyRIGyhC?= References: <9d732d950708010100y2df3d17dk99b84bbc85259fc0@mail.gmail.com><44471.163.135.10.34.1185956707.squirrel@webmail.knlab.com><9d732d950708010158q3d28618dqdb39d859435cbb9b@mail.gmail.com> <9292c1390708010220y2d64ff4bo3bb550c2bda3f391@mail.gmail.com> Message-ID: <018501c7d449$099f89a0$0203a8c0@yamato> こんばんは。小久保です。 朝の話がえらく進んでいて驚きました(汗) このプロジェクトに参加して日も浅いので的を得ているか少し不安ですが、 発言させていただきます。 >> 2つのプロジェクトを起こした場合、 >> >> ・データ関係のメンバーは会社にいる間は、TOMOYOのほうの作業をして、 >> 　プライベートの部分でCCSのほうの作業をする >> ・tomoyo-dev（これも引っ越しか？）のメンバーはCCSで作業する >> ・CCSのプロジェクトはデータ社員以外がプロジェクトを運営する >> >> という整理かと思いますが意識合ってますか？ > > 自分の意識とは違いはありません。 > >> ・CCSのプロジェクトはデータ社員以外がプロジェクトを運営する > は社内で肩身が狭くならないようにする都合で最初は必須だよなぁ、とか > いう部分まで合致していたりします。 > > Red hatとFedoraの関係のように、後からうまく再定義して近づけていく、 > というのはアリだと思います。 > > ……という政治層とかマネー層の話はどうでもよくて(ぉい 名称は現状もふまえ戦略的に決めるべきだと考えます。 現状、少なくともTOMOYOの名前で名前が通ってしまっている以上、 現時点における名称改変はプロジェクトのマイナスではないかと心配しています。 理由としてはある程度知れ渡ったところでもう一度名前を再周知するのは 何かとTOMOYO?　CCS? ・・・etc と皆さん(特に使う側)に混乱を招く原因ではなかろうかと思います。 名称変更は再アナウンス、体制再構築などメインライン化に向けた必須作業外の作業を単純に増加させる方向だと思います。 同様の意味でTOMOYO-CCSといった名称変更も同様の理由で、反対させていただきました。 (以前TOMOYOで今はTOMOYO-CCSならばユーザはまず何が違うのか、 CCSってなんなの?と必ず説明する必要が生じてくるのではと考えます) 現在、メインライン化へ向けた取り組みが必要というのは開発会議でもあったように 共通の認識ではなかろうかと考えます。 そうであるならば現時点ではメインライン化の障害となる、 もしくはなりうる事象、しなくても良い作業は可能な限り排除すべきと考えます。 ただ、メインライン化が完成したのち、 CCSとTOMOYO等にわかれることは問題ないと考えます。 そうであればどちらも最終的には生き残ることができる(忘れられない)と思います。 現時点では忘れられないための作業に集中すべきではないでしょうか。 > 「今すぐ」決めた方がいいのは(コードに大手術が入るので)、 > ・実装面で使うキーワードはCCSでGo? No go? > だと思います。 > > ここをまず突き詰めて、フォークする・しないの話は後でまとめた方が > 良くないでしょうか？ 賛成です。 ただ、大体開発というのは開発者の趣味趣向が反映されるものです。 ですのでCCSが残ることは(も)大いに賛成です。 #私も、某NTT系携帯電話交換機の一部に一二〇八計画なんてのを残しました。 (本当は「画計八〇二一」なんですが、、、という事は・・・割と194X年代の艦長らしいですねw 　最近は蒸気タービンでも波動エンジン搭載の艦でもOKです！w) #レビューの時は冷たい汗をかきながらとても苦しい説明をしました・・・ 設計として、明らかな問題(ユーザが使いにくい等)がある場合は見直す必要があると思います。 今回の話を見ていますとそんな次元の話ではないように感じます。 なにかTOMOYOの重要なファイルがccsと言うディレクトリの中に入っているぐらいの話と認識していますが。 もしユーザのインタフェースとしてのディレクトリがccsあり、tomoyoあり、tmyありetcでは明らかに混乱を招くので 使いやすいものを提供するという視点でいずれかに統合しようという議論は必要です。 現状その点は考慮され統一されているようですので問題ないですね。 個人的にはプロジェクト名にtomoyo、ディレクトリ名にccsで使い分けはされているのでなんら問題ないのでは感じてしまうのですが。 使う側の立場とプロジェクトに貢献した半田さんへの敬意をはらっている実装ですで良いと思うのですが。 いかがでしょう。 -------------- 小久保　和宏 dai-yamato-zero ＠ gaea.ocn.ne.jp From yocto1 ＠ gmail.com Thu Aug 2 01:07:39 2007 From: yocto1 ＠ gmail.com (yocto) Date: Thu, 2 Aug 2007 01:07:39 +0900 Subject: [Tomoyo-dev 447] Re: =?iso-2022-jp?b?GyRCQmgbKEIxGyRCMnMzK0gvMnE1RCU1JV4laiE8GyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <5fb14edc0707301844k637d8eeaj329baaeb81777cce@mail.gmail.com> References: <46AE8DB0.9020306@nttdata.co.jp> <5fb14edc0707301844k637d8eeaj329baaeb81777cce@mail.gmail.com> Message-ID: <8f3c749a0708010907r21768227g709284ffd845c378@mail.gmail.com> クスノです。 手を上げます。 07/07/31 に Kentaro Takeda さんは書きました: > たけだです。 > ... > 再投稿へ向けての残作業は、 > ・機能の実装 > ・コードのクリーンアップ > です。実装は武田と半田さんで一気にやってしまい、一番時間のかかるコードの > クリーンアップ作業をtomoyo-devの皆さんに手伝っていただきたいと思っています。 > 方法についてはまた別途ご連絡しますが、協力したいという方は、vanillaカーネルの > 最新版が動作する環境の準備に加え、以下のドキュメントを読んでおいて > いただけるとスムーズに作業に入れると思います。 > > Linuxカーネルコーディング規約 > (en) http://lxr.linux.no/source/Documentation/CodingStyle > (ja) http://www.linux.or.jp/JF/JFdocs/kernel-docs-2.6/CodingStyle.html > Quiltコマンドのmanpage > http://linux.die.net/man/1/quilt > > 作業を手伝っていただいたことで実質的な報酬は出ませんが、 > コードの動作が変わらないように編集することで、 > TOMOYOがどのように動いているのかを深く理解できること請け合いです。 > > 以上、何かご意見、コメントなどありましたらお願いします。 > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev From yocto1 ＠ gmail.com Thu Aug 2 01:32:50 2007 From: yocto1 ＠ gmail.com (yocto) Date: Thu, 2 Aug 2007 01:32:50 +0900 Subject: [Tomoyo-dev 448] =?iso-2022-jp?b?GyRCJWElJCVzJWklJCVzMj0kWDh+JDEkRhsoQg==?= Message-ID: <8f3c749a0708010932u2299eb4ai415becb05ad09405@mail.gmail.com> クスノ＠どこにリプライしていいかわからないので別メールにしましたです。 私の意見 ・名前は現状のまま、ディレクトリの整理だけする。 ・2.1の実装を進める。 ・現状では、実作業をNTTデータとコミュニティで分けることは 　オーバヘッドが増えるだけだと思われる。 ・いろいろな事を整理するのは筋だと思いますが、それよりも 　まずは必要最低限の整理でlkmlへ出す。 　（必要最低限を決めるのがまた問題ではありますが...） ただ、 １．きっちりしないで出してもメインライン化は出来ない ２．AAに先を越されるとメインライン化は出来ない のどちらかだとすれば（ほんとか）、私は２よりは１の方がいいと考えています。 全然議論には、ついていけてなくて申し訳ないですが、もう寝ますm(__)m From matthew0115 ＠ gmail.com Thu Aug 2 08:08:25 2007 From: matthew0115 ＠ gmail.com (matthew.szulik@gmail.com) Date: Thu, 02 Aug 2007 08:08:25 +0900 Subject: [Tomoyo-dev 449] Re: =?iso-2022-jp?b?GyRCQmgbKEIxGyRCMnMzK0gvMnE1RCU1JV4laiE8GyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <5fb14edc0707312334j43b51a27m4afb0c2d298d8903@mail.gmail.com> References: <46AE8DB0.9020306@nttdata.co.jp> <5fb14edc0707301844k637d8eeaj329baaeb81777cce@mail.gmail.com> <46B024B5.8000906@gmail.com> <5fb14edc0707312334j43b51a27m4afb0c2d298d8903@mail.gmail.com> Message-ID: <46B11269.8020209@gmail.com> おはようございます。秋元です。 Kentaro Takeda さんは書きました: > たけだです。 > >> LSMは実は概要程度しか理解していないのですが、そのまえにLSMのフックポイン >> トを把握しているサイト、フックポイント箇所（システムコール単位）の一覧な >> どが掲載されているサイトはあるでしょうか？ > LIDSの面さんが今年4月にまとめられた、 > システムコールとLSMフックの対応表がありますよ。 > http://www.selinux.gr.jp/LIDS-JP/systemcalls.html こういうのあったんですね（でも今年4月だ）。 > > LSMのフックの数は多いですが、TOMOYOの機能で使用するのは > そのごく一部です。参考までに、たけだが移植に必要そうなLSMのフックを > 探す手順をさらしてみます。具体例としてマウント制限を挙げます。 > > 1. TOMOYO 1.xのソースツリーから、CheckMountPermissionを検索 > http://tomoyo.sourceforge.jp/cgi-bin/lxr/search?v=linux-2.6.21.3-tomoyo-1.4.1;string=CheckMountPermission > 独自フックが挿入されているのはnamespace.cの1426行目のみで > あることがわかる。 > 2. フックが挿入されている付近にある使えそうなLSMのフックを探す > http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/fs/namespace.c?v=linux-2.6.21.3-tomoyo-1.4.1#L1426 > この場合、namespace.cの1451行目に使えそうなsecurity_sb_mountがある。 > フックに渡される引数も充分そう…。 > 3. security_sb_mountが呼び出されている場所を検索 > http://tomoyo.sourceforge.jp/cgi-bin/lxr/ident?v=linux-2.6.21.3-tomoyo-1.4.1;i=security_sb_mount > さっき見つけた場所だけっぽい。ということは、 > TOMOYO 1.xと比べても過不足がない。 > > という具合です。 なるほど。この手順なら判断つきますね。 ところで、TOMOYOのフック位置とLSMフック位置が離れていて、その中に幾つか 処理が入って、1.4系と2.0系で挙動がちょっと異なってくることは想像できます。 From k.takeda26 ＠ gmail.com Thu Aug 2 09:18:09 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Thu, 2 Aug 2007 09:18:09 +0900 Subject: [Tomoyo-dev 450] Re: =?iso-2022-jp?b?GyRCQmgbKEIxGyRCMnMzK0gvMnE1RCU1JV4laiE8GyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <46B11269.8020209@gmail.com> References: <46AE8DB0.9020306@nttdata.co.jp> <5fb14edc0707301844k637d8eeaj329baaeb81777cce@mail.gmail.com> <46B024B5.8000906@gmail.com> <5fb14edc0707312334j43b51a27m4afb0c2d298d8903@mail.gmail.com> <46B11269.8020209@gmail.com> Message-ID: <5fb14edc0708011718k18ee51ecpb2cb65047dc60860@mail.gmail.com> たけだです。 > ところで、TOMOYOのフック位置とLSMフック位置が離れていて、その中に幾つか > 処理が入って、1.4系と2.0系で挙動がちょっと異なってくることは想像できます。 そうなんです。昨日まさにそれではまりかけました。 現状のLSMの仕様で移植できないTOMOYO 1.x系の機能は、 そもそもフックがないということが原因の場合もありますし、 フックに渡される引数が足りないだとか、 使えそうなフックはあるけれど排他制御の関係で実は無理、 ということもあります。（この辺までくると熊猫先生首っ引きです） From haradats ＠ gmail.com Thu Aug 2 10:39:48 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Thu, 2 Aug 2007 10:39:48 +0900 Subject: [Tomoyo-dev 451] Re: =?iso-2022-jp?b?GyRCJWElJCVzJWklJCVzMj0kWDh+JDEkRhsoQg==?= In-Reply-To: <8f3c749a0708010932u2299eb4ai415becb05ad09405@mail.gmail.com> References: <8f3c749a0708010932u2299eb4ai415becb05ad09405@mail.gmail.com> Message-ID: <9d732d950708011839r2b6c8d3ep3e7d315be8465457@mail.gmail.com> 原田です。 07/08/02 に yocto さんは書きました: > クスノ＠どこにリプライしていいかわからないので別メールにしましたです。 > > 私の意見 > ・名前は現状のまま、ディレクトリの整理だけする。 > ・2.1の実装を進める。 > ・現状では、実作業をNTTデータとコミュニティで分けることは > オーバヘッドが増えるだけだと思われる。 > ・いろいろな事を整理するのは筋だと思いますが、それよりも > まずは必要最低限の整理でlkmlへ出す。 > （必要最低限を決めるのがまた問題ではありますが...） > > ただ、 > １．きっちりしないで出してもメインライン化は出来ない > ２．AAに先を越されるとメインライン化は出来ない > のどちらかだとすれば（ほんとか）、私は２よりは１の方がいいと考えています。 > > 全然議論には、ついていけてなくて申し訳ないですが、もう寝ますm(__)m ディレクトリの名前から始まった話ですが、今やプロジェクトとしての 在り方に関する本質的な議論になっています。 ひと言で言うと、NTTデータとしての取り組みである限り完全に オープンな開発は行えないということです。 できないことをやろうとすると無理やひずみが生じます。 それは違うものを一緒にしようとするところから生じるもので、 オープンとオープンでないものを明確に分離しない限り解決しません。 程度や影響が小さいから良いというものでもありません。 選択肢としては、 1. 現在のTOMOYOプロジェクトを完全にオープンで 　NTTデータと関係ないものにする 2. TOMOYO以外にオープンなプロジェクトを興す 　（いわゆるフォーク） 3. やめる しかありません。1は100%不可能だとも思いませんが、 可能だったとしてもオープンなプロジェクトと NTTデータのプロジェクトは明確に分けるべきだというのが 私の結論です。 現在のTOMOYOプロジェクトは、NTTデータの プロジェクトです。そこをオープンにするのはやめようと 思います。 新しいオープンなプロジェクトはNTTデータと関係を 持たないプロジェクトであり、リリースの決裁を含め 一切NTTデータからの束縛を受けません（当たり前ですが）。 NTTデータのプロジェクトとしてのTOMOYOプロジェクトと オープンなプロジェクトは互いに独立であって、 TOMOYOプロジェクトは技術的な交流、連携を行いながらも 独立して開発を行います（必ずしもオープンなプロジェクトの ミラーになるわけではありません）。 レポジトリもmlもドキュメントも、NTTデータとしての プロジェクトとオープンなプロジェクトは明確に分離すべきと 思っています。 今週の金曜日、原田、武田、半田の3名で新宿に行くことに なりました。8/3の夜6時頃、新宿に来られる方はどのくらい いますか？ -- Toshiharu Harada haradats ＠ gmail.com From haradats ＠ gmail.com Thu Aug 2 10:55:26 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Thu, 2 Aug 2007 10:55:26 +0900 Subject: [Tomoyo-dev 452] Re: =?iso-2022-jp?b?GyRCJWElJCVzJWklJCVzMj0kWDh+JDEkRhsoQg==?= In-Reply-To: <9d732d950708011839r2b6c8d3ep3e7d315be8465457@mail.gmail.com> References: <8f3c749a0708010932u2299eb4ai415becb05ad09405@mail.gmail.com> <9d732d950708011839r2b6c8d3ep3e7d315be8465457@mail.gmail.com> Message-ID: <9d732d950708011855k76799664uc461f15d989fd307@mail.gmail.com> 補足です。 原田と武田君はNTTデータの社員ですが、同時に個人でもあります。 なので、新しいオープンなプロジェクトには参加できますし、 そのつもりですが、自分（原田）についてはTOMOYOプロジェクトの 管理者であるため、オープンなプロジェクトへの参加は、 慎重に判断したいと思いますし、少なくともプロジェクト管理者には ならないつもりです。 オープンソースとして公開したときにも今回と全く同じことが 起こりました。そのときは私と半田さんしかいませんでしたから、 私が一人で判断しましたが、今回はtomoyo-dev-mlの方々がいて、 やりとりがmlで行われた点が違うだけです。 一連の議論で、何人かの方から私が半田さんを個人攻撃していると いうような指摘をいただきました。受け取り方はさまざまですね。 私としては個人攻撃をしたつもりはありません。プロジェクト 管理者として、プロジェクトの利益を考えて判断、行動しただけです。 07/08/02 に Toshiharu Harada さんは書きました: > 原田です。 > > 07/08/02 に yocto さんは書きました: > > クスノ＠どこにリプライしていいかわからないので別メールにしましたです。 > > > > 私の意見 > > ・名前は現状のまま、ディレクトリの整理だけする。 > > ・2.1の実装を進める。 > > ・現状では、実作業をNTTデータとコミュニティで分けることは > > オーバヘッドが増えるだけだと思われる。 > > ・いろいろな事を整理するのは筋だと思いますが、それよりも > > まずは必要最低限の整理でlkmlへ出す。 > > （必要最低限を決めるのがまた問題ではありますが...） > > > > ただ、 > > １．きっちりしないで出してもメインライン化は出来ない > > ２．AAに先を越されるとメインライン化は出来ない > > のどちらかだとすれば（ほんとか）、私は２よりは１の方がいいと考えています。 > > > > 全然議論には、ついていけてなくて申し訳ないですが、もう寝ますm(__)m > > ディレクトリの名前から始まった話ですが、今やプロジェクトとしての > 在り方に関する本質的な議論になっています。 > > ひと言で言うと、NTTデータとしての取り組みである限り完全に > オープンな開発は行えないということです。 > できないことをやろうとすると無理やひずみが生じます。 > それは違うものを一緒にしようとするところから生じるもので、 > オープンとオープンでないものを明確に分離しない限り解決しません。 > 程度や影響が小さいから良いというものでもありません。 > > 選択肢としては、 > 1. 現在のTOMOYOプロジェクトを完全にオープンで > NTTデータと関係ないものにする > 2. TOMOYO以外にオープンなプロジェクトを興す > （いわゆるフォーク） > 3. やめる > しかありません。1は100%不可能だとも思いませんが、 > 可能だったとしてもオープンなプロジェクトと > NTTデータのプロジェクトは明確に分けるべきだというのが > 私の結論です。 > > 現在のTOMOYOプロジェクトは、NTTデータの > プロジェクトです。そこをオープンにするのはやめようと > 思います。 > > 新しいオープンなプロジェクトはNTTデータと関係を > 持たないプロジェクトであり、リリースの決裁を含め > 一切NTTデータからの束縛を受けません（当たり前ですが）。 > NTTデータのプロジェクトとしてのTOMOYOプロジェクトと > オープンなプロジェクトは互いに独立であって、 > TOMOYOプロジェクトは技術的な交流、連携を行いながらも > 独立して開発を行います（必ずしもオープンなプロジェクトの > ミラーになるわけではありません）。 > > レポジトリもmlもドキュメントも、NTTデータとしての > プロジェクトとオープンなプロジェクトは明確に分離すべきと > 思っています。 -- Toshiharu Harada haradats ＠ gmail.com From nez ＠ samba.gr.jp Thu Aug 2 10:21:34 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Thu, 2 Aug 2007 10:21:34 +0900 (JST) Subject: [Tomoyo-dev 453] Re: =?iso-2022-jp?b?GyRCQmgbKEIxGyRCMnMzK0gvMnE1RCU1JV4laiE8GyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <5fb14edc0708011718k18ee51ecpb2cb65047dc60860@mail.gmail.com> References: <46AE8DB0.9020306@nttdata.co.jp><5fb14edc0707301844k637d8eeaj329baaeb81777cce@mail.gmail.com><46B024B5.8000906@gmail.com><5fb14edc0707312334j43b51a27m4afb0c2d298d8903@mail.gmail.com><46B11269.8020209@gmail.com> <5fb14edc0708011718k18ee51ecpb2cb65047dc60860@mail.gmail.com> Message-ID: <36235.163.135.10.36.1186017694.squirrel@webmail.knlab.com> 根津です。 On 2007年 8月 2日 (木) 9:18, Kentaro Takeda wrote: > たけだです。 > >> ところで、TOMOYOのフック位置とLSMフック位置が離れていて、その中に幾つか >> 処理が入って、1.4系と2.0系で挙動がちょっと異なってくることは想像できます。 > そうなんです。昨日まさにそれではまりかけました。 > > 現状のLSMの仕様で移植できないTOMOYO 1.x系の機能は、 > そもそもフックがないということが原因の場合もありますし、 > フックに渡される引数が足りないだとか、 > 使えそうなフックはあるけれど排他制御の関係で実は無理、 > ということもあります。（この辺までくると熊猫先生首っ引きです） フックの問題ばかりでなく、関数が大きすぎるとか位置関係の調整などと いって、呼び出し関係や関数のグラニュリティを不用意に変更すると、 割り込みでタスクスイッチに突入してしまったり、怖いことになりかねない ので、単純な整形以外はかなり注意が必要です。 ＃少なくともそのオーダーになると、カーネルプログラミング経験者か ＃デバイスドライバ作成経験者でないとつらいと思います。 -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From haradats ＠ gmail.com Thu Aug 2 11:09:53 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Thu, 2 Aug 2007 11:09:53 +0900 Subject: [Tomoyo-dev 454] Re: =?iso-2022-jp?b?GyRCJCQkQyQ9JE4kMyRIGyhC?= In-Reply-To: <1059.163.135.10.34.1185959262.squirrel@webmail.knlab.com> References: <9d732d950708010100y2df3d17dk99b84bbc85259fc0@mail.gmail.com> <44471.163.135.10.34.1185956707.squirrel@webmail.knlab.com> <9d732d950708010158q3d28618dqdb39d859435cbb9b@mail.gmail.com> <1059.163.135.10.34.1185959262.squirrel@webmail.knlab.com> Message-ID: <9d732d950708011909x739cabaeo29a83ed968692912@mail.gmail.com> 原田です。 07/08/01 に Kensuke Nezu さんは書きました: > > 2つのプロジェクトを起こした場合、 > > > > ・データ関係のメンバーは会社にいる間は、TOMOYOのほうの作業をして、 > > プライベートの部分でCCSのほうの作業をする > > これは、「あくまでも」NTTデータ社内の方のお話なので、私ら関係ないっす。 そう、そのとおりです。そして、逆もまた真です。 なので、新しいプロジェクトができたら(SourceForge.netにすれば 良いと思います)、mlも分けましょう。 > たとえば、「コミュニティへの還元」ということで就業時間中にCCSいじっても > いいことになっていた方が実は開発陣は楽チンではないかと"個人的には" > 思いますけどネｗ そこをちゃんと使い分けてもらえれば本当はそれが良いと 思います（思っていました）。 > > ・tomoyo-dev（これも引っ越しか？）のメンバーはCCSで作業する > > ・CCSのプロジェクトはデータ社員以外がプロジェクトを運営する > > これはいいですね。ここだけは守っておかないと線引きがおかしくなります。 そう。この分離を明確にすることが重要です。 tomoyo-devは近いうちに解散し、TOMOYOはクローズドなプロジェクトに します。 > > という整理かと思いますが意識合ってますか？ > > あとは、TOMOYOの位置づけですか・・・。 > > ・TOMOYOは、実験的な実装（お砂場）CCSでのベータテストのフィードバックを > 吸収する。安定版機能のみを取り込む。管理はNTTデータ社員のみで行う。 > > みたいな感じ？ > > ＃RHELとFedoraCoreみたいになってるといいのかな・・・。 そこはNTTデータとして判断します。:) 冗談はともかく（冗談でもないですが）、ただミラーとする つもりはなくて、サブセット+アルファみたいなイメージを 考えています。技術的な議論やコードは勿論、境目なく 流通し、プロジェクト間はどんどん交流したいですね。 新しいプロジェクトで、ひとつ心配しているのは、 それがCCS Linuxなのか、あるいはCCSという思想なのか、です。 それは同じように見えていて全然違います。半田さんの 一連の発言を見ていると、本当はCCSの思想や世界観に 共感する人を集めて開発すべきではないかと思っています。 -- Toshiharu Harada haradats ＠ gmail.com From haradats ＠ gmail.com Thu Aug 2 12:15:24 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Thu, 2 Aug 2007 12:15:24 +0900 Subject: [Tomoyo-dev 455] Re: =?iso-2022-jp?b?GyRCJWElJCVzJWklJCVzMj0kWDh+JDEkRhsoQg==?= In-Reply-To: <9d732d950708011839r2b6c8d3ep3e7d315be8465457@mail.gmail.com> References: <8f3c749a0708010932u2299eb4ai415becb05ad09405@mail.gmail.com> <9d732d950708011839r2b6c8d3ep3e7d315be8465457@mail.gmail.com> Message-ID: <9d732d950708012015i71ebc049k5eacb1a877de47a2@mail.gmail.com> 原田です。 下記の内容について、さきほど半田さん、武田君と話し合いました。 半田さんからの懸案事項としては、 ・tomoyoとccs（仮称）でディレクトリ名称、コマンド名や 　仕様が異なってしまうと、開発面ではソースの取り込み 　（移植）作業が繁雑になり、ユーザから見た場合 　混乱を生じるおそれがある。 ・「もし」tomoyoがメインラインに入ってしまうと、 　ccsは後から入ることは不可能であり、/proc/tomoyo等を 　/proc/ccsのように変更できない。 ・tomoyo版（NTTデータ版）について、完全にクローズに 　すると試験ができない。 があがりました。他に、皆さんのほうで問題になりそうな 項目があればお知らせ下さい。 07/08/02 に Toshiharu Harada さんは書きました: > 原田です。 > > 07/08/02 に yocto さんは書きました: > > クスノ＠どこにリプライしていいかわからないので別メールにしましたです。 > > > > 私の意見 > > ・名前は現状のまま、ディレクトリの整理だけする。 > > ・2.1の実装を進める。 > > ・現状では、実作業をNTTデータとコミュニティで分けることは > > オーバヘッドが増えるだけだと思われる。 > > ・いろいろな事を整理するのは筋だと思いますが、それよりも > > まずは必要最低限の整理でlkmlへ出す。 > > （必要最低限を決めるのがまた問題ではありますが...） > > > > ただ、 > > １．きっちりしないで出してもメインライン化は出来ない > > ２．AAに先を越されるとメインライン化は出来ない > > のどちらかだとすれば（ほんとか）、私は２よりは１の方がいいと考えています。 > > > > 全然議論には、ついていけてなくて申し訳ないですが、もう寝ますm(__)m > > ディレクトリの名前から始まった話ですが、今やプロジェクトとしての > 在り方に関する本質的な議論になっています。 > > ひと言で言うと、NTTデータとしての取り組みである限り完全に > オープンな開発は行えないということです。 > できないことをやろうとすると無理やひずみが生じます。 > それは違うものを一緒にしようとするところから生じるもので、 > オープンとオープンでないものを明確に分離しない限り解決しません。 > 程度や影響が小さいから良いというものでもありません。 > > 選択肢としては、 > 1. 現在のTOMOYOプロジェクトを完全にオープンで > NTTデータと関係ないものにする > 2. TOMOYO以外にオープンなプロジェクトを興す > （いわゆるフォーク） > 3. やめる > しかありません。1は100%不可能だとも思いませんが、 > 可能だったとしてもオープンなプロジェクトと > NTTデータのプロジェクトは明確に分けるべきだというのが > 私の結論です。 > > 現在のTOMOYOプロジェクトは、NTTデータの > プロジェクトです。そこをオープンにするのはやめようと > 思います。 -- Toshiharu Harada haradats ＠ gmail.com From from-tomoyo-dev ＠ i-love.sakura.ne.jp Thu Aug 2 12:44:31 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Thu, 02 Aug 2007 12:44:31 +0900 Subject: [Tomoyo-dev 456] Re: =?iso-2022-jp?b?GyRCJWElJCVzJWklJCVzMj0kWDh+JDEkRhsoQg==?= In-Reply-To: <9d732d950708012015i71ebc049k5eacb1a877de47a2@mail.gmail.com> References: <8f3c749a0708010932u2299eb4ai415becb05ad09405@mail.gmail.com> <9d732d950708011839r2b6c8d3ep3e7d315be8465457@mail.gmail.com> <9d732d950708012015i71ebc049k5eacb1a877de47a2@mail.gmail.com> Message-ID: <200708020344.l723iVb2066913@www262.sakura.ne.jp> > ・tomoyoとccs（仮称）でディレクトリ名称、コマンド名や > 　仕様が異なってしまうと、開発面ではソースの取り込み > 　（移植）作業が繁雑になり、ユーザから見た場合 > 　混乱を生じるおそれがある。 ポリシーの構文や、コーディングスタイル（関数名の命名規則・関数の分割基準） や構造体の内容まで違うでしょうから、パッチを流用するというレベルでは済まないでしょう。 > ・「もし」tomoyoがメインラインに入ってしまうと、 > 　ccsは後から入ることは不可能であり、/proc/tomoyo等を > 　/proc/ccsのように変更できない。 これは、 ccs 版がずっと LSM 版のメンテナンスを 継続しなければならなくなることを意味しており、 tomoyo 版には無いが ccs 版にはある機能を使いたいと思ったユーザやディストリビュータが 「 tomoyo 版には必要な機能が無いから使わない」 「 ccs 版ではメンテナンスと動作確認が必要になるから使えない」 という悩ましい状況になりかねません。 ccs 版の機能がそのまま tomoyo 版に入るのならともかく、 tomoyo 版に入れるかどうかの判断はNTTデータが行うことになり、 tomoyo 版に入らない可能性があります。 > ・tomoyo版（NTTデータ版）について、完全にクローズに > 　すると試験ができない。 そもそも共同開発者・テスターを募集したのは 私の知識とスキルだけでは十分な動作テストができないからであって、 クローズにして動作テストが不十分になってしまうのでは意味が無いと思います。 メインラインに入って、高い知識とスキルを持つ世界中の開発者の助けが 得られるようになれば解消するかもしれませんが、それまでは助けは得られません。 そして、そのようになると、今度は ccs 版の動作テストが（ tomoyo 版でしか 世界中の開発者の助けが得られないがために） tomoyo 版のようにできなくなるでしょう。 tomoyo 版と ccs 版をなんとかして統合しろと言われるのがオチでしょう。 私には、 tomoyo 版と ccs 版を分けることが得策には思えません。 From nez ＠ samba.gr.jp Thu Aug 2 12:47:57 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Thu, 2 Aug 2007 12:47:57 +0900 (JST) Subject: [Tomoyo-dev 457] Re: =?iso-2022-jp?b?GyRCJWElJCVzJWklJCVzMj0kWDh+JDEkRhsoQg==?= In-Reply-To: <9d732d950708012015i71ebc049k5eacb1a877de47a2@mail.gmail.com> References: <8f3c749a0708010932u2299eb4ai415becb05ad09405@mail.gmail.com><9d732d950708011839r2b6c8d3ep3e7d315be8465457@mail.gmail.com> <9d732d950708012015i71ebc049k5eacb1a877de47a2@mail.gmail.com> Message-ID: <60325.163.135.10.36.1186026477.squirrel@webmail.knlab.com> 根津です。 On 2007年 8月 2日 (木) 12:15, Toshiharu Harada wrote: > 原田です。 > > 下記の内容について、さきほど半田さん、武田君と話し合いました。 > 半田さんからの懸案事項としては、 > > ・tomoyoとccs（仮称）でディレクトリ名称、コマンド名や > 　仕様が異なってしまうと、開発面ではソースの取り込み > 　（移植）作業が繁雑になり、ユーザから見た場合 > 　混乱を生じるおそれがある。 元々、メインの開発者がTOMOYOにいるのですから、これは私も 一本化したほうがよさげにおもいます。 フォークとはいっても、CentOSみたいにTOMOYOの商標だけ抜いた 版という扱いレベルのフォークでいいんじゃないかと・・・ｗ > ・「もし」tomoyoがメインラインに入ってしまうと、 > 　ccsは後から入ることは不可能であり、/proc/tomoyo等を > 　/proc/ccsのように変更できない。 ディレクトリ名称の話は、 ・プロジェクト名にのみTOMOYOを用いる ・内部的にはぜーんぶccsに統一 というレベルで落ち着いた・・・と思ってましたｗ > ・tomoyo版（NTTデータ版）について、完全にクローズに > 　すると試験ができない。 管理がクローズであり、テストファームとして不完全版リリースなり アルファ／ベータリリースをccs版という形で出せばいいと思ってました。 hitoさんやクスノさんのおっしゃるとおり、フォークすることで 管理の手間があまりにも増えたり、メインライン化の邪魔になることは 極力避けた方がいいと思うので、 ・コミュニティ版は看板だけ用意しておく。 　（何かあった時の保険みたいなもの？） という形で、手間のかからないレベルでやりませんか？ -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From haradats ＠ nttdata.co.jp Thu Aug 2 13:08:07 2007 From: haradats ＠ nttdata.co.jp (Toshiharu Harada) Date: Thu, 02 Aug 2007 13:08:07 +0900 Subject: [Tomoyo-dev 458] Re: =?iso-2022-jp?b?GyRCJWElJCVzJWklJCVzMj0kWDh+JDEkRhsoQg==?= In-Reply-To: <60325.163.135.10.36.1186026477.squirrel@webmail.knlab.com> References: <8f3c749a0708010932u2299eb4ai415becb05ad09405@mail.gmail.com><9d732d950708011839r2b6c8d3ep3e7d315be8465457@mail.gmail.com> <9d732d950708012015i71ebc049k5eacb1a877de47a2@mail.gmail.com> <60325.163.135.10.36.1186026477.squirrel@webmail.knlab.com> Message-ID: <46B158A7.4070106@nttdata.co.jp> 原田です。 半田さんは、 > 私には、 tomoyo 版と ccs 版を分けることが得策には思えません。 根津さんは、 > という形で、手間のかからないレベルでやりませんか？ と書いていますが、私としてはこれは損得や手間の問題では ないと思っています。自由な開発をできる場を作るべきであって、 自由な場を作らない限りは、またいつか同じ議論が 起こるでしょう。 自由な開発は、NTTデータという会社を含め、あらゆる制約を 受けたくないでしょうし、逆にNTTデータのプロジェクトは、 社外からの意見は聞いてもそれに左右されず、NTTデータの プロジェクトとしての意識を持つべきです。違いますか？ -- 原田季栄 (Toshiharu Harada) haradats ＠ nttdata.co.jp From haradats ＠ nttdata.co.jp Thu Aug 2 13:14:27 2007 From: haradats ＠ nttdata.co.jp (Toshiharu Harada) Date: Thu, 02 Aug 2007 13:14:27 +0900 Subject: [Tomoyo-dev 459] Re: =?iso-2022-jp?b?GyRCJWElJCVzJWklJCVzMj0kWDh+JDEkRhsoQg==?= In-Reply-To: <46B158A7.4070106@nttdata.co.jp> References: <8f3c749a0708010932u2299eb4ai415becb05ad09405@mail.gmail.com><9d732d950708011839r2b6c8d3ep3e7d315be8465457@mail.gmail.com> <9d732d950708012015i71ebc049k5eacb1a877de47a2@mail.gmail.com> <60325.163.135.10.36.1186026477.squirrel@webmail.knlab.com> <46B158A7.4070106@nttdata.co.jp> Message-ID: <46B15A23.3000107@nttdata.co.jp> このメールを送ってから、某社の執行役員が私の席にきて、 こう話しかけました。私の席の後ろに座っている 武田君もこの会話の一部始終を聞いています。 一体TOMOYOはいつから稼げるのかね？ 早ければ今年度中に 遅ければ？ 3年後かもしれません 一体いつメインラインに入るのかね？ 今取り組んでいて、今年度中を目指しています メインラインに入ったらどうやってお金を稼ぐのかね？ 現時点では具体的道筋は見えていません おいおい、稼ぐつもりはないということか（立ち去る） これは実際の会話で虚飾はありません。これが企業の 現実です。下記に追加して、NTTデータとしての TOMOYOはいつ終わってもおかしくありません。 NTTデータとしてのTOMOYOしかなければ、プロジェクトが 終わった時点で終了します。そうならないためにも という意味もあります。 Toshiharu Harada さんは書きました: > 原田です。 > > 半田さんは、 >> 私には、 tomoyo 版と ccs 版を分けることが得策には思えません。 > > 根津さんは、 >> という形で、手間のかからないレベルでやりませんか？ > > と書いていますが、私としてはこれは損得や手間の問題では > ないと思っています。自由な開発をできる場を作るべきであって、 > 自由な場を作らない限りは、またいつか同じ議論が > 起こるでしょう。 > > 自由な開発は、NTTデータという会社を含め、あらゆる制約を > 受けたくないでしょうし、逆にNTTデータのプロジェクトは、 > 社外からの意見は聞いてもそれに左右されず、NTTデータの > プロジェクトとしての意識を持つべきです。違いますか？ > -- 原田季栄 (Toshiharu Harada) haradats ＠ nttdata.co.jp From okajima ＠ digitalinfra.co.jp Thu Aug 2 13:22:43 2007 From: okajima ＠ digitalinfra.co.jp (Jun OKAJIMA) Date: Thu, 02 Aug 2007 13:22:43 +0900 Subject: [Tomoyo-dev 460] SELinux + TOMOYO Message-ID: <200708020422.AA02309@bbb-jz5c7z9hn9y.digitalinfra.co.jp> 有限会社デジタルインフラの岡島と申します。はじめまして。 議論を拝見させていただいて、ひとつ疑問がわいたのですが、 なぜ、カーネルモードにこだわっているのでしょうか。 なぜ、独自開発にこだわっているのでしょうか。 TOMOYO Linuxのウリとは、ようは、実行結果から 対話式にポリシーを作れることですよね。 Windowsのファイアーウォールの設定のようなもの。 この理解が正しいとして・・・。 でしたら、SELinuxの実行結果を解析し、 ここから対話的にSELinuxのポリシーは作れないのでしょうか。 もし、それが可能であれば、SELinux ベースに全面的に変更するのも 一案だと思います。 そうすれば、普及とメンテに関しては、大幅に楽になります。 部外者がチャチャを入れるようで恐縮ですが、 オリジナルのカーネルモジュールは、普及とメンテが非常に大変ですよ・・・。 有限会社デジタルインフラ 取締役社長 岡島 純 http://www.digitalinfra.co.jp/ http://www.machboot.com/ http://www.colinux.org/ From haradats ＠ gmail.com Thu Aug 2 13:32:19 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Thu, 2 Aug 2007 13:32:19 +0900 Subject: [Tomoyo-dev 461] Re: =?iso-2022-jp?b?GyRCJWElJCVzJWklJCVzMj0kWDh+JDEkRhsoQg==?= In-Reply-To: <46B15A23.3000107@nttdata.co.jp> References: <8f3c749a0708010932u2299eb4ai415becb05ad09405@mail.gmail.com> <9d732d950708011839r2b6c8d3ep3e7d315be8465457@mail.gmail.com> <9d732d950708012015i71ebc049k5eacb1a877de47a2@mail.gmail.com> <60325.163.135.10.36.1186026477.squirrel@webmail.knlab.com> <46B158A7.4070106@nttdata.co.jp> <46B15A23.3000107@nttdata.co.jp> Message-ID: <9d732d950708012132s3f7fb831g7aa0ebabe2c4082a@mail.gmail.com> これは独り言です。 ThinkIT連載で書いた記事から引用します。 http://www.thinkit.co.jp/cert/article/0706/17/1/4.htm 最後に、TOMOYO Linuxのプロジェクトマネージャである私自身の チャレンジとしては、「TOMOYO Linuxというプロジェクトによる NTTデータへの貢献」を実現したいと思っています。オープンソースの 開発は企業における通常のプロジェクトとは異なり直接利益を 生みだしません。リソースを投じて開発を行い、その成果を オープンソースとして返します。つまりはボランティアです。 ボランティアには限界があります。利益をあげることは企業に とって必要であり、適切な利益により企業は発展し、社会に貢献します。 それはオープンソースの取り組みについても例外ではないはずです。 TOMOYO Linuxを企業としてのオープンソースの関わり方の成功事例と することにより、今後第2第3のTOMOYO Linuxが生まれて、 オープンソースの世界が充実していくという夢を実現したいと考えています。 SourceForgeの「今月のプロジェクト」の記事から引用します。 http://sourceforge.jp/projects/sourceforge/wiki/TomoyoLinux 技術以外の目標は、TOMOYO Linuxの取り組みを、何らかの形で それを世に送り出したNTTデータに還元したいということです。 Linuxに代表されるオープンソースは日々さまざまなところで 利用されています。オープンソースの発展に貢献した企業は、 そのことによって評価されるべきです。適切な対価を受け取ることに よりオープンソースも企業も、また利用者も幸せになります。 メインライン化とは違った意味で難しい課題ですが、是非実現したいと 思います。TOMOYO Linuxを使ってビジネスを始めたいという方が あれば、いつでも連絡をお待ちしています。 二つの記事は同じことを言っていますし、この他、例えば UNIX magazineの記事も同じです。私が考えていることを 書いているから同じになるわけです。 私は個人としてもこのプロジェクトに関わり時間を使って いますが、会社員として、自分の業務としても取り組んでいます。 業務としてのこのプロジェクトや自分のミッションは、 達成されておらず、失敗しています。それにも関わらず 今日まで取り組みを続けることを認めてもらえたことに 私は感謝しています。 -- Toshiharu Harada haradats ＠ gmail.com From nez ＠ samba.gr.jp Thu Aug 2 13:18:33 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Thu, 2 Aug 2007 13:18:33 +0900 (JST) Subject: [Tomoyo-dev 462] Re: =?iso-2022-jp?b?GyRCJWElJCVzJWklJCVzMj0kWDh+JDEkRhsoQg==?= In-Reply-To: <46B158A7.4070106@nttdata.co.jp> References: <8f3c749a0708010932u2299eb4ai415becb05ad09405@mail.gmail.com><9d732d950708011839r2b6c8d3ep3e7d315be8465457@mail.gmail.com> <9d732d950708012015i71ebc049k5eacb1a877de47a2@mail.gmail.com><60325.163.135.10.36.1186026477.squirrel@webmail.knlab.com> <46B158A7.4070106@nttdata.co.jp> Message-ID: <4005.163.135.10.36.1186028313.squirrel@webmail.knlab.com> $B:,DE$G$9!#(B On 2007$BG/(B 8$B7n(B 2$BF|(B ($BLZ(B) 13:08, Toshiharu Harada wrote: > $B86ED$G$9!#(B > > $BH>ED$5$s$O!"(B >> $B;d$K$O!"(B tomoyo $BHG$H(B ccs $BHG$rJ,$1$k$3$H$,F@:v$K$O;W$($^$;$s!#(B > > $B:,DE$5$s$O!"(B >> $B$H$$$&7A$G!" > $B$H=q$$$F$$$^$9$,!";d$H$7$F$O$3$l$OB;F@$d $B$J$$$H;W$C$F$$$^$9!#<+M3$J3+H/$r$G$-$k>l$r:n$k$Y$-$G$"$C$F!"(B > $B<+M3$J>l$r:n$i$J$$8B$j$O!"$^$?$$$D$+F1$85DO@$,(B > $B5/$3$k$G$7$g$&!#(B $B:#2s$N$3$H$O!":,K\E*$K$O86ED$5$s$N$*$C$7$c$k$H$*$j$G$O$"$k$H(B $B;W$$$^$9!#$7$+$7!"%Q%o!<$K$O8B3&$,$"$k$N$G!"8= $B<+M3$J3+H/$O!"(BNTT$B%G!<%?$H$$$&2q $B $B $B%W%m%8%'%/%H$H$7$F$N0U<1$r;}$D$Y$-$G$9!#0c$$$^$9$+!)(B (I"$B0U<1(I#$B$OI,MW$@$1$l$I!"(I"$BIi2Y:n6H$O8:$i$7$?$$(I#$B$H;d$O9M$($F$^$9!#(B $B$V$C$A$c$1$A$c$&$H!"$?$H$($P!"(Bccs$B%W%m%8%'%/%H$C$F!I$?$H$($P!I(B $B$G$9$,!"(B $B!!!V;d0l?M$N$W$m$8$'$/$H(I#(B $B$G$b$$$$$s$G$9!#(B $B!t$?$@!"(BTOMOYO$B$,%j%j!<%9$5$l$?$i!"$=$3$+$i(BTOMOYO$B$N>&I8$@$1(B $B!t%j%`!<%V$7$?$j!"(BCCS$B$NL>$G<9I.$dH/I=$r$7$?$$?M$,$$$k$H$-$N(B $B!t8rDL ＠ 0M}$N;vL36I:n6H$H$+!"%[!<%`%Z!<%8$N>l=j$@$1MQ0U$9$k!&!&!&(B $B!t$H$+$M#w(B $B$3$l$J$i References: <200708020422.AA02309@bbb-jz5c7z9hn9y.digitalinfra.co.jp> Message-ID: <46B16018.1060609@nttdata.co.jp> 岡島様、 はじめまして。お名前はよく他のmlで拝見しています。 Jun OKAJIMA さんは書きました: > > 有限会社デジタルインフラの岡島と申します。はじめまして。 > > 議論を拝見させていただいて、ひとつ疑問がわいたのですが、 > なぜ、カーネルモードにこだわっているのでしょうか。 > なぜ、独自開発にこだわっているのでしょうか。 > > TOMOYO Linuxのウリとは、ようは、実行結果から > 対話式にポリシーを作れることですよね。 > Windowsのファイアーウォールの設定のようなもの。 > > この理解が正しいとして・・・。 > > でしたら、SELinuxの実行結果を解析し、 > ここから対話的にSELinuxのポリシーは作れないのでしょうか。 「SELinuxの実行結果の解析から」ではありませんが、 プロセスの実行履歴の追跡からSELinuxのポリシーを 作ろうとしたことはありますが、結論としては 失敗しました。その内容は、NSF2003の論文と発表資料に 書いてあります。 http://www.jnsa.org/nsf2003/ （TOMOYO ＠ SourceForge.jpの文書にもありますが） > もし、それが可能であれば、SELinux ベースに全面的に変更するのも > 一案だと思います。 Stephenから提案されているのは、それに近い内容だと 思っています。個人的には興味あるところです。 > そうすれば、普及とメンテに関しては、大幅に楽になります。 > 部外者がチャチャを入れるようで恐縮ですが、 > オリジナルのカーネルモジュールは、普及とメンテが非常に大変ですよ・・・。 いや、確かにそうだと思います。(^^; -- 原田季栄 (Toshiharu Harada) haradats ＠ nttdata.co.jp From haradats ＠ nttdata.co.jp Thu Aug 2 13:46:54 2007 From: haradats ＠ nttdata.co.jp (Toshiharu Harada) Date: Thu, 02 Aug 2007 13:46:54 +0900 Subject: [Tomoyo-dev 464] Re: =?iso-2022-jp?b?GyRCJWElJCVzJWklJCVzMj0kWDh+JDEkRhsoQg==?= In-Reply-To: <4005.163.135.10.36.1186028313.squirrel@webmail.knlab.com> References: <8f3c749a0708010932u2299eb4ai415becb05ad09405@mail.gmail.com><9d732d950708011839r2b6c8d3ep3e7d315be8465457@mail.gmail.com> <9d732d950708012015i71ebc049k5eacb1a877de47a2@mail.gmail.com><60325.163.135.10.36.1186026477.squirrel@webmail.knlab.com> <46B158A7.4070106@nttdata.co.jp> <4005.163.135.10.36.1186028313.squirrel@webmail.knlab.com> Message-ID: <46B161BE.6070708@nttdata.co.jp> 根津さん、 半田さんといい、根津さんといい、ここに来て揺り戻されるとは・・・、 思ってました（笑）。 Kensuke Nezu さんは書きました: > 根津です。 > > On 2007年 8月 2日 (木) 13:08, Toshiharu Harada wrote: >> 原田です。 >> >> 半田さんは、 >>> 私には、 tomoyo 版と ccs 版を分けることが得策には思えません。 >> 根津さんは、 >>> という形で、手間のかからないレベルでやりませんか？ >> と書いていますが、私としてはこれは損得や手間の問題では >> ないと思っています。自由な開発をできる場を作るべきであって、 >> 自由な場を作らない限りは、またいつか同じ議論が >> 起こるでしょう。 > > 今回のことは、根本的には原田さんのおっしゃるとおりではあると > 思います。しかし、パワーには限界があるので、現実的な解も必要です。 正直に言いますと、ここでいう「現実的な解」は、 データの悪口を言いながら、データのリソースだけ使うような イメージがあり、なんだか虫がよい気がして あまり好きになれません。 >> 自由な開発は、NTTデータという会社を含め、あらゆる制約を >> 受けたくないでしょうし、逆にNTTデータのプロジェクトは、 >> 社外からの意見は聞いてもそれに左右されず、NTTデータの >> プロジェクトとしての意識を持つべきです。違いますか？ > > 「意識」は必要だけれど、「負荷作業は減らしたい」と私は考えてます。 > ぶっちゃけちゃうと、たとえば、ccsプロジェクトって”たとえば” > ですが、 > 　「私一人のぷろじぇくと」 > でもいいんです。 「でもいいんです」というよりは「そうしたほうが良い」 「そうすべきだ」というのが今の私の考えなんです。 > ＃ただ、TOMOYOがリリースされたら、そこからTOMOYOの商標だけ > ＃リムーブしたり、CCSの名で執筆や発表をしたい人がいるときの > ＃交通整理の事務局作業とか、ホームページの場所だけ用意する・・・ > ＃とかねｗ > > これなら手間はかからないし、「意識」もちゃんとisolateできませんか？ > > ＃あたしゃccsはコミュニティディストリビューションでいいと思うですよ。 データのプロジェクトとは別のCCSができて、それが知られ 普及してビジネスで利用したいと思ったときに、CCSだと 利用しにくくて、TOMOYOに来る、そのような意味もあると思っています。 また、普及や利用を考えたときに私はあまり変えすぎるのは 良くないと思っていて、半田さんにもずっとそう言い続けて きました。でも多分、開発者である半田さんとしては思いついた 機能は必要であり実装したいのです。そういう意味でも、 自由な開発版と利用、普及版は分かれている意味があると思います。 -- 原田季栄 (Toshiharu Harada) haradats ＠ nttdata.co.jp From haradats ＠ gmail.com Thu Aug 2 13:54:10 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Thu, 2 Aug 2007 13:54:10 +0900 Subject: [Tomoyo-dev 465] Re: =?iso-2022-jp?b?GyRCJWElJCVzJWklJCVzMj0kWDh+JDEkRhsoQg==?= In-Reply-To: <9d732d950708012132s3f7fb831g7aa0ebabe2c4082a@mail.gmail.com> References: <8f3c749a0708010932u2299eb4ai415becb05ad09405@mail.gmail.com> <9d732d950708011839r2b6c8d3ep3e7d315be8465457@mail.gmail.com> <9d732d950708012015i71ebc049k5eacb1a877de47a2@mail.gmail.com> <60325.163.135.10.36.1186026477.squirrel@webmail.knlab.com> <46B158A7.4070106@nttdata.co.jp> <46B15A23.3000107@nttdata.co.jp> <9d732d950708012132s3f7fb831g7aa0ebabe2c4082a@mail.gmail.com> Message-ID: <9d732d950708012154t642558d4t1c2a79bdfe3ae9a1@mail.gmail.com> > 私は個人としてもこのプロジェクトに関わり時間を使って > いますが、会社員として、自分の業務としても取り組んでいます。 > 業務としてのこのプロジェクトや自分のミッションは、 > 達成されておらず、失敗しています。 開発が続き（続けられ）、名前が知られ、普及するように、 自分ができることは思いつく限りほぼやってきました。 このプロジェクトはずっと私と半田さんだけでしたから、 CLAMP事務所への手紙を書いたり、掲示板にレスをつけたり、 公開や商標の調査、リリース、発表等に関する事務処理（決裁）も 全て自分でやってきました。 うまく言っているとは思いませんが、自分としてできることは やってきたということは言えます。でも、おそらく そろそろ限界ということです。 From nez ＠ samba.gr.jp Thu Aug 2 14:13:33 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Thu, 2 Aug 2007 14:13:33 +0900 (JST) Subject: [Tomoyo-dev 466] Re: =?iso-2022-jp?b?GyRCJWElJCVzJWklJCVzMj0kWDh+JDEkRhsoQg==?= In-Reply-To: <9d732d950708012154t642558d4t1c2a79bdfe3ae9a1@mail.gmail.com> References: <8f3c749a0708010932u2299eb4ai415becb05ad09405@mail.gmail.com><9d732d950708011839r2b6c8d3ep3e7d315be8465457@mail.gmail.com><9d732d950708012015i71ebc049k5eacb1a877de47a2@mail.gmail.com><60325.163.135.10.36.1186026477.squirrel@webmail.knlab.com><46B158A7.4070106@nttdata.co.jp> <46B15A23.3000107@nttdata.co.jp><9d732d950708012132s3f7fb831g7aa0ebabe2c4082a@mail.gmail.com> <9d732d950708012154t642558d4t1c2a79bdfe3ae9a1@mail.gmail.com> Message-ID: <62584.163.135.10.36.1186031613.squirrel@webmail.knlab.com> $B:,DE$G$9!#(B $B!t$G!";d$N(I"$B;W$$(I#$B$r$$$&$H!&!&!&!#(B $B$J$s$G$3$3$K$-$F!"$$$-$J$j@<$rBg$-$/$7$?$N$+$H$$$($P!"(B $B86ED$5$s$HH>ED$5$s$,(BNTT$B%G!<%?$NOH$NCf$G$b$,$-$J$,$i(B $B:n$C$?$b$N$r!"(BNTT$B%G!<%?$N;q8;$rEjF~$7$F:n$C$?$b$N$r(B MOTTAINAI$B@:?@$G9-$2$?$$!&!&!&$=$l$H$*FsJ}$N?4$NIiC4$r(B $B>/$7$G$b7Z$/$7$?$$!&!&!&$H$$$&$3$H$,$"$k$N$G$9!#(B $B$J$N$G!"$$$m$$$m$J0UL#$G!"(I"$BF($2$i$l$k!W>l=j$H$7$F!"(B $B%f!<%62q$J$j!V(BCCS$B$W$m$8$'$/$H$A!<$`!W$J$j$rMQ0U$7$F(B $B$"$2$F$*$1$k$H$$$$$J!&!&!&$H$$$&DxEY$G9M$($F$$$^$9!#(B On 2007$BG/(B 8$B7n(B 2$BF|(B ($BLZ(B) 13:54, Toshiharu Harada wrote: > $B$&$^$/8@$C$F$$$k$H$O;W$$$^$;$s$,!"<+J,$H$7$F$G$-$k$3$H$O(B > $B$d$C$F$-$?$H$$$&$3$H$O8@$($^$9!#$G$b!"$*$=$i$/(B > $B$=$m$=$m8B3&$H$$$&$3$H$G$9!#(B $B$8$c!"$H$j$"$($:!V(BPROJECT CCS$B!W$H$$$&%A!<%`$r:n$j$^$7$g$&!#(B $B;vL36I$O;d$,$d$j$^$9!#(B $B$A!<$`$j!<$@!'%J%>$N?MJ*!V7'G-$5$/$i!W$5$s(B $B%j%j!<%94IM}!'%J%>$N?MJ*(Bdats$B$5$s(B $B;(MQ78!'(Bnez $B$H$+!#(B $B!t%$%l%b%N$5$(:n$C$F$*$1$P!"$"$H$O;~4|$r$_$F0\9T$9$l$P$h$$$N$G$O!)(B -- ------ $B:,DE(B $B8&2p(B $BF|K\(BSamba$B%f!<%62q(B/NTT$B%G!<%?@hC<5;=Q!J3t!K(B Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11$B%;%-%e%j%F%#%5%$%H!'(Bhttp://www.famm.jp/wireless $B"(!V(BSELinux$B%7%9%F%`4IM}!=%;%-%e%"(BOS$B$N4pAC$H1?MQ!W(B http://www.oreilly.co.jp/books/4873112257/ $B"(!V References: <8f3c749a0708010932u2299eb4ai415becb05ad09405@mail.gmail.com> <9d732d950708011839r2b6c8d3ep3e7d315be8465457@mail.gmail.com> <9d732d950708012015i71ebc049k5eacb1a877de47a2@mail.gmail.com> <60325.163.135.10.36.1186026477.squirrel@webmail.knlab.com> <46B158A7.4070106@nttdata.co.jp> <46B15A23.3000107@nttdata.co.jp> <9d732d950708012132s3f7fb831g7aa0ebabe2c4082a@mail.gmail.com> <9d732d950708012154t642558d4t1c2a79bdfe3ae9a1@mail.gmail.com> <62584.163.135.10.36.1186031613.squirrel@webmail.knlab.com> Message-ID: <9d732d950708012244w66eaad8ch56c3caaf7df1aa6f@mail.gmail.com> 根津さん、 07/08/02 に Kensuke Nezu さんは書きました: > なんでここにきて、いきなり声を大きくしたのかといえば、 > 原田さんと半田さんがNTTデータの枠の中でもがきながら > 作ったものを、NTTデータの資源を投入して作ったものを > MOTTAINAI精神で広げたい・・・それとお二方の心の負担を > 少しでも軽くしたい・・・ということがあるのです。 そうだったのですか・・・。（ちょっと意味なく点をつないで みました） > なので、いろいろな意味で、「逃げられる」場所として、 > ユーザ会なり「CCSぷろじぇくとちーむ」なりを用意して > あげておけるといいな・・・という程度で考えています。 どうもありがとうございます。 ちなみに、「外」からどう見えているかわからないのですが、 私はちょっとデータの社員としての限界を超えてしまった かもしれません、というか丸尾君ふうに言うと、「明らかに 超えてしまっているでしょー」（こういう表現も普通のデータの 人は使いません）別にルールを破ったりとか、会社に迷惑を かけるようなことはしていませんよ。 後悔はしていませんが、やりすぎたかなという気はします。(~_~; > On 2007年 8月 2日 (木) 13:54, Toshiharu Harada wrote: > > うまく言っているとは思いませんが、自分としてできることは > > やってきたということは言えます。でも、おそらく > > そろそろ限界ということです。 > > じゃ、とりあえず「PROJECT CCS」というチームを作りましょう。 > 事務局は私がやります。 > > ちーむりーだ：ナゾの人物「熊猫さくら」さん > リリース管理：ナゾの人物datsさん > 雑用係：nez > > とか。 > > ＃イレモノさえ作っておけば、あとは時期をみて移行すればよいのでは？ 別スレッドにあったようにCCSのネーミングは事前確認が 必要ですね。それさえできれば、SourceForge.netは無料だし、 とりたければドメインもとれば良く、別に（会社でやるのと 違って）難しいことは何もないと思います。 「移行」は、別に差し迫った期限は今のところないので、 特にあわてる必要はありませんが、開発環境は早く 作っておくべきですね。 -- Toshiharu Harada haradats ＠ gmail.com From haradats ＠ nttdata.co.jp Thu Aug 2 15:24:23 2007 From: haradats ＠ nttdata.co.jp (Toshiharu Harada) Date: Thu, 02 Aug 2007 15:24:23 +0900 Subject: [Tomoyo-dev 468] =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYzKyQ3GyhC?= =?iso-2022-jp?b?GyRCJF4kNyRnJCYbKEI=?= In-Reply-To: <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <9d732d950707301536ib067596v7509cd8c95969267@mail.gmail.com> <53275.163.135.10.34.1185849256.squirrel@webmail.knlab.com> <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> Message-ID: <46B17897.5090500@nttdata.co.jp> ccsかtomoyoかの議論が始まったところで、 1.5および2.1の作業とコードのクリーンナップ作業が 止まっていますが、再開したいと思います。 とりあえず"ccs"を前提で、 /sbin, /usr/sbin/ccs のように整理したいのですが、半田さんのほうで これまでの議論をベースとしたたたき台を作ってもらえませんか？ Tetsuo Handa さんは書きました: >>> この際、名称からツールのディレクトリからパッケージ名から、あらゆるものを >>> 統一していただくとすっきりします(^^) >> そう言えば、ccsをtomoyoに統一しよう。 >> tomoyoはキーボードの右側ばかり使う（笑）。 >> tmyに略す？ >> >> のような話もありましたね。 > > 名前をどうするかの話が止まっているようですが、 > 他にご意見はありませんか？ -- 原田季栄 (Toshiharu Harada) haradats ＠ nttdata.co.jp From from-tomoyo-dev ＠ i-love.sakura.ne.jp Thu Aug 2 15:58:49 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Thu, 02 Aug 2007 15:58:49 +0900 Subject: [Tomoyo-dev 469] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <46B17897.5090500@nttdata.co.jp> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <9d732d950707301536ib067596v7509cd8c95969267@mail.gmail.com> <53275.163.135.10.34.1185849256.squirrel@webmail.knlab.com> <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <46B17897.5090500@nttdata.co.jp> Message-ID: <200708020658.l726wn7g015179@www262.sakura.ne.jp> 　最初に、カーネルの中にハードコーディングする必要があるポリシーローダの デフォルトのパス名を決めてしまいたいと思います。 　ポリシーローダとして現状では /.init を使っていますが、 / ディレクトリに置きたくないという話があるので、場所と名前を決めましょう。 /sbin/init の開始前なので / パーティションしかマウントされていないため、 / パーティション上にあるディレクトリに置く必要があります。 また、 Debian 系では initrd.img の中にも /sbin/init が含まれるため、 initrd.img の中に含まれるパス名と衝突してはいけません。 　/sbin/.init にするか、 /sbin/ccs-init にするか、 /sbin/tomoyo-init にするかのどれかでしょうか？ 　カーネルのコマンドラインに init=/.init を指定しないで済むようにする方法としては、 fs/ccs_common.c の CCS_LoadPolicy() の中を struct nameidata nd; char *argv[2], *envp[3]; if (!ccs_loader) ccs_loader = "ポリシーローダのパス名（現状では /.init）"; if (path_lookup(ccs_loader, lookup_flags, &nd)) { printk("Not activating Mandatory Access Control now since %s doesn't exist.\n", ccs_loader); return; } path_release(&nd); argv[0] = ccs_loader; argv[1] = NULL; envp[0] = "HOME=/"; envp[1] = "PATH=/sbin:/bin:/usr/sbin:/usr/bin"; envp[2] = NULL; call_usermodehelper(argv[0], argv, envp, 1); みたいな感じに修正して call_usermodehelper() を呼び出し、 ポリシーローダの終了を待ってから先に進むという方法が考えられます。 この方法で問題なく動くかどうかは確認が必要です。 From yocto1 ＠ gmail.com Thu Aug 2 20:59:00 2007 From: yocto1 ＠ gmail.com (yocto) Date: Thu, 2 Aug 2007 20:59:00 +0900 Subject: [Tomoyo-dev 470] =?iso-2022-jp?b?OC8zGyRCJE43bxsoQg==?= Message-ID: <8f3c749a0708020459h77f9af78gf0ff56479bf684f7@mail.gmail.com> クスノです。 07/08/02 に Toshiharu Harada さんは書きました: > 原田です。 ... > 今週の金曜日、原田、武田、半田の3名で新宿に行くことに > なりました。8/3の夜6時頃、新宿に来られる方はどのくらい > いますか？ ぜひ行きたいのですが、多少遅れても大丈夫でしょうか。 From haradats ＠ gmail.com Thu Aug 2 21:17:09 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Thu, 2 Aug 2007 21:17:09 +0900 Subject: [Tomoyo-dev 471] Re: =?iso-2022-jp?b?OC8zGyRCJE43bxsoQg==?= In-Reply-To: <8f3c749a0708020459h77f9af78gf0ff56479bf684f7@mail.gmail.com> References: <8f3c749a0708020459h77f9af78gf0ff56479bf684f7@mail.gmail.com> Message-ID: <9d732d950708020517u25f5f60j49a1eed9ebe0019f@mail.gmail.com> クスノ様、 5時からTOMOYO Linuxの打ち合わせがあり、6時には 終わるはずです。その後は特に予定等ありませんので、 大丈夫です。 私は自宅が横浜で、勤務先が豊洲で、品川から左というか 西は全く土地勘がありません。新宿はさっぱりわからないので、 クスノさんの居場所によってはもう少し東側でも大丈夫です （自分だけなら横浜なら最強です（笑））。 候補的には、新宿、恵比寿、品川あたりでしょうか。 TOMOYO(CCS?)の話はそこそこにビールでも 飲みたいところです（悪酔いするかも）。 07/08/02 に yocto さんは書きました: > クスノです。 > > 07/08/02 に Toshiharu Harada さんは書きました: > > 原田です。 > ... > > 今週の金曜日、原田、武田、半田の3名で新宿に行くことに > > なりました。8/3の夜6時頃、新宿に来られる方はどのくらい > > いますか？ > > ぜひ行きたいのですが、多少遅れても大丈夫でしょうか。 -- Toshiharu Harada haradats ＠ gmail.com From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Thu Aug 2 22:11:26 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Thu, 2 Aug 2007 22:11:26 +0900 Subject: [Tomoyo-dev 472] Re: =?iso-2022-jp?b?U3RlcGhlbiAbJEIkWCROJWEhPCVrGyhC?= In-Reply-To: <46A322B4.4080706@nttdata.co.jp> References: <46A322B4.4080706@nttdata.co.jp> Message-ID: <200708022211.BDH03900.ZtStNGPPPNEWUPF@I-love.SAKURA.ne.jp> > BoFの後考えている取り組み（予定）について、7月20日 > SELinuxのStephenに打診してみる目的で送信した > メールを転送します。 　上記のメールへの返信は http://lists.sourceforge.jp/mailman/archives/tomoyo-dev/2007-July/000344.html です。 　以下は上記のメールのやりとりに先立って私が送ったメールです。 　私が Stephen と Chris 宛に送ったメールです。 TOMOYO Linux について BoF のデモだけでは 伝わりきっていないのではないかと思い、 OLS2007 から時間が経過して忘れられてしまわないうちに 説明するために送りました。 ------- Forwarded Message Subject: Concept of TOMOYO Linux. Date: Thu, 12 Jul 2007 00:06:16 +0900 Hello! Thank you for attending TOMOYO Linux BoF at OLS2007. TOMOYO Linux project members (we) are searching for phrases that can describe the way of TOMOYO Linux's thinking. For example, we tried "approach based access control", but this phrases didn't convey the idea well. I'm writing this message without deep consideration. So, please ask me whatever you couldn't understand. Traditional access control (standard Linux and SELinux and many of other implementations) is performed based on subject's attribute and object's attribute. For example, they allow access to an object that is associated with /etc/shadow provided that the object has appropriate attribute. They are interested in object's attribute. But TOMOYO Linux's access control is performed based on subject's behavior history and object's location. TOMOYO Linux allows access to any objects that is located on /etc/shadow provided that the process requesting access has appropriate behavior history. TOMOYO Linux is interested in subject's behavior history. Traditional access control allows users to make replicas rather freely (as SELinux demonstrates "ln /etc/shadow /tmp/shadow" is safe) because replicas have the same attribute and affects nothing to access control. So, they don't care what has happened before a request to /tmp/shadow arise. TOMOYO Linux's access control doesn't allow users to make replicas or move locations unless it is essential for the system to work properly because making replicas or moving locations affects critically to access control. So, TOMOYO Linux cares what has happened before a request to /tmp/shadow arise. To avoid unneeded replications or relocations, TOMOYO Linux traces each process's state rigidly and allows requests that are essential at that state. Now, I speak in images. Suppose you are in the entrance of a library. Traditional access control tells you that "You may walk as you like, but you must ask me before you read a book." and as you walked somewhere and picked up a book. Traditional access control tells you that "The book you picked up is categorized to comics, so you can read the book." and you read the book. Suppose you are in the entrance of a library. TOMOYO Linux tells you that "You may walk forward to 10 steps, but you may not walk to anywhere else." and as you walked 10 steps forward, TOMOYO Linux tells you that "You may turn left here, but you must not turn other directions." and as you turned left, TOMOYO Linux tells you that "You may walk forward to 10 steps, but you may not walk other directions." and as you walked 10 steps forward, TOMOYO Linux tells you that "You may raise your right arm, but you must not raise your left arm." and as you raise your right arm, TOMOYO Linux tells you that "You may read all books that you can pick up." and you pickup a book and read the book. This restriction is applied to everybody. There is no chance to move books from science journal's shelf to comic's shelf. So, the book you got is categorized to comics unless TOMOYO Linux allows someone actions to move books from science journal's shelf to comic's shelf. "everybody" corresponds to each "struct task_struct". "You may walk/turn/raise ..." corresponds to invocation of program. At the time of "You may read all books that you can pick up.", your credential is "I entered into a library and then I walked 10 steps forward and then I turned left there and then I walked 10 steps forward and then I raised my right arm". TOMOYO Linux checks whether a man requesting access has "entered into a library and walked 10 steps forward and turned left there and walked 10 steps forward and raised his right arm" credential, and allows the man to read all books that he can pick up at that attitude. You may wonder if such rigid state tracing can work. Yes, it works! This is the flow of "struct task_struct". Did this example help your understanding or make you confused? I'm waiting for your comment. Regards. ------- End of Forwarded Message 　Stephen からの返事です。 TOMOYO Linux についてはもう理解しているから、 AppArmor にできなくて TOMOYO にできることを示すことを求められました。 ------- Forwarded Message Subject: Re: Concept of TOMOYO Linux. Date: Wed, 11 Jul 2007 12:09:03 -0400 On Thu, 2007-07-12 at 00:06 +0900, Tetsuo Handa wrote: > Hello! > > Thank you for attending TOMOYO Linux BoF at OLS2007. > > TOMOYO Linux project members (we) are searching for > phrases that can describe the way of TOMOYO Linux's thinking. > For example, we tried "approach based access control", > but this phrases didn't convey the idea well. > > I'm writing this message without deep consideration. > So, please ask me whatever you couldn't understand. I think we already understand your approach and rationale. I just don't agree with it, and Chris thinks it doesn't offer enough difference from AppArmor to justify merging them both. For me, the issues are: - path-based security is fundamentally unsound, - history-based security can be achieved via SELinux policy (domain transitions) in a more flexible and secure way, - doing policy generation entirely via learning won't lead to more secure systems, - access control schemes that try to completely hide themselves from users and application developers consign themselves to irrelevance - you can't get more secure systems without ultimately affecting how users and application developers work, - users will be given a false sense of security and will choose the easiest path in the absence of a real understanding of the tradeoff, - many different security models in the kernel with incompatible policies and APIs will lead to users and developers ignoring them all, which is fatal to genuine MAC being mainstreamed throughout the software stack. Fake MAC will drive out genuine MAC. For Chris, the main issues seem to be: - TOMOYO and AppArmor are too much alike to merge them both, - AppArmor is further along in the submission process than TOMOYO, - AppArmor has the support of at least one major distribution and inclusion by another, whereas TOMOYO has no real vendor pull that I know of. > But TOMOYO Linux's access control is performed based on > subject's behavior history and object's location. > TOMOYO Linux allows access to any objects that is located on /etc/shadow > provided that the process requesting access has appropriate behavior history. > TOMOYO Linux is interested in subject's behavior history. SELinux can control based on the invocation history via domain transitions, and further, as a MAC scheme, you know the possible information flows that a given domain may have performed, so you can e.g. ensure that a low integrity subject never gets to write to /etc/shadow or a low secrecy subject never gets to read it. > TOMOYO Linux's access control doesn't allow users to make replicas or move locations > unless it is essential for the system to work properly > because making replicas or moving locations affects critically to access control. > So, TOMOYO Linux cares what has happened before a request to /tmp/shadow arise. > To avoid unneeded replications or relocations, > TOMOYO Linux traces each process's state rigidly and > allows requests that are essential at that state. I would argue that such security is too fragile, but even if one accepts it, how does it differ from AppArmor's controls on creating hard links or renaming files for confined processes, and its controls over namespace manipulation? What is a real example of useful security goal you can achieve with TOMOYO that AppArmor cannot achieve? Specifics, please. > Now, I speak in images. > > Suppose you are in the entrance of a library. Traditional access control tells you that > "You may walk as you like, but you must ask me before you read a book." > and as you walked somewhere and picked up a book. Traditional access control tells you that > "The book you picked up is categorized to comics, so you can read the book." > and you read the book. > > Suppose you are in the entrance of a library. TOMOYO Linux tells you that > "You may walk forward to 10 steps, but you may not walk to anywhere else." > and as you walked 10 steps forward, TOMOYO Linux tells you that > "You may turn left here, but you must not turn other directions." > and as you turned left, TOMOYO Linux tells you that > "You may walk forward to 10 steps, but you may not walk other directions." > and as you walked 10 steps forward, TOMOYO Linux tells you that > "You may raise your right arm, but you must not raise your left arm." > and as you raise your right arm, TOMOYO Linux tells you that > "You may read all books that you can pick up." > and you pickup a book and read the book. > This restriction is applied to everybody. > There is no chance to move books from science journal's shelf to comic's shelf. > So, the book you got is categorized to comics > unless TOMOYO Linux allows someone actions to move books from science journal's shelf to comic's shelf. I'm not sure I see the benefit here, and it certainly seems less understandable. SELinux would let you ensure that data in the "comics" type can never leak to data in the "science journal" type if that is what you want to achieve, far more simply. > "everybody" corresponds to each "struct task_struct". > "You may walk/turn/raise ..." corresponds to invocation of program. > At the time of "You may read all books that you can pick up.", your credential is > "I entered into a library and then I walked 10 steps forward > and then I turned left there and then I walked 10 steps forward > and then I raised my right arm". > TOMOYO Linux checks whether a man requesting access has > "entered into a library and walked 10 steps forward > and turned left there and walked 10 steps forward and raised his right arm" credential, > and allows the man to read all books that he can pick up at that attitude. > > You may wonder if such rigid state tracing can work. > Yes, it works! This is the flow of "struct task_struct". > > > Did this example help your understanding or make you confused? > I'm waiting for your comment. I don't think the issue is a lack of understanding on our side - I think we just disagree. -- Stephen Smalley National Security Agency ------- End of Forwarded Message 　私が Stephen に送った回答です。 AppArmor にできなくて TOMOYO Linux にできることについて、さんざん悩みました。 ------- Forwarded Message Subject: Re: Concept of TOMOYO Linux. Date: Sun, 15 Jul 2007 13:20:09 +0900 Hello. I'm sorry for my slow response. Stephen Smalley wrote: > I think we already understand your approach and rationale. I just don't > agree with it, and Chris thinks it doesn't offer enough difference from > AppArmor to justify merging them both. For me, the issues are: > - path-based security is fundamentally unsound, It is true if path-based security is used alone. TOMOYO is not just a path-based security. TOMOYO is a combination of a path-based access control and a history-based access control. > - doing policy generation entirely via learning won't lead to more > secure systems, TOMOYO is less secure than SELinux. But at least, TOMOYO can lead to more secure system than normal Linux. People don't use TOMOYO's automatically generated policy without confirmation. People understand what permissions are given to each domains and delete permissions they don't want to give. > For Chris, the main issues seem to be: > - TOMOYO and AppArmor are too much alike to merge them both, Yes, TOMOYO and AppArmor are very alike. But please see differences other than path-based access control. > - AppArmor is further along in the submission process than TOMOYO, TOMOYO is behind AppArmor in submission process. But I think AppArmor is behind TOMOYO in functionality and designs. In the AppArmor's BoF in OLS2007, Seth Arnold showed that AppArmor is going to incorporate many of TOMOYO Linux's features as a future plan. What TOMOYO wants to incorporate from AppArmor is changehat feature, but we don't have userland softwares we can maintain (because we are not a Linux distributor). We can implement AppArmor's changehat, but we don't have userland programs we can maintain. > - AppArmor has the support of at least one major distribution and > inclusion by another, whereas TOMOYO has no real vendor pull that I know > of. TOMOYO Linux 1.3.1 is included in TurboLinux 10 Server (a distribution famous in Japan). Since TOMOYO Linux is lightweight and less memory consuming and requires no GUI environment, embedded system developers (CELF members in Japan) are eagerly encouraging us to merge TOMOYO Linux into mainline. They are early and conclusive supporter of TOMOYO Linux. This is why we developed LSM version of TOMOYO Linux (a.k.a. TOMOYO Linux 2.0) and submitting it. > I would argue that such security is too fragile, but even if one accepts > it, how does it differ from AppArmor's controls on creating hard links > or renaming files for confined processes, and its controls over > namespace manipulation? What is a real example of useful security goal > you can achieve with TOMOYO that AppArmor cannot achieve? Specifics, > please. TOMOYO checks old_pathname and new_pathname together for link and rename operations, while AppArmor doesn't. TOMOYO checks combination of mount_device, mount_point, filesystems for mount operation to prevent unwanted mounts, while AppArmor doesn't. This ensures that /dev/sda1 (for /boot partition) is mounted on /boot and /dev/sda2 (for / partition) is mounted on / and /dev/sda3 (for /home partition) is mounted on /home and tmpfs won't be mounted on /boot / /home etc. TOMOYO checks combination of old_root and new_root for pivot_root() operation to prevent unwanted exchange (although pivot_root() is seldom used after /sbin/init starts). TOMOYO uses absolute pathname that is not affected by chroot() (although AppArmor's patch is proposing d_namespace_path() to do the same thing). TOMOYO's targets are limited to systems that don't require complicated namespace manipulation (e.g. same pathname indicating different objects). I think there are many systems that don't require complicated namespace manipulation. Real examples of useful security goal you can achieve with TOMOYO nut you cannot achieve with AppArmor: (1) Provide TOMOYO enabled systems a proof that the sequence of program invocation happens along with domain transition tree. Administrator can know what program will be invoked next, and what pathnames will be requested by each program. Administrator preliminarily knows all requests that will arise. Administrator gains the peace of mind knowing "No unexpected requests will happen". (2) TOMOYO's domain transition tree allows administrator to apply RBAC-like access control. You can split domain transition tree by program's name and give different permissions for each subtree. For example, allow " /usr/sbin/sshd /bin/bash" domain to restart Apache and allow " /usr/sbin/sshd /bin/tcsh" domain to restart Sendmail. (3) TOMOYO's domain transition tree allows administrator deploy buffers for brute force attack. For example, allow " /usr/sbin/sshd /bin/bash" domain to execute only "/bin/extra_authentication" that performs different types of authentication and allow " /usr/sbin/sshd /bin/bash /bin/extra_authentication /bin/bash" domain to execute all operations that are allowed for login session. You can chase away an intruder with /bin/extra_authentication . (4) This is a bit different from security goal, but one of usages of TOMOYO Linux. TOMOYO Linux can report pathnames that are requested by each domain, and users can pick up reported pathnames to make minimal set of files for minimal sized root filesystem. What TOMOYO can do but AppArmor cannot do: (1) Track all process's program invocation chain and requests. TOMOYO is designed to cover all processes and can apply access control over all processes, whereas AppArmor is designed to cover specific processes and cannot apply access control over all processes. TOMOYO is a white-listing while AppArmor is a black-listing in point of view of which programs to apply access control. (2) Create domains automatically and transit to that domain automatically whenever a program is invoked. (You can suppress domain transition if you want.) (3) Create policy from scratch, no default policy provided by distributors is needed. (4) Generate policy automatically from /sbin/init till just before power failure. (5) Automatically generated policy contains minimal permissions that are essential for the program to run properly. The system can operate properly in enforcing mode without modification to automatically generated policy. (6) Allow administrator give different permissions depending on how a program is invoked. For example, you can distinguish "/usr/sbin/sendmail.sendmail invoked from /bin/bash" and "/usr/sbin/sendmail.sendmail invoked from /bin/tcsh" if you want. (7) TOMOYO's automatic domain creation and transition makes easy to apply access control for login session. Creating policy for login session is extremely easy. An administrator runs commands and accesses files that they want to allow. Learning mode feature will generate policy for login session from scratch. An administrator reviews automatically generated policy and use it in enforcing mode. AppArmor can apply access control for login session if an administrator has skill to create policy for login session. It is not impossible, but it is more difficult and needs more time than TOMOYO because an administrator needs to design domains and domain transitions manually. The following is some memorandum I wrote for OLS2007 (but not used). TOMOYO Linux is an implementation of mandatory access control for Linux. TOMOYO Linux is interested in "How the system behaves", but is indifferent about "How the information propagates". TOMOYO Linux aims for "Permit operations what are requisite at the right moment", but does NOT aim for "Provide guarantees about information flow like BLP model". In the world of TOMOYO Linux, the administrator plans the entire scenario "What will happen" in advance. The TOMOYO Linux' kernel reports the administrator "What has happened and What will happen next" to help the administrator plan the entire scenario. The system behaves based on a scenario of administrator's plan. The administrator preliminarily knows everything that can happen. The administrator gains the peace of mind knowing "Nothing unexpected will happen". In short, the world of TOMOYO Linux is "Penguin on Rails". :) You might say pathname-based access control allows accesses via symbolic links and "..", but it's not true inside kernel. TOMOYO Linux calculates pathnames from dentry and vfsmount to exclude symbolic links and ".." in its pathname. TOMOYO Linux forbids (1) "ln -s /etc/shadow /tmp/shadow; cat /tmp/shadow" by dereferencing all symbolic links when calculating pathnames. (2) "cat /tmp/../etc/shadow" by solving all ".." when calculating pathnames. (3) "ln /etc/shadow /etc/shadow+; cat /etc/shadow+" by not granting "allow_link /etc/shadow /etc/shadow+" permission. (4) "mv /etc/shadow /etc/shadow+; cat /etc/shadow+" by not granting "allow_rename /etc/shadow /etc/shadow+" permission. (5) "mount --bind /etc/ /tmp/; cat /tmp/shadow" by not granting "allow_mount /etc/ /tmp/ --bind" permission. You assume pathnames are freely link()able, rename()able, mount()able, but it is not true in TOMOYO Linux. And if such requests shown above are need to be granted, that is because such requests are essential for the system to work. Regards. ------- End of Forwarded Message 　上手く表現できていない箇所があったので訂正するメールです。 ------- Forwarded Message Subject: Re: Concept of TOMOYO Linux. Date: Mon, 16 Jul 2007 19:35:43 +0900 Tetsuo Handa wrote: > (1) Track all process's program invocation chain and requests. > > TOMOYO is designed to cover all processes and can apply access control > over all processes, whereas AppArmor is designed to cover specific processes > and cannot apply access control over all processes. > > TOMOYO is a white-listing while AppArmor is a black-listing > in point of view of which programs to apply access control. My mistake. This should be: TOMOYO is a white-listing while AppArmor is a black-listing in point of view of which programs to *bypass* access control. Regards. ------- End of Forwarded Message 　上手く表現できていない箇所があったので再度訂正するメールです。 ------- Forwarded Message Subject: Re: Concept of TOMOYO Linux. Date: Tue, 17 Jul 2007 01:02:50 +0900 Tetsuo Handa wrote: > Tetsuo Handa wrote: > > TOMOYO is a white-listing while AppArmor is a black-listing > > in point of view of which programs to apply access control. > My mistake. This should be: > TOMOYO is a white-listing while AppArmor is a black-listing > in point of view of which programs to *bypass* access control. Well, white-listing and black-listing looks incorrect here. This should be: TOMOYO is all-by-default while AppArmor is none-by-default in point of view of which programs to apply access control. ------- End of Forwarded Message 　Stephen からの返事です。 やっぱり納得してもらえませんでした。 ------- Forwarded Message Subject: Re: Concept of TOMOYO Linux. Date: Tue, 17 Jul 2007 09:51:31 -0400 On Sun, 2007-07-15 at 13:20 +0900, Tetsuo Handa wrote: > Hello. > > I'm sorry for my slow response. > > Stephen Smalley wrote: > > I think we already understand your approach and rationale. I just don't > > agree with it, and Chris thinks it doesn't offer enough difference from > > AppArmor to justify merging them both. For me, the issues are: > > - path-based security is fundamentally unsound, > > It is true if path-based security is used alone. > TOMOYO is not just a path-based security. > TOMOYO is a combination of a path-based access control > and a history-based access control. Nonetheless, the same inability to enforce system-wide security goals and provide global and persistent protection of the data remains. > > - doing policy generation entirely via learning won't lead to more > > secure systems, > > TOMOYO is less secure than SELinux. But at least, TOMOYO can lead to > more secure system than normal Linux. > > People don't use TOMOYO's automatically generated policy without confirmation. > People understand what permissions are given to each domains and > delete permissions they don't want to give. No, users don't really understand what they are allowing with these systems; they just keep allowing permissions until the system works, and you aren't providing them with any way to evaluate the end result (no way to analyze it meaningfully). > > For Chris, the main issues seem to be: > > - TOMOYO and AppArmor are too much alike to merge them both, > > Yes, TOMOYO and AppArmor are very alike. > But please see differences other than path-based access control. > > > - AppArmor is further along in the submission process than TOMOYO, > > TOMOYO is behind AppArmor in submission process. > But I think AppArmor is behind TOMOYO in functionality and designs. > > In the AppArmor's BoF in OLS2007, Seth Arnold showed that AppArmor is > going to incorporate many of TOMOYO Linux's features as a future plan. > What TOMOYO wants to incorporate from AppArmor is changehat feature, > but we don't have userland softwares we can maintain > (because we are not a Linux distributor). > We can implement AppArmor's changehat, but we don't have userland programs > we can maintain. This is likely an argument you should be making on lsm and/or lkml lists then, as part of submitting TOMOYO, in order to justify why it should exist separately from AppArmor. But it isn't enough to say that you have more functionality in your non-LSM kernel patches; you have to have your code in a form that is mergeable, which means using LSM (extending it as needed). > > - AppArmor has the support of at least one major distribution and > > inclusion by another, whereas TOMOYO has no real vendor pull that I know > > of. > > TOMOYO Linux 1.3.1 is included in TurboLinux 10 Server (a distribution famous in Japan). Ok, another point to make in presenting your code in lsm and/or lkml lists, i.e. that you have some vendor/user pull. I don't personally know what it means for TurboLinux to ship your code; they shipped SELinux for a while too, but that doesn't mean that it was enabled by default or used by anyone. > Since TOMOYO Linux is lightweight and less memory consuming and requires no GUI environment, > embedded system developers (CELF members in Japan) are eagerly encouraging us > to merge TOMOYO Linux into mainline. They are early and conclusive supporter of TOMOYO Linux. > This is why we developed LSM version of TOMOYO Linux (a.k.a. TOMOYO Linux 2.0) and submitting it. SELinux doesn't require a GUI environment (unless you are using the SELinux Policy Editor, which we don't, but even then, you only need that on the build system where you are creating the policy; you should be able to build and ship policy to the end systems without a GUI there at all). On the "lightweight" and less memory consuming side, we have done work to improve SELinux's footprint as have Yuichi and KaiGai, and you could be helping there too if you wanted to. Too much of a not-invented-here mentality, everyone wants to make their own LSM rather than collaborate to make a single optimal one. Anyway, I'm not sure how your argument above differentiates you from e.g. AppArmor in terms of footprint, and I suspect that the embedded folks don't especially care about TOMOYO vs. AppArmor, they just want something they can use. > > I would argue that such security is too fragile, but even if one accepts > > it, how does it differ from AppArmor's controls on creating hard links > > or renaming files for confined processes, and its controls over > > namespace manipulation? What is a real example of useful security goal > > you can achieve with TOMOYO that AppArmor cannot achieve? Specifics, > > please. > > TOMOYO checks old_pathname and new_pathname together for link and rename operations, > while AppArmor doesn't. Not sure I understand, but this is really an argument you need to make as part of submitting TOMOYO, not in private to me or chrisw. But double check your facts (e.g. AppArmor does appear to apply a check on link based on the accesses allowed to both names), and make sure you write it in a way that is meaningful to users, IOW why should a user care that TOMOYO does X while AppArmor does Y. > TOMOYO checks combination of mount_device, mount_point, filesystems for mount operation > to prevent unwanted mounts, while AppArmor doesn't. > This ensures that /dev/sda1 (for /boot partition) is mounted on /boot > and /dev/sda2 (for / partition) is mounted on / > and /dev/sda3 (for /home partition) is mounted on /home > and tmpfs won't be mounted on /boot / /home etc. Again, this belongs as part of submitting TOMOYO, but IIUC, AppArmor prohibits namespace manipulation like mount by confined programs entirely. And are you sure that users want to encode their fstab into their kernel policy? > Real examples of useful security goal you can achieve with TOMOYO nut you cannot achieve with AppArmor: > > (1) Provide TOMOYO enabled systems a proof that the sequence of program invocation happens > along with domain transition tree. Administrator can know what program will be > invoked next, and what pathnames will be requested by each program. > Administrator preliminarily knows all requests that will arise. > Administrator gains the peace of mind knowing "No unexpected requests will happen". Unless you happen to exercise a program in a different way the next time, at which point it may read a different file or execute a different program. Most/many programs are data-driven and thus their behavior can change significantly at runtime. But anyway, this kind of thing should be part of your submission, but again rewritten in a way that makes it clear why users should care about this. Typical user won't understand what you describe above at all, or want to know about it. > (2) TOMOYO's domain transition tree allows administrator to apply > RBAC-like access control. > You can split domain transition tree by program's name > and give different permissions for each subtree. > For example, allow " /usr/sbin/sshd /bin/bash" domain to restart Apache > and allow " /usr/sbin/sshd /bin/tcsh" domain to restart Sendmail. Contrived, unconvincing example (bash vs. tcsh? Who cares?). And for real RBAC, you actually want something based on the authenticated user, thus you want either SELinux's pam_selinux or AppArmor's pam_apparmor and change_hat support (you don't need to ship your own distro to supply a pam module and config with your kernel code). > (3) TOMOYO's domain transition tree allows administrator deploy buffers > for brute force attack. > For example, allow " /usr/sbin/sshd /bin/bash" domain to execute > only "/bin/extra_authentication" that performs different types of authentication > and allow " /usr/sbin/sshd /bin/bash /bin/extra_authentication /bin/bash" domain > to execute all operations that are allowed for login session. > You can chase away an intruder with /bin/extra_authentication . Being able to construct protected subsystems (unbypassable component that enforces a security goal) is good, and something SELinux/TE is specifically designed to do. Although again your particular example isn't very compelling; if the attacker can break sshd, then odds are high that he will be able to subvert your later authentication stage, just by controlling sshd and waiting until the desired user logs in, and interposing on his pty. > What TOMOYO can do but AppArmor cannot do: > > (1) Track all process's program invocation chain and requests. > > TOMOYO is designed to cover all processes and can apply access control > over all processes, whereas AppArmor is designed to cover specific processes > and cannot apply access control over all processes. This one is important, although it doesn't match the heading (being able to track the invocation chain is different than being able to control all processes). I'd agree that AppArmor design limitation to only selective confinement is a flaw in it. Something to call out in your submission on list. > (3) Create policy from scratch, no default policy provided by distributors is needed. IMHO, this is not what you actually want, as it guarantees only status quo encapsulation (just encoding what already occurs, no real thought to security), is unlikely to actually capture all possible code paths or take into account data-driven activity (thus will be fragile and prone to breakage, and users will be forced to run 'permissive' for a long time before they can switch). > (5) Automatically generated policy contains minimal permissions that are essential for > the program to run properly. The system can operate properly in enforcing mode > without modification to automatically generated policy. Again, unless you exercise a different code path by providing different inputs to the program. > (6) Allow administrator give different permissions depending on how a program is invoked. > For example, you can distinguish "/usr/sbin/sendmail.sendmail invoked from /bin/bash" > and "/usr/sbin/sendmail.sendmail invoked from /bin/tcsh" if you want. Bad example, as no one cares about bash vs. tcsh. > (7) TOMOYO's automatic domain creation and transition makes easy to > apply access control for login session. > Creating policy for login session is extremely easy. > An administrator runs commands and accesses files that they want to allow. > Learning mode feature will generate policy for login session from scratch. > An administrator reviews automatically generated policy and use it in enforcing mode. How do you bind that policy to a particular user? Support different policies for different users? > TOMOYO Linux is an implementation of mandatory access control for Linux. > TOMOYO Linux is interested in "How the system behaves", > but is indifferent about "How the information propagates". Except that users actually need/want to control how information propagates if they want to enforce confidentiality or integrity goals. Oops! > TOMOYO Linux aims for "Permit operations what are requisite at the right moment", > but does NOT aim for "Provide guarantees about information flow like BLP model". Except that the concatenation/sequence of "operations requisite at the right moment" can lead to undesired information flows that violate your confidentiality or integrity goals. Oops! > In the world of TOMOYO Linux, the administrator plans the entire scenario > "What will happen" in advance. > The TOMOYO Linux' kernel reports the administrator "What has happened and > What will happen next" to help the administrator plan the entire scenario. > The system behaves based on a scenario of administrator's plan. > The administrator preliminarily knows everything that can happen. > The administrator gains the peace of mind knowing "Nothing unexpected will happen". > In short, the world of TOMOYO Linux is "Penguin on Rails". :) > > > You might say pathname-based access control allows accesses via symbolic links > and "..", but it's not true inside kernel. > TOMOYO Linux calculates pathnames from dentry and vfsmount to exclude symbolic links > and ".." in its pathname. > TOMOYO Linux forbids > > (1) "ln -s /etc/shadow /tmp/shadow; cat /tmp/shadow" by dereferencing all symbolic links > when calculating pathnames. > > (2) "cat /tmp/../etc/shadow" by solving all ".." when calculating pathnames. > > (3) "ln /etc/shadow /etc/shadow+; cat /etc/shadow+" by not granting > "allow_link /etc/shadow /etc/shadow+" permission. > > (4) "mv /etc/shadow /etc/shadow+; cat /etc/shadow+" by not granting > "allow_rename /etc/shadow /etc/shadow+" permission. > > (5) "mount --bind /etc/ /tmp/; cat /tmp/shadow" by not granting > "allow_mount /etc/ /tmp/ --bind" permission. > > You assume pathnames are freely link()able, rename()able, mount()able, > but it is not true in TOMOYO Linux. And if such requests shown above are > need to be granted, that is because such requests are essential for > the system to work. Such a policy seems to be very rigid and difficult to apply to any general purpose system, particularly one with real users. But please, don't reply to me. If you want TOMOYO to be merged, then keep pushing for it by submitting code to lsm and/or lkml, provide rationale as to why it differs substantively from AppArmor and what users care about it, and do so in a way that is understandable to your audience. Or if you want to actually make systems more secure, help us improve SELinux. Your call. -- Stephen Smalley National Security Agency ------- End of Forwarded Message 　Chris からの返事です。 ------- Forwarded Message Subject: Re: Concept of TOMOYO Linux. Date: Tue, 17 Jul 2007 08:39:27 -0700 * Tetsuo Handa (200707 ＠ I-love.SAKURA.ne.jp) wrote: > TOMOYO is all-by-default while AppArmor is none-by-default > in point of view of which programs to apply access control. This is an implementation (or usability) detail. There is nothing in the architecture of AppArmor that requires none-by-default, but like TOMOYO or SELinux in strict mode, making a secure policy that doesn't break applications gets more difficult. ------- End of Forwarded Message From nez ＠ samba.gr.jp Fri Aug 3 02:36:18 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Fri, 03 Aug 2007 02:36:18 +0900 Subject: [Tomoyo-dev 473] Re: =?iso-2022-jp?b?OC8zGyRCJE43bxsoQg==?= In-Reply-To: <9d732d950708020517u25f5f60j49a1eed9ebe0019f@mail.gmail.com> References: <8f3c749a0708020459h77f9af78gf0ff56479bf684f7@mail.gmail.com> <9d732d950708020517u25f5f60j49a1eed9ebe0019f@mail.gmail.com> Message-ID: <46B21612.6010208@samba.gr.jp> 根津です。 Toshiharu Harada wrote: > クスノ様、 > > 5時からTOMOYO Linuxの打ち合わせがあり、6時には > 終わるはずです。その後は特に予定等ありませんので、 > 大丈夫です。 うーん。惜しい・・・。新宿居るんですけど、工学院大学で作業ちう だと思います・・・。_|￣|○ > 私は自宅が横浜で、勤務先が豊洲で、品川から左というか > 西は全く土地勘がありません。新宿はさっぱりわからないので、 > クスノさんの居場所によってはもう少し東側でも大丈夫です > （自分だけなら横浜なら最強です（笑））。 私も横浜、関内近辺なら最強！ｗ -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From haradats ＠ gmail.com Fri Aug 3 07:14:46 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Fri, 3 Aug 2007 07:14:46 +0900 Subject: [Tomoyo-dev 474] Re: SELinux + TOMOYO In-Reply-To: <200708020422.AA02309@bbb-jz5c7z9hn9y.digitalinfra.co.jp> References: <200708020422.AA02309@bbb-jz5c7z9hn9y.digitalinfra.co.jp> Message-ID: <9d732d950708021514s6a5b2b48sa80f103d859fa12c@mail.gmail.com> 原田です。おはようございます。 すごいことに気がついてしまいました。 TOMOYO Linuxは必ずしもメインラインにいれなければならない わけではありません。TOMOYO Linuxは、既にプログラムと パッケージが存在していて、動作します。GUIもあります。 だから、「Linux以外のできるだけ権威や影響力のある国際会議」の チュートリアルで、「TOMOYO Linuxでできること」を ただ、見せれば良いのです。つまり、実装や技術論、方式ではなく、 「できること」をアピールします。 それを見せても興味を持ってもらえなかったり、利用者が 増えなければそれはそれまでです。でも、そうでなければ 飛躍的に利用者が増えて、他のプラットフォームへの 導入（移植）の検討も始まるでしょう。それは十分に起こりえる ことだと思います。その場合、「メインラインに入っていない ことは関係ありません」。 本当にそうなったら、Linuxの世界や某社の考えも変わるでしょう。 07/08/02 に Jun OKAJIMA さんは書きました: > > > 有限会社デジタルインフラの岡島と申します。はじめまして。 > > 議論を拝見させていただいて、ひとつ疑問がわいたのですが、 > なぜ、カーネルモードにこだわっているのでしょうか。 > なぜ、独自開発にこだわっているのでしょうか。 > > TOMOYO Linuxのウリとは、ようは、実行結果から > 対話式にポリシーを作れることですよね。 > Windowsのファイアーウォールの設定のようなもの。 > > この理解が正しいとして・・・。 > > でしたら、SELinuxの実行結果を解析し、 > ここから対話的にSELinuxのポリシーは作れないのでしょうか。 > > もし、それが可能であれば、SELinux ベースに全面的に変更するのも > 一案だと思います。 > > そうすれば、普及とメンテに関しては、大幅に楽になります。 > 部外者がチャチャを入れるようで恐縮ですが、 > オリジナルのカーネルモジュールは、普及とメンテが非常に大変ですよ・・・。 > > > 有限会社デジタルインフラ 取締役社長 岡島 純 > http://www.digitalinfra.co.jp/ > http://www.machboot.com/ > http://www.colinux.org/ > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -- Toshiharu Harada haradats ＠ gmail.com From haradats ＠ gmail.com Fri Aug 3 07:20:53 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Fri, 3 Aug 2007 07:20:53 +0900 Subject: [Tomoyo-dev 475] =?iso-2022-jp?b?VE9NT1lPIExpbnV4GyRCJSolVTJxJE4kKkNOJGkkOxsoQg==?= Message-ID: <9d732d950708021520o37252c7ev816a8575b6dd1efb@mail.gmail.com> 8/3 18:30頃、恵比寿付近（銀座ライオンになるかも）で、 かる〜〜〜く暑気払いでもしようかと思います。 （特に何かを検討や、議論はしません。暑気払いです） 今のところ参加予定はクスノさんと原田の2名ですが、 参加したいという方があれば、私宛メールください。 （原田連絡先はDevelopフォーラムに書いてあります） 07/08/02 に yocto さんは書きました: > クスノです。 > > 07/08/02 に Toshiharu Harada さんは書きました: > > 原田です。 > ... > > 今週の金曜日、原田、武田、半田の3名で新宿に行くことに > > なりました。8/3の夜6時頃、新宿に来られる方はどのくらい > > いますか？ > > ぜひ行きたいのですが、多少遅れても大丈夫でしょうか。 > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -- Toshiharu Harada haradats ＠ gmail.com From haradats ＠ gmail.com Fri Aug 3 07:26:21 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Fri, 3 Aug 2007 07:26:21 +0900 Subject: [Tomoyo-dev 476] Re: SELinux + TOMOYO In-Reply-To: <9d732d950708021514s6a5b2b48sa80f103d859fa12c@mail.gmail.com> References: <200708020422.AA02309@bbb-jz5c7z9hn9y.digitalinfra.co.jp> <9d732d950708021514s6a5b2b48sa80f103d859fa12c@mail.gmail.com> Message-ID: <9d732d950708021526h52f9dcb4y2dc97785b59d2f48@mail.gmail.com> 07/08/03 に Toshiharu Harada さんは書きました: > すごいことに気がついてしまいました。 私の考えが正しければ、多分TOMOYO Linuxは既に勝っています。 戦う相手を間違えていただけです。 「作り（実装）なんかどうでも良い、問題は何ができるか」という できるだけ権威のある場を見つけて、そこでチュートリアルを 採択されると良いのです。 勿論、メインライン化はやめるわけではありません。 それをできる状況を作ります。SELinux陣営や某社が文句を 言えない状況を作ります。 利用者は多分TOMOYO Linuxに興味を持ち、味方（なまか）に なってくれるはずです。それが「使えるセキュアLinux」である TOMOYO Linuxの強みです。 某社は権威には弱いのです。（おいおい） -- Toshiharu Harada haradats ＠ gmail.com From haradats ＠ gmail.com Fri Aug 3 07:40:53 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Fri, 3 Aug 2007 07:40:53 +0900 Subject: [Tomoyo-dev 477] Re: SELinux + TOMOYO In-Reply-To: <9d732d950708021526h52f9dcb4y2dc97785b59d2f48@mail.gmail.com> References: <200708020422.AA02309@bbb-jz5c7z9hn9y.digitalinfra.co.jp> <9d732d950708021514s6a5b2b48sa80f103d859fa12c@mail.gmail.com> <9d732d950708021526h52f9dcb4y2dc97785b59d2f48@mail.gmail.com> Message-ID: <9d732d950708021540u8fd3f2buf166aa6df5c72ea2@mail.gmail.com> 07/08/03 に Toshiharu Harada さんは書きました: > 私の考えが正しければ、多分TOMOYO Linuxは既に勝っています。 > 戦う相手を間違えていただけです。 > 「作り（実装）なんかどうでも良い、問題は何ができるか」という > できるだけ権威のある場を見つけて、そこでチュートリアルを > 採択されると良いのです。 自分でも探しますが、上記のような国際会議があれば教えて下さい。 場所はどこでも良いです（どこでも行きます）。 ELC, OLSというLinuxのメジャーの場で発表を 行っていることは選考の際に考慮されるでしょう。 動画はプログラムが存在していることの証明になります。 ポイントは、応用と見せ方（プレゼンテーション）に なると思います。 -- Toshiharu Harada haradats ＠ gmail.com From haradats ＠ gmail.com Fri Aug 3 08:02:40 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Fri, 3 Aug 2007 08:02:40 +0900 Subject: [Tomoyo-dev 478] Re: path-based MAC In-Reply-To: <9d732d950707301518l7ed2c53cp3692d37320901b3d@mail.gmail.com> References: <9d732d950707301518l7ed2c53cp3692d37320901b3d@mail.gmail.com> Message-ID: <9d732d950708021602o62bb1652x3f1af5316afdefe6@mail.gmail.com> 07/07/31 に Toshiharu Harada さんは書きました: > 原田です。 > > パス名ベースのMACが駄目だということがちゃんとした > 議論がなされないまま一種定説的になっているというのは、 > 例えば、Jonathanの書いた記事やLKMLの発言から > 確認できます。 > > 「根拠」として挙げられている例は、似通っていて、 > /etc/shadowがリンクされるとパス名が違って見えるから > MACがきかないという稚拙なものしか見たことが > ありません。こちらがちゃんとした説明を（英文で）発表していないのも > 悪いのですが（素材を書いてくれたら外に出すのを手伝いますから > まとめてもらえませんか？＞半田さん）、mlだとあまり議論にならず、特に > LKMLはその議論を行うのは不適であることが > （実際に投稿および議論をして）わかりました。 > > ひとつ比較的新しい書き込みを見つけました。 > > http://securityblog.org/brindle/2007/07/15/misunderstanding-unix-security/#comment-15822 > > Brindle on securityというこのブログの著者Joshua Brindleは、 > Stephenを含めたNSAのメンバーと親しいようで、ここで議論をすれば > おそらくStephenも読みますし、参加してくるでしょう。 > Joshuaは、TOMOYO BoFにも参加し、助言（彼のBoFの > topdown securityの記事を読むように）をしてくれるなど > とても協調的で親切ですから、ケンカをするつもりはありませんが、 > 書いてあることがおかしいので、軽くジャブをいれました。 > 反応があれば継続して議論します。 > > そのほか議論の場としては、Jonathan他が運用している > LWN.netで、ここはもっと上のレイヤーで方針、あるべき論などを > 議論するところです（個別の技術や例を紹介する場では > ありません）。 その後毎日モニターしていますが、フォローはついていません。 理由として考えられるのは、 1. 気がついていない 2. 困っていて返答できない 3. 書き込みの意味が通じていない 4. 無視されている 5. その他 ですが、このまま返答がつかなくても良いように、「証拠」を 追加しておきたいと思います。「証拠」とは、オペレーションと ログです。 半田さんか武田君で素材を作ってもらえませんか？ 原田が書いたコメントの内容を裏付けするようなもので あれば、ディストロ等は問いません。シンプルなのが 望ましいです。 -- Toshiharu Harada haradats ＠ gmail.com From ynakam ＠ hitachisoft.jp Fri Aug 3 08:27:50 2007 From: ynakam ＠ hitachisoft.jp (Yuichi Nakamura) Date: Fri, 03 Aug 2007 08:27:50 +0900 Subject: [Tomoyo-dev 479] Re: SELinux + TOMOYO In-Reply-To: <9d732d950708021540u8fd3f2buf166aa6df5c72ea2@mail.gmail.com> References: <9d732d950708021526h52f9dcb4y2dc97785b59d2f48@mail.gmail.com> <9d732d950708021540u8fd3f2buf166aa6df5c72ea2@mail.gmail.com> Message-ID: <20070803080541.54B2.YNAKAM@hitachisoft.jp> 原田さん 中村です。 最近ROMっております。 実用系で、権威がある場と言えば、 USENIXではないでしょうか（既にご存知と思いますが） 論文の採択率も、他学会より低いと聞きます。 近いイベントだと、 USENIXのシステム管理ですね。 http://www.usenix.org/events/lisa07/ 論文締め切りは8/20ですか(普通は延びるでしょうが。。） ポスターなら間に合うかも。。 チュートリアルもありますね。 http://www.usenix.org/events/lisa07/cfp/training.html SELinuxとpath-namebased MACの議論を見てると、 完全に平行線ですよね。 確かに、 正面から対峙しては、無駄な時間を過ごすことになるかもしれません。 SELinuxは、（理論的には）自分達が使いやすいと信じているっぽいし。。 セキュアOS=無効という図式の拡大を阻止したいです。 On Fri, 3 Aug 2007 07:40:53 +0900 "Toshiharu Harada" wrote: > 07/08/03 に Toshiharu Harada さんは書きました: > > 私の考えが正しければ、多分TOMOYO Linuxは既に勝っています。 > > 戦う相手を間違えていただけです。 > > 「作り（実装）なんかどうでも良い、問題は何ができるか」という > > できるだけ権威のある場を見つけて、そこでチュートリアルを > > 採択されると良いのです。 > > 自分でも探しますが、上記のような国際会議があれば教えて下さい。 > 場所はどこでも良いです（どこでも行きます）。 > > ELC, OLSというLinuxのメジャーの場で発表を > 行っていることは選考の際に考慮されるでしょう。 > 動画はプログラムが存在していることの証明になります。 > ポイントは、応用と見せ方（プレゼンテーション）に > なると思います。 > > -- > Toshiharu Harada > haradats ＠ gmail.com > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev -- Yuichi Nakamura Hitachi Software Engineering Co., Ltd. Japan SELinux Users Group(JSELUG): http://www.selinux.gr.jp/ SELinux Policy Editor: http://seedit.sourceforge.net/ From haradats ＠ gmail.com Fri Aug 3 08:32:29 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Fri, 3 Aug 2007 08:32:29 +0900 Subject: [Tomoyo-dev 480] Re: SELinux + TOMOYO In-Reply-To: <20070803080541.54B2.YNAKAM@hitachisoft.jp> References: <9d732d950708021526h52f9dcb4y2dc97785b59d2f48@mail.gmail.com> <9d732d950708021540u8fd3f2buf166aa6df5c72ea2@mail.gmail.com> <20070803080541.54B2.YNAKAM@hitachisoft.jp> Message-ID: <9d732d950708021632t67854154r8e8e4f055cf04ab2@mail.gmail.com> 中村さん、 tomoyo-devに入ってたんですね。(^^; 知りませんでした。 ということは、読んでいるのですね・・・。（そりゃ、そうだ） いずれにせよありがとうございました。(_ _; ELCとOLSを思えば、それ以上の難しさはありません。 検討します。 07/08/03 に Yuichi Nakamura さんは書きました: > 原田さん > > 中村です。 > 最近ROMっております。 > > 実用系で、権威がある場と言えば、 > USENIXではないでしょうか（既にご存知と思いますが） > 論文の採択率も、他学会より低いと聞きます。 > > 近いイベントだと、 > USENIXのシステム管理ですね。 > http://www.usenix.org/events/lisa07/ > 論文締め切りは8/20ですか(普通は延びるでしょうが。。） > ポスターなら間に合うかも。。 > チュートリアルもありますね。 > http://www.usenix.org/events/lisa07/cfp/training.html > > SELinuxとpath-namebased MACの議論を見てると、 > 完全に平行線ですよね。 > 確かに、 > 正面から対峙しては、無駄な時間を過ごすことになるかもしれません。 > SELinuxは、（理論的には）自分達が使いやすいと信じているっぽいし。。 > セキュアOS=無効という図式の拡大を阻止したいです。 > > > On Fri, 3 Aug 2007 07:40:53 +0900 > "Toshiharu Harada" wrote: > > > 07/08/03 に Toshiharu Harada さんは書きました: > > > 私の考えが正しければ、多分TOMOYO Linuxは既に勝っています。 > > > 戦う相手を間違えていただけです。 > > > 「作り（実装）なんかどうでも良い、問題は何ができるか」という > > > できるだけ権威のある場を見つけて、そこでチュートリアルを > > > 採択されると良いのです。 > > > > 自分でも探しますが、上記のような国際会議があれば教えて下さい。 > > 場所はどこでも良いです（どこでも行きます）。 > > > > ELC, OLSというLinuxのメジャーの場で発表を > > 行っていることは選考の際に考慮されるでしょう。 > > 動画はプログラムが存在していることの証明になります。 > > ポイントは、応用と見せ方（プレゼンテーション）に > > なると思います。 > > > > -- > > Toshiharu Harada > > haradats ＠ gmail.com > > > > _______________________________________________ > > tomoyo-dev mailing list > > tomoyo-dev ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > > -- > Yuichi Nakamura > Hitachi Software Engineering Co., Ltd. > Japan SELinux Users Group(JSELUG): http://www.selinux.gr.jp/ > SELinux Policy Editor: http://seedit.sourceforge.net/ > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -- Toshiharu Harada haradats ＠ gmail.com From ynakam ＠ hitachisoft.jp Fri Aug 3 08:40:25 2007 From: ynakam ＠ hitachisoft.jp (Yuichi Nakamura) Date: Fri, 03 Aug 2007 08:40:25 +0900 Subject: [Tomoyo-dev 481] Re: SELinux + TOMOYO In-Reply-To: <9d732d950708021632t67854154r8e8e4f055cf04ab2@mail.gmail.com> References: <20070803080541.54B2.YNAKAM@hitachisoft.jp> <9d732d950708021632t67854154r8e8e4f055cf04ab2@mail.gmail.com> Message-ID: <20070803083312.54B8.YNAKAM@hitachisoft.jp> 中村です。 On Fri, 3 Aug 2007 08:32:29 +0900 "Toshiharu Harada" wrote: > 中村さん、 > > tomoyo-devに入ってたんですね。(^^; 知りませんでした。 > > ということは、読んでいるのですね・・・。（そりゃ、そうだ） SELinuxファン & アンチSELinux & 隠れTOMOYOファン という複雑な心境ですので、 TOMOYOの状況はウォッチしております。 > いずれにせよありがとうございました。(_ _; > > ELCとOLSを思えば、それ以上の難しさはありません。 > 検討します。 頑張ってください！ あとは、学術系もいかがでしょうか(汗 IEEEとかACMがらみで、 セキュリティ関係の学会がいくつかありますよね。 知り合いの大学の先生と論文を一緒に書くとか。 学術系で、ある程度認められれば、 皆さん反論しにくくなるかと思います。 もっとも、論文書こうとすると、論文用の実験、評価が必要になりますが。。 > > 07/08/03 に Yuichi Nakamura さんは書きました: > > 原田さん > > > > 中村です。 > > 最近ROMっております。 > > > > 実用系で、権威がある場と言えば、 > > USENIXではないでしょうか（既にご存知と思いますが） > > 論文の採択率も、他学会より低いと聞きます。 > > > > 近いイベントだと、 > > USENIXのシステム管理ですね。 > > http://www.usenix.org/events/lisa07/ > > 論文締め切りは8/20ですか(普通は延びるでしょうが。。） > > ポスターなら間に合うかも。。 > > チュートリアルもありますね。 > > http://www.usenix.org/events/lisa07/cfp/training.html > > > > SELinuxとpath-namebased MACの議論を見てると、 > > 完全に平行線ですよね。 > > 確かに、 > > 正面から対峙しては、無駄な時間を過ごすことになるかもしれません。 > > SELinuxは、（理論的には）自分達が使いやすいと信じているっぽいし。。 > > セキュアOS=無効という図式の拡大を阻止したいです。 > > > > > > On Fri, 3 Aug 2007 07:40:53 +0900 > > "Toshiharu Harada" wrote: > > > > > 07/08/03 に Toshiharu Harada さんは書きました: > > > > 私の考えが正しければ、多分TOMOYO Linuxは既に勝っています。 > > > > 戦う相手を間違えていただけです。 > > > > 「作り（実装）なんかどうでも良い、問題は何ができるか」という > > > > できるだけ権威のある場を見つけて、そこでチュートリアルを > > > > 採択されると良いのです。 > > > > > > 自分でも探しますが、上記のような国際会議があれば教えて下さい。 > > > 場所はどこでも良いです（どこでも行きます）。 > > > > > > ELC, OLSというLinuxのメジャーの場で発表を > > > 行っていることは選考の際に考慮されるでしょう。 > > > 動画はプログラムが存在していることの証明になります。 > > > ポイントは、応用と見せ方（プレゼンテーション）に > > > なると思います。 > > > > > > -- > > > Toshiharu Harada > > > haradats ＠ gmail.com > > > > > > _______________________________________________ > > > tomoyo-dev mailing list > > > tomoyo-dev ＠ lists.sourceforge.jp > > > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > > > > -- > > Yuichi Nakamura > > Hitachi Software Engineering Co., Ltd. > > Japan SELinux Users Group(JSELUG): http://www.selinux.gr.jp/ > > SELinux Policy Editor: http://seedit.sourceforge.net/ > > > > _______________________________________________ > > tomoyo-dev mailing list > > tomoyo-dev ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > > > > > -- > Toshiharu Harada > haradats ＠ gmail.com > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev -- Yuichi Nakamura Hitachi Software Engineering Co., Ltd. Japan SELinux Users Group(JSELUG): http://www.selinux.gr.jp/ SELinux Policy Editor: http://seedit.sourceforge.net/ From from-tomoyo-dev ＠ i-love.sakura.ne.jp Fri Aug 3 09:29:48 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Fri, 03 Aug 2007 09:29:48 +0900 Subject: [Tomoyo-dev 482] Re: =?iso-2022-jp?b?GyRCJCQkQyQ9JE4kMyRIGyhC?= In-Reply-To: <1059.163.135.10.34.1185959262.squirrel@webmail.knlab.com> References: <9d732d950708010100y2df3d17dk99b84bbc85259fc0@mail.gmail.com><44471.163.135.10.34.1185956707.squirrel@webmail.knlab.com> <9d732d950708010158q3d28618dqdb39d859435cbb9b@mail.gmail.com> <1059.163.135.10.34.1185959262.squirrel@webmail.knlab.com> Message-ID: <200708030029.l730Tmo2036894@www262.sakura.ne.jp> 　あぁ、なんだかめまぐるしく状況が変わっているなぁ。 　今朝思ったことを書きます。 「 stable な位置づけの TOMOYO 版と development な位置づけの CCS 版に分離される」と仮定します。 　TOMOYO 版がメインラインに取り込まれた場合、 CCS 版がメインラインに取り込まれることは （ AppArmor と TOMOYO Linux の両方が取り込まれる以上に） ありえないことになるでしょう。 　TOMOYO 版がメインラインに入った後、世界中の開発者から 新機能や仕様変更の提案などを受けると思います。 それなのに、 stable だからという理由で採用を拒否するのでしょうか？ development の CCS 版で採用することはできますが、 メインラインに入っていない以上、 TOMOYO 版では不要なメンテナンスを CCS 版では行う必要があり、 不利な扱いを CCS 版が受けることにならないでしょうか？ 　stable なものを使うか development なものを使うかをディストリビュータが選び、 そのディストリビュータの方針に沿ってユーザが選ぶものだと思います。 Fedora はカーネルの 2.6.XX の部分が変化するのを恐れずに 新機能や仕様変更を頻繁に行い、 Fedora のユーザはそれを受け入れています。 Debian はカーネルの 2.6.XX の部分が変化しないように 新機能や仕様変更を行わず、 Debian のユーザはそれを受け入れています。 　stable なものにするかどうかはディストリビュータに選んでもらえばいいので、 新機能や仕様変更を受け付けないバージョンをメインラインに入れるのはどうなのかと思います。 むしろ、メインラインへ入れるのは新機能や仕様変更をどんどん受け入れられるバージョンではないでしょうか？ なんだか TOMOYO 版がメインラインに入るのを妨害してやりたいとさえ思えてしまいます。 From okajima ＠ digitalinfra.co.jp Fri Aug 3 10:34:36 2007 From: okajima ＠ digitalinfra.co.jp (Jun OKAJIMA) Date: Fri, 03 Aug 2007 10:34:36 +0900 Subject: [Tomoyo-dev 483] Re: SELinux + TOMOYO In-Reply-To: <9d732d950708021514s6a5b2b48sa80f103d859fa12c@mail.gmail.com> References: <9d732d950708021514s6a5b2b48sa80f103d859fa12c@mail.gmail.com> Message-ID: <200708030134.AA02311@bbb-jz5c7z9hn9y.digitalinfra.co.jp> > >TOMOYO Linuxは必ずしもメインラインにいれなければならない >わけではありません。TOMOYO Linuxは、既にプログラムと >パッケージが存在していて、動作します。GUIもあります。 >だから、「Linux以外のできるだけ権威や影響力のある国際会議」の >チュートリアルで、「TOMOYO Linuxでできること」を >ただ、見せれば良いのです。つまり、実装や技術論、方式ではなく、 >「できること」をアピールします。 > >それを見せても興味を持ってもらえなかったり、利用者が >増えなければそれはそれまでです。でも、そうでなければ >飛躍的に利用者が増えて、他のプラットフォームへの >導入（移植）の検討も始まるでしょう。それは十分に起こりえる >ことだと思います。その場合、「メインラインに入っていない >ことは関係ありません」。 > >本当にそうなったら、Linuxの世界や某社の考えも変わるでしょう。 > 意外な方向性に議論がすすんでいますが、 便乗してレスさせていただきます。 より、根本的な次元に目を向けたほうがいいのではないでしょうか。 なんとなくおもうのですが、 とりあえず技術研究だけを目的に作っていた → 別に実用なんてどうでもいいんですが → あれ？意外と実用になりそうだ → そうだ、実用にしよう → でも、どうやって？ いま、こんな段階ではないでしょうか。 であれば、すべきことは、ある意味、何もしないことでしょうね。 3ヶ月ぐらい、リゾートでもいって遊んでくるとか。 もし、私の勝手な推測が正しければ、大切なのは、根本的な路線を 検討しなおすことであり、ガリガリとコーディングすることではありません。 以上、部外者の勝手な推測で恐縮です。 有限会社デジタルインフラ 岡島 From nez ＠ samba.gr.jp Fri Aug 3 10:42:19 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Fri, 3 Aug 2007 10:42:19 +0900 (JST) Subject: [Tomoyo-dev 484] Re: =?iso-2022-jp?b?GyRCJCQkQyQ9JE4kMyRIGyhC?= In-Reply-To: <200708030029.l730Tmo2036894@www262.sakura.ne.jp> References: <9d732d950708010100y2df3d17dk99b84bbc85259fc0@mail.gmail.com><44471.163.135.10.34.1185956707.squirrel@webmail.knlab.com><9d732d950708010158q3d28618dqdb39d859435cbb9b@mail.gmail.com><1059.163.135.10.34.1185959262.squirrel@webmail.knlab.com> <200708030029.l730Tmo2036894@www262.sakura.ne.jp> Message-ID: <40426.163.135.10.34.1186105339.squirrel@webmail.knlab.com> 根津です。 On 2007年 8月 3日 (金) 9:29, from-tomoyo-dev ＠ i-love.sakura.ne.jp wrote: > 　あぁ、なんだかめまぐるしく状況が変わっているなぁ。 > > 　今朝思ったことを書きます。 > > 「 stable な位置づけの TOMOYO 版と development な位置づけの CCS 版に分離され > る」と仮定します。 > > 　TOMOYO 版がメインラインに取り込まれた場合、 > CCS 版がメインラインに取り込まれることは > （ AppArmor と TOMOYO Linux の両方が取り込まれる以上に） > ありえないことになるでしょう。 分離しちゃうんですか？ 私は取り込みの時期が違えこそすれ、最終的には同じものになるように する・・・くらいのつもりですが・・・。 ＃最初のうちは、FedoraとRHELの関係というよりも、CentOSとRHELの ＃関係みたいに「ほぼ同じ」コードの共有（ビルドした人が違うだけ） ＃くらいのつもりでいるんですけどｗ > 　stable なものを使うか development なものを使うかをディストリビュータが選び、 > そのディストリビュータの方針に沿ってユーザが選ぶものだと思います。 > Fedora はカーネルの 2.6.XX の部分が変化するのを恐れずに > 新機能や仕様変更を頻繁に行い、 Fedora のユーザはそれを受け入れています。 > Debian はカーネルの 2.6.XX の部分が変化しないように > 新機能や仕様変更を行わず、 Debian のユーザはそれを受け入れています。 ダウト。その考え方は間違っています。 どこが？かというと、カーネルについては、 ・開発版カーネル（2.3.x, 2.5.x、...） がディストリビューションに入ることはないし、各種のドライバや機能も SELinuxだって、AppArmerだって、PRISMドライバだってReiserFSだって ぜーんぶ「ある開発ファーム」で開発が継続しながらも「ある時点で機能 を安定させて仕様をFIXさせたもの」をカーネルのアップストリームに マージしているんですよねｗ TOMOYOはそういった、カーネル内機能の実験的開発なんですから、「常に」 新機能や変化があっては困ります。ある程度の仕様と品質の安定性の確保は *絶対*に必要です。 Fedoraがやっているのは、仕様と機能が一応安定したカーネルなどのパーツ を叩いてくみ上げて一台の自動車という製品を作ってみたら、あっちこっちに でっぱったりへこんだりの不具合があったり、組み合わせの不具合があったり するのを調整したり、調整しきれないものは切り捨てたり・・・という作業 をしているだけです。 仕様の変更は、素材となるパーツの仕様が異なるために仕方なくそうなって いるだけで決して望んでやっているものではないですし、機能の改良として 独自に変更しているものでもないはずです。 > 　stable なものにするかどうかはディストリビュータに選んでもらえばいいので、 > 新機能や仕様変更を受け付けないバージョンをメインラインに入れるのはどうなのか > と思います。 > むしろ、メインラインへ入れるのは新機能や仕様変更をどんどん受け入れられるバー > ジョンではないでしょうか？ > なんだか TOMOYO 版がメインラインに入るのを妨害してやりたいとさえ思えてしまい > ます。 なので、こんな考え方をしていたら永久にカーネルのアップストリームには マージされません。ある一定期間ごとに機能をFIXし、仕様をFIXした上で、 品質テストをある程度十分に行って、これをリリースしていくという繰り返し にならなければいけません。 ＃一人で作って一人で配って、人はかんけーないし、使ってもらうも ＃もらわないもかんけーない・・・というのでなければこれくらいは ＃やらなきゃいけない。 -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From nez ＠ samba.gr.jp Fri Aug 3 10:27:40 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Fri, 3 Aug 2007 10:27:40 +0900 (JST) Subject: [Tomoyo-dev 485] Re: SELinux + TOMOYO In-Reply-To: <9d732d950708021514s6a5b2b48sa80f103d859fa12c@mail.gmail.com> References: <200708020422.AA02309@bbb-jz5c7z9hn9y.digitalinfra.co.jp> <9d732d950708021514s6a5b2b48sa80f103d859fa12c@mail.gmail.com> Message-ID: <60528.163.135.10.34.1186104460.squirrel@webmail.knlab.com> 根津です。 On 2007年 8月 3日 (金) 7:14, Toshiharu Harada wrote: > 原田です。おはようございます。 > > すごいことに気がついてしまいました。 ｗｗｗ これを行うためには、「Linuxへの実装は、モデルの実装実験である」と いう形で、SELinuxみたいな立場をとらないといけないですねｗ > TOMOYO Linuxは必ずしもメインラインにいれなければならない > わけではありません。TOMOYO Linuxは、既にプログラムと > パッケージが存在していて、動作します。GUIもあります。 > だから、「Linux以外のできるだけ権威や影響力のある国際会議」の > チュートリアルで、「TOMOYO Linuxでできること」を > ただ、見せれば良いのです。つまり、実装や技術論、方式ではなく、 > 「できること」をアピールします。 できること・・・には、何らかの開発意図があり、それについて 検討が可能である必要が多分あると思います。 ＃セキュアだね・・・うん、感覚的には正しいからきっと正しいヨ ＃だとなかなかセキュリティの世界的には広がりにくいと思います。 ＃AppArmerが一番失敗しているところで、力で押し通すのに巨額の ＃費用をかけてますよね。TOMOYOでそれは無茶です。 > それを見せても興味を持ってもらえなかったり、利用者が > 増えなければそれはそれまでです。でも、そうでなければ > 飛躍的に利用者が増えて、他のプラットフォームへの > 導入（移植）の検討も始まるでしょう。それは十分に起こりえる > ことだと思います。その場合、「メインラインに入っていない > ことは関係ありません」。 > > 本当にそうなったら、Linuxの世界や某社の考えも変わるでしょう。 まぁ、やっぱり実装はあくまでも「実験的なもの」だと私は個人的には 思うので、そこから抽象化された理論を見つけ出したいと考え始めている 今日この頃だったりします・・・ｗ -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From from-tomoyo-dev ＠ i-love.sakura.ne.jp Fri Aug 3 13:20:34 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Fri, 03 Aug 2007 13:20:34 +0900 Subject: [Tomoyo-dev 486] Re: =?iso-2022-jp?b?GyRCJCQkQyQ9JE4kMyRIGyhC?= In-Reply-To: <40426.163.135.10.34.1186105339.squirrel@webmail.knlab.com> References: <9d732d950708010100y2df3d17dk99b84bbc85259fc0@mail.gmail.com><44471.163.135.10.34.1185956707.squirrel@webmail.knlab.com><9d732d950708010158q3d28618dqdb39d859435cbb9b@mail.gmail.com><1059.163.135.10.34.1185959262.squirrel@webmail.knlab.com> <200708030029.l730Tmo2036894@www262.sakura.ne.jp> <40426.163.135.10.34.1186105339.squirrel@webmail.knlab.com> Message-ID: <200708030420.l734KYaO083353@www262.sakura.ne.jp> > ・開発版カーネル（2.3.x, 2.5.x、...） > > がディストリビューションに入ることはないし、各種のドライバや機能も > SELinuxだって、AppArmerだって、PRISMドライバだってReiserFSだって > ぜーんぶ「ある開発ファーム」で開発が継続しながらも「ある時点で機能 > を安定させて仕様をFIXさせたもの」をカーネルのアップストリームに > マージしているんですよねｗ TOMOYO 版も CCS 版も「開発ファーム」での開発をしながら 「ある時点で機能を安定させて仕様をFIXさせたもの」をリリースするものだと思います。 > なので、こんな考え方をしていたら永久にカーネルのアップストリームには > マージされません。ある一定期間ごとに機能をFIXし、仕様をFIXした上で、 > 品質テストをある程度十分に行って、これをリリースしていくという繰り返し > にならなければいけません。 stable と development という表現が良くなかったですね。 TOMOYO 版も CCS 版も「ある時点で機能を安定させて仕様をFIXさせたもの」をマージします。 ただ、 TOMOYO 版が RHEL のように「ある時点で機能を安定させて仕様をFIXさせたもの」を何年間も使い続けるバージョン、 CCS 版が Fedora のように「ある時点で機能を安定させて仕様をFIXさせたもの」を半年くらい使うバージョン という位置づけになってしまうと、何年間も新機能がメインラインに取り込まれないようになってしまうことを心配しました。 From nez ＠ samba.gr.jp Fri Aug 3 14:01:26 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Fri, 3 Aug 2007 14:01:26 +0900 (JST) Subject: [Tomoyo-dev 487] Re: =?iso-2022-jp?b?GyRCJCQkQyQ9JE4kMyRIGyhC?= In-Reply-To: <200708030420.l734KYaO083353@www262.sakura.ne.jp> References: <9d732d950708010100y2df3d17dk99b84bbc85259fc0@mail.gmail.com><44471.163.135.10.34.1185956707.squirrel@webmail.knlab.com><9d732d950708010158q3d28618dqdb39d859435cbb9b@mail.gmail.com><1059.163.135.10.34.1185959262.squirrel@webmail.knlab.com><200708030029.l730Tmo2036894@www262.sakura.ne.jp><40426.163.135.10.34.1186105339.squirrel@webmail.knlab.com> <200708030420.l734KYaO083353@www262.sakura.ne.jp> Message-ID: <32197.163.135.10.34.1186117286.squirrel@webmail.knlab.com> 根津です。 On 2007年 8月 3日 (金) 13:20, from-tomoyo-dev ＠ i-love.sakura.ne.jp wrote: > TOMOYO 版も CCS 版も「ある時点で機能を安定させて仕様をFIXさせたもの」をマー > ジします。 > ただ、 TOMOYO 版が RHEL のように「ある時点で機能を安定させて仕様をFIXさせた > もの」を何年間も使い続けるバージョン、 > CCS 版が Fedora のように「ある時点で機能を安定させて仕様をFIXさせたもの」を > 半年くらい使うバージョン > という位置づけになってしまうと、何年間も新機能がメインラインに取り込まれない > ようになってしまうことを心配しました。 大丈夫でしょう。そこはそれGPLなオープンソースのプラットホームですから、 たとえ、TOMOYOがメインラインに取り込まれて、それがずーーーーっと固定 されてたら、（上記の例をそのまま踏襲しますが）CCS版から誰かがアップ ストリーム用のパッチを作ってそれを投げ込み、それが「TOMOYO」として メインラインに取り込まれていくだけでしょ？ ＃だから結局、成長に微々たる差がでても、結局、一卵性双生児になるんだと ＃思うんですが・・・。 ＃それとも、CCSな世界で一卵性双生児は許されない（ぁゃしぃ・・・。 ＃どーゆーいみだ？）かんけーでしょうか？＞熊猫せんせい -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From haradats ＠ gmail.com Fri Aug 3 14:46:49 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Fri, 3 Aug 2007 14:46:49 +0900 Subject: [Tomoyo-dev 488] Re: SELinux + TOMOYO In-Reply-To: <200708030134.AA02311@bbb-jz5c7z9hn9y.digitalinfra.co.jp> References: <9d732d950708021514s6a5b2b48sa80f103d859fa12c@mail.gmail.com> <200708030134.AA02311@bbb-jz5c7z9hn9y.digitalinfra.co.jp> Message-ID: <9d732d950708022246n710f36cs2db46ecfc0e0e50c@mail.gmail.com> 岡島さん、 07/08/03 に Jun OKAJIMA さんは書きました: > 意外な方向性に議論がすすんでいますが、 > 便乗してレスさせていただきます。 > > より、根本的な次元に目を向けたほうがいいのではないでしょうか。 > なんとなくおもうのですが、 > > とりあえず技術研究だけを目的に作っていた → > 別に実用なんてどうでもいいんですが → > あれ？意外と実用になりそうだ → > そうだ、実用にしよう → > でも、どうやって？ > > いま、こんな段階ではないでしょうか。 > > であれば、すべきことは、ある意味、何もしないことでしょうね。 > 3ヶ月ぐらい、リゾートでもいって遊んでくるとか。 > もし、私の勝手な推測が正しければ、大切なのは、根本的な路線を > 検討しなおすことであり、ガリガリとコーディングすることではありません。 大変当を得た指摘だと思います。 上で書かれている根本的な路線の検討とはプロジェクトの目標の設定とも 言えますね。やらなければならない作業や課題は存在していますし、 プロジェクトのリソースが有限なのも事実ですが、 それらに振り回されていては仕方ありません。 今日午前中、データにいる4名でずっと打ち合わせをしていました。 止める必要のない作業は止めませんが、私自身は 今後極力個別論や開発に関する議論に参加せず、全体の目標や 根本的な路線の検討に注力し、それを推進していこうと 思います。午前中行った議論の結果については、半田さんと 武田君から報告があります。 -- Toshiharu Harada haradats ＠ gmail.com From haradats ＠ gmail.com Fri Aug 3 15:10:05 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Fri, 3 Aug 2007 15:10:05 +0900 Subject: [Tomoyo-dev 489] Re: SELinux + TOMOYO In-Reply-To: <60528.163.135.10.34.1186104460.squirrel@webmail.knlab.com> References: <200708020422.AA02309@bbb-jz5c7z9hn9y.digitalinfra.co.jp> <9d732d950708021514s6a5b2b48sa80f103d859fa12c@mail.gmail.com> <60528.163.135.10.34.1186104460.squirrel@webmail.knlab.com> Message-ID: <9d732d950708022310g309eec74s33eb9453745d66d6@mail.gmail.com> 原田です。 まもなく外出するのですが、このメールだけリプライしておきます。 07/08/03 に Kensuke Nezu さんは書きました: > 根津です。 > > On 2007年 8月 3日 (金) 7:14, Toshiharu Harada wrote: > > 原田です。おはようございます。 > > > > すごいことに気がついてしまいました。 > > ｗｗｗ 笑われてしまいましたね。 > これを行うためには、「Linuxへの実装は、モデルの実装実験である」と > いう形で、SELinuxみたいな立場をとらないといけないですねｗ 言いたかったことをちょっと補足させてもらうと、 TOMOYO Linuxの「強み」は、「使いやすいこと」、 「今、使えること」だと思っています。 ところが、その強みはSELinux陣営に対しては、あまり意味が ありません。最大の強みが強みとなっておらず、その他の 「弱み」あるいは「ハンデ」の部分で苦戦しています。 目標についてはこの後明確にしますが、いずれにしても 強みは強みとして活かします。 > > TOMOYO Linuxは必ずしもメインラインにいれなければならない > > わけではありません。TOMOYO Linuxは、既にプログラムと > > パッケージが存在していて、動作します。GUIもあります。 > > だから、「Linux以外のできるだけ権威や影響力のある国際会議」の > > チュートリアルで、「TOMOYO Linuxでできること」を > > ただ、見せれば良いのです。つまり、実装や技術論、方式ではなく、 > > 「できること」をアピールします。 > > できること・・・には、何らかの開発意図があり、それについて > 検討が可能である必要が多分あると思います。 突拍子のないことを言い出した、と受け取られた方が多いかも しれませんが、実は私の中ではそうではありません。説明します。 私の目標は、 ・TOMOYO Linuxの開発成果や利点をLinux全体に還元し、 　セキュリティ強化を含めて世界で活用してもらうこと ・NTTデータとして開発した成果を活用し、ビジネスとして 　NTTデータの事業に還元すること であり、メインライン化はそれを実現する上での不可欠な ステップという認識でした。「開発」という観点からは マイルストーンです。メインラインに入らない状態で、 世界中で使われる状況は想像できないでいましたが、 メインライン化されてからの道のりも見えておらず、 その意味で、計画的ではありませんでした。 メインライン化も使えることのアピールも手段ですが、 今一度目的設定、本当に目指すべきものに立ち返り、 個別の取り組みも見直します。（3ヶ月のバケーションには 行きませんが） > ＃セキュアだね・・・うん、感覚的には正しいからきっと正しいヨ > ＃だとなかなかセキュリティの世界的には広がりにくいと思います。 > ＃AppArmerが一番失敗しているところで、力で押し通すのに巨額の > ＃費用をかけてますよね。TOMOYOでそれは無茶です。 データがディストロを興せば同じような状況になりますが、 それは無茶というか無理（不可能）です。 王道としては、「セキュリティはかくあるべし」でFlaskなり 理論に基づいて、証明することですが、実際のところ 理論や証明から始まっていないわけです。（難しいなぁ） > > それを見せても興味を持ってもらえなかったり、利用者が > > 増えなければそれはそれまでです。でも、そうでなければ > > 飛躍的に利用者が増えて、他のプラットフォームへの > > 導入（移植）の検討も始まるでしょう。それは十分に起こりえる > > ことだと思います。その場合、「メインラインに入っていない > > ことは関係ありません」。 > > > > 本当にそうなったら、Linuxの世界や某社の考えも変わるでしょう。 > > まぁ、やっぱり実装はあくまでも「実験的なもの」だと私は個人的には > 思うので、そこから抽象化された理論を見つけ出したいと考え始めている > 今日この頃だったりします・・・ｗ 仮にメインラインに取り込まれたとして、そのままの形では はいらないでしょう。中村さんのSEEditがそうであったように、 大きく変わると思います。それによって、初めて実装が検証され、 コードが良くなり、コミュニティによる進化の道が開けるわけです。 実はSF.jpで公開した目的のひとつはその検証でしたが、国内だけでは それは期待できない、その意味でもメインラインは意味があります。 -- Toshiharu Harada haradats ＠ gmail.com From k.takeda26 ＠ gmail.com Fri Aug 3 23:04:51 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Fri, 3 Aug 2007 23:04:51 +0900 Subject: [Tomoyo-dev 490] =?iso-2022-jp?b?GyRCJDMkThsoQjEbJEI9NTRWJF4kSCRhGyhC?= Message-ID: <5fb14edc0708030704y12c459a4x533e841f3841bf6b@mail.gmail.com> たけだです。 今日午前中に、原田さん、半田さん、平坂さん、武田で 話し合った結果をご報告します。 結論からいうと、フォークしません。 先週の開発会議終了後の状態にほぼ戻った、という認識で間違いありません。 ご心配をおかけしました。m(_ _)m /etcや/procの問題は、1系はccs、2系はtomoyoでいきます。 ツールが2系統になってしまいますが、そもそもが1系と2系では 機能も違うのでツールも違っていいのではないかと思います。 大きな変更ではないですし。 1系はポリシーローダなどを直した版を1.5としてリリースし、 それを「長期サポートバージョン」として明言します。 2系は1系の機能移植とLSMそのものの拡張、コードのクリーンアップを 目下の開発とします。目指すところはメインラインです。 いずれにせよ、1系、2系ともども共同開発者の方々と議論しながら 開発を進めていきます。（この点が開発会議前後での最大の違いですね） SourceForge.jpとは別に、開発コミュニティの外部サーバで 最新版のソースコードやバイナリパッケージを配布していこう、 という点も開発会議終了後の状況と同じです。 今までどおり、1系の主開発者は半田さん、2系の主開発者は武田、 GUIの主開発者は平坂さんですし、プロジェクトマネージャは原田さんです。 ただし、開発に関する個別の議論については原田さんではなく、 武田が主体で進めていこうと思います。 1週間たって元の鞘に戻った、という感じですが、 各人言いたいことを言って、必要な時間だったのではないかと考えます。 tomoyo-devに投げている人、ROMっている人、立場はさまざまでしょうが、 引き続き、皆さんのためのTOMOYO Linuxでありますよう…ご愛顧ください。 以上、たけだがお送りしました。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Fri Aug 3 23:27:20 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Fri, 3 Aug 2007 23:27:20 +0900 Subject: [Tomoyo-dev 491] Re: path-based MAC In-Reply-To: <9d732d950708021602o62bb1652x3f1af5316afdefe6@mail.gmail.com> References: <9d732d950707301518l7ed2c53cp3692d37320901b3d@mail.gmail.com> <9d732d950708021602o62bb1652x3f1af5316afdefe6@mail.gmail.com> Message-ID: <200708032327.GDB14057.EWUtPZNPPPFGtNS@I-love.SAKURA.ne.jp> 　熊猫です。 > 半田さんか武田君で素材を作ってもらえませんか？ > 原田が書いたコメントの内容を裏付けするようなもので > あれば、ディストロ等は問いません。シンプルなのが > 望ましいです。 メモ書きですが http://tomoyo.sourceforge.jp/wiki/?path-vs-label に置きました。 ハードリンクとその他の操作を組み合わせて /etc/shadow から shadow_t を奪う方法もあります。 この中に、私の考えなのですが 「パス名ベースのアクセス制御対ラベルベースのアクセス制御の論争の原因は、 ラベルベースのアクセス制御では、期待したとおりのパス名が割り当てられていることを保証できないパス名を 信用するのは危険であり、ラベルだけしか信用できる情報が無いと考えているのに対し、 パス名ベースのアクセス制御では、期待したとおりのラベルが割り当てられていることを保証できないラベルだけを 信用するのは危険であり、パス名も要素に含めるべきだと考えていることにあると考える。」 という部分を入れてみました。これは、このメモを書きながら感じたことです。 実際、 TOMOYO Linux はパス名ベースのアクセス制御ですが、 if 節と組み合わせることで （ uid などの標準で取得できる属性だけですが）ラベルに相当する情報も加味したアクセス制御を行うこともできます。 ＬＫＭＬ等での議論を読んでいると、パス名ベースのアクセス制御ではパス名以外の情報を加味してはいけないかのような 思い込みがあるように感じました。でも、実際には 「パス名ベースのアクセス制御がラベルベースのアクセス制御の一部を取り込むことを否定や禁止するものではないように、 ラベルベースのアクセス制御がパス名ベースのアクセス制御の一部を取り込むことを否定や禁止するものでもない。」ものだと 思うのです。 From okajima ＠ digitalinfra.co.jp Sat Aug 4 11:16:00 2007 From: okajima ＠ digitalinfra.co.jp (Jun OKAJIMA) Date: Sat, 04 Aug 2007 11:16:00 +0900 Subject: [Tomoyo-dev 492] Re: SELinux + TOMOYO In-Reply-To: <9d732d950708022246n710f36cs2db46ecfc0e0e50c@mail.gmail.com> References: <9d732d950708022246n710f36cs2db46ecfc0e0e50c@mail.gmail.com> Message-ID: <200708040216.AA02312@bbb-jz5c7z9hn9y.digitalinfra.co.jp> > >私自身は >今後極力個別論や開発に関する議論に参加せず、全体の目標や >根本的な路線の検討に注力し、それを推進していこうと >思います。 > まったくハズしていたわけではなさそうなので、 悪乗りして追加でレスさせていただきます。 今の状況は、 「実用指向のセキュアOSの研究」 で始めたプロジェクトが、 その目的が一応成功した（のですよね？）こともあり、 なぜか、突然、 「実用セキュアOSの開発」に変わってしまっている ところにあると思います。 この二つ、字は似てますが、まったく違うんですよね・・・。 前者であれば、最終的には、学会での受賞などが評価基準になりますので、 学会ウケ、大学教授ウケ「のみ」を考えて作ればいいのですが、 後者は、そんなんじゃダメですよ。象牙の塔の研究者（失礼！）にいくらウケてもだめです。 考えなければいけないのは、 - RH社ウケ - マスコミウケ - コミュニティウケ - 現場ウケ - 顧客ウケ （この場合の顧客とは、ようは、CGIサーバを発注するEC業者、など） こんなところになりますし、 現場ウケ、顧客ウケ、ともなると、業種によりまったく発想が違うんですよ。 グーグルのような技術指向の会社が言ってくることと、 広告代理店系のような会社が言うことはまったく違いますし、 Webデザイン系の人、既存通販事業者、、、もうまったく違いますよ。 マスコミだって、 - 一般紙 - 技術誌 - そのほか そのような違いだけでも、求められる方向性はまったく違います。 ソフトウェアデザイン誌と日経産業新聞におなじプレスリリースを送ってもダメです。 で、とにかく、結論としてすべきことは、 このあたりの方向転換を念頭に、じっくりゼロから練り直す、ということでしょうね。 それこそ、サバティカル（というのが原田様の会社にあれば）でも取って、 三ヶ月ぐらい遊んできたら？とおもいます。 なお、思いつきの案ですが、Ruby On Rails 作戦はどうでしょうか。 あれがウケた理由のひとつが、あの衝撃的なデモムービーがあったと思います。 本当にこんなにうまく行くわけないよな、と分かってはいても、 あはり、あれを見せられると、 じゃ、一冊ぐらい本でも買うか、一度ぐらいセミナーでも行くか、 という気分にはなります。 で、それをさらに発展させた作戦がこれ。 「ハッタリムービー」。 さすがに、原田様の会社名で行うのはまずいですが、 なぞのハッカー「はらだっち」などの、適当な名義で、 ハッタリムービーを作るんですよ。 既存RHELサーバにインストールするだけで、 いきなり3分でセキュリティ問題がすべて解決してしまうとか、 そんなあまりに都合がよすぎる内容。 これを、たとえば Youtubeなどに掲載。 ポイントは、このムービーは、実際には単なるハッタリであって、 どこにも「実際に動く」とは明示されていないですし、 タイトルも、あくまで「デモムービー」とかにしてあるのですが、 しかし、タイトルを読まず、映像だけ見ると、 一見、実際に動いていると勘違いしそうな内容にするんですよ。 これで、勘違いして問い合わせてくる人が相次ぐようなら、 （当然、その場合は、ハッタリです、と正直に答える）、 その方向性は正解だと思います。 別の言い方をすれば、 （中身は実在しないが）ウケるムービーを作り、 反響を確かめてから、 それにあわせて中身を作れば、かなりの率でヒットすると思います。 一番笑える展開はこんなのでしょうね。 原田さんの上長が勘違いしてくれて・・・ 「原田くん、これ、すごいね。すぐリリースしよう」 「本当にすごいと思いますか？」 「すごいよ、これは。絶対に売れるよ。すぐリリースしよう」 「あのぉ。。。・・・これ、デモですけど・・・」 「でも、予算と人員さえ頂ければ、すぐにでも完成できますよ」 「絶対に売れる、と先ほどいいましたよね。なら予算いただけますよね？」 以上、長文駄文、恐縮です。 有限会社デジタルインフラ 岡島 From from-tomoyo-dev ＠ i-love.sakura.ne.jp Mon Aug 6 13:53:23 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Mon, 06 Aug 2007 13:53:23 +0900 Subject: [Tomoyo-dev 493] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <200708020658.l726wn7g015179@www262.sakura.ne.jp> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <9d732d950707301536ib067596v7509cd8c95969267@mail.gmail.com> <53275.163.135.10.34.1185849256.squirrel@webmail.knlab.com> <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <46B17897.5090500@nttdata.co.jp> <200708020658.l726wn7g015179@www262.sakura.ne.jp> Message-ID: <200708060453.l764rNhU085090@www262.sakura.ne.jp> 　熊猫です。 > 　カーネルのコマンドラインに init=/.init を指定しないで済むようにする方法としては、 > fs/ccs_common.c の CCS_LoadPolicy() の中を > > struct nameidata nd; > char *argv[2], *envp[3]; > if (!ccs_loader) ccs_loader = "ポリシーローダのパス名（現状では /.init）"; > if (path_lookup(ccs_loader, lookup_flags, &nd)) { > printk("Not activating Mandatory Access Control now since %s doesn't exist.\n", ccs_loader); > return; > } > path_release(&nd); > argv[0] = ccs_loader; > argv[1] = NULL; > envp[0] = "HOME=/"; > envp[1] = "PATH=/sbin:/bin:/usr/sbin:/usr/bin"; > envp[2] = NULL; > call_usermodehelper(argv[0], argv, envp, 1); > > みたいな感じに修正して call_usermodehelper() を呼び出し、 > ポリシーローダの終了を待ってから先に進むという方法が考えられます。 > この方法で問題なく動くかどうかは確認が必要です。 call_usermodehelper() によるポリシーローダー（ /sbin/.init ）の呼び出しは 標準入出力（ /dev/console ）が繋がっていないので TOMOYO Linux: Enter 'disabled' within $TMOUT seconds to disable TOMOYO Linux. TOMOYO Linux> というプロンプトを表示したり disabled と入力したりすることができませんでしたが、 その代わり grub.conf に init=/sbin/.init を追加する必要を無くすことができます。 call_usermodehelper() に /sbin/.init を実行させると動作上の問題が生じる 環境の場合には明示的に init=/sbin/.init を指定することで対処できると思います。 　バイナリパッケージでのインストールを行う際に grub.conf を操作するための記述が不要になるという利点がありますので、 init=/sbin/.init が指定されなかった場合には /sbin/init の起動直前に call_usermodehelper() で /sbin/.init を実行するという 仕様に変更するのは如何でしょうか？ From k.takeda26 ＠ gmail.com Mon Aug 6 14:46:46 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Mon, 6 Aug 2007 14:46:46 +0900 Subject: [Tomoyo-dev 494] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <200708060453.l764rNhU085090@www262.sakura.ne.jp> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <9d732d950707301536ib067596v7509cd8c95969267@mail.gmail.com> <53275.163.135.10.34.1185849256.squirrel@webmail.knlab.com> <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <46B17897.5090500@nttdata.co.jp> <200708020658.l726wn7g015179@www262.sakura.ne.jp> <200708060453.l764rNhU085090@www262.sakura.ne.jp> Message-ID: <5fb14edc0708052246q59551db4y55f51b5dd4df15ec@mail.gmail.com> たけだです。 grub.confの設定がいらないようにぜひすべきだと思います。 yum install tomoyolinuxでカーネル・ツールから基本設定まで、 全部使える状態で入る（かつ、それが通常のLinuxの文化から 見て妥当な入り方である）のが1.5で目指す形だと思います。 > というプロンプトを表示したり disabled と入力したりすることができませんでしたが、 TOMOYOを無効にしたいなら、通常のカーネルで起動するか、 アクセス制御を無効にするカーネルコマンドラインオプションを 用意しておけばよいと思います。（すでにありましたっけ？？） ポリシーローダの名前は、 （1系）/sbin/ccs-init （2系）/sbin/tomoyo-init くらいですかね。 From nez ＠ samba.gr.jp Mon Aug 6 14:34:34 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Mon, 6 Aug 2007 14:34:34 +0900 (JST) Subject: [Tomoyo-dev 495] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <200708060453.l764rNhU085090@www262.sakura.ne.jp> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <9d732d950707301536ib067596v7509cd8c95969267@mail.gmail.com> <53275.163.135.10.34.1185849256.squirrel@webmail.knlab.com> <46AEA4C4.2000600@gmail.com><46AEA626.8030307@nttdata.co.jp><200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp><46B17897.5090500@nttdata.co.jp><200708020658.l726wn7g015179@www262.sakura.ne.jp> <200708060453.l764rNhU085090@www262.sakura.ne.jp> Message-ID: <23170.163.135.10.35.1186378474.squirrel@webmail.knlab.com> 根津です。 On 2007年 8月 6日 (月) 13:53, from-tomoyo-dev ＠ i-love.sakura.ne.jp wrote: > call_usermodehelper() によるポリシーローダー（ /sbin/.init ）の呼び出しは > 標準入出力（ /dev/console ）が繋がっていないので > > TOMOYO Linux: Enter 'disabled' within $TMOUT seconds to disable TOMOYO > Linux. > TOMOYO Linux> > > というプロンプトを表示したり disabled と入力したりすることができませんでした > が、 > その代わり grub.conf に init=/sbin/.init を追加する必要を無くすことができま > す。 > call_usermodehelper() に /sbin/.init を実行させると動作上の問題が生じる > 環境の場合には明示的に init=/sbin/.init を指定することで対処できると思います。 > > 　バイナリパッケージでのインストールを行う際に > grub.conf を操作するための記述が不要になるという利点がありますので、 > init=/sbin/.init が指定されなかった場合には > /sbin/init の起動直前に call_usermodehelper() で /sbin/.init を実行するとい > う > 仕様に変更するのは如何でしょうか？ その方向でいいと思います。 ただし、どの時点で（2.0で？それとも1.5の整理で？）かは別として、ファイル名 が.initなのはいただけない気がします。 ＃他の今後出てくるかもしれない機能やパッケージと衝突しそうです。 -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Mon Aug 6 22:46:05 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Mon, 6 Aug 2007 22:46:05 +0900 Subject: [Tomoyo-dev 496] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <5fb14edc0708052246q59551db4y55f51b5dd4df15ec@mail.gmail.com> References: <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp><46B17897.5090500@nttdata.co.jp><200708020658.l726wn7g015179@www262.sakura.ne.jp><200708060453.l764rNhU085090@www262.sakura.ne.jp><5fb14edc0708052246q59551db4y55f51b5dd4df15ec@mail.gmail.com> Message-ID: <200708062246.BCF88234.PNPEPPNFWSZUGtt@I-love.SAKURA.ne.jp> 　熊猫です。 > ポリシーローダの名前は、 > （1系）/sbin/ccs-init > （2系）/sbin/tomoyo-init > くらいですかね。 　とりあえず /sbin/ccs-init として subversion に反映しました。 カーネル 2.4 では call_usermodehelper() がプログラムの終了を待ってくれないので、 /proc/ccs/info/meminfo にアクセスされたらポリシーのロードが完了したものとみなすように修正しました。 そのため、 /sbin/ccs-init は (1) 先に /proc/ccs/ ディレクトリ以下にポリシーを書き込む (2) 最後に /proc/ccs/info/meminfo にアクセスすることでポリシーのロードが完了したことを通知する という２つの要件を満たす必要があります。 開発会議では trunk/パッケージ名/バージョン/ の順でディレクトリを切ろうと思っていましたが、 ccs-patch ccs-tools htdocs は３つで１セットなので trunk/バージョン/パッケージ名/ で切ることにしました。 http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/?root=tomoyo From haradats ＠ gmail.com Mon Aug 6 23:24:24 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Mon, 6 Aug 2007 23:24:24 +0900 Subject: [Tomoyo-dev 497] Re: =?iso-2022-jp?b?U1ZOGyRCJTMlXyVDJUglYSE8JWtNUSROGyhCbWw=?= =?iso-2022-jp?b?GyRCJHI6bkAuJDckXiQ3JD8bKEI=?= In-Reply-To: <46AEAFAF.6040905@nttdata.co.jp> References: <9d732d950707271518t21feb5d3u2fde1020bd372d86@mail.gmail.com> <46AEAFAF.6040905@nttdata.co.jp> Message-ID: <9d732d950708060724q4b3276b7jf31f36642e93423f@mail.gmail.com> コミットメールで、パッチを本文に含むという設定にしていましたが、 本文の長さ制限(40KB)によりパッチのメールがエラーになるという事象が 何度か発生しています。長さ制限の上限の変更箇所を見つけられなかったので、 パッチを添付するという設定にしてみました。 07/07/31 に Toshiharu Harada さんは書きました: > 読み方は個人毎にmlで設定できます。私は試しに > まとめ読みにしてみましたが、そうすると日本語が > 化けてしまうようです。 > > 下記にあるグローバルな設定の変更は要望があれば > 随時お知らせ下さいませ。 > > Toshiharu Harada さんは書きました: > > 原田です。 > > > > SF.jpがいつのまにかsubversionのコミットメールlに対応していました。 > > コミットメール送付用のmlを作成したので、受け取りたい方は > > 下記より購読下さい。 > > > > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-svn > > > > コミットメールは、 > > ・Subject prefix: "TOMOYO svn commit" > > ・From: svnnotify ＠ sourceforge.jp > > ・Diff: 本文に展開 > > > > で送信される設定としています。 -- Toshiharu Harada haradats ＠ gmail.com From matthew0115 ＠ gmail.com Tue Aug 7 08:29:35 2007 From: matthew0115 ＠ gmail.com (matthew.szulik@gmail.com) Date: Tue, 07 Aug 2007 08:29:35 +0900 Subject: [Tomoyo-dev 498] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <200708062246.BCF88234.PNPEPPNFWSZUGtt@I-love.SAKURA.ne.jp> References: <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp><46B17897.5090500@nttdata.co.jp><200708020658.l726wn7g015179@www262.sakura.ne.jp><200708060453.l764rNhU085090@www262.sakura.ne.jp><5fb14edc0708052246q59551db4y55f51b5dd4df15ec@mail.gmail.com> <200708062246.BCF88234.PNPEPPNFWSZUGtt@I-love.SAKURA.ne.jp> Message-ID: <46B7AEDF.7020004@gmail.com> 秋元です。 Tetsuo Handa さんは書きました: > 　熊猫です。 > >> ポリシーローダの名前は、 >> （1系）/sbin/ccs-init >> （2系）/sbin/tomoyo-init >> くらいですかね。 > > 　とりあえず /sbin/ccs-init として subversion に反映しました。 tomoyo-svnを取り寄せていますが、HTMLファイルの中の漢字コードがshift-jis のようなのですが、もしそうだとしたら何か理由があるんですか？ From from-tomoyo-dev ＠ i-love.sakura.ne.jp Tue Aug 7 09:02:50 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Tue, 07 Aug 2007 09:02:50 +0900 Subject: [Tomoyo-dev 499] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <46B7AEDF.7020004@gmail.com> References: <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp><46B17897.5090500@nttdata.co.jp><200708020658.l726wn7g015179@www262.sakura.ne.jp><200708060453.l764rNhU085090@www262.sakura.ne.jp><5fb14edc0708052246q59551db4y55f51b5dd4df15ec@mail.gmail.com> <200708062246.BCF88234.PNPEPPNFWSZUGtt@I-love.SAKURA.ne.jp> <46B7AEDF.7020004@gmail.com> Message-ID: <200708070002.l7702opM037048@www262.sakura.ne.jp> 　熊猫です。 > tomoyo-svnを取り寄せていますが、HTMLファイルの中の漢字コードがshift-jis > のようなのですが、もしそうだとしたら何か理由があるんですか？ Windows + 秀丸で編集しているからです。 他のコードの方が好都合ですか？ ＃ UTF-8 だと Winbiff で読めないというのもあります。 From k.takeda26 ＠ gmail.com Tue Aug 7 09:18:33 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Tue, 7 Aug 2007 09:18:33 +0900 Subject: [Tomoyo-dev 500] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <46B17897.5090500@nttdata.co.jp> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <9d732d950707301536ib067596v7509cd8c95969267@mail.gmail.com> <53275.163.135.10.34.1185849256.squirrel@webmail.knlab.com> <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <46B17897.5090500@nttdata.co.jp> Message-ID: <5fb14edc0708061718s754021c5l903a94b62e833db5@mail.gmail.com> たけだです。 ポリシーローダ以外のツールの配置案を2つ提案します。 tomoyo-devの皆さんのご意見をお聞かせください。 【案1：用途ごとにディレクトリを分ける】 現在あるツールは、以下の4種類くらいに分類でき、 その分類ごとに置く場所を以下のようにする案。 /usr/sbinや/usr/binに置くものにはプレフィックス{ccs-,tmy-}をつける。 ■初期設定ツール：init_policy.sh make_alias.sh, make_allow_read.sh, make_exception.sh, make_file_pattern.sh, makesyaoranconf /usr/sbin ■TOMOYOの設定のコアツール：editpolicy, editpolicy_offline, loadpolicy, savepolicy, setlevel, setprofile, ccs-auditd, ccs-queryd, ld-watch /usr/sbin ■その他便利ツール：ccstree, checkpolicy, domainmatch, findtemp, pathmatch, patternize, realpath, sortpolicy /usr/binか/usr/sbin ■サンプル実装：candy, chaplet, checktoken, gettoken, groovy, honey, mailauth, timeauth, falsh, proxy /usr/lib/{ccs,tomoyo}、もしくは同梱しない。 【案2：1箇所にまとめる】 FHSによると、/usr/libにサブディレクトリを作るのがOKなようなので、 /usr/lib/{ccs,tomoyo}にまとめて置くという案。 http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA From nez ＠ samba.gr.jp Tue Aug 7 14:46:50 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Tue, 7 Aug 2007 14:46:50 +0900 (JST) Subject: [Tomoyo-dev 501] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <5fb14edc0708061718s754021c5l903a94b62e833db5@mail.gmail.com> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com><9d732d950707301536ib067596v7509cd8c95969267@mail.gmail.com><53275.163.135.10.34.1185849256.squirrel@webmail.knlab.com><46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp><200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp><46B17897.5090500@nttdata.co.jp> <5fb14edc0708061718s754021c5l903a94b62e833db5@mail.gmail.com> Message-ID: <55301.163.135.10.34.1186465610.squirrel@webmail.knlab.com> 根津です。 On 2007年 8月 7日 (火) 9:18, Kentaro Takeda wrote: > たけだです。 > > ポリシーローダ以外のツールの配置案を2つ提案します。 > tomoyo-devの皆さんのご意見をお聞かせください。 > > 【案1：用途ごとにディレクトリを分ける】 > 現在あるツールは、以下の4種類くらいに分類でき、 > その分類ごとに置く場所を以下のようにする案。 > /usr/sbinや/usr/binに置くものにはプレフィックス{ccs-,tmy-}をつける。 > > ■初期設定ツール：init_policy.sh make_alias.sh, make_allow_read.sh, > make_exception.sh, make_file_pattern.sh, makesyaoranconf > /usr/sbin シェルプログラムって、結局、手で打つ代わりの「何か」なので、/usr/sbin というほど重要なものではないような印象が・・・。 > ■TOMOYOの設定のコアツール：editpolicy, editpolicy_offline, loadpolicy, > savepolicy, setlevel, setprofile, ccs-auditd, ccs-queryd, ld-watch > /usr/sbin あれ？両方とも/usr/sbinですか？ 設定のコアツールというのは、「これがないと”絶対に”困る」んでしょうか？ ＃ディスク容量が足りなければ削れる・・・ようなコマンドならもっと ＃レベル低くてもいいかも・・・とか思いました。 そういえば、余談になりますが、ccsになんか違和感あった理由がわかりました。 Solarisが開発系のコマンドやライブラリを/usr/binや/usr/libから分離するのに /usr/ccs/binとか/usr/ccs/libとか使っているんですよね。 何の略か昔聴いた記憶がかすかにあるんですが、忘れましたm(__)m > ■その他便利ツール：ccstree, checkpolicy, domainmatch, findtemp, pathmatch, > patternize, realpath, sortpolicy > /usr/binか/usr/sbin ツール・・・ですよね・・・。 なければないでも動作させるのにまったく問題ないんですよね？ そういうのは、/usr/binとか/usr/sbinに入れたくないですね。 > ■サンプル実装：candy, chaplet, checktoken, gettoken, groovy, honey, mailaut > h, > timeauth, falsh, proxy > /usr/lib/{ccs,tomoyo}、もしくは同梱しない。 /usr/share/doc/tomoyo-${version}/samples ですかねぇ・・・。 > 【案2：1箇所にまとめる】 > FHSによると、/usr/libにサブディレクトリを作るのがOKなようなので、 > /usr/lib/{ccs,tomoyo}にまとめて置くという案。 > http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA まとめてフラットにおく・・・んじゃなくて、/usr/lib/{ccs, tomoyo}/にsbinとか binとかdocとかサブフォルダ切って、それぞれ分類してぶちこんで、 /usr/sbin/配下とか、/usr/bin配下とかにはそれぞれリンク・・・という パターンもありではないかと・・・。 -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From k.takeda26 ＠ gmail.com Tue Aug 7 16:20:21 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Tue, 7 Aug 2007 16:20:21 +0900 Subject: [Tomoyo-dev 502] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <55301.163.135.10.34.1186465610.squirrel@webmail.knlab.com> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <9d732d950707301536ib067596v7509cd8c95969267@mail.gmail.com> <53275.163.135.10.34.1185849256.squirrel@webmail.knlab.com> <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <46B17897.5090500@nttdata.co.jp> <5fb14edc0708061718s754021c5l903a94b62e833db5@mail.gmail.com> <55301.163.135.10.34.1186465610.squirrel@webmail.knlab.com> Message-ID: <5fb14edc0708070020v64914c20la485e61c4d058e29@mail.gmail.com> たけだです。 > > ■初期設定ツール： > シェルプログラムって、結局、手で打つ代わりの「何か」なので、/usr/sbin > というほど重要なものではないような印象が・・・。 使うときはインストール時くらいなので、/usr/sbinではない方がいいかも。 代替案としてはやはり/usr/lib/{ccs,tomoyo}でしょうか。 初期設定ツールはもっとまとめられそうですね。 いっそinit_policy.shにまとめてしまいましょうか。 > > ■TOMOYOの設定のコアツール： > あれ？両方とも/usr/sbinですか？ > 設定のコアツールというのは、「これがないと"絶対に"困る」んでしょうか？ これらはないと困るので、/usr/sbinが適当かと思います。 > > ■その他便利ツール > ツール・・・ですよね・・・。 > なければないでも動作させるのにまったく問題ないんですよね？ > そういうのは、/usr/binとか/usr/sbinに入れたくないですね。 /usr/binでもダメですかね？ > > ■サンプル実装 > /usr/share/doc/tomoyo-${version}/samples ですかねぇ・・・。 サンプルですね。うーん。確かにそうですが、 実行プログラムがdocの下にあるのは変な気もします。 >> 【案2：1箇所にまとめる】 > まとめてフラットにおく・・・んじゃなくて、/usr/lib/{ccs, tomoyo}/にsbinとか > binとかdocとかサブフォルダ切って、それぞれ分類してぶちこんで、 > /usr/sbin/配下とか、/usr/bin配下とかにはそれぞれリンク・・・という > パターンもありではないかと・・・。 これはこれでありですね。 参考までにAppArmorのツールは、 ・/usr/sbin直下にバイナリを置いて、 ・/usr/sbin/aa-*からシンボリックリンク というなかなか勇気のある方法を取っているようです。 From nez ＠ samba.gr.jp Tue Aug 7 16:37:11 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Tue, 7 Aug 2007 16:37:11 +0900 (JST) Subject: [Tomoyo-dev 503] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <5fb14edc0708070020v64914c20la485e61c4d058e29@mail.gmail.com> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com><9d732d950707301536ib067596v7509cd8c95969267@mail.gmail.com><53275.163.135.10.34.1185849256.squirrel@webmail.knlab.com><46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp><200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp><46B17897.5090500@nttdata.co.jp><5fb14edc0708061718s754021c5l903a94b62e833db5@mail.gmail.com><55301.163.135.10.34.1186465610.squirrel@webmail.knlab.com> <5fb14edc0708070020v64914c20la485e61c4d058e29@mail.gmail.com> Message-ID: <49644.163.135.10.34.1186472231.squirrel@webmail.knlab.com> 根津です。 On 2007年 8月 7日 (火) 16:20, Kentaro Takeda wrote: > たけだです。 > >> > ■初期設定ツール： >> シェルプログラムって、結局、手で打つ代わりの「何か」なので、/usr/sbin >> というほど重要なものではないような印象が・・・。 > 使うときはインストール時くらいなので、/usr/sbinではない方がいいかも。 > 代替案としてはやはり/usr/lib/{ccs,tomoyo}でしょうか。 > 初期設定ツールはもっとまとめられそうですね。 > いっそinit_policy.shにまとめてしまいましょうか。 あ、それくらいシンプルの方がいいですね。 >> > ■TOMOYOの設定のコアツール： >> あれ？両方とも/usr/sbinですか？ >> 設定のコアツールというのは、「これがないと"絶対に"困る」んでしょうか？ > これらはないと困るので、/usr/sbinが適当かと思います。 なるほど。 >> > ■その他便利ツール >> ツール・・・ですよね・・・。 >> なければないでも動作させるのにまったく問題ないんですよね？ >> そういうのは、/usr/binとか/usr/sbinに入れたくないですね。 > /usr/binでもダメですかね？ まぁ、/usr/lib/{ccs,tomoyo}/tools/ とか /usr/lib/{ccs,tomoyo}/contrib/ とかですかねぇ・・・。 >> > ■サンプル実装 >> /usr/share/doc/tomoyo-${version}/samples ですかねぇ・・・。 > サンプルですね。うーん。確かにそうですが、 > 実行プログラムがdocの下にあるのは変な気もします。 ふむ。では、パッケージレベルでみて、 /usr/share/doc/tomoyo-${version}/sample_implementations/ とか？ >>> 【案2：1箇所にまとめる】 >> まとめてフラットにおく・・・んじゃなくて、/usr/lib/{ccs, tomoyo}/にsbinとか >> binとかdocとかサブフォルダ切って、それぞれ分類してぶちこんで、 >> /usr/sbin/配下とか、/usr/bin配下とかにはそれぞれリンク・・・という >> パターンもありではないかと・・・。 > これはこれでありですね。 これがうれしいのは、パッケージ作るときに、post-instで ファイル名の衝突見つけたら、勝手に頭に{ccs,tomoyo}-つける・・・ とか作りやすいというのがあるんですよね。 ＃conflict起こしにくい。 > 参考までにAppArmorのツールは、 > ・/usr/sbin直下にバイナリを置いて、 > ・/usr/sbin/aa-*からシンボリックリンク > というなかなか勇気のある方法を取っているようです。 彼らはOpenSUSEでぶつかんなきゃイイってくらいしか考えてない ・・・に１０００カノッサ（ふるっ -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From yocto1 ＠ gmail.com Wed Aug 8 01:40:06 2007 From: yocto1 ＠ gmail.com (yocto) Date: Wed, 8 Aug 2007 01:40:06 +0900 Subject: [Tomoyo-dev 504] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <49644.163.135.10.34.1186472231.squirrel@webmail.knlab.com> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <53275.163.135.10.34.1185849256.squirrel@webmail.knlab.com> <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <46B17897.5090500@nttdata.co.jp> <5fb14edc0708061718s754021c5l903a94b62e833db5@mail.gmail.com> <55301.163.135.10.34.1186465610.squirrel@webmail.knlab.com> <5fb14edc0708070020v64914c20la485e61c4d058e29@mail.gmail.com> <49644.163.135.10.34.1186472231.squirrel@webmail.knlab.com> Message-ID: <8f3c749a0708070940u74f4e082kb41e40e3024932b1@mail.gmail.com> クスノです。 下記の案１に一票 07/08/07 に Kensuke Nezu さんは書きました: > 根津です。 > > On 2007年 8月 7日 (火) 16:20, Kentaro Takeda wrote: > > たけだです。 > > > >> > ■初期設定ツール： > >> シェルプログラムって、結局、手で打つ代わりの「何か」なので、/usr/sbin > >> というほど重要なものではないような印象が・・・。 > > 使うときはインストール時くらいなので、/usr/sbinではない方がいいかも。 > > 代替案としてはやはり/usr/lib/{ccs,tomoyo}でしょうか。 > > 初期設定ツールはもっとまとめられそうですね。 > > いっそinit_policy.shにまとめてしまいましょうか。 > > あ、それくらいシンプルの方がいいですね。 > > >> > ■TOMOYOの設定のコアツール： > >> あれ？両方とも/usr/sbinですか？ > >> 設定のコアツールというのは、「これがないと"絶対に"困る」んでしょうか？ > > これらはないと困るので、/usr/sbinが適当かと思います。 > > なるほど。 > > >> > ■その他便利ツール > >> ツール・・・ですよね・・・。 > >> なければないでも動作させるのにまったく問題ないんですよね？ > >> そういうのは、/usr/binとか/usr/sbinに入れたくないですね。 > > /usr/binでもダメですかね？ > > まぁ、/usr/lib/{ccs,tomoyo}/tools/ とか /usr/lib/{ccs,tomoyo}/contrib/ > とかですかねぇ・・・。 > > >> > ■サンプル実装 > >> /usr/share/doc/tomoyo-${version}/samples ですかねぇ・・・。 > > サンプルですね。うーん。確かにそうですが、 > > 実行プログラムがdocの下にあるのは変な気もします。 > > ふむ。では、パッケージレベルでみて、 > /usr/share/doc/tomoyo-${version}/sample_implementations/ > とか？ > > >>> 【案2：1箇所にまとめる】 > >> まとめてフラットにおく・・・んじゃなくて、/usr/lib/{ccs, tomoyo}/にsbinとか > >> binとかdocとかサブフォルダ切って、それぞれ分類してぶちこんで、 > >> /usr/sbin/配下とか、/usr/bin配下とかにはそれぞれリンク・・・という > >> パターンもありではないかと・・・。 > > これはこれでありですね。 > > これがうれしいのは、パッケージ作るときに、post-instで > ファイル名の衝突見つけたら、勝手に頭に{ccs,tomoyo}-つける・・・ > とか作りやすいというのがあるんですよね。 > > ＃conflict起こしにくい。 > > > 参考までにAppArmorのツールは、 > > ・/usr/sbin直下にバイナリを置いて、 > > ・/usr/sbin/aa-*からシンボリックリンク > > というなかなか勇気のある方法を取っているようです。 > > 彼らはOpenSUSEでぶつかんなきゃイイってくらいしか考えてない > ・・・に１０００カノッサ（ふるっ > > -- > ------ > 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） > Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) > 802.11セキュリティサイト：http://www.famm.jp/wireless > ※「SELinuxシステム管理―セキュアOSの基礎と運用」 > http://www.oreilly.co.jp/books/4873112257/ > ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 > http://www.oreilly.co.jp/books/4873112877/ > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > From pirasaka ＠ gmail.com Wed Aug 8 15:30:43 2007 From: pirasaka ＠ gmail.com (t.pira) Date: Wed, 8 Aug 2007 15:30:43 +0900 Subject: [Tomoyo-dev 505] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <8f3c749a0708070940u74f4e082kb41e40e3024932b1@mail.gmail.com> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <46B17897.5090500@nttdata.co.jp> <5fb14edc0708061718s754021c5l903a94b62e833db5@mail.gmail.com> <55301.163.135.10.34.1186465610.squirrel@webmail.knlab.com> <5fb14edc0708070020v64914c20la485e61c4d058e29@mail.gmail.com> <49644.163.135.10.34.1186472231.squirrel@webmail.knlab.com> <8f3c749a0708070940u74f4e082kb41e40e3024932b1@mail.gmail.com> Message-ID: $B$T$i$5$+$G$9!#(B $B4pK\E*$K(B GUI $B$NN)>l$+$i$N%3%a%s%H$G$9!#(B $B#17O!"#27O$G(B {ccs-,tmy-} $B$H%W%l%U%#%C%/%9$,$o$+$l$J$$$h$&$K$7$F$[$7$$$G$9!#(B $BNc$($P!V ＠ _Dj$N%3%"%D!<%k!W$G$"$k(B loadpolicy $B$O(B /usr/sbin $B$K3JG<$5$l$k$3$H$K(B $B$J$kN.$l$G$9$,!"$3$N%3%^%s%I$O(B {ccs | tmy}-loadpolicy $B$H#2=E$K$J$j$^$9$M!#(B $B$3$N$h$&$K%P!<%8%g%sJL$K%3%^%s%IL>$,$3$H$J$k$H(B GUI $B$H$7$F$O$H$F$b$D$i$$$G$9!#(B $B%3%^%s%I$r8F$S=P$9$H$-$K!"$^$:#x7O!J%P!<%8%g%s!K$NH=JL$,I,MW$K$J$j$^$9$,!"(B $B8=:_$N(B TOMOYO $B$N;EMM$H$7$F2?$i$+$N%3%^%s%I$d%U%!%$%k$r;2>H$7$F%P!<%8%g%s>pJs$,(B $Bl=j$K$"$C$F$b!"<+F0$G$O$I$3!J$I$A$i!K$K(B $B3JG<$5$l$F$$$k$N$+!"H=JL$G$-$^$;$s$+$i$M!#(B $B7+$jJV$7$G$9$,!"#17O!"#27O0c$$!J%P!<%8%g%s$N0c$$!K$,!"2?$i$+$NJ}K!$G3Nl=j$HL>A0$,0c$&$N$G$9$+$i!#(B $BJ#?tBf$N%]%j%7!<$N%P%C%/%"%C%W$rA0$H>l=j$rJQ$($k$J$i$P!"$I$N%P!<%8%g%s$+H=CG$G$-$k$h$&$J(B $B;EAH$_$rDs6!$9$k!#(B $B-"#17O!"#27O$GL>A0$H>l=j$rJQ$($J$$$H$7$F!"%W%l%U%#%C%/%9$O(B ccs, tomoyo, tmy $B$N(B $B$$$:$l$+$GE}0l$9$k!#(B $B$H$$$&$3$H$N$$$:$l$+$K$7$F$[$7$$$H;W$C$F$$$^$9!#(B $B0J>e$G$9!#(B -------------- next part -------------- HTML$B$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B... URL: http://lists.sourceforge.jp/mailman/archives/tomoyo-dev/attachments/20070808/bd5b9911/attachment.htm From nez ＠ samba.gr.jp Wed Aug 8 16:41:30 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Wed, 8 Aug 2007 16:41:30 +0900 (JST) Subject: [Tomoyo-dev 506] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com><46AEA4C4.2000600@gmail.com> <46AEA626.8030307@nttdata.co.jp><200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp><46B17897.5090500@nttdata.co.jp><5fb14edc0708061718s754021c5l903a94b62e833db5@mail.gmail.com><55301.163.135.10.34.1186465610.squirrel@webmail.knlab.com><5fb14edc0708070020v64914c20la485e61c4d058e29@mail.gmail.com><49644.163.135.10.34.1186472231.squirrel@webmail.knlab.com><8f3c749a0708070940u74f4e082kb41e40e3024932b1@mail.gmail.com> Message-ID: <37560.163.135.10.35.1186558890.squirrel@webmail.knlab.com> $B:,DE$G$9!#(B On 2007$BG/(B 8$B7n(B 8$BF|(B ($B?e(B) 15:30, t.pira wrote: > $B$T$i$5$+$G$9!#(B $B$R$i$5$+$5$s$N%j%/%(%9%H$r9MN8$9$k$H!"(B /usr/lib/{ccs, toyomo$B$N$$$:$l$+(B} $B$K(I"$BL>A0$NJQ$o$i$J$$!W%3%^%s%I$d%U%!%$%k$,$9$Y$F=8$^$C$F$$$F!"(B $B$=$3$+$i!"I,MW$J(BFHS$B$K=>$C$?%G%#%l%/%H%j$K%j%s%/$,D%$C$F$"$k(B $B$H$$$&7A<0$@$H!"$I$3$KJQ$o$C$F$b(BGUI$B$O(B/usr/lib/{ccs, tomoyo}$B$@$1(B $B$r;2>H$9$l$P$h$/$J$k$N$G$h$$$N$+$b$7$l$^$;$s$M!#(B $B%Q%9$dL>A0$rJQ$($?$iF0$+$J$$!&!&!&$H$$$&$N$O!"%G%#%9%H%j%S%e!<%7%g%s(B $B$N%Q%C%1!<%8$NET9g$G!"JQ$o$C$F$b%@%a$H$$$&$3$H$K$J$j$^$9$,!"(B $B$=$3$^$G(I"$BG{$j(I#$B$,F~$k$H%Q%C%1!<%8%c$N<+M3EY$,Mn$A$F$7$^$$$^$9!#(B $B!t(BGUI$B$rA*Br$9$k$?$a$K!"2?$+$N5!G=!J$b$7%3%^%s%I$,$V$D$+$C$?>l9g!K(B $B!t$r5>@7$K$7$F!&!&!&$H$$$&$N$O%j%9%/$,Bg$-$9$.$k$N$G!&!&!&!#(B -- ------ $B:,DE(B $B8&2p(B $BF|K\(BSamba$B%f!<%62q(B/NTT$B%G!<%?@hC<5;=Q!J3t!K(B Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11$B%;%-%e%j%F%#%5%$%H!'(Bhttp://www.famm.jp/wireless $B"(!V(BSELinux$B%7%9%F%`4IM}!=%;%-%e%"(BOS$B$N4pAC$H1?MQ!W(B http://www.oreilly.co.jp/books/4873112257/ $B"(!V References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <46B17897.5090500@nttdata.co.jp> <5fb14edc0708061718s754021c5l903a94b62e833db5@mail.gmail.com> <55301.163.135.10.34.1186465610.squirrel@webmail.knlab.com> <5fb14edc0708070020v64914c20la485e61c4d058e29@mail.gmail.com> <49644.163.135.10.34.1186472231.squirrel@webmail.knlab.com> <8f3c749a0708070940u74f4e082kb41e40e3024932b1@mail.gmail.com> <37560.163.135.10.35.1186558890.squirrel@webmail.knlab.com> Message-ID: ひらさかです。 > /usr/lib/{ccs, toyomoのいずれか} > > に「名前の変わらない」コマンドやファイルがすべて集まっていて、 > ... > を参照すればよくなるのでよいのかもしれませんね。 なるほど。そうですね。 > そこまで「縛り」が入るとパッケージャの自由度が落ちてしまいます。 確かにです。ここまで思いが巡っていませんでした。 あまりにもガチガチにしてはいけませんね。 あと /usr/lib/{ccs, toyomoのいずれか} に、１系／２系両方の ツールを同じ名前で配置するとなると、何かに支障がないのか気になりました。 例えば、/usr/lib/{ccs | tomoyo}/editpolicy と１つのコマンドになったとすると、 １系・２系で必要な機能は違うでしょうから、実装を一緒にするのが大変とか、 １系固有の機能を実装すると２系では影響がでるとか… 07/08/08 に Kensuke Nezu さんは書きました: > > 根津です。 > > On 2007年 8月 8日 (水) 15:30, t.pira wrote: > > ぴらさかです。 > > ひらさかさんのリクエストを考慮すると、 > > /usr/lib/{ccs, toyomoのいずれか} > > に「名前の変わらない」コマンドやファイルがすべて集まっていて、 > そこから、必要なFHSに従ったディレクトリにリンクが張ってある > という形式だと、どこに変わってもGUIは/usr/lib/{ccs, tomoyo}だけ > を参照すればよくなるのでよいのかもしれませんね。 > > パスや名前を変えたら動かない・・・というのは、ディストリビューション > のパッケージの都合で、変わってもダメということになりますが、 > そこまで「縛り」が入るとパッケージャの自由度が落ちてしまいます。 > > ＃GUIを選択するために、何かの機能（もしコマンドがぶつかった場合） > ＃を犠牲にして・・・というのはリスクが大きすぎるので・・・。 > > > -- > ------ > 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） > Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) > 802.11セキュリティサイト：http://www.famm.jp/wireless > ※「SELinuxシステム管理―セキュアOSの基礎と運用」 > http://www.oreilly.co.jp/books/4873112257/ > ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 > http://www.oreilly.co.jp/books/4873112877/ > > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > > -------------- next part -------------- HTMLの添付ファイルを保管しました... URL: http://lists.sourceforge.jp/mailman/archives/tomoyo-dev/attachments/20070808/6d3ad87f/attachment.htm From nez ＠ samba.gr.jp Thu Aug 9 07:11:35 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Thu, 09 Aug 2007 07:11:35 +0900 Subject: [Tomoyo-dev 508] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <46B17897.5090500@nttdata.co.jp> <5fb14edc0708061718s754021c5l903a94b62e833db5@mail.gmail.com> <55301.163.135.10.34.1186465610.squirrel@webmail.knlab.com> <5fb14edc0708070020v64914c20la485e61c4d058e29@mail.gmail.com> <49644.163.135.10.34.1186472231.squirrel@webmail.knlab.com> <8f3c749a0708070940u74f4e082kb41e40e3024932b1@mail.gmail.com> <37560.163.135.10.35.1186558890.squirrel@webmail.knlab.com> Message-ID: <46BA3F97.3000200@samba.gr.jp> 根津です。 t.pira wrote: > ひらさかです。 > > > /usr/lib/{ccs, toyomoのいずれか} > > > > に「名前の変わらない」コマンドやファイルがすべて集まっていて、 > > ... > > を参照すればよくなるのでよいのかもしれませんね。 > > なるほど。そうですね。 > > > そこまで「縛り」が入るとパッケージャの自由度が落ちてしまいます。 > > 確かにです。ここまで思いが巡っていませんでした。 > あまりにもガチガチにしてはいけませんね。 がちがちというかパス名が何らかの理由で変わるとGUIが動作しなくなる ・・・というのをパッケージャーに配慮しなさい・・・というのはちょっと 負担が大きそうだ・・・と思った次第です。 > あと /usr/lib/{ccs, toyomoのいずれか} に、１系／２系両方の > ツールを同じ名前で配置するとなると、何かに支障がないのか気になりました。 > > 例えば、/usr/lib/{ccs | tomoyo}/editpolicy と１つのコマンドになったとす > ると、 > １系・２系で必要な機能は違うでしょうから、実装を一緒にするのが大変とか、 > １系固有の機能を実装すると２系では影響がでるとか… 現在の武田さんの案ですと、 1.x系：/usr/lib/ccs/ 2.x系：/usr/lib/tomoyo/ なので切替は問題なさそうですが、GUIでキックするレベルのコマンドライン オプションとかが、もし変わるならちょっとGUIが大変でしょうか・・・？ ＃オプションの互換が今後無くなっていったりしたときにそれがわかる ＃ようにする必要があるんですね、考えてみると・・・。 ＃そうすると、 ＃2.x系： /usr/lib/tomoyo2/ ＃3.x系： /usr/lib/tomoyo3/ ＃みたいにした方が安全なんですかね・・・？保険として・・・。 -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From haradats ＠ gmail.com Thu Aug 9 07:36:08 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Thu, 9 Aug 2007 07:36:08 +0900 Subject: [Tomoyo-dev 509] =?iso-2022-jp?b?GyRCJUklLSVlJWElcyVIJE5KODt6JTMhPCVJJEskRCQkGyhC?= =?iso-2022-jp?b?GyRCJEYbKEI=?= Message-ID: <9d732d950708081536i3baade3fgfdfb84e1f013bff@mail.gmail.com> 原田です。 議論を蒸し返すつもりはないのですが、気になったので メールしておきます。 07/08/07 に from-tomoyo-dev ＠ i-love.sakura.ne.jp さんは書きました: > > tomoyo-svnを取り寄せていますが、HTMLファイルの中の漢字コードがshift-jis > > のようなのですが、もしそうだとしたら何か理由があるんですか？ > Windows + 秀丸で編集しているからです。 > 他のコードの方が好都合ですか？ > > ＃ UTF-8 だと Winbiff で読めないというのもあります。 半田さんがあげている理由は、秀丸はコード自動判別ができるわけ ですし、本来編集側作業（者）の都合は考慮はしても最優先とは すべきでないでしょう。 TOMOYOのオンラインドキュメントの文字コードをshift-jisとするのは、 それほど問題ないと思うのですが、配布する中に含まれる日本語 ドキュメントの文字コードは、euc-jpかutf8のほうが良いですね （長期的にはutf8になると思っています）。ただ、そもそも 日本語ドキュメントメイン(must)ではなく、README.euc等 補足的な使い方がメインでしょうけれども。 -- Toshiharu Harada haradats ＠ gmail.com From haradats ＠ gmail.com Thu Aug 9 08:01:27 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Thu, 9 Aug 2007 08:01:27 +0900 Subject: [Tomoyo-dev 510] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <46BA3F97.3000200@samba.gr.jp> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <5fb14edc0708061718s754021c5l903a94b62e833db5@mail.gmail.com> <55301.163.135.10.34.1186465610.squirrel@webmail.knlab.com> <5fb14edc0708070020v64914c20la485e61c4d058e29@mail.gmail.com> <49644.163.135.10.34.1186472231.squirrel@webmail.knlab.com> <8f3c749a0708070940u74f4e082kb41e40e3024932b1@mail.gmail.com> <37560.163.135.10.35.1186558890.squirrel@webmail.knlab.com> <46BA3F97.3000200@samba.gr.jp> Message-ID: <9d732d950708081601q3d8f874dhac1c1ccad34cb0aa@mail.gmail.com> 07/08/09 に Kensuke Nezu さんは書きました: > 根津です。 > > t.pira wrote: > > ひらさかです。 > > > > > /usr/lib/{ccs, toyomoのいずれか} > > > > > > に「名前の変わらない」コマンドやファイルがすべて集まっていて、 > > > ... > > > を参照すればよくなるのでよいのかもしれませんね。 > > > > なるほど。そうですね。 > > > > > そこまで「縛り」が入るとパッケージャの自由度が落ちてしまいます。 > > > > 確かにです。ここまで思いが巡っていませんでした。 > > あまりにもガチガチにしてはいけませんね。 > > がちがちというかパス名が何らかの理由で変わるとGUIが動作しなくなる > ・・・というのをパッケージャーに配慮しなさい・・・というのはちょっと > 負担が大きそうだ・・・と思った次第です。 > > > あと /usr/lib/{ccs, toyomoのいずれか} に、１系／２系両方の > > ツールを同じ名前で配置するとなると、何かに支障がないのか気になりました。 > > > > 例えば、/usr/lib/{ccs | tomoyo}/editpolicy と１つのコマンドになったとす > > ると、 > > １系・２系で必要な機能は違うでしょうから、実装を一緒にするのが大変とか、 > > １系固有の機能を実装すると２系では影響がでるとか… > > 現在の武田さんの案ですと、 > > 1.x系：/usr/lib/ccs/ > 2.x系：/usr/lib/tomoyo/ > > なので切替は問題なさそうですが、GUIでキックするレベルのコマンドライン > オプションとかが、もし変わるならちょっとGUIが大変でしょうか・・・？ > > ＃オプションの互換が今後無くなっていったりしたときにそれがわかる > ＃ようにする必要があるんですね、考えてみると・・・。 > ＃そうすると、 > ＃2.x系： /usr/lib/tomoyo2/ > ＃3.x系： /usr/lib/tomoyo3/ > ＃みたいにした方が安全なんですかね・・・？保険として・・・。 現状だけでなく、今後のバージョンアップにより仕様の変化を 考慮するというのは、良いポイントですね。 2系は今後機能を追加していくことが確実です。GUIがサーバ側の 仕様を判断するためのバージョンを最初に取得する必要があるとすれば、 それを見に行く場所だけ固定しておいて、そこからtomoyo/ccs/その他の 「シンボル（のsuffix）」を併せて取得してというのだと （tomoyo, ccs以外への変更を含め）ある程度柔軟に対応できるかも しれません。 ただ、1系をフリーズするという流れを素直にとらえたら、本来は 未来のGUIバージョンでの1系の動作を気にする必要はないと 思いますが・・・。 ところで、今さらですが、ccsの使用については、tomoyoの使用とは、 単純に横並びに考えて良いのかちょっと気になってきました。 ・tomoyoはプロジェクトの名前として、CCSのキャラクター「も」意識 　（キャラクター以外の意味もある）している。CLAMP事務所に 　利用の相談も送付済み。また、商標を取得している。 ・ccsはtomoyoとは異なり、プロジェクト自体での他の定義はなく、 　あくまでもccsとして使用している。ccsは、キャラクターではなく、 　CLAMP作品名「そのもの（略称）」。CLAMP事務所に利用の相談は 　送っていない。 （だからccsはやめようと言うつもりはありませんが） -- Toshiharu Harada haradats ＠ gmail.com From hitoht ＠ gmail.com Thu Aug 9 08:18:43 2007 From: hitoht ＠ gmail.com (hito) Date: Thu, 9 Aug 2007 08:18:43 +0900 Subject: [Tomoyo-dev 511] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <46BA3F97.3000200@samba.gr.jp> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <5fb14edc0708061718s754021c5l903a94b62e833db5@mail.gmail.com> <55301.163.135.10.34.1186465610.squirrel@webmail.knlab.com> <5fb14edc0708070020v64914c20la485e61c4d058e29@mail.gmail.com> <49644.163.135.10.34.1186472231.squirrel@webmail.knlab.com> <8f3c749a0708070940u74f4e082kb41e40e3024932b1@mail.gmail.com> <37560.163.135.10.35.1186558890.squirrel@webmail.knlab.com> <46BA3F97.3000200@samba.gr.jp> Message-ID: <9292c1390708081618g71132b14ib2343bdf85c7154e@mail.gmail.com> hitoです。まったく手が回っていませんのでここだけですが、 > ＃オプションの互換が今後無くなっていったりしたときにそれがわかる > ＃ようにする必要があるんですね、考えてみると・・・。 > ＃そうすると、 > ＃2.x系： /usr/lib/tomoyo2/ > ＃3.x系： /usr/lib/tomoyo3/ > ＃みたいにした方が安全なんですかね・・・？保険として・・・。 これは互換性が失われてから初めて/usr/lib/tomoyo3/ なりにして、 今の時点では/usr/lib/tomoyoにするべきです。 でないとtomoyo3系を出すときに、たとえ互換性が維持されてても 「PATHが3系になっても/usr/lib/tomoyo2っておかしいので変えませんか」 という不毛な検討が必要になってしまいます。 From hitoht ＠ gmail.com Thu Aug 9 08:28:51 2007 From: hitoht ＠ gmail.com (hito) Date: Thu, 9 Aug 2007 08:28:51 +0900 Subject: [Tomoyo-dev 512] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <46AEA626.8030307@nttdata.co.jp> <200707312042.BGE95145.NNFPWtSPEUtGPZP@I-love.SAKURA.ne.jp> <46B17897.5090500@nttdata.co.jp> <5fb14edc0708061718s754021c5l903a94b62e833db5@mail.gmail.com> <55301.163.135.10.34.1186465610.squirrel@webmail.knlab.com> <5fb14edc0708070020v64914c20la485e61c4d058e29@mail.gmail.com> <49644.163.135.10.34.1186472231.squirrel@webmail.knlab.com> <8f3c749a0708070940u74f4e082kb41e40e3024932b1@mail.gmail.com> Message-ID: <9292c1390708081628j43237b0doabc8bb8e724a8025@mail.gmail.com> > 繰り返しですが、１系、２系違い（バージョンの違い）が、何らかの方法で確実に > わかる仕組みがあれば構わないのですが… hackyな方法ですが、今の方向性なら /proc/ccs があるか /proc/tomoyo が あるか、を判断の基準にすることができます。 なにかしらUniform pathを用意しておいて、そこにアクセスするとバージョンが 帰ってくる、という仕組みが欲しいところですが、その名前をどうする、とか、 tomoyotoolsとccstoolsは両方入れておいて、それをKernel切り替えで併用する、 というユースケースをサポートするのが大変、とかが悩ましいです。 （仮にそういうインターフェースを用意するのなら、スペシャルデバイス以外の 方法で実現するとtomoyotoolsとccstoolsパッケージがコンフリクトすることに なってしまいます） From pirasaka ＠ gmail.com Thu Aug 9 09:23:05 2007 From: pirasaka ＠ gmail.com (t.pira) Date: Thu, 9 Aug 2007 09:23:05 +0900 Subject: [Tomoyo-dev 513] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <9d732d950708081601q3d8f874dhac1c1ccad34cb0aa@mail.gmail.com> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <55301.163.135.10.34.1186465610.squirrel@webmail.knlab.com> <5fb14edc0708070020v64914c20la485e61c4d058e29@mail.gmail.com> <49644.163.135.10.34.1186472231.squirrel@webmail.knlab.com> <8f3c749a0708070940u74f4e082kb41e40e3024932b1@mail.gmail.com> <37560.163.135.10.35.1186558890.squirrel@webmail.knlab.com> <46BA3F97.3000200@samba.gr.jp> <9d732d950708081601q3d8f874dhac1c1ccad34cb0aa@mail.gmail.com> Message-ID: 原田さん、 > ところで、今さらですが、ccsの使用については、tomoyoの使用とは、 > 単純に横並びに考えて良いのかちょっと気になってきました。 個人的には、おかしいモノだと感じています。 以前 [Tomoyo-dev 445] で半田さんが > http://I-love.SAKURA.ne.jp/tomoyo/ の「開発コードの由来について」が解説図面ですねぇ。 > 「さくら」＋「知世」＋「小狼」＋「ケルベロス」＋「ユエ」＝「ＣＣＳ」という関係です。 > なので、「ＣＣＳ」が「知世」を包含しているという関係です。 と ccs が tomoyo を包含すると示しています。 この関係は TOMOYO や SAKURA はコンポーネントで、それらが集まって CCS という フレームワークになるとも捉えられるでしょう。こう考えても、やっぱり tomoyo と ccs は 同列の概念ではないですよね。 これは > 事情により CCS Linux ではなく TOMOYO Linux というプロジェクト名になってしまったわけですが、 ということで遠慮＆諸事情によって ccs でまとめたいところが中途半端になっていると思っています。 現在議論している "ディレクトリ構成" の話に、上記の経緯によって {ccs, tomoyo} プレッフィクスが 混在することになっているので、なんだか分かりにくいものになってきていると感じています。 個人的には、プレフィックスについては ccs でも tomoyo にでも（個人的には ccs がしっくりくるかな） 統一して、素直に「何を、どこに、どのように置く」というシンプルな話になればと思います。 -------------- next part -------------- HTMLの添付ファイルを保管しました... URL: http://lists.sourceforge.jp/mailman/archives/tomoyo-dev/attachments/20070809/4acaa4de/attachment.htm From haradats ＠ gmail.com Thu Aug 9 10:08:26 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Thu, 9 Aug 2007 10:08:26 +0900 Subject: [Tomoyo-dev 514] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <5fb14edc0708070020v64914c20la485e61c4d058e29@mail.gmail.com> <49644.163.135.10.34.1186472231.squirrel@webmail.knlab.com> <8f3c749a0708070940u74f4e082kb41e40e3024932b1@mail.gmail.com> <37560.163.135.10.35.1186558890.squirrel@webmail.knlab.com> <46BA3F97.3000200@samba.gr.jp> <9d732d950708081601q3d8f874dhac1c1ccad34cb0aa@mail.gmail.com> Message-ID: <9d732d950708081808y12501e38mf67f9a34902ec21f@mail.gmail.com> 07/08/09 に t. pira さんは書きました: > 原田さん、 > > > ところで、今さらですが、ccsの使用については、tomoyoの使用とは、 > > 単純に横並びに考えて良いのかちょっと気になってきました。 > > 個人的には、おかしいモノだと感じています。 > > 以前 [Tomoyo-dev 445] で半田さんが > > > http://I-love.SAKURA.ne.jp/tomoyo/ > の「開発コードの由来について」が解説図面ですねぇ。 > > 「さくら」＋「知世」＋「小狼」＋「ケルベロス」＋「ユエ」＝「ＣＣＳ」という関係です。 > > なので、「ＣＣＳ」が「知世」を包含しているという関係です。 > > と ccs が tomoyo を包含すると示しています。 > > この関係は TOMOYO や SAKURA はコンポーネントで、それらが集まって CCS という > フレームワークになるとも捉えられるでしょう。こう考えても、やっぱり tomoyo と ccs は > 同列の概念ではないですよね。 > > これは > > > 事情により CCS Linux ではなく TOMOYO Linux というプロジェクト名になってしまったわけですが、 > > ということで遠慮＆諸事情によって ccs でまとめたいところが中途半端になっていると思っています。 > > 現在議論している "ディレクトリ構成" の話に、上記の経緯によって {ccs, tomoyo} プレッフィクスが > 混在することになっているので、なんだか分かりにくいものになってきていると感じています。 > > 個人的には、プレフィックスについては ccs でも tomoyo にでも（個人的には ccs がしっくりくるかな） > 統一して、素直に「何を、どこに、どのように置く」というシンプルな話になればと思います。 私もそう思っていますし、開発会議の結果もその方向でした。 「シンプルな話」には誰も異存はないはずです。 -- Toshiharu Harada haradats ＠ gmail.com From matthew0115 ＠ gmail.com Thu Aug 9 10:24:24 2007 From: matthew0115 ＠ gmail.com (matthew.szulik@gmail.com) Date: Thu, 09 Aug 2007 10:24:24 +0900 Subject: [Tomoyo-dev 515] Re: =?iso-2022-jp?b?GyRCJUklLSVlJWElcyVIJE5KODt6JTMhPCVJJEsbKEI=?= =?iso-2022-jp?b?GyRCJEQkJCRGGyhC?= In-Reply-To: <9d732d950708081536i3baade3fgfdfb84e1f013bff@mail.gmail.com> References: <9d732d950708081536i3baade3fgfdfb84e1f013bff@mail.gmail.com> Message-ID: <46BA6CC8.3080905@gmail.com> 秋元です。 Toshiharu Harada さんは書きました: > 原田です。 > TOMOYOのオンラインドキュメントの文字コードをshift-jisとするのは、 > それほど問題ないと思うのですが、配布する中に含まれる日本語 > ドキュメントの文字コードは、euc-jpかutf8のほうが良いですね > （長期的にはutf8になると思っています）。ただ、そもそも > 日本語ドキュメントメイン(must)ではなく、README.euc等 > 補足的な使い方がメインでしょうけれども。 急ぎのことではないし、変換も一瞬ですから、私も将来的にはUTF-8で統一され ればと思います。 From matthew0115 ＠ gmail.com Thu Aug 9 10:44:25 2007 From: matthew0115 ＠ gmail.com (matthew.szulik@gmail.com) Date: Thu, 09 Aug 2007 10:44:25 +0900 Subject: [Tomoyo-dev 516] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <55301.163.135.10.34.1186465610.squirrel@webmail.knlab.com> <5fb14edc0708070020v64914c20la485e61c4d058e29@mail.gmail.com> <49644.163.135.10.34.1186472231.squirrel@webmail.knlab.com> <8f3c749a0708070940u74f4e082kb41e40e3024932b1@mail.gmail.com> <37560.163.135.10.35.1186558890.squirrel@webmail.knlab.com> <46BA3F97.3000200@samba.gr.jp> <9d732d950708081601q3d8f874dhac1c1ccad34cb0aa@mail.gmail.com> Message-ID: <46BA7179.1080604@gmail.com> 秋元です。 t.pira さんは書きました: > 原田さん、 > 個人的には、プレフィックスについては ccs でも tomoyo にでも（個人的には > ccs がしっくりくるかな） 半田さんの名前の由来説明サイトや開発WikiにTOMOYO Linuxの名前の意味が掲載 されています。 Task Oriented Management Obviates Your Onus on Linux ところが CCS については見当たりません（私が見つけられないだけです か？）。CLAMP作品を知らない人にもわかるように別の意味を持たせるようなこ とはなかったんでしょうか？ セキュリティ強化部分と使い方が分かりやすいということで、 Clear-Cut Security Linux なんて考えてましたが、いかがでしょう？ From k.takeda26 ＠ gmail.com Thu Aug 9 11:57:07 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Thu, 9 Aug 2007 11:57:07 +0900 Subject: [Tomoyo-dev 517] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <9d732d950708081808y12501e38mf67f9a34902ec21f@mail.gmail.com> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <49644.163.135.10.34.1186472231.squirrel@webmail.knlab.com> <8f3c749a0708070940u74f4e082kb41e40e3024932b1@mail.gmail.com> <37560.163.135.10.35.1186558890.squirrel@webmail.knlab.com> <46BA3F97.3000200@samba.gr.jp> <9d732d950708081601q3d8f874dhac1c1ccad34cb0aa@mail.gmail.com> <9d732d950708081808y12501e38mf67f9a34902ec21f@mail.gmail.com> Message-ID: <5fb14edc0708081957j61533d31j84839dfead905e50@mail.gmail.com> たけだです。 /procと/etcはやはり ・1系：/proc/ccs, /etc/ccs ・2系：/proc/tomoyo, /etc/tomoyo でいこうと思います。で、バージョンコードを 　/proc/{ccs,tomoyo}/version に設けて、それに応じてツール側に判定してもらう、 というのがいちばんスマートな方法かと。 で、課題のツールの名前と置き場所ですが、 ユーザがたたく名前は共通なほうが迷いが少ないと思います。 そういう意味で、1系、2系ともにユーザランドは 「ccs-」で統一してはどうでしょうか？ 場所も思い切りシンプルに、 ・コアツール：/usr/sbin/ccs-* ・それ以外：/usr/lib/ccs/* という配置で。 カーネルにハードコードする必要があるポリシーローダだけは、 /sbin/{ccs,tomoyo}-initという名前で1系2系でわける、と。 From nez ＠ samba.gr.jp Thu Aug 9 11:52:44 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Thu, 9 Aug 2007 11:52:44 +0900 (JST) Subject: [Tomoyo-dev 518] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <46BA7179.1080604@gmail.com> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <55301.163.135.10.34.1186465610.squirrel@webmail.knlab.com> <5fb14edc0708070020v64914c20la485e61c4d058e29@mail.gmail.com> <49644.163.135.10.34.1186472231.squirrel@webmail.knlab.com> <8f3c749a0708070940u74f4e082kb41e40e3024932b1@mail.gmail.com> <37560.163.135.10.35.1186558890.squirrel@webmail.knlab.com> <46BA3F97.3000200@samba.gr.jp> <9d732d950708081601q3d8f874dhac1c1ccad34cb0aa@mail.gmail.com> <46BA7179.1080604@gmail.com> Message-ID: <19059.163.135.10.35.1186627964.squirrel@webmail.knlab.com> 根津です。 On 2007年 8月 9日 (木) 10:44, matthew.szulik ＠ gmail.com wrote: > ところが CCS については見当たりません（私が見つけられないだけです > か？）。CLAMP作品を知らない人にもわかるように別の意味を持たせるようなこ > とはなかったんでしょうか？ > > セキュリティ強化部分と使い方が分かりやすいということで、 > > Clear-Cut Security Linux > > なんて考えてましたが、いかがでしょう？ あまりにもわかりやすい気が・・・・（笑 じゃあ、こんなのは？ （表題ちっくなものの頭文字ってことで・・・） Certfied, Clarified, and Sealed Linux 保障されていて、明確で、密閉されたLinux -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From from-tomoyo-dev ＠ i-love.sakura.ne.jp Thu Aug 9 13:03:30 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Thu, 09 Aug 2007 13:03:30 +0900 Subject: [Tomoyo-dev 519] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <5fb14edc0708081957j61533d31j84839dfead905e50@mail.gmail.com> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <49644.163.135.10.34.1186472231.squirrel@webmail.knlab.com> <8f3c749a0708070940u74f4e082kb41e40e3024932b1@mail.gmail.com> <37560.163.135.10.35.1186558890.squirrel@webmail.knlab.com> <46BA3F97.3000200@samba.gr.jp> <9d732d950708081601q3d8f874dhac1c1ccad34cb0aa@mail.gmail.com> <9d732d950708081808y12501e38mf67f9a34902ec21f@mail.gmail.com> <5fb14edc0708081957j61533d31j84839dfead905e50@mail.gmail.com> Message-ID: <200708090403.l7943U8A016698@www262.sakura.ne.jp> 　熊猫です。 (1) /proc/{ccs,tomoyo}/version から カーネルがサポートしているポリシーのバージョン番号を取得できるようにする。 (2) カーネルがサポートしているポリシーのバージョン番号が同じなのに 　　サポートされている構文がカーネルコンフィグに依存しないようにするために、 　　カーネルコンフィグで各機能（CONFIG_TOMOYO_MAC_FOR_FILE CONFIG_TOMOYO_MAC_FOR_ARGV0 等）の 　　選択を行わせないようにする。 (3) サポートしているポリシーのバージョン番号は複数表示できるようにする。 　　例えばポリシーのバージョン 1 と 2 と 3 が定義されており、 　　バージョン 3 はバージョン 2 を完全に包含している 　　（バージョン 2 のポリシーをバージョン 3 のカーネルで使える）場合は 　　2 3 の両方を表示する。 　　バージョン 3 がバージョン 2 を完全には包含していない 　　（バージョン 2 のポリシーをバージョン 3 のカーネルで使えない）場合は 　　3 だけを表示する。 (4) ポリシー構文チェッカの checkpolicy の引数にポリシーのバージョン番号を 　　指定するようにして、定義されている全てのバージョンのポリシーをチェックできるようにする。 (5) ポリシーローダ（ /sbin/{ccs,tomoyo}-init ）の処理を以下のように変更する。 　　変更前 　　　(1) ポリシーファイルを /proc/{ccs,tomoyo}/ インタフェースに流し込む。 　　　　　サポートされていない構文やエラーを含む行はカーネルにより読み捨てられる。 　　変更後 　　　(1) /proc/{ccs,tomoyo}/version からサポートされているポリシーのバージョン番号を取得する。 (2) /etc/{ccs,tomoyo}/ にあるポリシーファイルの内容をポリシー構文チェッカ 　　　　　checkpolicy に流し込み、問題が無いことを確認する。 　　　(3) ポリシーファイルを /proc/{ccs,tomoyo}/ インタフェースに流し込む。 　　　　　サポートされていない構文やエラーを含む行はカーネルにより読み捨てられるが、 　　　　　先に checkpolicy で確認してから流し込むので読み捨てられることは無い。 　　ポリシーファイルの先頭行にバージョン番号を付与する方法は採用しない。その理由は、 　　(1) ポリシーファイルの先頭行にあるバージョン番号が正しくても 　　　　ポリシーの内容にエラーが含まれていないことを保証できない。 　　(2) ポリシーファイルの先頭行にあるバージョン番号が正しくても 　　　　ポリシーの内容にサポートされていない構文が含まれていないことを保証できない。 　　(3) sort コマンドや sortpolicy コマンドで行単位（ドメイン用ポリシーはドメイン単位）の 　　　　並べ替えが可能という利点が失われる。 課題としては (1) checkpolicy はポリシーローダから呼ばれるので / パーティションに置かなければいけない。 (2) init= を用いてポリシーローダを実行しない（ call_usermodehelper() に実行させる）場合、 　　標準入出力が無いのでポリシーに問題があってもエラーメッセージを表示できない。 　　そのため、問題があった場合、エラーメッセージを表示できないままポリシーローダの中で永遠にスリープするか 　　ポリシーをロードできないままポリシーローダが終了することでカーネルパニックするかしか選択肢がない。 From from-tomoyo-dev ＠ i-love.sakura.ne.jp Thu Aug 9 13:05:42 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Thu, 09 Aug 2007 13:05:42 +0900 Subject: [Tomoyo-dev 520] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <46BA7179.1080604@gmail.com> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <55301.163.135.10.34.1186465610.squirrel@webmail.knlab.com> <5fb14edc0708070020v64914c20la485e61c4d058e29@mail.gmail.com> <49644.163.135.10.34.1186472231.squirrel@webmail.knlab.com> <8f3c749a0708070940u74f4e082kb41e40e3024932b1@mail.gmail.com> <37560.163.135.10.35.1186558890.squirrel@webmail.knlab.com> <46BA3F97.3000200@samba.gr.jp> <9d732d950708081601q3d8f874dhac1c1ccad34cb0aa@mail.gmail.com> <46BA7179.1080604@gmail.com> Message-ID: <200708090405.l7945gcq017191@www262.sakura.ne.jp> 　熊猫です。 > ところが CCS については見当たりません（私が見つけられないだけです > か？）。CLAMP作品を知らない人にもわかるように別の意味を持たせるようなこ > とはなかったんでしょうか？ CCS については ccs-patch の README.ccs に書かれているだけです。 これといった頭文字は考えていません。 From pirasaka ＠ gmail.com Thu Aug 9 13:37:49 2007 From: pirasaka ＠ gmail.com (t.pira) Date: Thu, 9 Aug 2007 13:37:49 +0900 Subject: [Tomoyo-dev 521] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <200708090405.l7945gcq017191@www262.sakura.ne.jp> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <8f3c749a0708070940u74f4e082kb41e40e3024932b1@mail.gmail.com> <37560.163.135.10.35.1186558890.squirrel@webmail.knlab.com> <46BA3F97.3000200@samba.gr.jp> <9d732d950708081601q3d8f874dhac1c1ccad34cb0aa@mail.gmail.com> <46BA7179.1080604@gmail.com> <200708090405.l7945gcq017191@www262.sakura.ne.jp> Message-ID: ひらさかです。 ccs-patch の README.ccs より > This project was very inspired by the comic "Card Captor SAKURA", > one of the CLAMP's masterworks. > The names SAKURA and TOMOYO and SYAORAN were borrowed from the comic > with the heartfelt thanks to CLAMP. そこにあったのですね。まぁ、そうだとは思っていましたが… 原義は上記のとおりだとして、例えば CCS って何？という話をするにしても、 フランクな会話では「comic の名前です」とぶっちゃけられますが、 上司とかお客さんから聞かれたような時には、「Clear-Cut Security Linux」らしいですよとか 「Certfied, Clarified, and Sealed Linuxです」って聞きましたけど…、などと 言えるようになっていて欲しいという気がしています。 （TOMOYO の機能や本質の話前に、別の先入観が入ってしまうのを避けるため） こんな考慮をしなくてはならないのは、そもそも不思議（というか面倒）な気もしていましたが、 セキュアＯＳなのにコミックのキャラが散りばめられている自由のひきかえに、 商用化やメインライン化（こちらはあまり関係ないかな？）を踏まえると、 プロジェクトの広報戦略？として準備しておく価値があることだと思いました。 自分も、だいぶ CCS をどう表現できるのか考えていましたが、matthew さんや根津さんのような いい感じの頭字語が浮かびませんでした…。 07/08/09 に from-tomoyo-dev ＠ i-love.sakura.ne.jp < from-tomoyo-dev ＠ i-love.sakura.ne.jp> さんは書きました: > > 熊猫です。 > > > ところが CCS については見当たりません（私が見つけられないだけです > > か？）。CLAMP作品を知らない人にもわかるように別の意味を持たせるようなこ > > とはなかったんでしょうか？ > CCS については ccs-patch の README.ccs に書かれているだけです。 > これといった頭文字は考えていません。 > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -------------- next part -------------- HTMLの添付ファイルを保管しました... URL: http://lists.sourceforge.jp/mailman/archives/tomoyo-dev/attachments/20070809/7a287b5f/attachment.htm From from-tomoyo-dev ＠ i-love.sakura.ne.jp Thu Aug 9 14:05:20 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Thu, 09 Aug 2007 14:05:20 +0900 Subject: [Tomoyo-dev 522] =?iso-2022-jp?b?L3Byb2MvY2NzLyAbJEIwSjI8JE44K0Q+JDckSyREJCQbKEI=?= =?iso-2022-jp?b?GyRCJEYbKEI=?= Message-ID: <200708090505.l7955KL3029990@www262.sakura.ne.jp> 　熊猫です。 　TOMOYO Linux 1.4.2 には以下の /proc/ccs/ インタフェースがあります。 /proc/ccs/status 　プロファイルを取得したり設定したりする。（ setlevel コマンドが利用。） /proc/ccs/info/.updates_counter 　ポリシーの変更の有無を監視する。（ TOMOYO GUI が利用。） /proc/ccs/info/meminfo 　メモリの消費量を取得する。 /proc/ccs/info/self_domain 　カレントプロセスのドメイン名を取得する。 /proc/ccs/info/reject_log 　ポリシーに違反したアクセス要求のログを取得する。（ ccs-auditd コマンドが利用。） /proc/ccs/info/grant_log 　ポリシーに違反しなかったアクセス要求のログを取得する。（ ccs-auditd コマンドが利用。） /proc/ccs/info/.process_status 　任意のプロセスのドメイン名とプロファイル番号を取得する。（ ccstree コマンドが利用。） /proc/ccs/policy/manager 　/proc/ccs/ 経由でポリシーを操作できるプログラムやドメインを取得したり設定したりする。 /proc/ccs/policy/.domain_status 　ドメインのプロファイル番号を取得したり設定したりする。（ setprofile コマンドが利用。） /proc/ccs/policy/exception_policy 　例外ポリシーを取得したり設定したりする。（ editpolicy コマンド等が利用。） /proc/ccs/policy/domain_policy 　ドメインポリシーを取得したり設定したりする。（ editpolicy コマンド等が利用。） /proc/ccs/policy/system_policy 　システムポリシーを取得したり設定したりする。（ editpolicy コマンド等が利用。） /proc/ccs/policy/query 　ポリシーに違反したアクセス要求に割り込みをかけて諾否を指示する。（ ccs-queryd コマンドが利用。） 　情報取得系は /proc/ccs/info/ に、情報設定系は /proc/ccs/policy/ にと分けていますが、 分けなくても良いのではという意見がありました。 また、 TOMOYO Linux 1.2 まではドメイン単位でアクセス制御のレベルを切り替えるという機能が無かったので /proc/ccs/status は現在の制御レベルの状態を取得したり設定したりするということで正しかったのですが、 TOMOYO Linux 1.3 からはドメイン単位でアクセス制御のレベルを切り替えできるようになり、 プロファイルという概念を導入したので /proc/ccs/profile に改名すべきではという意見が出ています。 　そこで、ツールのインストール場所が /root/ccstools/ ではなくなるのを機に、 /proc/ccs/ 以下の見直しを行うかどうか決めたいと思います。 (1) /proc/ccs/info/ および /proc/ccs/policy/ ディレクトリを作成せずに、全て /proc/ccs/ ディレクトリに作成する。 (2) /proc/ccs/status を /proc/ccs/profile に改名する。 (3) /proc/ccs/version からカーネルがサポートしているポリシーのバージョンを取得できるようにする。 の３点を修正して、 /proc/ccs/.domain_status /proc/ccs/.process_status /proc/ccs/.updates_counter /proc/ccs/domain_policy /proc/ccs/exception_policy /proc/ccs/grant_log /proc/ccs/manager /proc/ccs/meminfo /proc/ccs/profile /proc/ccs/query /proc/ccs/reject_log /proc/ccs/self_domain /proc/ccs/system_policy /proc/ccs/version とするのは如何でしょうか？ From k.takeda26 ＠ gmail.com Thu Aug 9 14:14:35 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Thu, 9 Aug 2007 14:14:35 +0900 Subject: [Tomoyo-dev 523] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <200708090403.l7943U8A016698@www262.sakura.ne.jp> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <37560.163.135.10.35.1186558890.squirrel@webmail.knlab.com> <46BA3F97.3000200@samba.gr.jp> <9d732d950708081601q3d8f874dhac1c1ccad34cb0aa@mail.gmail.com> <9d732d950708081808y12501e38mf67f9a34902ec21f@mail.gmail.com> <5fb14edc0708081957j61533d31j84839dfead905e50@mail.gmail.com> <200708090403.l7943U8A016698@www262.sakura.ne.jp> Message-ID: <5fb14edc0708082214h6c136e94l793c768e67e43e06@mail.gmail.com> たけだです。 > (1) /proc/{ccs,tomoyo}/version から > カーネルがサポートしているポリシーのバージョン番号を取得できるようにする。 OK。 > (2) カーネルがサポートしているポリシーのバージョン番号が同じなのに > サポートされている構文がカーネルコンフィグに依存しないようにするために、 > カーネルコンフィグで各機能（CONFIG_TOMOYO_MAC_FOR_FILE CONFIG_TOMOYO_MAC_FOR_ARGV0 等）の > 選択を行わせないようにする。 OK。 > (3) サポートしているポリシーのバージョン番号は複数表示できるようにする。 > 例えばポリシーのバージョン 1 と 2 と 3 が定義されており、 > バージョン 3 はバージョン 2 を完全に包含している > （バージョン 2 のポリシーをバージョン 3 のカーネルで使える）場合は > 2 3 の両方を表示する。 > バージョン 3 がバージョン 2 を完全には包含していない > （バージョン 2 のポリシーをバージョン 3 のカーネルで使えない）場合は > 3 だけを表示する。 「ポリシーのバージョン」と「カーネルのバージョン」は異なるのでしょうか？ > (4) ポリシー構文チェッカの checkpolicy の引数にポリシーのバージョン番号を > 指定するようにして、定義されている全てのバージョンのポリシーをチェックできるようにする。 OK。 > (5) ポリシーローダ（ /sbin/{ccs,tomoyo}-init ）の処理を以下のように変更する。 基本的にOKですが、 > (1) checkpolicy はポリシーローダから呼ばれるので / パーティションに置かなければいけない。 これは仕方ないですね。 > (2) init= を用いてポリシーローダを実行しない（ call_usermodehelper() に実行させる）場合、 > 標準入出力が無いのでポリシーに問題があってもエラーメッセージを表示できない。 > そのため、問題があった場合、エラーメッセージを表示できないままポリシーローダの中で永遠にスリープするか > ポリシーをロードできないままポリシーローダが終了することでカーネルパニックするかしか選択肢がない。 SELinuxはカーネル起動時にポリシー読み込みに失敗するとパニクるようですね。 （ある意味安全側にこけている？） ポリシーローダの返り値がエラーの場合、そもそもユーザの意図したポリシーが 読み込まれていないという意味でパニックでよい気がします。 From k.takeda26 ＠ gmail.com Thu Aug 9 14:19:14 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Thu, 9 Aug 2007 14:19:14 +0900 Subject: [Tomoyo-dev 524] Re: =?iso-2022-jp?b?L3Byb2MvY2NzLyAbJEIwSjI8JE44K0Q+JDckSyREGyhC?= =?iso-2022-jp?b?GyRCJCQkRhsoQg==?= In-Reply-To: <200708090505.l7955KL3029990@www262.sakura.ne.jp> References: <200708090505.l7955KL3029990@www262.sakura.ne.jp> Message-ID: <5fb14edc0708082219j30057d73g98cf250ad75e1382@mail.gmail.com> たけだです。 > /proc/ccs/.domain_status > /proc/ccs/.process_status > /proc/ccs/.updates_counter > /proc/ccs/domain_policy > /proc/ccs/exception_policy > /proc/ccs/grant_log > /proc/ccs/manager > /proc/ccs/meminfo > /proc/ccs/profile > /proc/ccs/query > /proc/ccs/reject_log > /proc/ccs/self_domain > /proc/ccs/system_policy > /proc/ccs/version 賛成。 2系では/proc/tomoyoで同じようにフラットに配置しようかと。 （ちなみに、grant_logとreject_logは今の所2系ではありません） From nez ＠ samba.gr.jp Thu Aug 9 13:55:56 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Thu, 9 Aug 2007 13:55:56 +0900 (JST) Subject: [Tomoyo-dev 525] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <200708090403.l7943U8A016698@www262.sakura.ne.jp> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com><49644.163.135.10.34.1186472231.squirrel@webmail.knlab.com><8f3c749a0708070940u74f4e082kb41e40e3024932b1@mail.gmail.com><37560.163.135.10.35.1186558890.squirrel@webmail.knlab.com><46BA3F97.3000200@samba.gr.jp><9d732d950708081601q3d8f874dhac1c1ccad34cb0aa@mail.gmail.com><9d732d950708081808y12501e38mf67f9a34902ec21f@mail.gmail.com><5fb14edc0708081957j61533d31j84839dfead905e50@mail.gmail.com> <200708090403.l7943U8A016698@www262.sakura.ne.jp> Message-ID: <18108.163.135.10.35.1186635356.squirrel@webmail.knlab.com> 根津です。 On 2007年 8月 9日 (木) 13:03, from-tomoyo-dev ＠ i-love.sakura.ne.jp wrote: > 　熊猫です。 > > (1) /proc/{ccs,tomoyo}/version から > カーネルがサポートしているポリシーのバージョン番号を取得できるようにする。 > > (2) カーネルがサポートしているポリシーのバージョン番号が同じなのに > 　　サポートされている構文がカーネルコンフィグに依存しないようにするために、 > 　　カーネルコンフィグで各機能（CONFIG_TOMOYO_MAC_FOR_FILE CONFIG_TOMOYO_MAC > _FOR_ARGV0 等）の > 　　選択を行わせないようにする。 ここまでは賛成。 > (3) サポートしているポリシーのバージョン番号は複数表示できるようにする。 > 　　例えばポリシーのバージョン 1 と 2 と 3 が定義されており、 > 　　バージョン 3 はバージョン 2 を完全に包含している > 　　（バージョン 2 のポリシーをバージョン 3 のカーネルで使える）場合は > 　　2 3 の両方を表示する。 > 　　バージョン 3 がバージョン 2 を完全には包含していない > 　　（バージョン 2 のポリシーをバージョン 3 のカーネルで使えない）場合は > 　　3 だけを表示する。 これは、 /proc/ccs/acceptpolicy とかを読み出すと、 "1,2,3" みたいに返ってくる？ > (4) ポリシー構文チェッカの checkpolicy の引数にポリシーのバージョン番号を > 　　指定するようにして、定義されている全てのバージョンのポリシーをチェックで > きるようにする。 賛成します。 > (5) ポリシーローダ（ /sbin/{ccs,tomoyo}-init ）の処理を以下のように変更する。 > > 　　変更前 > 　　　(1) ポリシーファイルを /proc/{ccs,tomoyo}/ インタフェースに流し込む。 > 　　　　　サポートされていない構文やエラーを含む行はカーネルにより読み捨てら > れる。 > > 　　変更後 > 　　　(1) /proc/{ccs,tomoyo}/version からサポートされているポリシーのバージョ > ン番号を取得する。 サポートしているバージョンのリストなんだから、versionってファイル名はヘン。 acceptpolicyとかにして欲しいです。 > (2) /etc/{ccs,tomoyo}/ にあるポリシーファイルの内容をポリシー構文チェッ > カ > 　　　　　checkpolicy に流し込み、問題が無いことを確認する。 ここは思い切り反対します。 理由： １．カーネルのユーザランドヘルパーアプリケーションが増えるのはセキュリティ 　　上の脆弱性を内在する理由になる。 ２．毎回、起動のたびに何度もポリシーのバージョンをチェックするコストは 　　ポリシがでかくなると我慢しがたくなりそうでいやだ。 ３．カーネル読み込み時にはエラーにならないことが確実にできるにしても、 　　結局ローダの延長線上で拒否しなくちゃいけなくなって、それで、 > (2) init= を用いてポリシーローダを実行しない（ call_usermodehelper() に実行 > させる）場合、 > 　　標準入出力が無いのでポリシーに問題があってもエラーメッセージを表示できな > い。 > 　　そのため、問題があった場合、エラーメッセージを表示できないままポリシーロー > ダの中で永遠にスリープするか > 　　ポリシーをロードできないままポリシーローダが終了することでカーネルパニッ > クするかしか選択肢がない。 こんな問題がおきるんですから・・・。 それくらいなら、一度、ポリシーファイルを「コンパイル」してデジタル署名 をつけるようにして（MD5?）、改ざん防止の仕組みを作りこむ・・・そのときに ポリシーバージョンもあわせてチェックしてしまう・・・とかの方がよほど きれいです。 ＃もっとも、これは１、ｘ系はfreezeなので２．ｘ系での実現になるんでしょうが。 -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From from-tomoyo-dev ＠ i-love.sakura.ne.jp Thu Aug 9 14:49:34 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Thu, 09 Aug 2007 14:49:34 +0900 Subject: [Tomoyo-dev 526] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <5fb14edc0708082214h6c136e94l793c768e67e43e06@mail.gmail.com> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <37560.163.135.10.35.1186558890.squirrel@webmail.knlab.com> <46BA3F97.3000200@samba.gr.jp> <9d732d950708081601q3d8f874dhac1c1ccad34cb0aa@mail.gmail.com> <9d732d950708081808y12501e38mf67f9a34902ec21f@mail.gmail.com> <5fb14edc0708081957j61533d31j84839dfead905e50@mail.gmail.com> <200708090403.l7943U8A016698@www262.sakura.ne.jp> <5fb14edc0708082214h6c136e94l793c768e67e43e06@mail.gmail.com> Message-ID: <200708090549.l795nYAv039616@www262.sakura.ne.jp> 　熊猫です。 > > バージョン 3 がバージョン 2 を完全には包含していない > > （バージョン 2 のポリシーをバージョン 3 のカーネルで使えない）場合は > > 3 だけを表示する。 > 「ポリシーのバージョン」と「カーネルのバージョン」は異なるのでしょうか？ 「バージョン 2 のポリシーをバージョン 3 のポリシーに対応したカーネルで」と書けば良かったかな？ カーネルのサポートするポリシーのバージョンを表示するだけであって、 カーネルのバージョンは関係ないです。 バージョンを付けるときに難しいのが、 フックのかけ忘れを修正するだけで包含関係が失われる場合があるということです。 包含関係が失われない例： 　sys_strace() に対するフックとして MAC_FOR_CAPABILITY::SYS_STRACE を追加する。 　この場合、既存のポリシーをそのまま再利用でき、 　allow_capability SYS_STRACE という行が現れない限り 　sys_strace() に対するフックの無いカーネルでも利用できる。 　kernel/ptrace.c にフックを追加し、かつ、構文も変化した場合でも包含関係は失われない。 包含関係が失われる例： 　現状、ソケットに対して read() で受信した場合に MAC_FOR_NETWORK の制御ができていないので、 　read() に対して MAC_FOR_NETWORK の制御ができるように net/socket.c を修正する。 　net/socket.c を修正しない状態のカーネルで作成したポリシーを 　net/socket.c を修正した状態のカーネルで利用しようとした場合、 　allow_network UDP connect という行を追加しないと動作しない可能性がある。 　構文に変化が無くとも、 net/socket.c にフックを追加しただけで包含関係が失われる。 手作業でフックを挿入している 1.x 系では特に起こりやすいですが、 LSM のフックを利用している 2.x 系でも（ LSM に渡されるパラメータ不足等を補うために 手作業で修正を加える可能性や、 LSM フックの位置が変更される可能性など）起こらないとは限りません。 From from-tomoyo-dev ＠ i-love.sakura.ne.jp Thu Aug 9 15:43:37 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Thu, 09 Aug 2007 15:43:37 +0900 Subject: [Tomoyo-dev 527] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <18108.163.135.10.35.1186635356.squirrel@webmail.knlab.com> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com><49644.163.135.10.34.1186472231.squirrel@webmail.knlab.com><8f3c749a0708070940u74f4e082kb41e40e3024932b1@mail.gmail.com><37560.163.135.10.35.1186558890.squirrel@webmail.knlab.com><46BA3F97.3000200@samba.gr.jp><9d732d950708081601q3d8f874dhac1c1ccad34cb0aa@mail.gmail.com><9d732d950708081808y12501e38mf67f9a34902ec21f@mail.gmail.com><5fb14edc0708081957j61533d31j84839dfead905e50@mail.gmail.com> <200708090403.l7943U8A016698@www262.sakura.ne.jp> <18108.163.135.10.35.1186635356.squirrel@webmail.knlab.com> Message-ID: <200708090643.l796hbE3051179@www262.sakura.ne.jp> 　熊猫です。 > これは、 /proc/ccs/acceptpolicy とかを読み出すと、 > "1,2,3" > みたいに返ってくる？ そうです。 > ２．毎回、起動のたびに何度もポリシーのバージョンをチェックするコストは > 　　ポリシがでかくなると我慢しがたくなりそうでいやだ。 起動１回につき、ポリシーローダ内でのチェックが１回、 カーネル内でのチェックが１回の２回だけだと思いますが？ > ３．カーネル読み込み時にはエラーにならないことが確実にできるにしても、 > 　　結局ローダの延長線上で拒否しなくちゃいけなくなって、それで、 SELinux の場合は /sbin/init がポリシーをロードするような改造が加えられていますが、 TOMOYO Linux の場合は /sbin/init がポリシーをロードするような改造を加えることは （ /sbin/init をメンテナンスできる立場では無いので）できません。 (↓ Fedora Core 6 の場合) /sbin/init 6 /dev/console 6 /dev/initctl 6 /dev/tty\$ 4 /etc/inittab 1 /etc/rc.d/rc 1 /etc/rc.d/rc.sysinit 4 /etc/selinux/config 4 /etc/selinux/targeted/policy/policy.21 4 /proc/cmdline 1 /sbin/init 1 /sbin/mingetty 4 /selinux/enforce 6 /selinux/load 4 /selinux/mls 4 /selinux/policyvers 2 /var/log/wtmp 6 /var/run/utmp allow_capability SYS_IOCTL allow_capability SYS_MOUNT allow_capability SYS_REBOOT allow_capability create_fifo allow_mkfifo /dev/initctl allow_rewrite /var/log/wtmp だから、 init= を明示して /sbin/init の起動前に（標準入出力が利用可能になった状態で） ポリシーローダを実行するようにしていました。 しかし、 init= を指定しないで済むようにしたいという意見があるので、 call_usermodehelper() を用いて /sbin/init の起動前に（標準入出力が利用不可能な状態で） ポリシーローダを実行するように変更されようとしています。 SELinux の /sbin/init と同じように標準入出力を使える状態にしたいのなら、 call_usermodehelper() ではなく init= による実行をするしか無いのではないでしょうか？ > それくらいなら、一度、ポリシーファイルを「コンパイル」してデジタル署名 > をつけるようにして（MD5?）、改ざん防止の仕組みを作りこむ・・・そのときに > ポリシーバージョンもあわせてチェックしてしまう・・・とかの方がよほど > きれいです。 コンパイルというイメージが湧かないのですが・・・。 コンパイル前 +----------------------------+ |テキストで記述されたポリシー| +----------------------------+ コンパイル後 +----------------------------+ |ポリシーファイルのバージョン| +----------------------------+ |データ部のMD5SUM（バイナリ）| +----------------------------+ |データ部（バイナリ） | +----------------------------+ のようなイメージなのでしょうか？ でも、このままでは「データ部のMD5SUM」と「データ部」を一緒に改ざんされてしまいます。 データ部はカーネルによって生成されますが、それ以外にもポリシーエディタを用いた変更が発生します。 仮に、データ部の改ざんが行われていないことを検証させるとしても、 データ部に問題（サポートされていない構文や不適切な値）が無いことは保証できないと思います。 改ざん防止の仕組みを作りこむかどうかにかかわらず カーネル内でバイナリデータの中に問題が無いかどうかを検証する必要があると思います。 テキストをパースするよりかは高速に処理できるかもしれませんが、 ポリシーをカーネル内に読み込んだ後で検証する必要性は変わらないと思います。 From k.takeda26 ＠ gmail.com Thu Aug 9 15:49:55 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Thu, 9 Aug 2007 15:49:55 +0900 Subject: [Tomoyo-dev 528] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <200708090549.l795nYAv039616@www262.sakura.ne.jp> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com> <46BA3F97.3000200@samba.gr.jp> <9d732d950708081601q3d8f874dhac1c1ccad34cb0aa@mail.gmail.com> <9d732d950708081808y12501e38mf67f9a34902ec21f@mail.gmail.com> <5fb14edc0708081957j61533d31j84839dfead905e50@mail.gmail.com> <200708090403.l7943U8A016698@www262.sakura.ne.jp> <5fb14edc0708082214h6c136e94l793c768e67e43e06@mail.gmail.com> <200708090549.l795nYAv039616@www262.sakura.ne.jp> Message-ID: <5fb14edc0708082349s47ed3a26u972b0207e5329c97@mail.gmail.com> > カーネルのサポートするポリシーのバージョンを表示するだけであって、 > カーネルのバージョンは関係ないです。 カーネルコンフィグがなくなったなら、カーネルのバージョンが 決まれば一意に決まるのでは？「ポリシーのバージョン」という 新しいバージョン体系を増やすほどのことかな、と思います。 ポリシーのバージョンを決めるなら、ポリシーのヘッダには やはりバージョンを含めたほうがいい気がしますね。 From from-tomoyo-dev ＠ i-love.sakura.ne.jp Thu Aug 9 16:46:11 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Thu, 09 Aug 2007 16:46:11 +0900 Subject: [Tomoyo-dev 529] =?iso-2022-jp?b?GyRCSTg9YEZ+Tk8kKyRpJE4lXSVqJTchPCROJW0hPCVJGyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= Message-ID: <200708090746.l797kBs6066202@www262.sakura.ne.jp> 　熊猫です。 　現状、 ccs-tools に含まれている loadpolicy コマンドなどは 標準入力からの読み込みをサポートしていません。そのため、 TOMOYO GUI では （ /etc/ccs/domain_policy.txt を更新して loadpolicy df を実行するという方法ではなく） /etc/ccs/policy/manager に TOMOYO GUI がポリシーを書き込むためのドメイン （ /usr/sbin/sshd /bin/bash /bin/cat ）を登録することで、 printf "ポリシーの内容" | /bin/cat > /proc/ccs/policy/domain_policy のような方法で更新しています。 しかし、 loadpolicy コマンドが標準入力から読み込んでくれるようになれば TOMOYO GUI がポリシーを書き込むためのドメインを作成しないで済むようになるので 助かるという意見がありました。 そこで、 printf "ポリシーの内容" | loadpolicy d - のような方法でもロードできるようにしようかと思いますが如何でしょうか？ From nez ＠ samba.gr.jp Fri Aug 10 08:22:51 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Fri, 10 Aug 2007 08:22:51 +0900 Subject: [Tomoyo-dev 530] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <200708090643.l796hbE3051179@www262.sakura.ne.jp> References: <8f3c749a0707300836s1be59e86uf728d7d409d1fa24@mail.gmail.com><49644.163.135.10.34.1186472231.squirrel@webmail.knlab.com><8f3c749a0708070940u74f4e082kb41e40e3024932b1@mail.gmail.com><37560.163.135.10.35.1186558890.squirrel@webmail.knlab.com><46BA3F97.3000200@samba.gr.jp><9d732d950708081601q3d8f874dhac1c1ccad34cb0aa@mail.gmail.com><9d732d950708081808y12501e38mf67f9a34902ec21f@mail.gmail.com><5fb14edc0708081957j61533d31j84839dfead905e50@mail.gmail.com> <200708090403.l7943U8A016698@www262.sakura.ne.jp> <18108.163.135.10.35.1186635356.squirrel@webmail.knlab.com> <200708090643.l796hbE3051179@www262.sakura.ne.jp> Message-ID: <46BBA1CB.9050709@samba.gr.jp> 根津です。 from-tomoyo-dev ＠ i-love.sakura.ne.jp wrote: >> ２．毎回、起動のたびに何度もポリシーのバージョンをチェックするコストは >> 　　ポリシがでかくなると我慢しがたくなりそうでいやだ。 > 起動１回につき、ポリシーローダ内でのチェックが１回、 > カーネル内でのチェックが１回の２回だけだと思いますが？ 起動のたびに2回、変更されていようがいまいが必ずチェックされる んですよね？ムダじゃありません？これって、いわば、インタプリタが 実行するたびにソースコードをプリコンパイルするのと一緒ですよね。 >> ３．カーネル読み込み時にはエラーにならないことが確実にできるにしても、 >> 　　結局ローダの延長線上で拒否しなくちゃいけなくなって、それで、 > SELinux の場合は /sbin/init がポリシーをロードするような改造が加えられていますが、 > TOMOYO Linux の場合は /sbin/init がポリシーをロードするような改造を加えることは > （ /sbin/init をメンテナンスできる立場では無いので）できません。 いや、だから/sbin/init改造なんて話してませんが・・・ｗ >> それくらいなら、一度、ポリシーファイルを「コンパイル」してデジタル署名 >> をつけるようにして（MD5?）、改ざん防止の仕組みを作りこむ・・・そのときに >> ポリシーバージョンもあわせてチェックしてしまう・・・とかの方がよほど >> きれいです。 > > コンパイルというイメージが湧かないのですが・・・。 えーと、セキュリティ的な意味合いも兼ねて、tripwireのイメージで 考えています。 http://www.itmedia.co.jp/enterprise/0209/11/n13.html > コンパイル前 > > +----------------------------+ > |テキストで記述されたポリシー| > +----------------------------+ > > コンパイル後 > > +----------------------------+ > |ポリシーファイルのバージョン| > +----------------------------+ > |データ部のMD5SUM（バイナリ）| > +----------------------------+ > |データ部（バイナリ） | > +----------------------------+ > > のようなイメージなのでしょうか？ > でも、このままでは「データ部のMD5SUM」と「データ部」を一緒に改ざんされてしまいます。 一部改ざんされない方法は、デジタル署名という形で可能です。 > データ部はカーネルによって生成されますが、それ以外にもポリシーエディタを用いた変更が発生します。 > 仮に、データ部の改ざんが行われていないことを検証させるとしても、 > データ部に問題（サポートされていない構文や不適切な値）が無いことは保証できないと思います。 PKIの手法でMD5にデジタル署名しておけば問題ありません。 > 改ざん防止の仕組みを作りこむかどうかにかかわらず > カーネル内でバイナリデータの中に問題が無いかどうかを検証する必要があると思います。 > テキストをパースするよりかは高速に処理できるかもしれませんが、 > ポリシーをカーネル内に読み込んだ後で検証する必要性は変わらないと思います。 改ざんされないことが確実で、ポリシーチェッカできちんとチェックされた ものしかバイナリにコンパイルされなければ混入する可能性はほぼなくなる のですから、読めないものは読み飛ばす・・・でも、まぁ、良いかもしれない と（本当によいかはちょっと時間かけて考えないとわからない）は思います。 -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From nez ＠ samba.gr.jp Fri Aug 10 08:24:35 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Fri, 10 Aug 2007 08:24:35 +0900 Subject: [Tomoyo-dev 531] Re: =?iso-2022-jp?b?GyRCSTg9YEZ+Tk8kKyRpJE4lXSVqJTchPCROJW0bKEI=?= =?iso-2022-jp?b?GyRCITwlSSRLJEQkJCRGGyhC?= In-Reply-To: <200708090746.l797kBs6066202@www262.sakura.ne.jp> References: <200708090746.l797kBs6066202@www262.sakura.ne.jp> Message-ID: <46BBA233.7080902@samba.gr.jp> 根津です。 ポリシを書き込むためのドメインを用意するかしないかというのは 面倒よりも、セキュリティの観点で検討すべきだと思いました。 どちらがよりセキュアかで考えてみる点はセキュアOSとして一番 重要なのではないかと思います。 from-tomoyo-dev ＠ i-love.sakura.ne.jp wrote: > 　熊猫です。 > > 　現状、 ccs-tools に含まれている loadpolicy コマンドなどは > 標準入力からの読み込みをサポートしていません。そのため、 TOMOYO GUI では > （ /etc/ccs/domain_policy.txt を更新して loadpolicy df を実行するという方法ではなく） > /etc/ccs/policy/manager に TOMOYO GUI がポリシーを書き込むためのドメイン > （ /usr/sbin/sshd /bin/bash /bin/cat ）を登録することで、 > > printf "ポリシーの内容" | /bin/cat > /proc/ccs/policy/domain_policy > > のような方法で更新しています。 > しかし、 loadpolicy コマンドが標準入力から読み込んでくれるようになれば > TOMOYO GUI がポリシーを書き込むためのドメインを作成しないで済むようになるので > 助かるという意見がありました。 > > そこで、 > > printf "ポリシーの内容" | loadpolicy d - > > のような方法でもロードできるようにしようかと思いますが如何でしょうか？ > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From pirasaka ＠ gmail.com Fri Aug 10 09:11:16 2007 From: pirasaka ＠ gmail.com (t.pira) Date: Fri, 10 Aug 2007 09:11:16 +0900 Subject: [Tomoyo-dev 532] Re: =?iso-2022-jp?b?GyRCSTg9YEZ+Tk8kKyRpJE4lXSVqJTchPCROJW0bKEI=?= =?iso-2022-jp?b?GyRCITwlSSRLJEQkJCRGGyhC?= In-Reply-To: <46BBA233.7080902@samba.gr.jp> References: <200708090746.l797kBs6066202@www262.sakura.ne.jp> <46BBA233.7080902@samba.gr.jp> Message-ID: 平坂です。 セキュリティの観点では許容されないほどの穴にはならないと思っています。 editpolicy にこれまで以上の実行権限を与える必要はありませんし。 本当に（針の穴を通すようなことで）細かいことを気にするとしたら、 標準入力からポリシーを受け付けるので、TOMOYO 用のウイルスなどが 出てきたときに、感染したとして、また root 権限を奪取されたとして、 editpolicy にデータを流し込むということで、自動的にポリシーの改ざんが できてしまうという使われ方ができてしまうということくらいでしょうか。 このようなシナリオの可能性があるとすれば、やはり許容されないでしょうか？ 07/08/10 に Kensuke Nezu さんは書きました: > > 根津です。 > > ポリシを書き込むためのドメインを用意するかしないかというのは > 面倒よりも、セキュリティの観点で検討すべきだと思いました。 > どちらがよりセキュアかで考えてみる点はセキュアOSとして一番 > 重要なのではないかと思います。 > > from-tomoyo-dev ＠ i-love.sakura.ne.jp wrote: > > 熊猫です。 > > > > 現状、 ccs-tools に含まれている loadpolicy コマンドなどは > > 標準入力からの読み込みをサポートしていません。そのため、 TOMOYO GUI では > > （ /etc/ccs/domain_policy.txt を更新して loadpolicy df を実行するという方法ではなく） > > /etc/ccs/policy/manager に TOMOYO GUI がポリシーを書き込むためのドメイン > > （ /usr/sbin/sshd /bin/bash /bin/cat ）を登録することで、 > > > > printf "ポリシーの内容" | /bin/cat > /proc/ccs/policy/domain_policy > > > > のような方法で更新しています。 > > しかし、 loadpolicy コマンドが標準入力から読み込んでくれるようになれば > > TOMOYO GUI がポリシーを書き込むためのドメインを作成しないで済むようになるので > > 助かるという意見がありました。 > > > > そこで、 > > > > printf "ポリシーの内容" | loadpolicy d - > > > > のような方法でもロードできるようにしようかと思いますが如何でしょうか？ > > > > _______________________________________________ > > tomoyo-dev mailing list > > tomoyo-dev ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > > > > -- > ------ > 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） > Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) > 802.11セキュリティサイト：http://www.famm.jp/wireless > ※「SELinuxシステム管理―セキュアOSの基礎と運用」 > http://www.oreilly.co.jp/books/4873112257/ > ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 > http://www.oreilly.co.jp/books/4873112877/ > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -------------- next part -------------- HTMLの添付ファイルを保管しました... URL: http://lists.sourceforge.jp/mailman/archives/tomoyo-dev/attachments/20070810/06d02331/attachment.htm From k.takeda26 ＠ gmail.com Fri Aug 10 20:18:12 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Fri, 10 Aug 2007 20:18:12 +0900 Subject: [Tomoyo-dev 533] =?iso-2022-jp?b?Mi4xcmMxGyRCJHIbKEJTVk4bJEIkSyUzJV8lQyVIJDcbKEI=?= =?iso-2022-jp?b?GyRCJF4kNyQ/GyhC?= Message-ID: <5fb14edc0708100418v1918cc02lfee7d2d3f37f6997@mail.gmail.com> たけだです。 TOMOYO Linux 2.1rc1をSubversionにコミットしました。 バージョンは333です。以下のアクセス制御機能が使用できます。 ・ファイルに対するアクセス制御 ・ネットワークに対するアクセス制御 ・シグナルに対するアクセス制御 ・マウントに対するアクセス制御 http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/2.1.x/tomoyo-lsm/patches/?root=tomoyo でtarballをダウンロードして、vanillaカーネル2.6.23-rc2のソースツリーで展開して、 quilt push -a とたたくことでパッチがあてられます。 パッチの内容は、カーネル本体への軽微な修正と、 security/tomoyo以下のTOMOYO本体の生成です。 TOMOYOを有効にしてコンパイルするには、make menuconfigでsecurity optionsの TOMOYO Linux SupportをONに、以下の3つをOFFにしてください。 < > Default Linux Capabilities < > Root Plug Support [ ] NSA SELinux Support このカーネルで起動するには、ポリシーローダであるtomoyo-initを /sbinに置く必要があります。tomoyo-initは以下のURLからダウンロードできます。 http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/2.1.x/tomoyo-tools/tomoyo-init?rev=334&root=tomoyo&view=log 再起動前に/sbin/tomoyo-initに実行権限を付与するのを忘れずに。 （さっきはまった人 （-_-）ノ） editpolicyなどのツールを使用するには、 /proc/ccsではなく/proc/tomoyoを見に行くように ツールを修正する必要があります。添付したccs2tmy.shの引数に、 1.4.2用のツールの*.[ch]ファイルを指定してコンパイルすることで、 2.1でもツールを使用できるようになります。 たとえばこんな感じ。 cd ccstools find . -name '*.[ch]' | xargs ccs2tmy.sh make all コードクリーンアップ作業を協力していただきたい対象は以下の3つです。 ・security/tomoyo/signal.c ・security/tomoyo/mount.c ・security/tomoyo/common.c 作業の進め方についてはまた別途説明します。 とりあえず2.1rc1を動作する環境をつくって、 ぐりぐり動かしてみてください。 何かありましたら遠慮なくどうぞ ;-) From k.takeda26 ＠ gmail.com Fri Aug 10 20:20:49 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Fri, 10 Aug 2007 20:20:49 +0900 Subject: [Tomoyo-dev 534] Re: =?iso-2022-jp?b?Mi4xcmMxGyRCJHIbKEJTVk4bJEIkSyUzJV8lQyVIGyhC?= =?iso-2022-jp?b?GyRCJDckXiQ3JD8bKEI=?= In-Reply-To: <5fb14edc0708100418v1918cc02lfee7d2d3f37f6997@mail.gmail.com> References: <5fb14edc0708100418v1918cc02lfee7d2d3f37f6997@mail.gmail.com> Message-ID: <5fb14edc0708100420p1d66665bg962eda262ea0aa41@mail.gmail.com> たけだです。 言ってるそばから添付忘れ…。 > editpolicyなどのツールを使用するには、 > /proc/ccsではなく/proc/tomoyoを見に行くように > ツールを修正する必要があります。添付したccs2tmy.shの引数に、 > 1.4.2用のツールの*.[ch]ファイルを指定してコンパイルすることで、 > 2.1でもツールを使用できるようになります。 > > たとえばこんな感じ。 > cd ccstools > find . -name '*.[ch]' | xargs ccs2tmy.sh > make all -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: ccs2tmy.sh 型: application/x-sh サイズ: 265 バイト 説明: 無し URL: http://lists.sourceforge.jp/mailman/archives/tomoyo-dev/attachments/20070810/fad70b52/attachment.sh From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Fri Aug 10 21:49:04 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Fri, 10 Aug 2007 21:49:04 +0900 Subject: [Tomoyo-dev 535] Re: =?iso-2022-jp?b?GyRCJV0laiU3ITwlKCVHJSMlPyRLPydJVSQxGyhC?= In-Reply-To: <8f3c749a0707110720m637f1915w766ede05fd3330b7@mail.gmail.com> References: <8f3c749a0706270909s5ed75407xf90d502dd5b24e73@mail.gmail.com> <200707072336.FIB66431.PtSPEtPWNPNFGZU@I-love.SAKURA.ne.jp> <8f3c749a0707090718h7c69f4d9jaae4231f11672143@mail.gmail.com> <8f3c749a0707110720m637f1915w766ede05fd3330b7@mail.gmail.com> Message-ID: <200708102149.FCI21819.tZPtUNPNGPWSFPE@I-love.SAKURA.ne.jp> 　熊猫です。 > クスノです。 > > chgat()にしてみました。 　遅くなりましたが動作確認しました。表示の乱れは無いようですね。 このパッチを 1.5 および 2.1 に採用したいと思います。 　subversion の trunk の下をバージョン毎に分割したので、 クスノさんのほうで addcolor2.txt を適用して commit していただけませんでしょうか？ 対象は http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/1.5.x/ccs-tools/ccstools/ccstools.src/editpolicy.c?root=tomoyo です。 　よろしくお願いします。 From yocto1 ＠ gmail.com Sun Aug 12 01:00:54 2007 From: yocto1 ＠ gmail.com (yocto) Date: Sun, 12 Aug 2007 01:00:54 +0900 Subject: [Tomoyo-dev 536] Re: =?iso-2022-jp?b?GyRCJV0laiU3ITwlKCVHJSMlPyRLPydJVSQxGyhC?= In-Reply-To: <200708102149.FCI21819.tZPtUNPNGPWSFPE@I-love.SAKURA.ne.jp> References: <8f3c749a0706270909s5ed75407xf90d502dd5b24e73@mail.gmail.com> <200707072336.FIB66431.PtSPEtPWNPNFGZU@I-love.SAKURA.ne.jp> <8f3c749a0707090718h7c69f4d9jaae4231f11672143@mail.gmail.com> <8f3c749a0707110720m637f1915w766ede05fd3330b7@mail.gmail.com> <200708102149.FCI21819.tZPtUNPNGPWSFPE@I-love.SAKURA.ne.jp> Message-ID: <8f3c749a0708110900p279e183dr9d93d2a345fac64d@mail.gmail.com> クスノです。 editpolicy.cをcommitしました。 （Makefileは、commitしてません） 07/08/10 に Tetsuo Handa さんは書きました: > 　熊猫です。 > > > クスノです。 > > > > chgat()にしてみました。 > 遅くなりましたが動作確認しました。表示の乱れは無いようですね。 > このパッチを 1.5 および 2.1 に採用したいと思います。 > > subversion の trunk の下をバージョン毎に分割したので、 > クスノさんのほうで addcolor2.txt を適用して commit していただけませんでしょうか？ > 対象は http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/1.5.x/ccs-tools/ccstools/ccstools.src/editpolicy.c?root=tomoyo です。 > > よろしくお願いします。 > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > From yocto1 ＠ gmail.com Sun Aug 12 01:30:59 2007 From: yocto1 ＠ gmail.com (yocto) Date: Sun, 12 Aug 2007 01:30:59 +0900 Subject: [Tomoyo-dev 537] Re: =?iso-2022-jp?b?ZWRpdHBvbGljeRskQiROMn45VCUzITwlSRsoQg==?= In-Reply-To: References: Message-ID: <8f3c749a0708110930q7c3a3500nb725b339d3420ec4@mail.gmail.com> クスノです。 現状、CRですね。 Enter keyは通常CRのようですが、CRとLFのどちらも有効としているものが ほとんどみたいなので、下記にpatchを載せておきます。 $ svn diff Index: ccstools.src/readline.c =================================================================== --- ccstools.src/readline.c (リビジョン 342) +++ ccstools.src/readline.c (作業コピー) @@ -128,7 +128,7 @@ buffer[++buffer_len] = '\0'; if (cur_pos < window_width - 1) cur_pos++; else line_pos++; - } else if (c == '\r') { + } else if (c == '\r' || c == '\n') { break; } else if (c == KEY_BACKSPACE) { if (line_pos + cur_pos) { Index: ccstools.src/editpolicy.c =================================================================== --- ccstools.src/editpolicy.c (リビジョン 343) +++ ccstools.src/editpolicy.c (作業コピー) @@ -1436,7 +1436,7 @@ saved_current_item_index[current_screen] = current_item_index[current_screen]; saved_current_y[current_screen] = current_y[current_screen]; if (c == 'q' || c == 'Q') return MAXSCREEN; - if (c == '\r' && current_screen == SCREEN_ACL_LIST) return SCREEN_DOMAIN_LIST; + if ((c == '\r' || c == '\n') && current_screen == SCREEN_ACL_LIST) return SCREEN_DOMAIN_LIST; if (c == '\t') { if (current_screen == SCREEN_DOMAIN_LIST) return SCREEN_SYSTEM_LIST; else if (current_screen == SCREEN_SYSTEM_LIST) return SCREEN_EXCEPTION_LIST; @@ -1605,6 +1605,7 @@ } break; case '\r': + case '\n': if (current_screen == SCREEN_DOMAIN_LIST) { if (IsInitializerSource(current)) { int redirect_index; 07/07/29 に 渡辺信生 さんは書きました: > 渡辺です。 > 昨日はお疲れ様でした。 > > 個人的にはTomoyoプロジェクトの現状を知ることができたので、 > とても有意義な時間だったと思っています。 > またハンズオンセミナーなどもぜひ開催していただけるとうれしいです。 > > さて、昨日editpolicyでenterキーが使用できないと報告させていただきましたが > その詳細をメールさせていただきます。 > > 私の環境で問題となっているのはeditpolicyを使用中に改行コードをLFで送信すると > enterキーが使用できないというものです。 > ※ちなみに改行コードをCR、もしくはCRLFにて打ち込むと正常に反応します。 > > 使用している環境は > # uname -a > Linux centos01 2.6.9-42.0.10.EL_tomoyo_1.4 #1 Sun Mar 25 23:12:59 JST > 2007 i686 i686 i386 GNU/Linux > > 端末エミュレータは > poderosa 4.0.2(.NET Framework 2.0)を使用し、ssh接続でアクセス > (認証方法はパスワード) > > リモートPCはwindowsXPです。 > > poderosaの問題かと思い、teratermでも確認しようと思いましたが、 > teratermPro(Utf8版)4.52では改行コード送信にはなぜかLFがなかったため、 > 確認できていません。デフォルトCRのようですね。 > また、コンソールから直接操作する場合も特に問題はありません。 > コンソールの改行コードは調べていませんが…。 > > 日ごろpoderosaを使用し、LFにて作業を行っておりますのでちょっと気になりました。 > > 私の環境のせいかとは思うのですが、他の皆様の環境ではどうなのかを > お聞きしたいと思っております。他、足りない情報等もあるかと思いますので、 > 都度ご指摘していただければと思います。 > > どうぞよろしくお願い致します。 > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sun Aug 12 03:05:07 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 12 Aug 2007 03:05:07 +0900 Subject: [Tomoyo-dev 538] Re: =?iso-2022-jp?b?GyRCJV0laiU3ITwlKCVHJSMlPyRLPydJVSQxGyhC?= In-Reply-To: <8f3c749a0708110900p279e183dr9d93d2a345fac64d@mail.gmail.com> References: <200707072336.FIB66431.PtSPEtPWNPNFGZU@I-love.SAKURA.ne.jp> <8f3c749a0707090718h7c69f4d9jaae4231f11672143@mail.gmail.com> <8f3c749a0707110720m637f1915w766ede05fd3330b7@mail.gmail.com> <200708102149.FCI21819.tZPtUNPNGPWSFPE@I-love.SAKURA.ne.jp> <8f3c749a0708110900p279e183dr9d93d2a345fac64d@mail.gmail.com> Message-ID: <200708120305.FEE57143.PEStFtUWNPGPZNP@I-love.SAKURA.ne.jp> 　熊猫です。 > editpolicy.cをcommitしました。 > （Makefileは、commitしてません） ありがとうございます。 ~/.editpolicyrc みたいな設定ファイルを使って 自由に色指定ができるようになると良いかもしれませんね。 あるいは環境変数のほうが手間が掛からないかな？ From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sun Aug 12 03:05:55 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 12 Aug 2007 03:05:55 +0900 Subject: [Tomoyo-dev 539] Re: =?iso-2022-jp?b?ZWRpdHBvbGljeSAbJEIkTjJ+OVQlMyE8JUkbKEI=?= In-Reply-To: <8f3c749a0708110930q7c3a3500nb725b339d3420ec4@mail.gmail.com> References: <8f3c749a0708110930q7c3a3500nb725b339d3420ec4@mail.gmail.com> Message-ID: <200708120305.IAG61048.PFPWtGNSNEPZtUP@I-love.SAKURA.ne.jp> 　熊猫です。 > 現状、CRですね。 > Enter keyは通常CRのようですが、CRとLFのどちらも有効としているものが > ほとんどみたいなので、下記にpatchを載せておきます。 ありがとうございます。 せっかくですが、今すぐ commit は考えていません。 Enter キーで CRLF を送信してくる環境の場合 次の操作に対しても Enter キーの処理が走ってしまいます。 プログラムの起動後に最初に読み込んだ CR または LF を Enter キーとして認識させるような工夫が必要になるかと思います。 といっても、処理は簡単で int enter_key = -1; のように宣言して、 enter_key = -1 の間に getch2() で \r が来たら enter_key = '\r' を \n が来たら enter_key = '\n' を記憶させることで、 c == '\r' || c == '\n' ではなく c == enter_key のような比較をさせれば 事足りると思います。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sun Aug 12 03:41:17 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 12 Aug 2007 03:41:17 +0900 Subject: [Tomoyo-dev 540] =?iso-2022-jp?b?GyRCJV0laiU3ITwlKCVHJSMlPyRHJE4lUSU/ITwlczI9GyhC?= =?iso-2022-jp?b?GyRCO1kxZzUhRz0kSyREJCQkRhsoQg==?= Message-ID: <200708120341.EDF68740.tWZPPNFENPGStUP@I-love.SAKURA.ne.jp> 　熊猫です。 　file_pattern を使わずに学習させてしまったアクセス許可をパターン化させるには、 (a) 学習されたアクセス許可を削除し、 file_pattern を定義後に再学習する (b) 再学習はせず、ポリシーファイルを直接編集することでパターン化する という２種類の方法があります。 (b) を支援するツールとして findtemp と patternize コマンドが提供されていますが、 http://d.hatena.ne.jp/naothy/20070809 に書いたとおり、操作が面倒です。 「テンポラリファイルか否か」や 「テンポラリファイルを全て含むことができる必要十分なワイルドカードは何か」や 「ワイルドカードを含むパス名１とワイルドカードを含むパス名２は包含関係か否か」を コンピュータが判断することはできません。 しかし、 「ワイルドカードを含むパス名１がワイルドカードを含まないパス名２を包含しているか否か」を コンピュータが判断することはできます。 　例えばポリシーエディタで 2 /etc/mtab.123 2 /etc/mtab.205 2 /etc/mtab.507 というアクセス許可があった場合に 2 /etc/mtab.$? を足すと、上記の３つは /etc/mtab.$? に包含されているので削除することができます。 そこで、削除可能なエントリに　& マークを付けるという処理を行うための機能拡張を検討しています。 「テンポラリファイルを全て含むことができる必要十分なワイルドカードは何か」 （上記の例では /etc/mtab.$? ）を推測するのは人間にとっては簡単ですので、 人間がワイルドカードで指定し、コンピュータがそのワイルドカードに包含されてしまうエントリを 削除するというアプローチです。 まだ未完成ですが実装してみました。リビジョン 344 です。 2 /etc/mtab.$? を追加後、 2 /etc/mtab.$? の行にカーソルを合わせてから o キーを押すことで、 2 /etc/mtab.$? に包含される 2 /etc/mtab.123 、 2 /etc/mtab.205 、 2 /etc/mtab.507 の３行に対して & マークが付与されます。その後、 d キーを押すことで削除できます。 使い勝手はいかがでしょうか？ From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sun Aug 12 12:44:13 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 12 Aug 2007 12:44:13 +0900 Subject: [Tomoyo-dev 541] Re: =?iso-2022-jp?b?ZWRpdHBvbGljeSAbJEIkTjJ+OVQlMyE8JUkbKEI=?= In-Reply-To: <200708120305.IAG61048.PFPWtGNSNEPZtUP@I-love.SAKURA.ne.jp> References: <8f3c749a0708110930q7c3a3500nb725b339d3420ec4@mail.gmail.com> <200708120305.IAG61048.PFPWtGNSNEPZtUP@I-love.SAKURA.ne.jp> Message-ID: <200708121244.ABG71768.NEGZPNFtSWUPPtP@I-love.SAKURA.ne.jp> 　熊猫です。 > Enter キーで CRLF を送信してくる環境の場合 > 次の操作に対しても Enter キーの処理が走ってしまいます。 getch0() の中で CRLF を吸収するようにしました。 なので、もとのパッチに近い形で commit しました。 リビジョンは 345 です。 From sakura7270 ＠ gmail.com Sun Aug 12 23:05:40 2007 From: sakura7270 ＠ gmail.com (=?ISO-2022-JP?B?GyRCRU9KVT8uQDgbKEI=?=) Date: Sun, 12 Aug 2007 23:05:40 +0900 Subject: [Tomoyo-dev 542] Re: =?iso-2022-jp?b?ZWRpdHBvbGljeRskQiROMn45VCUzITwlSRsoQg==?= In-Reply-To: References: Message-ID: 渡辺です。 ありがとうございます！ 今帰省先で確認できないので、戻りしだいすぐに確認したいと思います。 07/07/29 に 渡辺信生 さんは書きました: > 渡辺です。 > 昨日はお疲れ様でした。 > > 個人的にはTomoyoプロジェクトの現状を知ることができたので、 > とても有意義な時間だったと思っています。 > またハンズオンセミナーなどもぜひ開催していただけるとうれしいです。 > > さて、昨日editpolicyでenterキーが使用できないと報告させていただきましたが > その詳細をメールさせていただきます。 > > 私の環境で問題となっているのはeditpolicyを使用中に改行コードをLFで送信すると > enterキーが使用できないというものです。 > ※ちなみに改行コードをCR、もしくはCRLFにて打ち込むと正常に反応します。 > > 使用している環境は > # uname -a > Linux centos01 2.6.9-42.0.10.EL_tomoyo_1.4 #1 Sun Mar 25 23:12:59 JST > 2007 i686 i686 i386 GNU/Linux > > 端末エミュレータは > poderosa 4.0.2(.NET Framework 2.0)を使用し、ssh接続でアクセス > (認証方法はパスワード) > > リモートPCはwindowsXPです。 > > poderosaの問題かと思い、teratermでも確認しようと思いましたが、 > teratermPro(Utf8版)4.52では改行コード送信にはなぜかLFがなかったため、 > 確認できていません。デフォルトCRのようですね。 > また、コンソールから直接操作する場合も特に問題はありません。 > コンソールの改行コードは調べていませんが…。 > > 日ごろpoderosaを使用し、LFにて作業を行っておりますのでちょっと気になりました。 > > 私の環境のせいかとは思うのですが、他の皆様の環境ではどうなのかを > お聞きしたいと思っております。他、足りない情報等もあるかと思いますので、 > 都度ご指摘していただければと思います。 > > どうぞよろしくお願い致します。 > From k.takeda26 ＠ gmail.com Mon Aug 13 10:19:18 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Mon, 13 Aug 2007 10:19:18 +0900 Subject: [Tomoyo-dev 543] Re: =?iso-2022-jp?b?Mi4xcmMxGyRCJHIbKEJTVk4bJEIkSyUzJV8lQyVIGyhC?= =?iso-2022-jp?b?GyRCJDckXiQ3JD8bKEI=?= In-Reply-To: <5fb14edc0708100418v1918cc02lfee7d2d3f37f6997@mail.gmail.com> References: <5fb14edc0708100418v1918cc02lfee7d2d3f37f6997@mail.gmail.com> Message-ID: <5fb14edc0708121819u41cd6276i143ee9bbe46c7e20@mail.gmail.com> たけだです。 2.1rc1を試された方はいませんか〜？ #お盆休みはTOMOYOで遊ぼう！ 先週末のコミットのあと、1.5.xのツールが2.1rc1でも使えるようになりました。 http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/1.5.x/ccs-tools/ccstools/?root=tomoyo から落とせば、[tomoyo-dev 533]で紹介したツールの修正は不要です。 From k.takeda26 ＠ gmail.com Mon Aug 13 20:15:11 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Mon, 13 Aug 2007 20:15:11 +0900 Subject: [Tomoyo-dev 544] Re: =?iso-2022-jp?b?Mi4xcmMxGyRCJHIbKEJTVk4bJEIkSyUzJV8lQyVIGyhC?= =?iso-2022-jp?b?GyRCJDckXiQ3JD8bKEI=?= In-Reply-To: <5fb14edc0708121819u41cd6276i143ee9bbe46c7e20@mail.gmail.com> References: <5fb14edc0708100418v1918cc02lfee7d2d3f37f6997@mail.gmail.com> <5fb14edc0708121819u41cd6276i143ee9bbe46c7e20@mail.gmail.com> Message-ID: <5fb14edc0708130415p5c71240eha30d8341e4e2f806@mail.gmail.com> たけだです。 さらに何度か修正してコミットしました。 変更内容は、ネットワークの受信系LSMのフックを追加する場所の変更と、 コーディングスタイルの変更です。 http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/2.1.x/tomoyo-lsm/patches/?root=tomoyo 動作報告をお待ちしてます。 #ちなみに2.6.23-rc3が出ましたが、今のバージョン351がそのまま当たります。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Mon Aug 13 22:01:25 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Mon, 13 Aug 2007 22:01:25 +0900 Subject: [Tomoyo-dev 545] Re: =?iso-2022-jp?b?GyRCJUclIyVsJS8lSCVqOT1ALiRONURPQCRyOkYbKEI=?= =?iso-2022-jp?b?GyRCMyskNyReJDckZyQmGyhC?= In-Reply-To: <200708090643.l796hbE3051179@www262.sakura.ne.jp> References: <9d732d950708081808y12501e38mf67f9a34902ec21f@mail.gmail.com> <5fb14edc0708081957j61533d31j84839dfead905e50@mail.gmail.com> <200708090403.l7943U8A016698@www262.sakura.ne.jp> <18108.163.135.10.35.1186635356.squirrel@webmail.knlab.com> <200708090643.l796hbE3051179@www262.sakura.ne.jp> Message-ID: <200708132201.IBH22706.PPtUFESNWtGNPZP@I-love.SAKURA.ne.jp> 　熊猫です。 > だから、 init= を明示して /sbin/init の起動前に（標準入出力が利用可能になった状態で） > ポリシーローダを実行するようにしていました。 > しかし、 init= を指定しないで済むようにしたいという意見があるので、 > call_usermodehelper() を用いて /sbin/init の起動前に（標準入出力が利用不可能な状態で） > ポリシーローダを実行するように変更されようとしています。 > SELinux の /sbin/init と同じように標準入出力を使える状態にしたいのなら、 > call_usermodehelper() ではなく init= による実行をするしか無いのではないでしょうか？ 　call_usermodehelper() からポリシーローダを実行した場合でも、ポリシーローダの先頭で exec 0/dev/console exec 2>/dev/console を実行することで標準入出力が利用可能になることが判明しました。 　画面にメッセージを表示でき、キーボードからの入力を読み込むことができるようになった以上、 ポリシーに問題があった場合にはエラーメッセージを表示して永遠にスリープ状態にすることも ユーザに対処法を尋ねることもできます。 FC6 での学習結果によると SELinux に対応した /sbin/init は /selinux/policyvers を読み込んで カーネルがサポートしているポリシーのバージョンを知ってから /etc/selinux/targeted/policy/policy.21 をカーネルにロードしているようです。 なので、 TOMOYO でも /sbin/ccs-init or /sbin/tomoyo-init が カーネルがサポートしているポリシーのバージョンを知ってから /etc/ccs or /etc/tomoyo からポリシーをカーネルにロードすることになると思います。 あとは、ポリシーファイルの中にどのようにバージョン情報を持たせるかです。 　もはや init= でポリシーローダを指定する理由はありません。 次のバージョンからは grub.conf で init= を指定する必要はなくなるでしょう。 From yocto1 ＠ gmail.com Mon Aug 13 23:58:07 2007 From: yocto1 ＠ gmail.com (yocto) Date: Mon, 13 Aug 2007 23:58:07 +0900 Subject: [Tomoyo-dev 546] Re: =?iso-2022-jp?b?GyRCJV0laiU3ITwlKCVHJSMlPyRLPydJVSQxGyhC?= In-Reply-To: <200708120305.FEE57143.PEStFtUWNPGPZNP@I-love.SAKURA.ne.jp> References: <200707072336.FIB66431.PtSPEtPWNPNFGZU@I-love.SAKURA.ne.jp> <8f3c749a0707090718h7c69f4d9jaae4231f11672143@mail.gmail.com> <8f3c749a0707110720m637f1915w766ede05fd3330b7@mail.gmail.com> <200708102149.FCI21819.tZPtUNPNGPWSFPE@I-love.SAKURA.ne.jp> <8f3c749a0708110900p279e183dr9d93d2a345fac64d@mail.gmail.com> <200708120305.FEE57143.PEStFtUWNPGPZNP@I-love.SAKURA.ne.jp> Message-ID: <8f3c749a0708130758y4d4c74c6r4badf9ab81953365@mail.gmail.com> クスノです。 07/08/12 に Tetsuo Handa さんは書きました: > 　熊猫です。 > > > editpolicy.cをcommitしました。 > > （Makefileは、commitしてません） > ありがとうございます。 > > ~/.editpolicyrc みたいな設定ファイルを使って > 自由に色指定ができるようになると良いかもしれませんね。 > あるいは環境変数のほうが手間が掛からないかな？ そうですね、環境変数なら簡単そうですね。 設定ファイルなら、キー割り当て等他にもないと ちょっと寂しい感じです。 From yocto1 ＠ gmail.com Tue Aug 14 00:06:35 2007 From: yocto1 ＠ gmail.com (yocto) Date: Tue, 14 Aug 2007 00:06:35 +0900 Subject: [Tomoyo-dev 547] Re: =?iso-2022-jp?b?Mi4xcmMxGyRCJHIbKEJTVk4bJEIkSyUzJV8lQyVIGyhC?= =?iso-2022-jp?b?GyRCJDckXiQ3JD8bKEI=?= In-Reply-To: <5fb14edc0708130415p5c71240eha30d8341e4e2f806@mail.gmail.com> References: <5fb14edc0708100418v1918cc02lfee7d2d3f37f6997@mail.gmail.com> <5fb14edc0708121819u41cd6276i143ee9bbe46c7e20@mail.gmail.com> <5fb14edc0708130415p5c71240eha30d8341e4e2f806@mail.gmail.com> Message-ID: <8f3c749a0708130806l6e7369b2h2daef80e5f043ea5@mail.gmail.com> クスノです。 あらら、2.1rc1はetchでビルドして動かしてみました。 auditはどのような設定をするのでしょうか？ 07/08/13 に Kentaro Takeda さんは書きました: > たけだです。 > > さらに何度か修正してコミットしました。 > 変更内容は、ネットワークの受信系LSMのフックを追加する場所の変更と、 > コーディングスタイルの変更です。 > http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/2.1.x/tomoyo-lsm/patches/?root=tomoyo > > 動作報告をお待ちしてます。 > #ちなみに2.6.23-rc3が出ましたが、今のバージョン351がそのまま当たります。 > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > From k.takeda26 ＠ gmail.com Tue Aug 14 21:46:50 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Tue, 14 Aug 2007 21:46:50 +0900 Subject: [Tomoyo-dev 548] Re: =?iso-2022-jp?b?Mi4xcmMxGyRCJHIbKEJTVk4bJEIkSyUzJV8lQyVIGyhC?= =?iso-2022-jp?b?GyRCJDckXiQ3JD8bKEI=?= In-Reply-To: <8f3c749a0708130806l6e7369b2h2daef80e5f043ea5@mail.gmail.com> References: <5fb14edc0708100418v1918cc02lfee7d2d3f37f6997@mail.gmail.com> <5fb14edc0708121819u41cd6276i143ee9bbe46c7e20@mail.gmail.com> <5fb14edc0708130415p5c71240eha30d8341e4e2f806@mail.gmail.com> <8f3c749a0708130806l6e7369b2h2daef80e5f043ea5@mail.gmail.com> Message-ID: <5fb14edc0708140546y11a9479dy1bf98fd7393b37b6@mail.gmail.com> たけだです。 > あらら、2.1rc1はetchでビルドして動かしてみました。 ありがとうございます。 今日1日ちょっとはまっててお返事が遅れました。 > auditはどのような設定をするのでしょうか？ 2.1rc1から、プロファイルに ・TOMOYO_AUDIT_GRANT ・TOMOYO_AUDIT_REJECT の2種類が追加されています。 01の2値をとり、許可ログ・拒否ログのauditをON・OFFできます。 auditdが稼動していない状態ではログはコンソールに出力されますが、 http://people.redhat.com/sgrubb/audit/index.html からauditdのバージョン1.5.6を落として、 添付のパッチをあててコンパイルしたauditdならば、 /var/log/audit/audit.logにTOMOYOのログが保存されるようになります。 （これって正しい方法なのかな…？） ルールの書き方は…だれか教えてください orz -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: tomoyo-auditd.diff 型: application/octet-stream サイズ: 1995 バイト 説明: 無し URL: http://lists.sourceforge.jp/mailman/archives/tomoyo-dev/attachments/20070814/82e85f2b/attachment.obj From haradats ＠ gmail.com Wed Aug 15 11:30:11 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Wed, 15 Aug 2007 11:30:11 +0900 Subject: [Tomoyo-dev 549] Re: path-based MAC In-Reply-To: <9d732d950707301518l7ed2c53cp3692d37320901b3d@mail.gmail.com> References: <9d732d950707301518l7ed2c53cp3692d37320901b3d@mail.gmail.com> Message-ID: <9d732d950708141930n18004823u226ef685ded02b9e@mail.gmail.com> 原田@夏休みです。暑いですね。 07/07/31 に Toshiharu Harada さんは書きました: > 「根拠」として挙げられている例は、似通っていて、 > /etc/shadowがリンクされるとパス名が違って見えるから > MACがきかないという稚拙なものしか見たことが > ありません。こちらがちゃんとした説明を（英文で）発表していないのも > 悪いのですが（素材を書いてくれたら外に出すのを手伝いますから > まとめてもらえませんか？＞半田さん）、mlだとあまり議論にならず、特に > LKMLはその議論を行うのは不適であることが > （実際に投稿および議論をして）わかりました。 > > ひとつ比較的新しい書き込みを見つけました。 > http://securityblog.org/brindle/2007/07/15/misunderstanding-unix-security/#comment-15822 > > Brindle on securityというこのブログの著者Joshua Brindleは、 > Stephenを含めたNSAのメンバーと親しいようで、ここで議論をすれば > おそらくStephenも読みますし、参加してくるでしょう。 > Joshuaは、TOMOYO BoFにも参加し、助言（彼のBoFの > topdown securityの記事を読むように）をしてくれるなど > とても協調的で親切ですから、ケンカをするつもりはありませんが、 > 書いてあることがおかしいので、軽くジャブをいれました。 > 反応があれば継続して議論します。 投稿してから2週間後、Joshua Brindle自身からレスがつきましたが、 その内容は、ちょっと予想外でした。 | @Toshi | | This example has nothing to do with path based access control | mechanisms or TOMOYO, it has to do with how hardlinks work on | unix systems and how DAC permissions are attached to the inode. | Please be a little more respectful and try to understand the post | in the future. 「元記事はDACの利点やハードリンクの仕組みについて触れただけ」と 言っていて、さらに私の投稿を失礼だとたしなめていますが、 記事では、「inodeは変わらないがpathは変わる、だから・・・」という ことを言っているように思います。少なくともそう受け止める人は あるでしょう。 「TOMOYO Linuxにも関係ない」については、その通りですが、 私の投稿でもTOMOYOありきではなく、「パス名ベースのMACが 有効ならpathに変更を与える操作は禁止されていると考えるのが普通」と いうことを言っているだけで、特にTOMOYO限定で話をしているつもりは ありません。「失礼=resplectfulではない」については、 Joshuaには悪いですが、これが失礼ならどうすれば良いのかと 思ってしまいます。 Joshuaの真意を知りたい気がしますが、とにかく、出入り禁止に されないように謝っておきました。（上のリンクで読めます） Joshuaの記事が全てではありませんが、path baesdに対しては、 やはり根強い偏見というか不適切な先入観のようなものが存在 しているように思います。技術的な内容以外にそうしたものを 考慮しなければならないというのは、面倒です。 -- Toshiharu Harada haradats ＠ gmail.com From k.takeda26 ＠ gmail.com Wed Aug 15 18:02:29 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Wed, 15 Aug 2007 18:02:29 +0900 Subject: [Tomoyo-dev 550] Re: =?iso-2022-jp?b?Mi4xcmMxGyRCJHIbKEJTVk4bJEIkSyUzJV8lQyVIGyhC?= =?iso-2022-jp?b?GyRCJDckXiQ3JD8bKEI=?= In-Reply-To: <5fb14edc0708140546y11a9479dy1bf98fd7393b37b6@mail.gmail.com> References: <5fb14edc0708100418v1918cc02lfee7d2d3f37f6997@mail.gmail.com> <5fb14edc0708121819u41cd6276i143ee9bbe46c7e20@mail.gmail.com> <5fb14edc0708130415p5c71240eha30d8341e4e2f806@mail.gmail.com> <8f3c749a0708130806l6e7369b2h2daef80e5f043ea5@mail.gmail.com> <5fb14edc0708140546y11a9479dy1bf98fd7393b37b6@mail.gmail.com> Message-ID: <5fb14edc0708150202y538dc965p851685c3c01df576@mail.gmail.com> たけだです。 2.1rc2をコミットしました。今のSVNのバージョンは355です。 2.1rc1にはマウントの制御でバグが存在していますので、 使用されている方は355以上のバージョンに置き換えてください。 バージョンを上げるには、古いパッチをpatchesディレクトリに置いたまま、 quilt pop -a としていったん素のカーネルに戻し、新しいパッチをpatchesに置いて、 quilt push -a としてください。 ちなみに豆知識として、quilt push -aで全部のパッチをあてた後、 quilt pop と1回だけたたくと、tomoyo-lsm-expansion.diffだけをはずせます。 この状態だと、現状のLSMの仕様の範囲で実現できる機能のみが有効になります。 具体的には、 ・ネットワークの受信系 ・シグナル の2つの機能が無効になります。 From k.takeda26 ＠ gmail.com Thu Aug 16 11:25:07 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Thu, 16 Aug 2007 11:25:07 +0900 Subject: [Tomoyo-dev 551] =?iso-2022-jp?b?GyRCJVElOUw+SlE5OUVAJF4kSCRhGyhC?= Message-ID: <5fb14edc0708151925i2b6776b5ld0f527728e3d0500@mail.gmail.com> たけだです。 2.1の内容も固まってきました。 ここらで1.5, 2.1でのユーザランドに見えるパス名の 変更点をおさらいしたいと思います。 ■ポリシーローダの絶対パス名 ・1.5：/sbin/ccs-init ・2.1：/sbin/tomoyo-init という名前に（これはカーネル中にハードコードする必要あり）。 ■/proc以下 ・1.5：/proc/ccs以下にフラットに配置 ・2.1：/proc/tomoyo以下にフラットに配置 ・1.5, 2.1共通： ・statusをprofileに変更 ・TOMOYOのバージョンを出力するversionを追加 ■/etc以下 ・1.5：/etc/ccs ・2.1：/etc/tomoyo ・1.5, 2.1共通： ・*.txtを*.confに変更 ・statusをprofileに変更 ■ツール群の配置 ツールは1系、2系共通にします。 ・実行可能ファイルの実体はすべて/usr/lib/ccsにフラットに配置 ・TOMOYOの設定コアツール（editpolicy, editpolicy_offline, loadpolicy, 　savepolicy, setlevel, setprofile, ccs-auditd, ccs-queryd, ld-watch）に対して、 　ccs-というプレフィックスをつけたシンボリックリンクを/usr/sbinに置く 　（/usr/sbin/ccs-editpolicy -> /usr/lib/ccs/editpolicy） この配置のメリットは、 ・ツール群を使用するツール（GUIなど）は、/usr/lib/ccsにを一元的に見れば済む ・今までのコマンド名で実行したいユーザは/usr/lib/ccsにパスを通してもらえれば充分 ・必要最小限のコマンドだけ/usr/sbinから実行できるのですっきりする 逆にデメリットは、 ・/usr/sbinに置くため接頭語ccs-が必要になり長くなる という感じでしょうか。 こんな感じで行こうと考えていますが、異論はありますか？ From from-tomoyo-dev ＠ i-love.sakura.ne.jp Thu Aug 16 12:38:12 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Thu, 16 Aug 2007 12:38:12 +0900 Subject: [Tomoyo-dev 552] Re: =?iso-2022-jp?b?Mi4xcmMxIBskQiRyGyhCIFNWTiAbJEIkSyUzJV8bKEI=?= =?iso-2022-jp?b?GyRCJUMlSCQ3JF4kNyQ/GyhC?= In-Reply-To: <5fb14edc0708130415p5c71240eha30d8341e4e2f806@mail.gmail.com> References: <5fb14edc0708100418v1918cc02lfee7d2d3f37f6997@mail.gmail.com> <5fb14edc0708121819u41cd6276i143ee9bbe46c7e20@mail.gmail.com> <5fb14edc0708130415p5c71240eha30d8341e4e2f806@mail.gmail.com> Message-ID: <200708160338.l7G3cClO068818@www262.sakura.ne.jp> 　熊猫です。 > 変更内容は、ネットワークの受信系LSMのフックを追加する場所の変更と、 　昨日行ったネットワークに関するアクセス制御方法の修正により以下の２点が変化しました。 (1) read() や recvmsg() で受信する場合もチェックできる (2) カーネル内での処理に起因するアクセス要求の場合はチェックしない 　(1) について、 TOMOYO Linux 1.4.x および 2.0 までは UDP パケットを read() で受信した場合や struct msghdr の msg_name フィールドを NULL に設定して recvmsg() で受信した場合には （パケットを受信する udp_recvmsg() 等の関数の中で msg_name フィールドに 送信元アドレスの情報がコピーされないことが原因で） allow_network UDP connect のチェックが行えないという問題があります。 　対処法として sock_recvmsg() に渡される struct msghdr の msg_name フィールドに char address[MAX_SOCK_ADDR]; で確保したメモリを強制的に代入するという方法を検討しましたが、 修正すべき箇所が多く、パッチを維持するのが大変だということが判明しました。 　そこで、パケットを UDP ソケットのキューから取り出す関数である skb_recv_datagram() の中に フックを追加することで、 sock_recvmsg() に渡される struct msghdr の msg_name フィールドが NULL であっても allow_network UDP connect のチェックが行われるように修正しました。 　この修正により、 TOMOYO Linux 1.5.x および 2.1 以降では recvfrom()/recv()/read()/recvmsg() 何れの方法で UDP パケットを受信する場合であっても、 allow_network UDP connect のチェックが行えるようになります。 　パラメータの不足が原因でアクセス制御ができないというバグを解決するための変更ではありますが、 この変更を 1.4.x に取り込んで 1.4.3 としてリリースしてしまうと 1.4.2 のポリシーでは動作できなくなる可能性がある （ MAC_FOR_NETWORK=3 を一時的に MAC_FOR_NETWORK=2 にして動作確認をする必要がある）ため、 1.4.x に取り込むべきかどうか悩むところです。 　(2) について、 TOMOYO Linux 1.4.x および 2.0 までは 例えば NFS マウントされたファイルシステム上のファイルにアクセスした場合、 アクセスを要求したユーザランドプロセスが属しているドメインに対して allow_network UDP connect xxx.xxx.xxx.xxx 2049 のようなアクセス許可が要求されます。 例えば /bin/cat や /bin/ls はネットワークを使う必要が無いのにもかかわらず NFS ファイルシステム側の都合により UDP を用いたアクセスを許可しなければならないという 不思議な状況が発生しています。 　そこで、ネットワークに関するアクセス制御を行う前に、 アクセス要求がユーザランドでの処理により生じたものかカーネル内部の処理により生じたものかを推測し、 後者の場合にはチェックを行わない（具体的には if (segment_eq(get_fs(), KERNEL_DS)) return 0; を挿入する）ように変更しました。 　これにより、 NFS ファイルシステム側の都合によりカーネル内部で UDP によるアクセス要求が生じても allow_network UDP connect というアクセス許可をアクセスを要求したユーザランドプロセスが属しているドメインに 与えないで済むようにしました。 　ユーザランドのプロセスがアクセスできるアドレスの範囲とカーネルがアクセスできる範囲を分離して、 ユーザランドのプロセスが勝手にカーネル内の情報を読み書きできないようにするために、 ユーザランドから提供された変数を読み書きする際には、その変数のアドレスがユーザランドのプロセスが アクセスできるアドレスの範囲に含まれているかどうかのチェックが行われます。 そのアドレスの範囲を保持しているのが get_fs() で取得できる変数です。 get_fs() == KERNEL_DS の場合は変数のアドレスが適切かどうかの検査が行われない状態で、 get_fs() != KERNEL_DS の場合は変数のアドレスが適切かどうかの検査が行われる状態です。 　普段は get_fs() != KERNEL_DS の状態になっており、ユーザランドのプロセスがアクセスできるアドレスの範囲に含まれない アドレス（つまりカーネルだけがアクセスできるアドレスの範囲）にアクセスする間だけ get_fs() == KERNEL_DS に切り替えます。 そのため、 get_fs() == KERNEL_DS であるかどうかをチェックすれば、カーネルだけがアクセスできるアドレスの範囲の 変数にアクセスしようとしているかどうかが判別できます。 　カーネルだけがアクセスできるアドレスの範囲の変数にアクセスする必要が生じるのは、 カーネル内の処理により生じたアクセス要求の場合です。そのため、 get_fs() == KERNEL_DS であるかどうかを カーネル内の処理により生じたアクセス要求であるか否かの「推測」に用いることにしました。 　ただし、 get_fs() == KERNEL_DS であれば必ずカーネル内の処理により生じたアクセス要求であるかというと そうとも限らないという欠点があります。例えば、 do_execve() に渡される filename と argv と envp は 元々はユーザランドが sys_execve() に渡した変数ですが、 filename については do_execve() を呼び出す前に カーネルだけがアクセスできるアドレスの範囲のバッファにコピーしてしまうため、 copy_strings() の中で get_fs() == KERNEL_DS であるからという理由で カーネル内の処理により生じたアクセス要求であるという判断を下すのは間違っています。 From k.takeda26 ＠ gmail.com Thu Aug 16 19:56:45 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Thu, 16 Aug 2007 19:56:45 +0900 Subject: [Tomoyo-dev 553] =?iso-2022-jp?b?GyRCJTMhPCVJJS8laiE8JXMlIiVDJVc6bjZIJEskRCQkGyhC?= =?iso-2022-jp?b?GyRCJEYbKEI=?= Message-ID: <5fb14edc0708160356w2ac1622sfc7573b57e8304a@mail.gmail.com> たけだです。 昨晩は夜中にあまりに暑くて目が覚めました。 日中は観測史上最高の気温を記録したとか。 みなさん熱中症にはお気をつけください。 さてさて、2.1の内容がだいたい固まってきました。 コードクリーンアップ作業を協力していただくつもりでしたが、 一番大きなcommon.cのクリーンアップを、 熊猫先生が週末にチェックスクリプトが通るところまでやってしまいました。 ということで、実は皆さんにお願いすることがなくなってしまいました…。 ただ、機械的なチェックスクリプトはとりあえず通りましたが、 さらに読みやすく修正してSubversionにアップしていただくのは 今後も大歓迎です。 ということで、クリーンアップ作業の基本的な方法をここで解説しておきます。 チェックスクリプトを利用したクリーンアップの流れは、 1. checkpatch.plでパッチのスタイルのチェック 2. 怒られた箇所を修正 3. quilt refreshでパッチを更新 の繰り返しです。 checkpatch.plというスクリプトが最近のカーネルのscriptsディレクトリに 含まれており、これの引数にパッチを指定すると、 パッチのスタイルをチェックしてくれます。たとえば以下のような感じ。 [root ＠ etch]# checkpatch.pl patches/tomoyo-hooks.diff WARNING: line over 80 characters #86: FILE: security/tomoyo/tomoyo.c:74: … ここでtomoyo.cの74行目を80桁を超えないように修正して保存して、 以下のコマンドでパッチをリフレッシュします。 quilt refresh tomoyo-hooks.diff 再度checkpatch.pl patches/tomoyo-hooks.diffでチェックすると、 先ほどのWARNINGが消えているはずです。 Subversionのtrunk最新版は、checkpatch.plのバージョン0.08で チェック済みのパッチ群です。 From k.takeda26 ＠ gmail.com Mon Aug 20 13:46:11 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Mon, 20 Aug 2007 13:46:11 +0900 Subject: [Tomoyo-dev 554] Re: =?iso-2022-jp?b?GyRCJTMhPCVJJS8laiE8JXMlIiVDJVc6bjZIJEsbKEI=?= =?iso-2022-jp?b?GyRCJEQkJCRGGyhC?= In-Reply-To: <5fb14edc0708160356w2ac1622sfc7573b57e8304a@mail.gmail.com> References: <5fb14edc0708160356w2ac1622sfc7573b57e8304a@mail.gmail.com> Message-ID: <5fb14edc0708192146p775f2539rf0349a9bf99c252a@mail.gmail.com> たけだです。 何らかの変更を加えてquiltでパッチを更新する際は、 以下の内容をホームディレクトリの.quiltrcに 書いておいてください。 QUILT_REFRESH_ARGS='-u --diffstat --no-index' QUILT_DIFF_OPTS='-p' パッチの形式を指定するオプションです。 unified形式で、diffの-pオプション（変更箇所の関数名を出力）をつけて、 diffstatを先頭につけて、Index:はつけないで、 という感じ。 From k.takeda26 ＠ gmail.com Fri Aug 24 22:38:04 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Fri, 24 Aug 2007 22:38:04 +0900 Subject: [Tomoyo-dev 555] =?iso-2022-jp?b?TEtNTBskQiRLOkZFajlGJDckXiQ3JD8bKEI=?= Message-ID: <5fb14edc0708240638i56f94bd7n482c5b7a07cb8e35@mail.gmail.com> たけだです。 先ほどLKMLに再投稿しました。 http://lkml.org/lkml/2007/08/24/116 6月の第1回の投稿、およびOttawa Linux Symposiumの フィードバックを受けての2度目の投稿です。 前回の投稿のときはバージョン2.0として、 ファイルに対するアクセス制御のみを搭載した形で投稿しました。 今回は From k.takeda26 ＠ gmail.com Fri Aug 24 22:43:42 2007 From: k.takeda26 ＠ gmail.com (Kentaro Takeda) Date: Fri, 24 Aug 2007 22:43:42 +0900 Subject: [Tomoyo-dev 556] Re: =?iso-2022-jp?b?TEtNTBskQiRLOkZFajlGJDckXiQ3JD8bKEI=?= In-Reply-To: <5fb14edc0708240638i56f94bd7n482c5b7a07cb8e35@mail.gmail.com> References: <5fb14edc0708240638i56f94bd7n482c5b7a07cb8e35@mail.gmail.com> Message-ID: <5fb14edc0708240643x2e23433dv955db61a47362748@mail.gmail.com> 見事に書いている途中で送信してしまいました。つかれてますね。 仕切りなおし。 先ほどLKMLに再投稿しました。 http://lkml.org/lkml/2007/08/24/116 6月の第1回の投稿、およびOttawa Linux Symposiumの フィードバックを受けての2度目の投稿です。 前回の投稿のときはバージョン2.0として、 ファイルに対するアクセス制御のみを搭載した形で投稿しました。 今回はバージョン2.1-rc3として、 ファイル以外にもネットワーク、シグナル、マウントなどを 制御できるようになっています。 TOMOYO Linuxメインライン化へ向けた第2歩を歩んだTOMOYO Linuxを 今後ともよろしくお願いいたします。