From from-tomoyo-users ＠ i-love.sakura.ne.jp Fri Jul 3 14:34:03 2009 From: from-tomoyo-users ＠ i-love.sakura.ne.jp (Tetsuo Handa) Date: Fri, 03 Jul 2009 14:34:03 +0900 Subject: [Tomoyo-dev 1104] =?iso-2022-jp?b?VE9NT1lPIDEuNi43IC8gMS42LjdwMSAvIDEuNi44IA==?= =?iso-2022-jp?b?GyRCJHIbKEIgQ09ORklHX1NMT0I9eSAbJEIkR014TVEbKEI=?= =?iso-2022-jp?b?GyRCJDkkaz5sOWckTiU7JS0lZSVqJUYlIyVbITwlaxsoQg==?= Message-ID: <200907030534.n635Y42c037687@www262.sakura.ne.jp> 　熊猫です。 TOMOYO 1.6.7 / 1.6.7p1 / 1.6.8 に関して、 CONFIG_SLOB=y の場合に バッファオーバーフローする可能性が発見されました。 CONFIG_SLAB=y または CONFIG_SLUB=y の場合は問題ありません。 問題となるコードは以下の部分です。 −−−定義部分−−− #define CCS_MAX_PATHNAME_LEN 4000 #define CCS_EXEC_TMPSIZE 4096 struct ccs_execve_entry { struct list_head list; struct task_struct *task; /* = current */ struct ccs_request_info r; struct ccs_obj_info obj; struct linux_binprm *bprm; int srcu_idx; /* For execute_handler */ const struct ccs_path_info *handler; char *program_path; /* Size is CCS_MAX_PATHNAME_LEN bytes */ /* For dumping argv[] and envp[]. */ struct ccs_page_dump dump; /* For temporary use. */ char *tmp; /* Size is CCS_EXEC_TMPSIZE bytes */ }; −−−割り当て部分−−− ee->program_path = kzalloc(CCS_MAX_PATHNAME_LEN, GFP_KERNEL); ee->tmp = kzalloc(CCS_MAX_PATHNAME_LEN, GFP_KERNEL); −−−利用部分−−− new_domain_name = ee->tmp; if (ccs_is_domain_initializer(r->domain->domainname, &rn, &ln)) { /* Transit to the child of ccs_kernel_domain domain. */ snprintf(new_domain_name, CCS_EXEC_TMPSIZE - 1, ROOT_NAME " " "%s", ee->program_path); ee->tmp には CCS_EXEC_TMPSIZE バイトの領域が割り当てられるとコメントに 書かれていますが、実際には CCS_MAX_PATHNAME_LEN バイトしか要求して いませんでした。 slab アロケータおよび slub アロケータを使用している場合は（内部処理により 2 のべき乗に丸められることにより）実際には 4096 バイトが割り当てられるため、 問題は生じません。しかし、 slob アロケータを使用している場合は 4000 バイト ちょうどしか割り当てられないため、バッファオーバーフローする可能性があります。 http://sourceforge.jp/projects/tomoyo/releases/?package_id=5026 から ダウンロードできるバイナリパッケージに関しては、 slob アロケータを 使っていないため、そのままでも大丈夫です。 自分でコンパイルされている方は、 CONFIG_SLOB=y となっていないかどうか確認し、 CONFIG_SLOB=y となっていた場合には以下のパッチを適用またはホットフィックスを ダウンロードして再コンパイルしていただきますようお願いいたします。 ccs-patch-1.6.8-20090703.tar.gz MD5:1114ea8c201d78b044c87f2127932b8e --- fs/tomoyo_domain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- ccs-patch.orig/fs/tomoyo_domain.c +++ ccs-patch/fs/tomoyo_domain.c @@ -1227,7 +1227,7 @@ static struct ccs_execve_entry *ccs_allo return NULL; memset(ee, 0, sizeof(*ee)); ee->program_path = ccs_alloc(CCS_MAX_PATHNAME_LEN, false); - ee->tmp = ccs_alloc(CCS_MAX_PATHNAME_LEN, false); + ee->tmp = ccs_alloc(CCS_EXEC_TMPSIZE, false); if (!ee->program_path || !ee->tmp) { ccs_free(ee->program_path); ccs_free(ee->tmp); From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat Jul 4 11:35:07 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 4 Jul 2009 11:35:07 +0900 Subject: [Tomoyo-dev 1105] Re: =?iso-2022-jp?b?c3VucmlzZSBvdmVybGF5IBskQiRLGyhCIGNjcy10b29s?= =?iso-2022-jp?b?cyAbJEIkLCRPJCQkaiReJDckPxsoQg==?= In-Reply-To: <87tz2qew5h.fsf@yue.localnetwork> References: <87tz2qew5h.fsf@yue.localnetwork> Message-ID: <200907041135.AJD13090.NNPFUtSWEPGPtZP@I-love.SAKURA.ne.jp> 　熊猫です。 　松鵜さんから ccs-tools を本家 portage tree へ 送っていただく申し出をいただきましたので転送します。 下記の仕様だと、自動的に /etc/ccs/ が作られてしまうため、 init_policy.sh を実行しなかった場合は /sbin/ccs-init が プロンプトを表示するので、 TOMOYO 1.x カーネルで起動後に ccs-tools をインストールしてリモートからシャットダウン しようとした場合に問題が生じてしまいますがどうしましょう？ MATSUU Takuto さんは書きました： > 松鵜です。 > > はい、転送問題ないです。 > > 2009/7/4 Tetsuo Handa : > > 　熊猫です。 > > > > MATSUU Takuto さんは書きました： > >> 松鵜です。 > >> > >> 昨日はありがとうございました。 > >> > >> sunriseのccs-toolsをベースに、ひとまず私のoverlayに作成しました。 > > ありがとうございます。 > > （このメールを tomoyo-dev ＠ lists.sourceforge.jp に転送しても構いませんか？） > > > >> http://git.overlays.gentoo.org/gitweb/?p=dev/matsuu.git;a=blob;f=sys-apps/ccs-tools/ccs-tools-1.6.8_p20090623.ebuild;hb=HEAD > >> Gentooのポリシーにあわせていくつか修正を施しました。 > >> > >> ・64bit環境対応のため、/usr/lib64または/usr/lib32に対応できるようにしています。 > >> 64bit環境の場合/usr/lib64/ccs/にインストールされますが、/usr/libは/usr/lib64へ > >> シンボリックリンクが張られておりますので、/usr/lib/ccsでもアクセス可能です。 > >> > >> ・CCを、Gentooが指定したCCに置き換えています。 > >> > >> ・-O2を、ユーザが/etc/make.confで指定した${CFLAGS}に置き換えています。 > >> > >> ・設定ファイルを、/etc/ccs/ccstools.confに設置するように変更しました。 > >> /usr/lib/ccs/ccstools.confからシンボリックリンクを張っておりますので影響はありません。 > >> sunriseにあったoverlayは/usr/lib/ccs/conf/にインストールしておりましたが、これは削除しております。 > >> > >> --- > >> > >> これらの修正に問題があるようでしたらお手数ではございますがご連絡くださいませ。 > >> > >> 一定期間テストした上で本家portage treeに取り込む予定です。 > >> > >> 以上、よろしくお願いいたします。 > >> > >> 2009/7/3 Tetsuo Handa : > >> > 熊猫さくらです。 > >> > > >> > 本日はお越しいただきましてどうもありがとうございました。 > >> > > >> > ccs-tools は Naohiro Aota さんがメンテナンスしており、現在 sunrise にあります。 > >> > http://sourceforge.jp/projects/tomoyo/lists/archive/dev/2009-June/001141.html > >> > > >> > ccs-sources と ccs_hardened-sources はメインライン版では無い方のカーネルパッチで、 > >> > http://tomoyo.sourceforge.jp/repos/gentoo-overlay/ にて > >> > Naohiro Aota さんがメンテナンスしています。 > >> > > >> > > > From naota ＠ elisp.net Sat Jul 4 19:40:31 2009 From: naota ＠ elisp.net (Naohiro Aota) Date: Sat, 04 Jul 2009 19:40:31 +0900 Subject: [Tomoyo-dev 1106] Re: =?iso-2022-jp?b?c3VucmlzZSBvdmVybGF5IBskQiRLGyhCIGNjcy10b29s?= =?iso-2022-jp?b?cyAbJEIkLCRPJCQkaiReJDckPxsoQg==?= In-Reply-To: <200907041135.AJD13090.NNPFUtSWEPGPtZP@I-love.SAKURA.ne.jp> (Tetsuo Handa's message of "Sat, 4 Jul 2009 11:35:07 +0900") References: <87tz2qew5h.fsf@yue.localnetwork> <200907041135.AJD13090.NNPFUtSWEPGPtZP@I-love.SAKURA.ne.jp> Message-ID: <87prcgohnk.fsf@yue.localnetwork> 青田です。 Tetsuo Handa writes: > 　熊猫です。 > > 　松鵜さんから ccs-tools を本家 portage tree へ > 送っていただく申し出をいただきましたので転送します。 とうとう本家にも入るんですね、うれしいかぎりです :) > 下記の仕様だと、自動的に /etc/ccs/ が作られてしまうため、 > init_policy.sh を実行しなかった場合は /sbin/ccs-init が > プロンプトを表示するので、 TOMOYO 1.x カーネルで起動後に > ccs-tools をインストールしてリモートからシャットダウン > しようとした場合に問題が生じてしまいますがどうしましょう？ Gentoo の人は emerge に時間がかかることに慣れていますし、 init_policy.sh は、すでにポリシーがある場合は上書きしないようになっていますし(あってま すよね?) pkg_postinst で init_policy.sh を呼ぶのが一番安全だと思います。 まぁ… ccs-sources では init_policy.sh を動かすようにメッセージを出して はいますが。 ^^; >> >> 2009/7/3 Tetsuo Handa : >> >> > 熊猫さくらです。 >> >> > >> >> > 本日はお越しいただきましてどうもありがとうございました。 >> >> > >> >> > ccs-tools は Naohiro Aota さんがメンテナンスしており、現在 sunrise にあります。 >> >> > http://sourceforge.jp/projects/tomoyo/lists/archive/dev/2009-June/001141.html >> >> > >> >> > ccs-sources と ccs_hardened-sources はメインライン版では無い方のカーネルパッチで、 >> >> > http://tomoyo.sourceforge.jp/repos/gentoo-overlay/ にて >> >> > Naohiro Aota さんがメンテナンスしています。 ccs-sources はアナウンスが遅れていましたが、こちらも sunrise に入ってい ます。 http://overlays.gentoo.org/proj/sunrise/browser/reviewed/sys-kernel/ccs-sources/ ということで、 ccs-tools と ccs-sources の2つが sunrise いりして (ccs-tools は本家いりしそうで) Gentoo で TOMOYO 1系を使ってみたい人はとりあえず使える状況になったので sourceforge においているぶんは ccs_hardened-sources を残して削除しようか と思っています。 -- 青田 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat Jul 4 21:30:08 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 4 Jul 2009 21:30:08 +0900 Subject: [Tomoyo-dev 1107] Re: =?iso-2022-jp?b?c3VucmlzZSBvdmVybGF5IBskQiRLGyhCIGNjcy10b29s?= =?iso-2022-jp?b?cyAbJEIkLCRPJCQkaiReJDckPxsoQg==?= In-Reply-To: <87prcgohnk.fsf@yue.localnetwork> References: <87tz2qew5h.fsf@yue.localnetwork> <200907041135.AJD13090.NNPFUtSWEPGPtZP@I-love.SAKURA.ne.jp> <87prcgohnk.fsf@yue.localnetwork> Message-ID: <200907042130.FAJ00501.NZUPFPtEWPPNtSG@I-love.SAKURA.ne.jp> 　熊猫です。 Naohiro Aota さんは書きました： > > 下記の仕様だと、自動的に /etc/ccs/ が作られてしまうため、 > > init_policy.sh を実行しなかった場合は /sbin/ccs-init が > > プロンプトを表示するので、 TOMOYO 1.x カーネルで起動後に > > ccs-tools をインストールしてリモートからシャットダウン > > しようとした場合に問題が生じてしまいますがどうしましょう？ > > Gentoo の人は emerge に時間がかかることに慣れていますし、 init_policy.sh > は、すでにポリシーがある場合は上書きしないようになっていますし(あってま > すよね?) pkg_postinst で init_policy.sh を呼ぶのが一番安全だと思います。 なるほど。では、その方法でお願いします。 TOMOYO 2.X を使うユーザもいると思うので tomoyo_init_policy.sh も 一緒に pkg_postinst で実行させちゃいます？ > ccs-sources はアナウンスが遅れていましたが、こちらも sunrise に入ってい > ます。 > > http://overlays.gentoo.org/proj/sunrise/browser/reviewed/sys-kernel/ccs-sources/ > > ということで、 ccs-tools と ccs-sources の2つが sunrise いりして > (ccs-tools は本家いりしそうで) Gentoo > で TOMOYO 1系を使ってみたい人はとりあえず使える状況になったので > sourceforge においているぶんは ccs_hardened-sources を残して削除しようか > と思っています。 おぉ！では、 SVN/tags/htdocs/ja/1.6.x/compile.html#Gentoo の更新を お願いしますね。 From matsuu ＠ gmail.com Sun Jul 5 00:02:16 2009 From: matsuu ＠ gmail.com (MATSUU Takuto) Date: Sun, 5 Jul 2009 00:02:16 +0900 Subject: [Tomoyo-dev 1108] Re: =?iso-2022-jp?b?c3VucmlzZSBvdmVybGF5IBskQiRLGyhCIGNjcy10b29s?= =?iso-2022-jp?b?cyAbJEIkLCRPJCQkaiReJDckPxsoQg==?= In-Reply-To: <200907042130.FAJ00501.NZUPFPtEWPPNtSG@I-love.SAKURA.ne.jp> References: <87tz2qew5h.fsf@yue.localnetwork> <200907041135.AJD13090.NNPFUtSWEPGPtZP@I-love.SAKURA.ne.jp> <87prcgohnk.fsf@yue.localnetwork> <200907042130.FAJ00501.NZUPFPtEWPPNtSG@I-love.SAKURA.ne.jp> Message-ID: こんにちは、松鵜です。 とりあえずebuildを作ってみただけで、init_policy.shまでは考慮してませんでした。 init_policy.shをざっくり見たところ、環境に合わせてカスタマイズが必要なんですね。ちょっと検討します。 init_policy.shのようなコマンドはおそらくpkg_postinstではダメで、実行するならpkg_config内になると思います。ただ、どのディストリビューションでも同じように使えるのが良いと思うので、 あえてpkg_configではなくinit_polish.shを実行させるフローにしようかと思っています。 取り急ぎ報告まで。 2009/7/4 Tetsuo Handa : > 　熊猫です。 > > Naohiro Aota さんは書きました： >> > 下記の仕様だと、自動的に /etc/ccs/ が作られてしまうため、 >> > init_policy.sh を実行しなかった場合は /sbin/ccs-init が >> > プロンプトを表示するので、 TOMOYO 1.x カーネルで起動後に >> > ccs-tools をインストールしてリモートからシャットダウン >> > しようとした場合に問題が生じてしまいますがどうしましょう？ >> >> Gentoo の人は emerge に時間がかかることに慣れていますし、 init_policy.sh >> は、すでにポリシーがある場合は上書きしないようになっていますし(あってま >> すよね?) pkg_postinst で init_policy.sh を呼ぶのが一番安全だと思います。 > なるほど。では、その方法でお願いします。 > TOMOYO 2.X を使うユーザもいると思うので tomoyo_init_policy.sh も > 一緒に pkg_postinst で実行させちゃいます？ > >> ccs-sources はアナウンスが遅れていましたが、こちらも sunrise に入ってい >> ます。 >> >> http://overlays.gentoo.org/proj/sunrise/browser/reviewed/sys-kernel/ccs-sources/ >> >> ということで、 ccs-tools と ccs-sources の2つが sunrise いりして >> (ccs-tools は本家いりしそうで) Gentoo >> で TOMOYO 1系を使ってみたい人はとりあえず使える状況になったので >> sourceforge においているぶんは ccs_hardened-sources を残して削除しようか >> と思っています。 > おぉ！では、 SVN/tags/htdocs/ja/1.6.x/compile.html#Gentoo の更新を > お願いしますね。 > > _______________________________________________ > 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 Mon Jul 6 13:58:07 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (Tetsuo Handa) Date: Mon, 06 Jul 2009 13:58:07 +0900 Subject: [Tomoyo-dev 1109] =?iso-2022-jp?b?aW5pdF9wb2xpY3kuc2ggGyRCJE44K0Q+JDckSyREJCQbKEI=?= =?iso-2022-jp?b?GyRCJEYbKEI=?= Message-ID: <200907060458.n664w723081766@www262.sakura.ne.jp> 　熊猫です。 　組込み環境だと find とか which とかを用意するのが面倒なのと、 処理時間を短縮することで .rpm や .deb の post install セクションで ポリシーの初期化をしてしまおうという企みのもと、 init_policy.c の make_exception() 部分をＣプログラム化してみました。 http://sourceforge.jp/projects/tomoyo/svn/view/branches/ccs-tools/ccstools/make_exception.c?root=tomoyo&view=co&content-type=text%2Fplain （ make_alias() 部分は既に make_alias.c に置き換わっています。） （↓所要時間は環境により大きく異なります。） −−− init_policy.sh の make_exception() １回目−−− real 0m10.579s user 0m0.167s sys 0m1.109s −−− make_exception.c １回目−−− real 0m9.431s user 0m0.003s sys 0m0.293s −−− init_policy.sh の make_exception() ２回目−−− real 0m0.921s user 0m0.155s sys 0m0.833s −−− make_exception.c ２回目−−− real 0m0.044s user 0m0.017s sys 0m0.029s ディスクアクセス待ちが実行時間のほとんどを占めているので 処理時間の短縮効果はあまり無いことが判りました。 重たいのは file_pattern と allow_read を登録するために find で /usr/share 以下から fonts ディレクトリや icons ディレクトリなどを 検索する処理だと考えています。 これらは学習モードで学習された後に \* に置換しても差し支えないでしょうし、 ディレクトリ階層が意味を持たないので file_pattern を使って複数行として学習 させるよりも path_group を使って手動で１行の @ に置換する方が適していると 思います。 でしたら、 ccs-savepolicy の実行前または後に何らかのコマンドを実行することで 学習後に置換させるという方法が考えられます。（現在は ccs-patternize という コマンドがありますが、パターンを自分で与える必要があるため、あまり使われて いないと思います。） 最初から init_policy.sh に全てのプログラム用の file_pattern と allow_read が 記述されていれば良いのですが、予め全てのパターンを網羅することは不可能です。 さらに、予め file_pattern や allow_read を作成する方法だと、一度 exception_policy.conf を作成した後は ccs-tools がアップデートされて init_policy.sh に新しいパターン情報が追加されたとしても反映されません。 でしたら、 init_policy.sh には必要最低限のパターンのみを登録し、 新しい file_pattern や allow_read が追加されたら domain_policy.conf を更新する という方法をとる方が使いやすいような気がしています。 つまり、 init_policy.sh を大幅に簡略化して、学習モードでざっと学習後に パターン化を行うというアプローチに移行してはどうかというアイデアです。 どうでしょう？ From hitoht ＠ gmail.com Mon Jul 6 23:15:02 2009 From: hitoht ＠ gmail.com (hito) Date: Mon, 6 Jul 2009 23:15:02 +0900 Subject: [Tomoyo-dev 1110] Re: =?iso-2022-jp?b?aW5pdF9wb2xpY3kuc2ggGyRCJE44K0Q+JDckSyREGyhC?= =?iso-2022-jp?b?GyRCJCQkRhsoQg==?= In-Reply-To: <200907060458.n664w723081766@www262.sakura.ne.jp> References: <200907060458.n664w723081766@www262.sakura.ne.jp> Message-ID: <9292c1390907060715k6ed8c582meb1c11ed7602acc2@mail.gmail.com> > つまり、 init_policy.sh を大幅に簡略化して、学習モードでざっと学習後に > パターン化を行うというアプローチに移行してはどうかというアイデアです。 > どうでしょう？ アリだと思います。というか、現在のinit_policy.shはあまりにも重すぎて 利用者への心理的な不安が大きいので、積極的に賛成します。 ただ、できればこの種のメールは先に提案を書いてくださいorz これ↓を読んでからでないと本文の一部を解釈するのがツラくて、二回メールを 読まないといけないので、なんつーか読むのがキビシイものがありますです。 > init_policy.sh を大幅に簡略化して、学習モードでざっと学習後に > パターン化を行うというアプローチに移行してはどうかというアイデアです。 > どうでしょう？ これはメールの頭に欲しいところです。 From hiroshi.shinji ＠ gmail.com Tue Jul 7 03:17:55 2009 From: hiroshi.shinji ＠ gmail.com (Hiroshi Shinji) Date: Tue, 7 Jul 2009 03:17:55 +0900 Subject: [Tomoyo-dev 1111] Re: =?iso-2022-jp?b?VE9NT1lPIBskQiROPCE0fCVQITwlOCVnJXMkWDh+GyhC?= =?iso-2022-jp?b?GyRCJDEkRiROO0VNTUpROTkkSyREJCQkRhsoQg==?= In-Reply-To: <200906271625.FHH57319.UZPWGPtNPPEtNSF@I-love.SAKURA.ne.jp> References: <200906271625.FHH57319.UZPWGPtNPPEtNSF@I-love.SAKURA.ne.jp> Message-ID: 宍道です。 > 構文が長くなるのを回避するための方法として、学習時には、 > 「パーミッションのチェックと遷移先ドメインを計算するのに利用するパス名 > （シンボリックリンク可）」が「シンボリックリンク解決後の絶対パス名」と > 一致する場合には exec.realpath= の部分を省略させ、 > 「パーミッションのチェックと遷移先ドメインを計算するのに利用するパス名 > （シンボリックリンク可）」が「最初の引数」と一致する場合には > exec.argv[0]= の部分を省略させるという選択肢があります。 可読性の観点から、省略できたほうが良いと思います。 > ただし、省略させた場合、「一致するかどうかのチェックを省略する」のか、 > 「一致するかどうかチェックする」のかを決めなければなりません。 > 前節の仕様からは「一致するかどうかチェックする」と解釈するのが妥当ですが、 > 何らかの理由により「一致するかどうかのチェックを省略させたい」場合があった > 場合に対処できなくなります。 どの程度、チェックに処理コストがかかるのかによりますが、 パフォーマンス優先などで、チェックを省略させたい場合はあると思います。 exec.realpathやexec.argv[0]を明記した場合にはそれぞれチェックし、 省略時はチェックをしないようにするほうに賛成です。 > 学習時に省略しないようにすれば、何らかの理由により「一致するかどうかの > チェックを省略させたい」場合にも対処できるようになります。 学習時に省略した形式でのポリシー生成が出きるようなオプションがあれば うれしいのですがどうでしょう？ （省略した形式で使いたい場合、修正にかかる作業量がとても多そう…） 2009/06/27 16:25 に Tetsuo Handa さんは書きました: > 　熊猫です。 > > メインライン版でガベージコレクタを実現できそうなので、非メインライン版でも > ガベージコレクタを実現したいと思います。今までは互換性を重視して重複する機能や > 古くなった機能でもずっと使えるようにしてきましたが、メインライン化されたのを > 機に見直しを行って次期バージョンとするのもありかなと思っています。 > > > > TOMOYO 1.7.0 では、ガベージコレクタが使えることを前提に、今まではメモリを解放 > できないために最小限しか学習させなかった allow_execute に関して、少し多めに学習 > させてみようかと思っています。 > > 現状（ TOMOYO 1.6.8/2.2.0 ）では > > # ln -s /bin/busybox /bin/ls > # ln -s /bin/busybox /bin/cat > > のようなシステムで、 /bin/ls が実行されたものとしてドメインを作成するには > > alias /bin/busybox /bin/ls > > という指定を exception_policy で明示的に行った上で > > allow_execute /bin/ls > > という指定を domain_policy に与える必要があります。 > そのため、 alias /bin/busybox /bin/cat という指定がなかった場合、 > /bin/cat を実行しようとすると /bin/busybox を実行する場合のアクセス許可が > チェックされて、遷移先ドメイン名にも /bin/busybox が使われてしまいます。 > > これを次期バージョンでは、 exception_policy で alias 指定を行う手順を省略し、 > domain_policy で alias 構文相当のチェックを行うようにします。具体的には、 > > allow_execute パーミッションのチェックと遷移先ドメインを計算するのに利用するパス名（シンボリックリンク可） if exec.realpath=シンボリックリンク解決後の絶対パス名 exec.argv[0]=最初の引数 > > のように exec.realpath というキーワードを導入します。例えば > > allow_execute /bin/ls if exec.realpath="/bin/busybox" exec.argv[0]="ls" > allow_execute /bin/ls if exec.realpath="/bin/busybox" exec.argv[0]="/bin/ls" > > のような感じです。このようにすると、 /bin/cat を実行しようとした場合、 > > allow_execute /bin/busybox > > ではなく > > allow_execute /bin/cat if exec.realpath="/bin/busybox" exec.argv[0]="/bin/cat" > がチェックされるようになります。 /bin/busybox の実行許可がないというエラー > メッセージではなく、 /bin/cat を実行する許可がないというエラーメッセージに > なるので、より理解しやすいかと思います。 > > > > インストール時のメリット／デメリット： > > シンボリックリンクのパス名に対して実行許可をチェックするので、 alias 構文を > 廃止できます。それに伴い、 alias の一覧を作成するために init_policy.sh の中の > make_alias （ find を使ってシステムに存在する実行可能ファイルへのシンボリック > リンクを検索する処理）が不要になるため、 init_policy.sh の実行時間が短縮 > されます。スクリプトをＣプログラムで書き直せば、 .rpm や .deb の post install > セクションで実行しても容認できる程度の実行時間になるかもしれません。 > > また、ハードリンクされたプログラムの実行を自動的に区別できるだけでなく、 > シンボリックリンクされたプログラムの実行に関しても事前の準備なしで自動的に > 区別できるようになります。 > > 既存のポリシーとの互換性がないこと以外に今のところ問題は見当たりません。 > > ポリシー作成時のメリット／デメリット： > > allow_argv0 の処理は allow_execute の if exec.argv[0] で代替可能であるため、 > allow_execute の学習時に if exec.argv[0] の部分も一緒に学習させることで、 > allow_argv0 構文とプロファイルの MAC_FOR_ARGV0 を廃止することができます。 > > 代替可能と書きましたが、厳密には allow_argv0 がチェックするのは argv[0] の > 最後の / 以降だけなので、 exec.argv[0] がチェックする範囲とは異なります。 > そのため、 execlp("/bin/cat", "cat", NULL); という要求と > execlp("/bin/cat", "/bin/cat", NULL); という要求は異なるものとして > 処理されるようになります。 argv[0] の内容で権限を分けたい場合には有用ですが、 > "cat /etc/passwd" と "/bin/cat /etc/passwd" を同一視したい場合には不便です。 > ポリシー作成時とアクセス制御時とで exec.argv[0] の内容が異なっていた場合 > （学習モードでは execl("/bin/cat", "cat", NULL); を要求したが、強制モードでは > execl("/bin/cat", "/bin/cat", NULL); を要求した場合）に、アクセスが拒否されて > しまうという危険性もあります。 > > init script ディレクトリをどう処理するか検討が必要です。現状では init script > ディレクトリは alias 構文の対象外にしているため、シンボリックリンクを解決後の > パス名で学習されるので > > allow_execute /etc/rc.d/init.d/sshd > > のように１個のアクセス許可に纏まり、遷移先ドメインも１個になります。 > しかし、シンボリックリンクを解決する前のパス名で学習した場合、 > > allow_execute /etc/rc0.d/K25sshd if exec.realpath="/etc/rc.d/init.d/sshd" exec.argv[0]="/etc/rc0.d/K25sshd" > allow_execute /etc/rc1.d/K25sshd if exec.realpath="/etc/rc.d/init.d/sshd" exec.argv[0]="/etc/rc1.d/K25sshd" > allow_execute /etc/rc2.d/S55sshd if exec.realpath="/etc/rc.d/init.d/sshd" exec.argv[0]="/etc/rc2.d/S55sshd" > allow_execute /etc/rc3.d/S55sshd if exec.realpath="/etc/rc.d/init.d/sshd" exec.argv[0]="/etc/rc3.d/S55sshd" > allow_execute /etc/rc4.d/S55sshd if exec.realpath="/etc/rc.d/init.d/sshd" exec.argv[0]="/etc/rc4.d/S55sshd" > allow_execute /etc/rc5.d/S55sshd if exec.realpath="/etc/rc.d/init.d/sshd" exec.argv[0]="/etc/rc5.d/S55sshd" > allow_execute /etc/rc6.d/K25sshd if exec.realpath="/etc/rc.d/init.d/sshd" exec.argv[0]="/etc/rc6.d/K25sshd" > > のように個別のアクセス許可とドメインとして学習されてしまいます。事前に > > aggregator /etc/rc\+.d/S\+\+sshd /etc/rc.d/init.d/sshd > aggregator /etc/rc\+.d/K\+\+sshd /etc/rc.d/init.d/sshd > > のように aggregator でまとめておいた場合でも > > allow_execute /etc/rc.d/init.d/sshd if exec.realpath="/etc/rc.d/init.d/sshd" exec.argv[0]="/etc/rc0.d/K25sshd" > allow_execute /etc/rc.d/init.d/sshd if exec.realpath="/etc/rc.d/init.d/sshd" exec.argv[0]="/etc/rc1.d/K25sshd" > allow_execute /etc/rc.d/init.d/sshd if exec.realpath="/etc/rc.d/init.d/sshd" exec.argv[0]="/etc/rc2.d/S55sshd" > allow_execute /etc/rc.d/init.d/sshd if exec.realpath="/etc/rc.d/init.d/sshd" exec.argv[0]="/etc/rc3.d/S55sshd" > allow_execute /etc/rc.d/init.d/sshd if exec.realpath="/etc/rc.d/init.d/sshd" exec.argv[0]="/etc/rc4.d/S55sshd" > allow_execute /etc/rc.d/init.d/sshd if exec.realpath="/etc/rc.d/init.d/sshd" exec.argv[0]="/etc/rc5.d/S55sshd" > allow_execute /etc/rc.d/init.d/sshd if exec.realpath="/etc/rc.d/init.d/sshd" exec.argv[0]="/etc/rc6.d/K25sshd" > > のように学習され、遷移先ドメインは１個になりますがアクセス許可は個別のままに > なってしまいます。学習後に手作業で exec.argv[0] の部分を削って > > allow_execute /etc/rc.d/init.d/sshd if exec.realpath="/etc/rc.d/init.d/sshd" > > のようにすれば、現状と同様に１個のアクセス許可と遷移先ドメインに > 集約できます。 > > アクセス制御時のメリット／デメリット： > > 自動的に argv[0] のチェックも行われるようになるため、 MAC_FOR_ARGV0 を有効に > していなかった場合と比べてセキュリティが向上しますが、 MAC_FOR_ARGV0 を > 有効にしていなかった場合と比べてパフォーマンスが低下すると予想されます。 > > 要検討事項： > > 常に if 節以降を付与することになるので構文が長くなって鬱陶しいと感じる > 可能性があります。 > > 構文が長くなるのを回避するための方法として、学習時には、 > 「パーミッションのチェックと遷移先ドメインを計算するのに利用するパス名 > （シンボリックリンク可）」が「シンボリックリンク解決後の絶対パス名」と > 一致する場合には exec.realpath= の部分を省略させ、 > 「パーミッションのチェックと遷移先ドメインを計算するのに利用するパス名 > （シンボリックリンク可）」が「最初の引数」と一致する場合には > exec.argv[0]= の部分を省略させるという選択肢があります。 > > ただし、省略させた場合、「一致するかどうかのチェックを省略する」のか、 > 「一致するかどうかチェックする」のかを決めなければなりません。 > 前節の仕様からは「一致するかどうかチェックする」と解釈するのが妥当ですが、 > 何らかの理由により「一致するかどうかのチェックを省略させたい」場合があった > 場合に対処できなくなります。 > > 学習時に省略しないようにすれば、何らかの理由により「一致するかどうかの > チェックを省略させたい」場合にも対処できるようになります。 > > > > その他、次期バージョンでは system_policy の内容を exception_policy または > domain_policy に移動させて、 system_policy を廃止しようと思っています。 > RESTRICT_MOUNT/RESTRICT_UNMOUNT/RESTRICT_CHROOT/RESTRICT_PIVOT_ROOT は > 統合して MAC_FOR_NAMESPACE に改名し、 domain_policy で指定するようにしたいと > 思います。 DENY_CONCEAL_MOUNT は MAC_FOR_CAPABILITY::allow_conceal_mount に > 改名しようと思っています。 > RESTRICT_AUTOBIND は（他のアクセス制御とは異なりスリープすることが許されて > いないため if 節等をサポートできないので）改名はせず、また、ドメイン単位で > 指定できる必要性が感じられないことから exception_policy で指定するように > したいと思います。 > ソースコード中の #ifdef を減らすために、カーネルコンフィグの CONFIG_SAKURA と > CONFIG_TOMOYO と CONFIG_SYAORAN を統合して CONFIG_CCSECURITY に改名したいと > 思います。 > > > > ・・・ということで、コメント・質問など募集しま〜す。 > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -- 宍道 洋 hiroshi.shinji ＠ gmail.com http://d.hatena.ne.jp/hshinji/ From hiroshi.shinji ＠ gmail.com Tue Jul 7 04:44:36 2009 From: hiroshi.shinji ＠ gmail.com (Hiroshi Shinji) Date: Tue, 7 Jul 2009 04:44:36 +0900 Subject: [Tomoyo-dev 1112] Re: =?iso-2022-jp?b?aW5pdF9wb2xpY3kuc2ggGyRCJE44K0Q+JDckSyREGyhC?= =?iso-2022-jp?b?GyRCJCQkRhsoQg==?= In-Reply-To: <9292c1390907060715k6ed8c582meb1c11ed7602acc2@mail.gmail.com> References: <200907060458.n664w723081766@www262.sakura.ne.jp> <9292c1390907060715k6ed8c582meb1c11ed7602acc2@mail.gmail.com> Message-ID: 宍道です。 >> つまり、 init_policy.sh を大幅に簡略化して、学習モードでざっと学習後に >> パターン化を行うというアプローチに移行してはどうかというアイデアです。 >> どうでしょう？ > > アリだと思います。というか、現在のinit_policy.shはあまりにも重すぎて > 利用者への心理的な不安が大きいので、積極的に賛成します。 私も賛成です。 > ただ、できればこの種のメールは先に提案を書いてくださいorz これも同感。 2009/07/06 23:15 に hito さんは書きました: >> つまり、 init_policy.sh を大幅に簡略化して、学習モードでざっと学習後に >> パターン化を行うというアプローチに移行してはどうかというアイデアです。 >> どうでしょう？ > > アリだと思います。というか、現在のinit_policy.shはあまりにも重すぎて > 利用者への心理的な不安が大きいので、積極的に賛成します。 > > > ただ、できればこの種のメールは先に提案を書いてくださいorz > > これ↓を読んでからでないと本文の一部を解釈するのがツラくて、二回メールを > 読まないといけないので、なんつーか読むのがキビシイものがありますです。 >> init_policy.sh を大幅に簡略化して、学習モードでざっと学習後に >> パターン化を行うというアプローチに移行してはどうかというアイデアです。 >> どうでしょう？ > > これはメールの頭に欲しいところです。 > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -- 宍道 洋 hiroshi.shinji ＠ gmail.com http://d.hatena.ne.jp/hshinji/ From from-tomoyo-dev ＠ i-love.sakura.ne.jp Tue Jul 7 11:17:08 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (Tetsuo Handa) Date: Tue, 07 Jul 2009 11:17:08 +0900 Subject: [Tomoyo-dev 1113] Re: =?iso-2022-jp?b?VE9NT1lPIBskQiROPCE0fCVQITwlOCVnJXMkWDh+GyhC?= =?iso-2022-jp?b?GyRCJDEkRiROO0VNTUpROTkkSyREJCQkRhsoQg==?= In-Reply-To: References: <200906271625.FHH57319.UZPWGPtNPPEtNSF@I-love.SAKURA.ne.jp> Message-ID: <200907070217.n672H8qD063608@www262.sakura.ne.jp> 　熊猫です。 Hiroshi Shinji さんは書きました： > どの程度、チェックに処理コストがかかるのかによりますが、 > パフォーマンス優先などで、チェックを省略させたい場合はあると思います。 > では、 MAC_FOR_ARGV0 と allow_argv0 は残したまま、 alias 構文だけを廃止して、 学習モードでは 　allow_execute パーミッションのチェックと遷移先ドメインを計算するのに利用するパス名（シンボリックリンク可） だけを学習し、必要に応じて手作業で 　exec.realpath="シンボリックリンク解決後の絶対パス名" 　exec.argv[0]="最初の引数" を追加することで 　allow_execute シンボリックリンクのパス名 if exec.realpath="シンボリックリンク解決後の絶対パス名" exec.argv[0]="最初の引数" のような形でのチェックもできるようにする、 というのはどうでしょう？ alias 構文が登場した当時（ TOMOYO 1.1.3 でサポート）はシンボリックリンクの 作成時にリンク先を制限する機能（ TOMOYO 1.6.8 でサポート）がまだ無かったので、 シンボリックリンクとそのリンク先をセットにして実行許可をチェックしないと 許可されていないプログラムの実行を認めてしまう危険性が非常に高かったです。 しかし、 allow_argv0 構文（ TOMOYO 1.2 でサポート）が追加され、 exec.argv[0] 構文と execute_handler 機能（どちらも TOMOYO 1.6.0 でサポート）も 追加された現在（ TOMOYO 1.6.8 ）では、 「実行が許可されていないプログラムへのシンボリックリンクを作成すること」も 「許可されていない argv[0] の内容で実行が許可されているプログラムを実行する こと」も非常に困難になっています。 つまり、そろそろ「 alias で明示された場合のみシンボリックリンクのパス名を 用いて実行許可をチェックする」という制約を廃止しても差し支えない状況に なってきたのではないかと思います。 （ MAC_FOR_FILE=enforcing にしない限り自由にシンボリックリンクを作成して 実行することが許可されてしまうため、 MAC_FOR_FILE=enforcing ではない場合には 対処できません。） 簡単なチェックを行いたい場合には allow_argv0 構文を、厳密なチェックを行いたい 場合には if exec.argv[0]= 構文を、 if exec.argv[0]= 構文では処理しきれない ような複雑なチェックを行いたい場合には execute_handler 機能を使います。 まだ「 exec.realpath="実体のパス名" 」の部分を実装していませんが、それ以外は branches/ccs-patch/ の rev 2738 以降で機能するかと思います。 ccs-patch-\*.diff は TOMOYO 1.6.8 用のをそのまま使えますが、 コンパイル前にカーネルコンフィグの更新が必要です。 > 学習時に省略した形式でのポリシー生成が出きるようなオプションがあれば > うれしいのですがどうでしょう？ > （省略した形式で使いたい場合、修正にかかる作業量がとても多そう…） > 機械的に exec.realpath= な部分を削っていけば済むのでそんなに大変な作業では 無いと思いますが・・・。まぁ、最初から if 節が付くと初心者には鬱陶しいかも しれないのでデフォルトは if 節無しですかねぇ。 From hiroshi.shinji ＠ gmail.com Wed Jul 8 04:15:40 2009 From: hiroshi.shinji ＠ gmail.com (Hiroshi Shinji) Date: Wed, 8 Jul 2009 04:15:40 +0900 Subject: [Tomoyo-dev 1114] Re: =?iso-2022-jp?b?aW5pdF9wb2xpY3kuc2ggGyRCJE44K0Q+JDckSyREGyhC?= =?iso-2022-jp?b?GyRCJCQkRhsoQg==?= In-Reply-To: <200907060458.n664w723081766@www262.sakura.ne.jp> References: <200907060458.n664w723081766@www262.sakura.ne.jp> Message-ID: 宍道です。 > （ make_alias() 部分は既に make_alias.c に置き換わっています。） make_alias.c 内で使用している scandir(3) は、システムコール getdents(2) を 呼び出していますが、d_type が利用できないファイルシステムもあります。 そのため、make_alias が全く動作しないシステムもあります。 getdents(2) の man page にあるテストコードを実行してみると、 ext3 の PCじょうでは、 $ ./test_i386 / --------------- nread=592 --------------- i-node# file type d_reclen d_off d_name 11 directory 24 45429244 lost+found 2842465 directory 16 63512428 dev 9997633 directory 16 291069474 home 9670913 directory 16 299722205 root ＜以下略＞ とでますが、initrd を使って起動している機器では # ./test_ppc / --------------- nread=256 --------------- i-node# file type d_reclen d_off d_name 2 ??? 16 12 . 2 ??? 16 24 .. 337 ??? 16 36 bin 30 ??? 16 48 dev 111 ??? 16 60 etc ＜以下略＞ などと出てきます。 ということで、スクリプト版の make_alias() も（現在のように コメントアウトした状態で良いので）使えるようにしておいて もらえるとありがたいです。 ＃ alias 構文がある間は。 2009/07/06 13:58 に Tetsuo Handa さんは書きました: > 　熊猫です。 > > 組込み環境だと find とか which とかを用意するのが面倒なのと、 > 処理時間を短縮することで .rpm や .deb の post install セクションで > ポリシーの初期化をしてしまおうという企みのもと、 init_policy.c の > make_exception() 部分をＣプログラム化してみました。 > http://sourceforge.jp/projects/tomoyo/svn/view/branches/ccs-tools/ccstools/make_exception.c?root=tomoyo&view=co&content-type=text%2Fplain > （ make_alias() 部分は既に make_alias.c に置き換わっています。） > （↓所要時間は環境により大きく異なります。） > > −−− init_policy.sh の make_exception() １回目−−− > real 0m10.579s > user 0m0.167s > sys 0m1.109s > > −−− make_exception.c １回目−−− > real 0m9.431s > user 0m0.003s > sys 0m0.293s > > −−− init_policy.sh の make_exception() ２回目−−− > real 0m0.921s > user 0m0.155s > sys 0m0.833s > > −−− make_exception.c ２回目−−− > real 0m0.044s > user 0m0.017s > sys 0m0.029s > > ディスクアクセス待ちが実行時間のほとんどを占めているので > 処理時間の短縮効果はあまり無いことが判りました。 > > 重たいのは file_pattern と allow_read を登録するために > find で /usr/share 以下から fonts ディレクトリや icons ディレクトリなどを > 検索する処理だと考えています。 > > これらは学習モードで学習された後に \* に置換しても差し支えないでしょうし、 > ディレクトリ階層が意味を持たないので file_pattern を使って複数行として学習 > させるよりも path_group を使って手動で１行の @ に置換する方が適していると > 思います。 > でしたら、 ccs-savepolicy の実行前または後に何らかのコマンドを実行することで > 学習後に置換させるという方法が考えられます。（現在は ccs-patternize という > コマンドがありますが、パターンを自分で与える必要があるため、あまり使われて > いないと思います。） > > 最初から init_policy.sh に全てのプログラム用の file_pattern と allow_read が > 記述されていれば良いのですが、予め全てのパターンを網羅することは不可能です。 > さらに、予め file_pattern や allow_read を作成する方法だと、一度 > exception_policy.conf を作成した後は ccs-tools がアップデートされて > init_policy.sh に新しいパターン情報が追加されたとしても反映されません。 > > でしたら、 init_policy.sh には必要最低限のパターンのみを登録し、 > 新しい file_pattern や allow_read が追加されたら domain_policy.conf を更新する > という方法をとる方が使いやすいような気がしています。 > > つまり、 init_policy.sh を大幅に簡略化して、学習モードでざっと学習後に > パターン化を行うというアプローチに移行してはどうかというアイデアです。 > どうでしょう？ > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -- 宍道 洋 hiroshi.shinji ＠ gmail.com http://d.hatena.ne.jp/hshinji/ From matsuu ＠ gmail.com Wed Jul 8 08:52:38 2009 From: matsuu ＠ gmail.com (MATSUU Takuto) Date: Wed, 8 Jul 2009 08:52:38 +0900 Subject: [Tomoyo-dev 1115] Re: =?iso-2022-jp?b?c3VucmlzZSBvdmVybGF5IBskQiRLGyhCIGNjcy10b29s?= =?iso-2022-jp?b?cyAbJEIkLCRPJCQkaiReJDckPxsoQg==?= In-Reply-To: References: <87tz2qew5h.fsf@yue.localnetwork> <200907041135.AJD13090.NNPFUtSWEPGPtZP@I-love.SAKURA.ne.jp> <87prcgohnk.fsf@yue.localnetwork> <200907042130.FAJ00501.NZUPFPtEWPPNtSG@I-love.SAKURA.ne.jp> Message-ID: 松鵜です。 ebuild作成／検証時にいくつか気になった点を質問させていただきます。 ■ccs-toolsをautotoolize化しませんか？ autotoolizeのメリットはこんな感じです。 -configureオプションでカスタマイズ用オプションを容易に作成できる -インストールディレクトリのカスタマイズが楽 -source tarballの作成が楽になる（make dist） -各ディストリビューションでのバイナリパッケージ作成が楽になる（はず） -その他諸々（すみません、あるはずなんですがすぐ思いつかず） Gentooのポリシーではあるのですが、64ビット環境では /usr/lib/ではなく/usr/lib64/と/usr/lib32/にを使うため、 インストール先を環境に合わせて適宜変更する必要があります。 autotoolize化されていれば、変更も非常に楽です。 試しにautotoolize化したものを以下に設置しています。 http://github.com/matsuu/ccs-tools/tree/master 主な変更点は以下です。 COPYING.ccsをCOPYINGへ名称変更。 README.ccsをREADMEとChangeLogへ分割。 man/man8/*.8.gzをgunzipで解凍。 conifgure.ac(autoscanの自動生成ベース)を作成。 各ディレクトリ内にMakefile.amを作成、Makefileは削除。 ccstools/直下にあるccstools.src/と*.cと各スクリプトをsrcディレクトリへ移動。 ■使用されていないファイルについて autotoolize時に気づいたのですが、次に列挙するのファイルは現在使用されていない との認識で間違いないでしょうか。 ccstools/env_chk.c ccstools/from-where.c ccstools/statvfs.c ccstools/kernel_test/dummyfs.c ccstools/kernel_test/generate_execve_log.c ccstools/man/ccs-auditd ccstools/man/ccs-ccstree ccstools/man/ccs-checkpolicy ccstools/man/ccs-domainmatch ccstools/man/ccs-editpolicy ccstools/man/ccs-editpolicy-agent ccstools/man/ccs-findtemp ccstools/man/ccs-init ccstools/man/ccs-ld-watch ccstools/man/ccs-loadpolicy ccstools/man/ccs-notifyd ccstools/man/ccs-pathmatch ccstools/man/ccs-patternize ccstools/man/ccs-queryd ccstools/man/ccs-savepolicy ccstools/man/ccs-setlevel ccstools/man/ccs-setprofile ccstools/man/ccs-sortpolicy ccstools/man/init_policy.sh ccstools/man/tomoyo-init ccstools/man/tomoyo_init_policy.sh ■kernel_testに含まれるテストについて kernel-2.6.30環境(2.2.x)においてkernel_test/testall.shが書いてあるとおりに動作しません。 どのテストも標準出力に何も表示されませんでした。 kernel_test/に含まれるテストは1.6.x用でしょうか。 ■/usr/lib/ccs/realpathについて 同じような機能を提供するrealpathがdebianからリリースされています。 http://packages.debian.org/unstable/utils/realpath 引数が異なるため現行のそのまま置き換えにはならないかもしれませんが、 こちらを利用される予定はないでしょうか。 ■パターンの表記規則について 何も分かっていない素人質問で恐縮ですが、「特定ディレクトリ配下全て」の意味になる ワイルドカード指定はできないのでしょうか。\*/\*/\*/...と書いてしまうのと配下全て指定 で、セキュリティ懸念上の違いが思いつかなかったのですが・・・。 ■so many ACLS to hold tomoyoをインストールしたGentooのデスクトップPCにおいて、 so many ACLs to holdでWARNINGが出てしましました、という報告です。 TOMOYO-WARNING: Domain ' /etc/init.d/xdm /lib64/rc/sh/runscript.sh /etc/X11/startDM.sh /sbin/start-stop-daemon /usr/bin/gdm /etc/X11/gdm/Xsession /usr/bin/awesome /usr/bin/firefox /usr/lib64/mozilla-firefox/firefox' has so many ACLs to hold. Stopped learning mode. 利用環境がバレバレですね -- 以上です。 From from-tomoyo-dev ＠ i-love.sakura.ne.jp Wed Jul 8 13:05:09 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (Tetsuo Handa) Date: Wed, 08 Jul 2009 13:05:09 +0900 Subject: [Tomoyo-dev 1116] Re: =?iso-2022-jp?b?c3VucmlzZSBvdmVybGF5IBskQiRLGyhCIGNjcy10b29s?= =?iso-2022-jp?b?cyAbJEIkLCRPJCQkaiReJDckPxsoQg==?= In-Reply-To: References: <87tz2qew5h.fsf@yue.localnetwork> <200907041135.AJD13090.NNPFUtSWEPGPtZP@I-love.SAKURA.ne.jp> <87prcgohnk.fsf@yue.localnetwork> <200907042130.FAJ00501.NZUPFPtEWPPNtSG@I-love.SAKURA.ne.jp> Message-ID: <200907080405.n68459UY083837@www262.sakura.ne.jp> 　熊猫です。 MATSUU Takuto さんは書きました： > ■ccs-toolsをautotoolize化しませんか？ > ccs-patch と ccs-tools はこちらで把握している以下の環境で同様にコンパイル／ 実行ができるように作成されています。（特定のディストリビューションでしか 動作しないパッケージ／コマンドを使わないようにしています。） * RedHat Linux 9 * Fedora Core 3/4/5/6 * Fedora 7/8/9/10/11 * CentOS 3.9/4.7/5.3 * Debian Sarge/Etch/Lenny * OpenSUSE 10.1/10.2/10.3/11.0/11.1 * Asianux 2.0/3.0 * Ubuntu 6.06/6.10/7.04/7.10/8.04/8.10/9.04 * Vine Linux 4.2 * Gentoo * Turbolinux Server 10/11 * Turbolinux Client 2008 * Mandriva 2008.1/2009.0 ざっと見た限り、上記の環境の内で最も古いパッケージは RedHat Linux 9/CentOS 3.9 の 　autoconf-2.57-3.noarch.rpm 　automake-1.6.3-5.noarch.rpm だと思われます。 http://www.spa.is.uec.ac.jp/~kinuko/slidemaker/autotools/slide2-0.html によると「細かいバージョンアップのたびに仕様がどんどん変わる」とのことで、 古めのディストリビューションでも動作することを確認してからでないと 決められないですね。 > autotoolize化されていれば、変更も非常に楽です。 > autotools 対応すると deb パッケージ化する上でも便利でしょうか？＞やまねさん＆ hito さん > ■使用されていないファイルについて > > autotoolize時に気づいたのですが、次に列挙するのファイルは現在使用されていない > との認識で間違いないでしょうか。 > > ccstools/env_chk.c > ccstools/from-where.c > ccstools/statvfs.c > ccstools/kernel_test/dummyfs.c > ccstools/kernel_test/generate_execve_log.c > ccstools/man/ccs-auditd > ccstools/man/ccs-ccstree > ccstools/man/ccs-checkpolicy > ccstools/man/ccs-domainmatch > ccstools/man/ccs-editpolicy > ccstools/man/ccs-editpolicy-agent > ccstools/man/ccs-findtemp > ccstools/man/ccs-init > ccstools/man/ccs-ld-watch > ccstools/man/ccs-loadpolicy > ccstools/man/ccs-notifyd > ccstools/man/ccs-pathmatch > ccstools/man/ccs-patternize > ccstools/man/ccs-queryd > ccstools/man/ccs-savepolicy > ccstools/man/ccs-setlevel > ccstools/man/ccs-setprofile > ccstools/man/ccs-sortpolicy > ccstools/man/init_policy.sh > ccstools/man/tomoyo-init > ccstools/man/tomoyo_init_policy.sh > env_chk.c from-where.c statvfs.c dummyfs.c generate_execve_log.c は ソースコードのみで、コンパイルはされないので、バイナリパッケージには 含まれません。 man/ 以下のファイルは make install によりインストールされるので、 使用されています。 > ■kernel_testに含まれるテストについて > kernel-2.6.30環境(2.2.x)においてkernel_test/testall.shが書いてあるとおりに動作しません。 > どのテストも標準出力に何も表示されませんでした。 > テストプログラムは /tmp/ に tmpfs をマウントするため、 kernel_test/ を /tmp/ の下に展開して実行した場合には何も表示されません。 > kernel_test/に含まれるテストは1.6.x用でしょうか。 > いくつかは 2.2.x でも動作しますが、多くは 1.6.x 用です。 LTP 向けに作成した 2.2.0 用のテストプログラムが http://sourceforge.jp/projects/tomoyo/svn/view/trunk/2.2.x/kernel_test/?root=tomoyo にあります。これらは http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/security/ に移動する予定です。 > ■/usr/lib/ccs/realpathについて > 同じような機能を提供するrealpathがdebianからリリースされています。 > > http://packages.debian.org/unstable/utils/realpath > > 引数が異なるため現行のそのまま置き換えにはならないかもしれませんが、 > こちらを利用される予定はないでしょうか。 > ありません。 Turbolinux さんの /usr/bin/readlink は teTeX パッケージに含まれる もので、 -f や -n オプションを認識できない仕様であることが判明したため、 readlink -f を実行するだけのプログラムとして ccs-tools 内に realpath コマンドを 含めました。 ただし、今後 init_policy.sh がＣプログラムで置き換えられるようになると 思うので、 realpath コマンドはもうじき ccs-tools から削除されるでしょう。 さらに、 which コマンドや find コマンドも不要になることでしょう。 > ■パターンの表記規則について > 何も分かっていない素人質問で恐縮ですが、「特定ディレクトリ配下全て」の意味になる > ワイルドカード指定はできないのでしょうか。\*/\*/\*/...と書いてしまうのと配下全て指定 > で、セキュリティ懸念上の違いが思いつかなかったのですが・・・。 > 現在はサポートしていません。同じ要望を何人からも受けているので、いつかは 実装する羽目になるのかもしれませんが。 この変更は TOMOYO のパターンマッチング処理を根底から覆す可能性があります。 現在は、パターンマッチを行う前に / の数を比較し、 / の数が一致している場合だけ パターンマッチを行うという仕様になっています。例えば /bin/true が /\*/\*/\*/\* と一致するかどうかは / の数を数えるだけで判ります。 これにより絶対一致しないパターンとの比較を省略して処理を高速化しているのです。 / と一致するワイルドカードを認めてしまうと、省略できなくなってしまいます。 また、速度面だけでなく、指定方法も考えなければいけません。 名前ベースのアクセス制御は、ディレクトリ内のファイル名を制限できることが 利点であり、それが活かせないような指定方法はしてほしくないのです。 http://thinkit.jp/article/973/1/ 向けに用意したものの使われなかった原稿 −−−−−始め−−−−− SELinux FAQ （ http://www.nsa.gov/research/selinux/faqs.shtml#I2 ）では、 「 SELinux により保護されたシステムのセキュリティは主にカーネルとポリシーの 正しさに依存する。」と述べていますが、同時に「アプリケーションの正しさや設定に 起因する問題により部分的な被害を生じる場合がある。」と限界があることも述べて います。 SELinux は権限のないユーザやアプリケーションから資源を確実に分離し 保護することを得意とします。しかし、権限のあるユーザやアプリケーションに資源を 悪用されてしまうと分離や保護が役に立たなくなってしまう場合が起こります。 TOMOYO はアプリケーションの「意図」に基づいてアクセスを制限することにより資源を 保護します。幾つか例を示しましょう。 （１）Ｗｅｂサーバからシェル（ /bin/sh ）の実行が要求された。パラメータは一切 　　　与えられなかった。 （２）Ｗｅｂサーバからシェル（ /bin/sh ）の実行が要求された。パラメータとして 　　　-c と /usr/lib/sendmail -t という２つが与えられた。 （３）Ｗｅｂサーバから /var/www/html/history.html というファイルの名前を 　　　/var/www/html/.htaccess という名前に変更することが要求された。 （４）Ｗｅｂサーバから /var/www/html/history.html というファイルの名前を 　　　/var/www/history.bak という名前に変更することが要求された。 （１）の場合は、目的を示さずにシェルの実行を要求しています。これは、悪意ある ユーザがＷｅｂサーバへの侵入を試みている可能性が高いので拒否すべきです。 （２）の場合は、 sendmail の実行を要求しています。ＣＧＩからメールを 送信しようとしていると考えられるので、きっと許可することでしょう。 （３）の場合は、Ｗｅｂコンテンツを設定ファイルに置き換えることを要求 しています。 .htaccess や .htpasswd などはＷｅｂサーバの動作に影響を与える ファイル名であり、悪意あるユーザがＷｅｂサーバへのリクエストを（例えば マルウェアの配布サイト宛に）転送しようとしている可能性が高いので、 拒否すべきです。 （４）の場合は、Ｗｅｂコンテンツのバックアップを作成することを要求しています。 ＣＧＩからのリクエストであると考えられるので、きっと許可することでしょう。 このように、 TOMOYO はファイルの名前やコマンドライン引数や環境変数など、 アプリケーションが何をしようとしているのかに基づいて、アクセスを制限することが できます。 従来、アプリケーションがどのような資源にアクセスするかの判断は アプリケーションに任されていましたが、セキュリティホールなどにより判断を 回避される場合がありました。その判断を TOMOYO も行うことで、 ベースラインとしてのパラメータチェック機能を与えることができるようになります。 TOMOYO はカーネルに埋め込まれたアプリケーションファイアウォールのように 機能するわけです。そのため、 SELinux の苦手とする分野を補うことができます。 −−−−−終わり−−−−− せっかく TOMOYO が詳細な粒度のパターンマッチング機能を提供しているのに、 \*.html ではなく \* で集約されてしまっては、 SELinux でも行えるディレクトリ 単位の粒度に落ちてしまいます。 なので、/ を含めた任意の文字に一致するワイルドカードを \& と仮定した場合、 /var/www/html/\& という指定がされてしまうのは嬉しくありません。 /var/www/html/\&/\*.html ならば良いのですが。 あとは \& と \- が組み合わさった場合をどう解釈するかですね。 > ■so many ACLS to hold > tomoyoをインストールしたGentooのデスクトップPCにおいて、 > so many ACLs to holdでWARNINGが出てしましました、という報告です。 > > TOMOYO-WARNING: Domain ' /etc/init.d/xdm > /lib64/rc/sh/runscript.sh /etc/X11/startDM.sh /sbin/start-stop-daemon > /usr/bin/gdm /etc/X11/gdm/Xsession /usr/bin/awesome /usr/bin/firefox > /usr/lib64/mozilla-firefox/firefox' has so many ACLs to hold. Stopped > learning mode. > はい。これは全てのメモリを食いつぶしてシステムがクラッシュするのを 回避するための安全装置が作動しただけです。 profile.conf の MAX_ACCEPT_ENTRY で 指定された数までしか学習モードでは追加されません。 > 利用環境がバレバレですね はい。ひとつ残らず記録しようとするのが知世ちゃんですから。 バッテリーの無駄遣いを防ぐためにブレーキを掛けてやらないといけない場面も あるかと。（＾＾； From from-tomoyo-dev ＠ i-love.sakura.ne.jp Wed Jul 8 13:14:56 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (Tetsuo Handa) Date: Wed, 08 Jul 2009 13:14:56 +0900 Subject: [Tomoyo-dev 1117] Re: =?iso-2022-jp?b?aW5pdF9wb2xpY3kuc2ggGyRCJE44K0Q+JDckSyREGyhC?= =?iso-2022-jp?b?GyRCJCQkRhsoQg==?= In-Reply-To: References: <200907060458.n664w723081766@www262.sakura.ne.jp> Message-ID: <200907080414.n684EujI086434@www262.sakura.ne.jp> 　熊猫です。 Hiroshi Shinji さんは書きました： > make_alias.c 内で使用している scandir(3) は、システムコール getdents(2) を > 呼び出していますが、d_type が利用できないファイルシステムもあります。 > そのため、make_alias が全く動作しないシステムもあります。 あらら。ライブラリ側の仕様ではなくてカーネル側（ファイルシステム側）の仕様で そうなってしまうんですか。 > ということで、スクリプト版の make_alias() も（現在のように > コメントアウトした状態で良いので）使えるようにしておいて > もらえるとありがたいです。 > ＃ alias 構文がある間は。 getdents() で DT_UNKNOWN となってしまったとしても、 lstat() で再チェックすれば "struct stat"->st_mode から判断することはできますよね？（そうでなかったら ls -l でファイル種別を表示できないでしょうし。） make_exception.c では DT_UNKNOWN の場合は lstat() で再チェックしています。 make_alias.c でも再チェックするようにしてやれば initrd を使って起動している 機器でも動作できるのではないでしょうか？ From from-tomoyo-dev ＠ i-love.sakura.ne.jp Wed Jul 8 13:43:31 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (Tetsuo Handa) Date: Wed, 08 Jul 2009 13:43:31 +0900 Subject: [Tomoyo-dev 1118] Re: =?iso-2022-jp?b?c3VucmlzZSBvdmVybGF5IBskQiRLGyhCIGNjcy10b29s?= =?iso-2022-jp?b?cyAbJEIkLCRPJCQkaiReJDckPxsoQg==?= In-Reply-To: <200907080405.n68459UY083837@www262.sakura.ne.jp> References: <87tz2qew5h.fsf@yue.localnetwork> <200907041135.AJD13090.NNPFUtSWEPGPtZP@I-love.SAKURA.ne.jp> <87prcgohnk.fsf@yue.localnetwork> <200907042130.FAJ00501.NZUPFPtEWPPNtSG@I-love.SAKURA.ne.jp> <200907080405.n68459UY083837@www262.sakura.ne.jp> Message-ID: <200907080443.n684hVB1092245@www262.sakura.ne.jp> 　熊猫です。 Tetsuo Handa さんは書きました： > man/ 以下のファイルは make install によりインストールされるので、 > 使用されています。 間違えました。 man/man8/ 以下のファイルは make install によりインストールされるので 使用されていますが、 man/ 直下のファイルはバイナリパッケージには含まれません。 From from-tomoyo-dev ＠ i-love.sakura.ne.jp Wed Jul 8 14:55:25 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Wed, 08 Jul 2009 14:55:25 +0900 Subject: [Tomoyo-dev 1119] Re: =?iso-2022-jp?b?c3VucmlzZSBvdmVybGF5IBskQiRLGyhCIGNjcy10b29s?= =?iso-2022-jp?b?cyAbJEIkLCRPJCQkaiReJDckPxsoQg==?= In-Reply-To: References: <87tz2qew5h.fsf@yue.localnetwork> <200907041135.AJD13090.NNPFUtSWEPGPtZP@I-love.SAKURA.ne.jp> <87prcgohnk.fsf@yue.localnetwork> <200907042130.FAJ00501.NZUPFPtEWPPNtSG@I-love.SAKURA.ne.jp> Message-ID: <200907080555.n685tQi8009381@www262.sakura.ne.jp> 　熊猫です。 MATSUU Takuto さんは書きました： > 試しにautotoolize化したものを以下に設置しています。 > > http://github.com/matsuu/ccs-tools/tree/master > CentOS 3.9 で試しました。エラーは起きませんでした。 > 主な変更点は以下です。 > > COPYING.ccsをCOPYINGへ名称変更。 > README.ccsをREADMEとChangeLogへ分割。 > man/man8/*.8.gzをgunzipで解凍。 > conifgure.ac(autoscanの自動生成ベース)を作成。 > 各ディレクトリ内にMakefile.amを作成、Makefileは削除。 > ccstools/直下にあるccstools.src/と*.cと各スクリプトをsrcディレクトリへ移動。 > インストールディレクトリのデフォルトが /usr/ ではなく /usr/local/ に なっているんですね。 Makefile が削除されたことで、 ccs-tools.spec を使った rpmbuild が動作しなく なりました。今までは Makefile で INSTALLDIR=%{buildroot} という形で （ rpmbuild から見た） make install 時のルートディレクトリを指定していました。 （つまり chroot 相当の機能がありました。） rpmbuild にとっては、 make install 時のルートディレクトリは /var/tmp/ccs-tools-1.6.8-2-buildroot/ なのですが、 ./configure の実行時に --prefix で指定する /usr/ や /usr/local/ とは異なるものです。 ccs-tools.spec の %build と %install の中から 　./configure 　make 　make install を呼ぶように修正することになるのだと思っていますが、 make install 時に （ rpmbuild のために） /var/tmp/ccs-tools-1.6.8-2-buildroot/ を ルートディレクトリとして、 /usr/ や /usr/local/ にインストールすることは 可能なのでしょうか？（それができない場合は / をルートディレクトリとして、 ccs-tools.spec の %files で１ファイルずつ指定するという事態になります。） From from-tomoyo-dev ＠ i-love.sakura.ne.jp Wed Jul 8 16:41:42 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (Tetsuo Handa) Date: Wed, 08 Jul 2009 16:41:42 +0900 Subject: [Tomoyo-dev 1120] Re: =?iso-2022-jp?b?aW5pdF9wb2xpY3kuc2ggGyRCJE44K0Q+JDckSyREGyhC?= =?iso-2022-jp?b?GyRCJCQkRhsoQg==?= In-Reply-To: References: <200907060458.n664w723081766@www262.sakura.ne.jp> Message-ID: <200907080741.n687fgn4033652@www262.sakura.ne.jp> 　熊猫です。 ↓で動きますでしょうか？ http://sourceforge.jp/projects/tomoyo/svn/view/branches/ccs-tools/ccstools/make_alias.c?view=markup&root=tomoyo From matsuu ＠ gmail.com Wed Jul 8 22:30:58 2009 From: matsuu ＠ gmail.com (MATSUU Takuto) Date: Wed, 8 Jul 2009 22:30:58 +0900 Subject: [Tomoyo-dev 1121] Re: =?iso-2022-jp?b?c3VucmlzZSBvdmVybGF5IBskQiRLGyhCIGNjcy10b29s?= =?iso-2022-jp?b?cyAbJEIkLCRPJCQkaiReJDckPxsoQg==?= In-Reply-To: <200907080555.n685tQi8009381@www262.sakura.ne.jp> References: <87tz2qew5h.fsf@yue.localnetwork> <200907041135.AJD13090.NNPFUtSWEPGPtZP@I-love.SAKURA.ne.jp> <87prcgohnk.fsf@yue.localnetwork> <200907042130.FAJ00501.NZUPFPtEWPPNtSG@I-love.SAKURA.ne.jp> <200907080555.n685tQi8009381@www262.sakura.ne.jp> Message-ID: 松鵜です。 諸々ご回答ありがとうございます。 > Makefile が削除されたことで、 ccs-tools.spec を使った rpmbuild が動作しなく > なりました。今までは Makefile で INSTALLDIR=%{buildroot} という形で > （ rpmbuild から見た） make install 時のルートディレクトリを指定していました。 > （つまり chroot 相当の機能がありました。） > > rpmbuild にとっては、 make install 時のルートディレクトリは > /var/tmp/ccs-tools-1.6.8-2-buildroot/ なのですが、 ./configure の実行時に > --prefix で指定する /usr/ や /usr/local/ とは異なるものです。 > ccs-tools.spec の %build と %install の中から > > ./configure > make > make install > > を呼ぶように修正することになるのだと思っていますが、 make install 時に > （ rpmbuild のために） /var/tmp/ccs-tools-1.6.8-2-buildroot/ を > ルートディレクトリとして、 /usr/ や /usr/local/ にインストールすることは > 可能なのでしょうか？（それができない場合は / をルートディレクトリとして、 > ccs-tools.spec の %files で１ファイルずつ指定するという事態になります。） > すみません、ccs-tools.specをautotoolを利用する形に変更してませんでした。 ccs-tools.spec.inを作成／追加したものを反映しました。specファイル自体のテスト はまだですが、こんな感じになります。 configureを実行するとccs-tools.specが生成されます。 autotool化されたMakefileの場合、INSTALLDIR相当の機能はDESTDIRが該当します。 specとautotoolsは親和性が高く、./configure --prefix=/usr... は %configure で、 make DESTDIR=%{buildroot} install は %makeinstall で対応可能です。 なお、specに埋め込まれたバージョン情報はconfigure.acに埋め込まれた情報を利用する (ccs-tools.spec.inの@VERSION@が置換されます)ので、バージョン番号更新漏れを 防ぐことができるメリットもあります。他のソースに埋め込まれたバージョン番号も 同じような管理が可能です。 autotoolsで出来上がったものは、ソースをいじらずインストールするだけであれば、 autoconf, automakeは不要ですが、逆にソースをいじるのであれば必要となってくる のは、ソースをいじくる開発者寄りのユーザにとっては確かに不便かもしれません。 利用するだけのユーザは特に問題ないのですが、バージョンアップの仕様変更で 苦しめられるのは主に開発者寄りです。:) せっかくならautotoolsなんてどうでしょう？ぐらいの軽い提案だったんで、 autotoolsに振り回されるぐらいなら導入しないというのもありだと思います。 --- その他の回答については了解です。 From hiroshi.shinji ＠ gmail.com Thu Jul 9 03:35:31 2009 From: hiroshi.shinji ＠ gmail.com (Hiroshi Shinji) Date: Thu, 9 Jul 2009 03:35:31 +0900 Subject: [Tomoyo-dev 1122] Re: =?iso-2022-jp?b?aW5pdF9wb2xpY3kuc2ggGyRCJE44K0Q+JDckSyREGyhC?= =?iso-2022-jp?b?GyRCJCQkRhsoQg==?= In-Reply-To: <200907080741.n687fgn4033652@www262.sakura.ne.jp> References: <200907060458.n664w723081766@www262.sakura.ne.jp> <200907080741.n687fgn4033652@www262.sakura.ne.jp> Message-ID: 宍道です。 早速の対応ありがとうございます。 > ↓で動きますでしょうか？ こんなんでました… # ./make_alias Revalidate /bin failed Revalidate /dev failed Revalidate /etc failed ＜中略＞ おかしいなと、思ってみたら間違いが。 --- make_alias.c.orig 2009-07-09 00:43:13.000000000 +0900 +++ make_alias.c 2009-07-09 00:39:26.000000000 +0900 @@ -103,7 +103,7 @@ static unsigned char revalidate_path(con if (!lstat(path, &buf)) { if (S_ISREG(buf.st_mode)) type = DT_REG; - else if (S_ISREG(buf.st_mode)) + else if (S_ISDIR(buf.st_mode)) type = DT_DIR; else if (S_ISLNK(buf.st_mode)) type = DT_LNK; で、改めて実行すると動作しました。 ただし、uClibcで使うときには、realpathのところを #if defined __UCLIBC__ cp = realpath(path, malloc(PATH_MAX)); #else cp = realpath(path, NULL); #endif とする必要はありますが。 ＃実はrealpath.cもおんなじ。 では。 2009/07/08 16:41 に Tetsuo Handa さんは書きました: > 　熊猫です。 > > ↓で動きますでしょうか？ > http://sourceforge.jp/projects/tomoyo/svn/view/branches/ccs-tools/ccstools/make_alias.c?view=markup&root=tomoyo > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -- 宍道 洋 hiroshi.shinji ＠ gmail.com http://d.hatena.ne.jp/hshinji/ From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Thu Jul 9 06:49:35 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Thu, 9 Jul 2009 06:49:35 +0900 Subject: [Tomoyo-dev 1123] Re: =?iso-2022-jp?b?aW5pdF9wb2xpY3kuc2ggGyRCJE44K0Q+JDckSyREGyhC?= =?iso-2022-jp?b?GyRCJCQkRhsoQg==?= In-Reply-To: References: <200907060458.n664w723081766@www262.sakura.ne.jp> <200907080741.n687fgn4033652@www262.sakura.ne.jp> Message-ID: <200907090649.JIG13547.tZGPWtSENPFPPNU@I-love.SAKURA.ne.jp> 　熊猫です。 　テストありがとうございました。 > - else if (S_ISREG(buf.st_mode)) > + else if (S_ISDIR(buf.st_mode)) （＾＾； > ただし、uClibcで使うときには、realpathのところを > > #if defined __UCLIBC__ > cp = realpath(path, malloc(PATH_MAX)); > #else > cp = realpath(path, NULL); > #endif > > とする必要はありますが。 > ＃実はrealpath.cもおんなじ。 はい。 Android で使われている bionic ライブラリでも同様です。 パス名の最大長が PATH_MAX であるとは限らないという理由で realpath() の第２引数に NULL 以外を渡すべきではないとされています。 #if defined __GLIBC__ の場合は realpath(path , NULL) でＯＫですが それ以外の場合は chdir() + getcwd() + strncat() で実現するバージョンの realpath() を作らないといけないですね。 で、 make_alias.c が動作するということは、 make_exception.c とマージして exception_policy.conf の部分を 完全にＣプログラム化できますね。 次のリリースからは readlink と find と which に依存しないものに なるかと思います。 LTP に TOMOYO 2.2.0 用のテストプログラムが追加されました。 http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/security/tomoyo/ From from-tomoyo-dev ＠ i-love.sakura.ne.jp Thu Jul 9 15:51:20 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (Tetsuo Handa) Date: Thu, 09 Jul 2009 15:51:20 +0900 Subject: [Tomoyo-dev 1124] Re: =?iso-2022-jp?b?aW5pdF9wb2xpY3kuc2ggGyRCJE44K0Q+JDckSyREGyhC?= =?iso-2022-jp?b?GyRCJCQkRhsoQg==?= In-Reply-To: <200907060458.n664w723081766@www262.sakura.ne.jp> References: <200907060458.n664w723081766@www262.sakura.ne.jp> Message-ID: <200907090651.n696pKi8048065@www262.sakura.ne.jp> 　熊猫です。 　init_policy.sh をＣプログラム化してみました。 http://sourceforge.jp/projects/tomoyo/svn/view/branches/ccs-tools/ccstools/init_policy.c?view=markup&root=tomoyo これにより、 init_policy.sh および tomoyo_init_policy.sh は find と which と realpath コマンドに依存しない実装になりました。 realpath() も __GLIBC__ の有無で切り替えるようになっているので uClibc や bionic でも動作するはず（未確認）です。 過去のドキュメントとの互換性のために --- init_policy.sh --- #! /bin/sh cd ${0%/*} exec ./init_policy version=1.6.8 "$@" --- tomoyo_init_policy.sh --- #! /bin/sh cd ${0%/*} exec ./init_policy version=2.2.0 という内容で残しておこうと思います。 From matsuu ＠ gmail.com Thu Jul 9 22:20:25 2009 From: matsuu ＠ gmail.com (MATSUU Takuto) Date: Thu, 9 Jul 2009 22:20:25 +0900 Subject: [Tomoyo-dev 1125] Re: =?iso-2022-jp?b?c3VucmlzZSBvdmVybGF5IBskQiRLGyhCIGNjcy10b29s?= =?iso-2022-jp?b?cyAbJEIkLCRPJCQkaiReJDckPxsoQg==?= In-Reply-To: References: <87tz2qew5h.fsf@yue.localnetwork> <200907041135.AJD13090.NNPFUtSWEPGPtZP@I-love.SAKURA.ne.jp> <87prcgohnk.fsf@yue.localnetwork> <200907042130.FAJ00501.NZUPFPtEWPPNtSG@I-love.SAKURA.ne.jp> Message-ID: 松鵜です。 ccs-tools、Gentoo本家に取り込みました。 http://packages.gentoo.org/package/sys-apps/ccs-tools 私が試せるのがamd64とx86のみでしたので、この2つをとりあえず サポート対象として追加しました。 以下のコマンドでインストールが可能です。 # emerge ccs-tools 前回ccstools.confを/etc/ccs/ccstools.confにインストールしていましたが、 MLの過去のやりとりを踏まえ、/usr/lib/ccs/conf/配下に保存するよう変更 しました。 取り急ぎ報告まで。 From from-tomoyo-dev ＠ i-love.sakura.ne.jp Mon Jul 13 10:22:54 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (Tetsuo Handa) Date: Mon, 13 Jul 2009 10:22:54 +0900 Subject: [Tomoyo-dev 1126] Re: =?iso-2022-jp?b?aW5pdF9wb2xpY3kuc2ggGyRCJE44K0Q+JDckSyREGyhC?= =?iso-2022-jp?b?GyRCJCQkRhsoQg==?= In-Reply-To: <200907090651.n696pKi8048065@www262.sakura.ne.jp> References: <200907060458.n664w723081766@www262.sakura.ne.jp> <200907090651.n696pKi8048065@www262.sakura.ne.jp> Message-ID: <200907130122.n6D1MsIN078758@www262.sakura.ne.jp> 　熊猫です。 /sbin/ccs-init および /sbin/tomoyo-init もＣプログラム化してみました。 http://sourceforge.jp/projects/tomoyo/svn/view/branches/ccs-tools/ccstools/ccs-init.c?view=markup&root=tomoyo で、 　#! /bin/sh 　exec 2>/dev/console 　time /sbin/ccs-init2 "$@" 　sleep 100 　exit 0 というラッパー経由で測定してみた結果、 　ccs-init (シェルスクリプト版)　　　　　　　　　　　　　　　　　　　　平均 　real 0.308 0.307 0.341 0.316 0.766 0.350 0.308 0.317 0.316 0.716 | 0.4045 　user 0.008 0.008 0.004 0.008 0.016 0.008 0.008 0.008 0.016 0.012 | 0.0096 　sys 0.120 0.100 0.104 0.108 0.144 0.120 0.124 0.100 0.116 0.120 | 0.1156 　ccs-init (Ｃプログラム版)　　　　　　　　　　　　　　　　　　　　　　平均 　real 0.143 0.251 0.093 0.094 0.226 0.109 0.094 0.250 0.091 0.093 | 0.1444 　user 0.000 0.004 0.008 0.004 0.004 0.004 0.004 0.004 0.004 0.004 | 0.0040 　sys 0.024 0.036 0.032 0.036 0.024 0.032 0.032 0.036 0.036 0.032 | 0.0320 ccs-init の実行時間は短縮できているようです。ただし、（結局は rc.sysinit などが cat や awk などを実行するので）シェルスクリプト版の ccs-init が使っていた cat や awk などを初めて実行する際のディスクシーク時間が rc.sysinit などに 移動するだけかもしれないので、トータルとしての起動時間短縮効果のほどは 不明です。(^^; From from-tomoyo-dev ＠ i-love.sakura.ne.jp Mon Jul 13 10:23:38 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (Tetsuo Handa) Date: Mon, 13 Jul 2009 10:23:38 +0900 Subject: [Tomoyo-dev 1127] Re: =?iso-2022-jp?b?c3VucmlzZSBvdmVybGF5IBskQiRLGyhCIGNjcy10b29s?= =?iso-2022-jp?b?cyAbJEIkLCRPJCQkaiReJDckPxsoQg==?= In-Reply-To: References: <87tz2qew5h.fsf@yue.localnetwork> <200907041135.AJD13090.NNPFUtSWEPGPtZP@I-love.SAKURA.ne.jp> <87prcgohnk.fsf@yue.localnetwork> <200907042130.FAJ00501.NZUPFPtEWPPNtSG@I-love.SAKURA.ne.jp> Message-ID: <200907130123.n6D1NcuX078940@www262.sakura.ne.jp> 　熊猫です。 > ccs-tools、Gentoo本家に取り込みました。 ありがとうございます。 Ｃプログラム化された init_policy と ccs-init をもうしばらくテストしてから ccs-tools-1.6.8 に入れようと思います。 From matsuu ＠ gmail.com Wed Jul 22 08:31:45 2009 From: matsuu ＠ gmail.com (MATSUU Takuto) Date: Wed, 22 Jul 2009 08:31:45 +0900 Subject: [Tomoyo-dev 1128] =?iso-2022-jp?b?Y2NzLXRvb2xzGyRCJHIbKEIxLjYueC8yLjIueBskQiRHGyhC?= =?iso-2022-jp?b?GyRCSixOJSEiJCokaCRTGyhCMi4yLngbJEIkWCROJVobKEI=?= =?iso-2022-jp?b?GyRCITwlOE02RjMkSyREJCQkRhsoQg==?= Message-ID: 松鵜です。 TOMOYOを利用しようとしている海外のGentooユーザーから何度か聞かれたのですが、 ccs-toolsに1.6.xと2.2.xの両方を兼ねているために、init_policy.shとtomoyo_init_policy.shを 間違ったり、ccs-querydやccs-auditdが動かない等の報告を受けています。 ccs-toolsを1.6.x用と2.2.x用に分離した形での配布する予定はないでしょうか。 また、メインライン化により、http://tomoyo.sourceforge.jp/index.html.en へ来られるユーザは2.2.xを利用しようと思われている方が多いのではないかと 推測していますが、2.2.xへの誘導が一番上部の「Searching for mainline version? It's here.」 だけだと見落とす可能性が大きい思います。 ATTENTIONのような形で、少し1.6.xと2.2.xの違いの説明を加えて 大きく表示してはいかがでしょうか。 以上、ご検討のほどよろしくお願いいたします。 From from-tomoyo-dev ＠ i-love.sakura.ne.jp Wed Jul 22 08:58:07 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (Tetsuo Handa) Date: Wed, 22 Jul 2009 08:58:07 +0900 Subject: [Tomoyo-dev 1129] Re: =?iso-2022-jp?b?Y2NzLXRvb2xzIBskQiRyGyhCIDEuNi54LzIuMi54IA==?= =?iso-2022-jp?b?GyRCJEdKLE4lISIkKiRoJFMbKEIgMi4yLnggGyRCJFgbKEI=?= =?iso-2022-jp?b?GyRCJE4lWiE8JThNNkYzJEskRCQkJEYbKEI=?= In-Reply-To: References: Message-ID: <200907212358.n6LNw7gc039089@www262.sakura.ne.jp> 　熊猫です。 MATSUU Takuto さんは書きました： > また、メインライン化により、http://tomoyo.sourceforge.jp/index.html.en > へ来られるユーザは2.2.xを利用しようと思われている方が多いのではないかと > 推測していますが、2.2.xへの誘導が一番上部の「Searching for mainline version? It's here.」 > だけだと見落とす可能性が大きい思います。 > > ATTENTIONのような形で、少し1.6.xと2.2.xの違いの説明を加えて > 大きく表示してはいかがでしょうか。 現在ドキュメントを作り直しているところです。まだ英語版しかありませんが http://tomoyo.sourceforge.jp/index2.html のような構成になる予定です。 （↑は仮ページなのでまだリンクしないでください。） From hitoht ＠ gmail.com Wed Jul 22 14:26:12 2009 From: hitoht ＠ gmail.com (hitoht ＠ gmail.com) Date: Wed, 22 Jul 2009 14:26:12 +0900 Subject: [Tomoyo-dev 1130] Re: =?iso-2022-jp?b?Y2NzLXRvb2xzIBskQiRyGyhCIDEuNi54LzIuMi54IA==?= =?iso-2022-jp?b?GyRCJEdKLE4lISIkKiRoJFMbKEIgMi4yLnggGyRCJFgkTiVaITwbKEI=?= =?iso-2022-jp?b?GyRCJThNNkYzJEskRCQkJEYbKEI=?= In-Reply-To: <200907212358.n6LNw7gc039089@www262.sakura.ne.jp> References: <200907212358.n6LNw7gc039089@www262.sakura.ne.jp> Message-ID: <87iqhlwaob.wl%hitoht@gmail.com> On Wed, 22 Jul 2009 08:58:07 +0900, wrote: > 現在ドキュメントを作り直しているところです。まだ英語版しかありませんが > http://tomoyo.sourceforge.jp/index2.html のような構成になる予定です。 > （↑は仮ページなのでまだリンクしないでください。） 必要なのはドキュメントの作り直しではなく、 　今すぐにトップページに、2.2.x への正しい誘導を貼る ことだと思います。 # 原田さんマターかと。 From haradats ＠ nttdata.co.jp Wed Jul 22 14:34:03 2009 From: haradats ＠ nttdata.co.jp (Toshiharu Harada) Date: Wed, 22 Jul 2009 14:34:03 +0900 Subject: [Tomoyo-dev 1131] Re: =?iso-2022-jp?b?Y2NzLXRvb2xzIBskQiRyGyhCIDEuNi54LzIuMi54IA==?= =?iso-2022-jp?b?GyRCJEdKLE4lISIkKiRoJFMbKEIgMi4yLnggGyRCJFgkTiVaITwbKEI=?= =?iso-2022-jp?b?GyRCJThNNkYzJEskRCQkJEYbKEI=?= In-Reply-To: <87iqhlwaob.wl%hitoht@gmail.com> References: <200907212358.n6LNw7gc039089@www262.sakura.ne.jp> <87iqhlwaob.wl%hitoht@gmail.com> Message-ID: <4A66A4CB.7030204@nttdata.co.jp> On 7/22/2009 2:26 PM, hitoht at gmail.com wrote: > On Wed, 22 Jul 2009 08:58:07 +0900, wrote: >> 現在ドキュメントを作り直しているところです。まだ英語版しかありませんが >> http://tomoyo.sourceforge.jp/index2.html のような構成になる予定です。 >> （↑は仮ページなのでまだリンクしないでください。） > > 必要なのはドキュメントの作り直しではなく、 > > 　今すぐにトップページに、2.2.x への正しい誘導を貼る > > ことだと思います。 > > # 原田さんマターかと。 またー、ですか・・・。(=_=; 「原田さんマター」大杉 TOMOYOプロジェクトのトップページは、http://tomoyo.sourceforge.jp ですが、英語版のほうはトップページに2系への正しい誘導が 貼られていますよ。（日本語版はこれから） http://tomoyo.sourceforge.jp/index.html.en 誘導を含め、かなり（劇的に）改善されたと思うのですがどうでしょう？ -- 原田季栄 (Toshiharu Harada) haradats at nttdata.co.jp From from-tomoyo-dev ＠ i-love.sakura.ne.jp Wed Jul 22 14:34:40 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (Tetsuo Handa) Date: Wed, 22 Jul 2009 14:34:40 +0900 Subject: [Tomoyo-dev 1132] Re: =?iso-2022-jp?b?Y2NzLXRvb2xzIBskQiRyGyhCIDEuNi54LzIuMi54IA==?= =?iso-2022-jp?b?GyRCJEdKLE4lISIkKiRoJFMbKEIgMi4yLnggGyRCJFgbKEI=?= =?iso-2022-jp?b?GyRCJE4lWiE8JThNNkYzJEskRCQkJEYbKEI=?= In-Reply-To: <87iqhlwaob.wl%hitoht@gmail.com> References: <200907212358.n6LNw7gc039089@www262.sakura.ne.jp> <87iqhlwaob.wl%hitoht@gmail.com> Message-ID: <200907220534.n6M5YeZ4011235@www262.sakura.ne.jp> 　熊猫です。 hito さんは書きました： > 必要なのはドキュメントの作り直しではなく、 もう新しいドキュメントで反映済みです。 http://tomoyo.sourceforge.jp/index.html.en From henrich ＠ debian.or.jp Wed Jul 22 15:02:37 2009 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Wed, 22 Jul 2009 15:02:37 +0900 Subject: [Tomoyo-dev 1133] Re: =?iso-2022-jp?b?Y2NzLXRvb2xzIBskQiRyGyhCIDEuNi54LzIuMi54IA==?= =?iso-2022-jp?b?GyRCJEdKLE4lISIkKiRoJFMbKEIgMi4yLnggGyRCJFgkTiVaITwbKEI=?= =?iso-2022-jp?b?GyRCJThNNkYzJEskRCQkJEYbKEI=?= In-Reply-To: <4A66A4CB.7030204@nttdata.co.jp> References: <200907212358.n6LNw7gc039089@www262.sakura.ne.jp> <87iqhlwaob.wl%hitoht@gmail.com> <4A66A4CB.7030204@nttdata.co.jp> Message-ID: <20090722150237.7e7b7c4e.henrich@debian.or.jp> On Wed, 22 Jul 2009 14:34:03 +0900 Toshiharu Harada wrote: > 誘導を含め、かなり（劇的に）改善されたと思うのですがどうでしょう？ 　1.x : Fully equipped version (needs tomoyo patch for kernel) 　など「パッチが必要なのはこっちだぜ！」とか。あと 2.x を上に持ってくる 　とかどうですかね。 -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp http://wiki.debian.org/HidekiYamane From hitoht ＠ gmail.com Wed Jul 22 16:43:07 2009 From: hitoht ＠ gmail.com (hitoht ＠ gmail.com) Date: Wed, 22 Jul 2009 16:43:07 +0900 Subject: [Tomoyo-dev 1134] Re: =?iso-2022-jp?b?Y2NzLXRvb2xzIBskQiRyGyhCIDEuNi54LzIuMi54IA==?= =?iso-2022-jp?b?GyRCJEdKLE4lISIkKiRoJFMbKEIgMi4yLnggGyRCJFgkTiVaITwbKEI=?= =?iso-2022-jp?b?GyRCJThNNkYzJEskRCQkJEYbKEI=?= In-Reply-To: <200907220534.n6M5YeZ4011235@www262.sakura.ne.jp> References: <200907212358.n6LNw7gc039089@www262.sakura.ne.jp> <87iqhlwaob.wl%hitoht@gmail.com> <200907220534.n6M5YeZ4011235@www262.sakura.ne.jp> Message-ID: <87hbx5w4c4.wl%hitoht@gmail.com> On Wed, 22 Jul 2009 14:34:40 +0900, wrote: > もう新しいドキュメントで反映済みです。 > http://tomoyo.sourceforge.jp/index.html.en げ。この新しいドキュメントを見て「こりゃダメやん」という感じで さきほどのメールを書いたりしたわけなのですが。 | 1.x : Fully equipped version | 2.x : Mainlined version という書き方は、連番付きリスト↓ 1. フル版 2. メインライン版 に見えます。語順と並び順の両方を変えて、 Mainlined version (2.x) Fully equipped version (1.x) としないと合目的性の面でダメなんじゃないでしょうか。 From hitoht ＠ gmail.com Wed Jul 22 16:47:16 2009 From: hitoht ＠ gmail.com (hitoht ＠ gmail.com) Date: Wed, 22 Jul 2009 16:47:16 +0900 Subject: [Tomoyo-dev 1135] Re: =?iso-2022-jp?b?Y2NzLXRvb2xzIBskQiRyGyhCIDEuNi54LzIuMi54IA==?= =?iso-2022-jp?b?GyRCJEdKLE4lISIkKiRoJFMbKEIgMi4yLnggGyRCJFgkTiVaITwbKEI=?= =?iso-2022-jp?b?GyRCJThNNkYzJEskRCQkJEYbKEI=?= In-Reply-To: <4A66A4CB.7030204@nttdata.co.jp> References: <200907212358.n6LNw7gc039089@www262.sakura.ne.jp> <87iqhlwaob.wl%hitoht@gmail.com> <4A66A4CB.7030204@nttdata.co.jp> Message-ID: <87fxcpw457.wl%hitoht@gmail.com> On Wed, 22 Jul 2009 14:34:03 +0900, wrote: > またー、ですか・・・。(=_=; 「原田さんマター」大杉 あきらめてください（非道な発言その1）。 > TOMOYOプロジェクトのトップページは、http://tomoyo.sourceforge.jp > ですが、英語版のほうはトップページに2系への正しい誘導が > 貼られていますよ。（日本語版はこれから） > http://tomoyo.sourceforge.jp/index.html.en 先ほどのメールにも書きましたが、かなりキケンなレベルで正しくない 誘導だと思います。 # ワンクリック詐欺のごとく1.xクリックさせるのが目的なら絶賛しますが # （非道な発言その2）、導線として非常にまずい状態だと思います。 From matsuu ＠ gmail.com Wed Jul 22 23:22:45 2009 From: matsuu ＠ gmail.com (MATSUU Takuto) Date: Wed, 22 Jul 2009 23:22:45 +0900 Subject: [Tomoyo-dev 1136] Re: =?iso-2022-jp?b?Y2NzLXRvb2xzIBskQiRyGyhCIDEuNi54LzIuMi54IA==?= =?iso-2022-jp?b?GyRCJEdKLE4lISIkKiRoJFMbKEIgMi4yLnggGyRCJFgbKEI=?= =?iso-2022-jp?b?GyRCJE4lWiE8JThNNkYzJEskRCQkJEYbKEI=?= In-Reply-To: <200907220534.n6M5YeZ4011235@www262.sakura.ne.jp> References: <200907212358.n6LNw7gc039089@www262.sakura.ne.jp> <87iqhlwaob.wl%hitoht@gmail.com> <200907220534.n6M5YeZ4011235@www262.sakura.ne.jp> Message-ID: 松鵜です。 下記、とても良いと思います。 ご対応ありがとうございます。 で、すみません、ccs-toolsの1.xと2.xの分離はいかがでしょうか？ （正直言うと、ccs-toolsの分離が私にとっての話のメインでした。） 2009/07/22 14:34 に Tetsuo Handa さんは書きました: > 　熊猫です。 > > hito さんは書きました： >> 必要なのはドキュメントの作り直しではなく、 > もう新しいドキュメントで反映済みです。 > http://tomoyo.sourceforge.jp/index.html.en > > _______________________________________________ > 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 Thu Jul 23 22:40:56 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Thu, 23 Jul 2009 22:40:56 +0900 Subject: [Tomoyo-dev 1137] Re: =?iso-2022-jp?b?Y2NzLXRvb2xzIBskQiRyGyhCIDEuNi54LzIuMi54IA==?= =?iso-2022-jp?b?GyRCJEdKLE4lISIkKiRoJFMbKEIgMi4yLnggGyRCJFgkTiVaITwbKEI=?= =?iso-2022-jp?b?GyRCJThNNkYzJEskRCQkJEYbKEI=?= In-Reply-To: References: <200907212358.n6LNw7gc039089@www262.sakura.ne.jp> <87iqhlwaob.wl%hitoht@gmail.com> <200907220534.n6M5YeZ4011235@www262.sakura.ne.jp> Message-ID: <200907232240.BAG13015.PENPPGZtUNWtFSP@I-love.SAKURA.ne.jp> 　熊猫です。 > で、すみません、ccs-toolsの1.xと2.xの分離はいかがでしょうか？ > （正直言うと、ccs-toolsの分離が私にとっての話のメインでした。） http://sourceforge.jp/projects/tomoyo/svn/view/trunk/2.2.x/tomoyo-tools/?root=tomoyo に 分離しました。まだ動作確認していません。 それから↓は http://bugs.gentoo.org/show_bug.cgi?id=278513 へのコメント案です。 > I found this at the end of /sbin/tomoyo-init: > > # [ $SECURITY_UNMOUNT -eq 1 ] && umount -n /sys/kernel/security > # [ $SYS_UNMOUNT -eq 1 ] && umount -n /sys > [ $PROC_UNMOUNT -eq 1 ] && umount -n /proc > exit 0 > > I suspect that uncommenting those two lines might solve the problem, but I'm > new to TOMOYO and might be missing something. Yes. Uncommenting those two lines will solve the problem. TOMOYO's management tools assume that securityfs is mounted on /sys/kernel/security/ . But many systems don't mount securityfs on /sys/kernel/security/ upon boot. If securityfs is not mounted, TOMOYO's management tools (e.g. ccs-editpolicy) can't work. Therefore, the author decided that /sbin/tomoyo-init leaves securityfs mounted on /sys/kernel/security/ . But in your environment, it causes problems... Should we ask users to add an entry to /etc/fstab so that /sys/kernel/security/ is mounted? Or, should we let TOMOYO's management tools try to mount /sys/kernel/security/ when the tools are executed? From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Thu Jul 23 23:39:06 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Thu, 23 Jul 2009 23:39:06 +0900 Subject: [Tomoyo-dev 1138] =?iso-2022-jp?b?L3NiaW4vdG9tb3lvLWluaXQgGyRCJEckThsoQiBzeXNmcyA=?= =?iso-2022-jp?b?GyRCJCokaCRTGyhCIHNlY3VyaXR5ZnMgGyRCJE4lIiVzJV4lJiVzGyhC?= =?iso-2022-jp?b?GyRCJUgkTkAnSHMkSyREJCQkRhsoQg==?= In-Reply-To: <200907232240.BAG13015.PENPPGZtUNWtFSP@I-love.SAKURA.ne.jp> References: <200907212358.n6LNw7gc039089@www262.sakura.ne.jp> <87iqhlwaob.wl%hitoht@gmail.com> <200907220534.n6M5YeZ4011235@www262.sakura.ne.jp> <200907232240.BAG13015.PENPPGZtUNWtFSP@I-love.SAKURA.ne.jp> Message-ID: <200907232339.HJJ13514.USGPPPttEZFNWPN@I-love.SAKURA.ne.jp> 　熊猫です。 > それから↓は http://bugs.gentoo.org/show_bug.cgi?id=278513 へのコメント案です。 SELinux の場合は /selinux/ にマウントされる selinuxfs を、 Smack の場合は /smack/ にマウントされる smackfs を、 AppArmor の場合は boot.apparmor という初期化スクリプトにより /sys/kernel/security/ にマウントされる securityfs を利用しています。 さて、 TOMOYO の場合は /sys/kernel/security/ にマウントされる securityfs を利用していますが、初期化スクリプトはありません。 /sbin/init の開始前に自動的に実行される /sbin/tomoyo-init が初期化スクリプトに相当するわけですが、 /sbin/tomoyo-init 内で sysfs と securityfs をアンマウントせずにそのまま続行すると、 /sbin/init 開始後に sysfs のマウントに失敗して起動できなくなるという報告が出たわけです。 /sbin/tomoyo-init 内で sysfs と securityfs をアンマウントしてやれば回避できますが、 何らかの方法で securityfs をマウントしてもらう必要が生じます。 （ sysfs は /etc/fstab で指定されているでしょうからデフォルト設定のままでＯＫでしょう。） 利用者に対して /etc/fstab に securityfs をマウントするよう設定をしてもらう手順に改めるか、 ポリシーエディタなどが自動で securityfs をマウントするかのどちらかになるかと思いますが、どうしましょう？ From from-tomoyo-dev ＠ i-love.sakura.ne.jp Fri Jul 24 14:06:44 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (Tetsuo Handa) Date: Fri, 24 Jul 2009 14:06:44 +0900 Subject: [Tomoyo-dev 1139] Re: =?iso-2022-jp?b?Y2NzLXRvb2xzIBskQiRyGyhCIDEuNi54LzIuMi54IA==?= =?iso-2022-jp?b?GyRCJEdKLE4lISIkKiRoJFMbKEIgMi4yLnggGyRCJFgbKEI=?= =?iso-2022-jp?b?GyRCJE4lWiE8JThNNkYzJEskRCQkJEYbKEI=?= In-Reply-To: <200907232240.BAG13015.PENPPGZtUNWtFSP@I-love.SAKURA.ne.jp> References: <200907212358.n6LNw7gc039089@www262.sakura.ne.jp> <87iqhlwaob.wl%hitoht@gmail.com> <200907220534.n6M5YeZ4011235@www262.sakura.ne.jp> <200907232240.BAG13015.PENPPGZtUNWtFSP@I-love.SAKURA.ne.jp> Message-ID: <200907240506.n6O56iNr030508@www262.sakura.ne.jp> 　熊猫です。 　現在動作テスト中です。 revision 2800 時点でのファイル配置は以下のようになっています。 # ls -l /sbin/tomoyo-init -rwx------ 1 root root 20865 Jul 24 12:32 /sbin/tomoyo-init # ls -l /usr/sbin/tomoyo-* -rwxr-xr-x 12 root root 97036 Jul 24 13:26 /usr/sbin/tomoyo-checkpolicy -rwxr-xr-x 1 root root 482 Jul 24 09:42 /usr/sbin/tomoyo-domainmatch -rwxr-xr-x 12 root root 97036 Jul 24 13:26 /usr/sbin/tomoyo-editpolicy -rwxr-xr-x 12 root root 97036 Jul 24 13:26 /usr/sbin/tomoyo-findtemp -rwxr-xr-x 12 root root 97036 Jul 24 13:26 /usr/sbin/tomoyo-ld-watch -rwxr-xr-x 12 root root 97036 Jul 24 13:26 /usr/sbin/tomoyo-loadpolicy -rwxr-xr-x 12 root root 97036 Jul 24 13:26 /usr/sbin/tomoyo-pathmatch -rwxr-xr-x 12 root root 97036 Jul 24 13:26 /usr/sbin/tomoyo-patternize -rwxr-xr-x 12 root root 97036 Jul 24 13:26 /usr/sbin/tomoyo-pstree -rwxr-xr-x 12 root root 97036 Jul 24 13:26 /usr/sbin/tomoyo-savepolicy -rwxr-xr-x 12 root root 97036 Jul 24 13:26 /usr/sbin/tomoyo-setlevel -rwxr-xr-x 12 root root 97036 Jul 24 13:26 /usr/sbin/tomoyo-setprofile -rwxr-xr-x 12 root root 97036 Jul 24 13:26 /usr/sbin/tomoyo-sortpolicy # ls -l /usr/lib/tomoyo/* -rw-r--r-- 1 root root 17987 Jul 23 13:00 /usr/lib/tomoyo/COPYING.tomoyo -rw-r--r-- 1 root root 224 Jul 24 10:16 /usr/lib/tomoyo/README.tomoyo -rwxr-xr-x 1 root root 15089 Jul 24 12:32 /usr/lib/tomoyo/candy -rwxr-xr-x 1 root root 13152 Jul 24 12:32 /usr/lib/tomoyo/chaplet -rwxr-xr-x 1 root root 13091 Jul 24 12:32 /usr/lib/tomoyo/checktoken -rwxr-xr-x 1 root root 16068 Jul 24 12:32 /usr/lib/tomoyo/falsh -rwxr-xr-x 1 root root 11811 Jul 24 12:32 /usr/lib/tomoyo/gettoken -rwxr-xr-x 1 root root 12703 Jul 24 12:32 /usr/lib/tomoyo/groovy -rwxr-xr-x 1 root root 13317 Jul 24 12:32 /usr/lib/tomoyo/honey -rwxr-xr-x 1 root root 17970 Jul 24 12:32 /usr/lib/tomoyo/mailauth -rwxr-xr-x 1 root root 22100 Jul 24 12:32 /usr/lib/tomoyo/timeauth -rwxr-xr-x 1 root root 18528 Jul 24 12:32 /usr/lib/tomoyo/tomoyo-editpolicy-agent -rwxr-xr-x 1 root root 47559 Jul 24 13:26 /usr/lib/tomoyo/tomoyo_init_policy lrwxrwxrwx 1 root root 18 Jul 24 13:20 /usr/lib/tomoyo/tomoyo_init_policy.sh -> tomoyo_init_policy -rw-r--r-- 1 root root 3005 Jul 23 13:00 /usr/lib/tomoyo/tomoyotools.conf tomoyo:~# # ls -l /usr/share/man/man8/tomoyo* -rw-r--r-- 1 root root 545 Jul 24 10:37 /usr/share/man/man8/tomoyo-checkpolicy.8.gz -rw-r--r-- 1 root root 503 Jul 24 10:37 /usr/share/man/man8/tomoyo-domainmatch.8.gz -rw-r--r-- 1 root root 792 Jul 24 10:37 /usr/share/man/man8/tomoyo-editpolicy-agent.8.gz -rw-r--r-- 1 root root 1022 Jul 24 10:37 /usr/share/man/man8/tomoyo-editpolicy.8.gz -rw-r--r-- 1 root root 692 Jul 24 10:37 /usr/share/man/man8/tomoyo-findtemp.8.gz -rw-r--r-- 1 root root 708 Jul 24 10:37 /usr/share/man/man8/tomoyo-init.8.gz -rw-r--r-- 1 root root 699 Jul 24 10:37 /usr/share/man/man8/tomoyo-ld-watch.8.gz -rw-r--r-- 1 root root 1157 Jul 24 12:33 /usr/share/man/man8/tomoyo-loadpolicy.8.gz -rw-r--r-- 1 root root 585 Jul 24 10:37 /usr/share/man/man8/tomoyo-pathmatch.8.gz -rw-r--r-- 1 root root 668 Jul 24 10:37 /usr/share/man/man8/tomoyo-patternize.8.gz -rw-r--r-- 1 root root 603 Jul 24 10:37 /usr/share/man/man8/tomoyo-pstree.8.gz -rw-r--r-- 1 root root 938 Jul 24 10:37 /usr/share/man/man8/tomoyo-savepolicy.8.gz -rw-r--r-- 1 root root 642 Jul 24 10:37 /usr/share/man/man8/tomoyo-setlevel.8.gz -rw-r--r-- 1 root root 800 Jul 24 10:37 /usr/share/man/man8/tomoyo-setprofile.8.gz -rw-r--r-- 1 root root 612 Jul 24 10:37 /usr/share/man/man8/tomoyo-sortpolicy.8.gz -rw-r--r-- 1 root root 619 Jul 24 10:39 /usr/share/man/man8/tomoyo_init_policy.8.gz tomoyo:~# cat /etc/tomoyo/manager.conf /usr/sbin/tomoyo-loadpolicy /usr/sbin/tomoyo-editpolicy /usr/sbin/tomoyo-setlevel /usr/sbin/tomoyo-setprofile /usr/sbin/tomoyo-ld-watch いくつか決めなければいけないことがあります。 （１）スクリプトで実装していた tomoyo_init_policy.sh はＣプログラムの 　　　tomoyo_init_policy.c に置き換えられたため、 tomoyo_init_policy.sh は 　　　tomoyo_init_policy へのシンボリックリンクになりました。 　　　ドキュメントでは ccs-tools パッケージの tomoyo_init_policy.sh を 　　　実行するようになっていますが、 tomoyo-tools パッケージに置き換わった後も 　　　tomoyo_init_policy.sh を残しておきますか？それとも tomoyo_init_policy 　　　だけで良いですか？ 　　　tomoyo_init_policy は（ tomoyo_init_policy.sh と入力するつもりで 　　　tomoyo_init_policy までで Enter を押してしまうというミスを避けるために） 　　　init_policy という名前にしておいた方が良いですか？ （２）スクリプトで実装していた tomoyo-init はＣプログラムの tomoyo-init.c に 　　　置き換えられました。 　　　現在 http://bugs.gentoo.org/show_bug.cgi?id=278513 にて tomoyo-init が 　　　/sys/ と /sys/kernel/security/ をアンマウントしないために起動スクリプトが 　　　失敗するという状況が発生しています。しかし、 tomoyo-editpolicy などは 　　　/sys/kernel/security/ がマウントされていないと動作できません。 　　　tomoyo-init で /sys/ と /sys/kernel/security/ をアンマウントさせますか？ 　　　アンマウントさせる場合、 /sys/kernel/security/ のマウントはどのように 　　　行わせますか？ （３）ログイン認証の強化のためのプログラムの内、 1.x でしか意味を成さないものを 　　　削除しました。 　　　残っている candy chaplet checktoken falsh gettoken groovy honey mailauth 　　　timeauth は 2.x でも利用できますが、残しますか？それとも削除しますか？ 　　　（ falsh を削除すると readline ライブラリへの依存を無くせます。） （４） /usr/lib/ がシンボリックリンクな環境への対処はどうしましょう？ （５）tomoyo-setlevel は echo | tomoyo-loadpolicy -p で代用できるのですが、 　　　残しますか？それとも削除しますか？ （６）tomoyo-checkpolicy は誰も使っていないと思いますが、残しますか？それとも 　　　削除しますか？ From from-tomoyo-dev ＠ i-love.sakura.ne.jp Mon Jul 27 16:26:20 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Mon, 27 Jul 2009 16:26:20 +0900 Subject: [Tomoyo-dev 1140] Re: =?iso-2022-jp?b?Y2NzLXRvb2xzIBskQiRyGyhCIDEuNi54LzIuMi54IA==?= =?iso-2022-jp?b?GyRCJEdKLE4lISIkKiRoJFMbKEIgMi4yLnggGyRCJFgbKEI=?= =?iso-2022-jp?b?GyRCJE4lWiE8JThNNkYzJEskRCQkJEYbKEI=?= In-Reply-To: <200907240506.n6O56iNr030508@www262.sakura.ne.jp> References: <200907212358.n6LNw7gc039089@www262.sakura.ne.jp> <87iqhlwaob.wl%hitoht@gmail.com> <200907220534.n6M5YeZ4011235@www262.sakura.ne.jp> <200907232240.BAG13015.PENPPGZtUNWtFSP@I-love.SAKURA.ne.jp> <200907240506.n6O56iNr030508@www262.sakura.ne.jp> Message-ID: <200907270726.n6R7QKBL037671@www262.sakura.ne.jp> 　熊猫です。 > いくつか決めなければいけないことがあります。 > 　反応が無かったので以下の仕様で固めました。 > （１）スクリプトで実装していた tomoyo_init_policy.sh はＣプログラムの > 　　　tomoyo_init_policy.c に置き換えられたため、 tomoyo_init_policy.sh は > 　　　tomoyo_init_policy へのシンボリックリンクになりました。 > > 　　　ドキュメントでは ccs-tools パッケージの tomoyo_init_policy.sh を > 　　　実行するようになっていますが、 tomoyo-tools パッケージに置き換わった後も > 　　　tomoyo_init_policy.sh を残しておきますか？それとも tomoyo_init_policy > 　　　だけで良いですか？ tomoyo_init_policy.sh を残しました。 > > 　　　tomoyo_init_policy は（ tomoyo_init_policy.sh と入力するつもりで > 　　　tomoyo_init_policy までで Enter を押してしまうというミスを避けるために） > 　　　init_policy という名前にしておいた方が良いですか？ tomoyo_init_policy という名前のままにしました。 > > （２）スクリプトで実装していた tomoyo-init はＣプログラムの tomoyo-init.c に > 　　　置き換えられました。 > > 　　　現在 http://bugs.gentoo.org/show_bug.cgi?id=278513 にて tomoyo-init が > 　　　/sys/ と /sys/kernel/security/ をアンマウントしないために起動スクリプトが > 　　　失敗するという状況が発生しています。しかし、 tomoyo-editpolicy などは > 　　　/sys/kernel/security/ がマウントされていないと動作できません。 > > 　　　tomoyo-init で /sys/ と /sys/kernel/security/ をアンマウントさせますか？ アンマウントさせることにしました。 > 　　　アンマウントさせる場合、 /sys/kernel/security/ のマウントはどのように > 　　　行わせますか？ 実行時にマウントするようにしました。 カーネル 2.6.16 以降では unshare(CLONE_NEWNS) を使うことで mount() の効果が 他のプロセスの名前空間に及ばないようにできます。 tomoyo-tools はカーネル 2.6.30 以降を対象としているので、 /sys/kernel/security/tomoyo/ へのアクセスが 必要となるプログラムの開始時に if (access("/sys/kernel/security/tomoyo/", X_OK)) { if (unshare(CLONE_NEWNS) || mount("none", "/sys/kernel/security", "securityfs", 0, NULL)) { fprintf(stderr, "Please mount securityfs on " "/sys/kernel/security/ .\n"); } } という処理を入れておけば、他のプロセスからは securityfs をマウントしたことが 見えないようにできます。難点は unshare(CLONE_NEWNS) も mount() も CAP_SYS_ADMIN 権限が必要となるため、 Ubuntu のように一般ユーザでログインする システムの場合、 sudo または setuid root で実行してもらうか、 /etc/fstab で securityfs をマウントするよう設定してもらわないといけないことです。 （ Ubuntu では AppArmor の初期化スクリプトが勝手に securityfs をマウントして くれるかなぁ？） > > （３）ログイン認証の強化のためのプログラムの内、 1.x でしか意味を成さないものを > 　　　削除しました。 > > 　　　残っている candy chaplet checktoken falsh gettoken groovy honey mailauth > 　　　timeauth は 2.x でも利用できますが、残しますか？それとも削除しますか？ > 　　　（ falsh を削除すると readline ライブラリへの依存を無くせます。） 削除しました。 これにより、コンパイルに readline パッケージは不要になりました。 > > （４） /usr/lib/ がシンボリックリンクな環境への対処はどうしましょう？ これは Gentoo の話ですので何か問題が見つかりましたらお知らせください。 > > （５）tomoyo-setlevel は echo | tomoyo-loadpolicy -p で代用できるのですが、 > 　　　残しますか？それとも削除しますか？ 残しました。 > > （６）tomoyo-checkpolicy は誰も使っていないと思いますが、残しますか？それとも > 　　　削除しますか？ 残しました。 tomoyo-tools パッケージは TOMOYO 2.2 専用です。なので、 [Tomoyo-dev 1095] で 挙がっていた、 Recommends: linux-patch-tomoyo を削った状態でパッケージ申請を お願いします。 http://osdn.dl.sourceforge.jp/tomoyo/41908/tomoyo-tools-2.2.0-20090727.tar.gz MD5SUM: cc97558865b2723834009fda2210f33f From from-tomoyo-dev ＠ i-love.sakura.ne.jp Mon Jul 27 17:25:53 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Mon, 27 Jul 2009 17:25:53 +0900 Subject: [Tomoyo-dev 1141] Re: =?iso-2022-jp?b?Y2NzLXRvb2xzIBskQiRyGyhCIDEuNi54LzIuMi54IA==?= =?iso-2022-jp?b?GyRCJEdKLE4lISIkKiRoJFMbKEIgMi4yLnggGyRCJFgbKEI=?= =?iso-2022-jp?b?GyRCJE4lWiE8JThNNkYzJEskRCQkJEYbKEI=?= In-Reply-To: <200907270726.n6R7QKBL037671@www262.sakura.ne.jp> References: <200907212358.n6LNw7gc039089@www262.sakura.ne.jp> <87iqhlwaob.wl%hitoht@gmail.com> <200907220534.n6M5YeZ4011235@www262.sakura.ne.jp> <200907232240.BAG13015.PENPPGZtUNWtFSP@I-love.SAKURA.ne.jp> <200907240506.n6O56iNr030508@www262.sakura.ne.jp> <200907270726.n6R7QKBL037671@www262.sakura.ne.jp> Message-ID: <200907270825.n6R8PrD7052699@www262.sakura.ne.jp> 　熊猫です。 　コンパイルエラーがあったので差し替えました。 http://osdn.dl.sourceforge.jp/tomoyo/41908/tomoyo-tools-2.2.0-20090727.tar.gz MD5: cc559fab1f7e2164a763bf124402298e From matsuu ＠ gmail.com Wed Jul 29 09:03:32 2009 From: matsuu ＠ gmail.com (MATSUU Takuto) Date: Wed, 29 Jul 2009 09:03:32 +0900 Subject: [Tomoyo-dev 1142] Re: =?iso-2022-jp?b?Y2NzLXRvb2xzIBskQiRyGyhCIDEuNi54LzIuMi54IA==?= =?iso-2022-jp?b?GyRCJEdKLE4lISIkKiRoJFMbKEIgMi4yLnggGyRCJFgbKEI=?= =?iso-2022-jp?b?GyRCJE4lWiE8JThNNkYzJEskRCQkJEYbKEI=?= In-Reply-To: <200907270726.n6R7QKBL037671@www262.sakura.ne.jp> References: <200907212358.n6LNw7gc039089@www262.sakura.ne.jp> <87iqhlwaob.wl%hitoht@gmail.com> <200907220534.n6M5YeZ4011235@www262.sakura.ne.jp> <200907232240.BAG13015.PENPPGZtUNWtFSP@I-love.SAKURA.ne.jp> <200907240506.n6O56iNr030508@www262.sakura.ne.jp> <200907270726.n6R7QKBL037671@www262.sakura.ne.jp> Message-ID: 松鵜です。 tomoyo-toolsのパッケージをGentooに取り込みました。 >> （４） /usr/lib/ がシンボリックリンクな環境への対処はどうしましょう？ > これは Gentoo の話ですので何か問題が見つかりましたらお知らせください。 > 了解しました。 /usr/libは環境に合わせて/usr/lib64または/usr/lib32に書き換え（または据え置き）に なるようにパッケージで対応しています。 なお、Gentooのファイル構成に合わせて、tomoyo_init_policyに独自パッチを適用しています。 http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/tomoyo-tools/files/tomoyo-tools-2.2.0_p20090727-gentoo.patch From from-tomoyo-dev ＠ i-love.sakura.ne.jp Wed Jul 29 10:32:33 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (Tetsuo Handa) Date: Wed, 29 Jul 2009 10:32:33 +0900 Subject: [Tomoyo-dev 1143] Re: =?iso-2022-jp?b?Y2NzLXRvb2xzIBskQiRyGyhCIDEuNi54LzIuMi54IA==?= =?iso-2022-jp?b?GyRCJEdKLE4lISIkKiRoJFMbKEIgMi4yLnggGyRCJFgbKEI=?= =?iso-2022-jp?b?GyRCJE4lWiE8JThNNkYzJEskRCQkJEYbKEI=?= In-Reply-To: References: <200907212358.n6LNw7gc039089@www262.sakura.ne.jp> <87iqhlwaob.wl%hitoht@gmail.com> <200907220534.n6M5YeZ4011235@www262.sakura.ne.jp> <200907232240.BAG13015.PENPPGZtUNWtFSP@I-love.SAKURA.ne.jp> <200907240506.n6O56iNr030508@www262.sakura.ne.jp> <200907270726.n6R7QKBL037671@www262.sakura.ne.jp> Message-ID: <200907290132.n6T1WXSO021214@www262.sakura.ne.jp> 　熊猫です。 > tomoyo-toolsのパッケージをGentooに取り込みました。 ありがとうございます。 > /usr/libは環境に合わせて/usr/lib64または/usr/lib32に書き換え（または据え置き）に > なるようにパッケージで対応しています。 /usr/lib/ がシンボリックリンクの場合にはそれを解決したパス名でポリシーが作成 されるようになっていますので、書き換えが必要になることはあまり生じないかと 思います。 > + echo("file_pattern /etc/group.edit"); > + echo("file_pattern /etc/gshadow.edit"); > + echo("file_pattern /etc/passwd.edit"); > + echo("file_pattern /etc/shadow.edit"); file_pattern にはワイルドカードを含むパターンを指定するので、 上記エントリは無視されます。他のエントリは有効なようですので、 昨日 Ubuntu 8.04.3 のデスクトップ環境でポリシーを作成した際に得られた エントリと一緒に本体に取り込みました。 http://sourceforge.jp/projects/tomoyo/svn/view/trunk/2.2.x/tomoyo-tools/tomoyo_init_policy.c?root=tomoyo&r1=2823&r2=2822 その他に問題点などありましたらお知らせください。 From henrich ＠ debian.or.jp Wed Jul 29 16:34:51 2009 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Wed, 29 Jul 2009 09:34:51 +0200 Subject: [Tomoyo-dev 1144] Re: =?iso-2022-jp?b?Y2NzLXRvb2xzIBskQiRyGyhCIDEuNi54LzIuMi54IA==?= =?iso-2022-jp?b?GyRCJEdKLE4lISIkKiRoJFMbKEIgMi4yLnggGyRCJFgkTiVaITwbKEI=?= =?iso-2022-jp?b?GyRCJThNNkYzJEskRCQkJEYbKEI=?= In-Reply-To: <200907270726.n6R7QKBL037671@www262.sakura.ne.jp> References: <200907212358.n6LNw7gc039089@www262.sakura.ne.jp> <87iqhlwaob.wl%hitoht@gmail.com> <200907220534.n6M5YeZ4011235@www262.sakura.ne.jp> <200907232240.BAG13015.PENPPGZtUNWtFSP@I-love.SAKURA.ne.jp> <200907240506.n6O56iNr030508@www262.sakura.ne.jp> <200907270726.n6R7QKBL037671@www262.sakura.ne.jp> Message-ID: <20090729093451.ad0a31e0.henrich@debian.or.jp> On Mon, 27 Jul 2009 16:26:20 +0900 from-tomoyo-dev ＠ i-love.sakura.ne.jp wrote: > tomoyo-tools パッケージは TOMOYO 2.2 専用です。なので、 [Tomoyo-dev 1095] で > 挙がっていた、 Recommends: linux-patch-tomoyo を削った状態でパッケージ申請を > お願いします。 　そうします。これから作業して申請するので入るのは…2ヶ月後ぐらいでしょうか。 　形が出来た所で hito さんチェックしていただけますか？ -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp http://wiki.debian.org/HidekiYamane From hitoht ＠ gmail.com Wed Jul 29 16:48:20 2009 From: hitoht ＠ gmail.com (hitoht ＠ gmail.com) Date: Wed, 29 Jul 2009 16:48:20 +0900 Subject: [Tomoyo-dev 1145] Re: =?iso-2022-jp?b?Y2NzLXRvb2xzIBskQiRyGyhCIDEuNi54LzIuMi54IA==?= =?iso-2022-jp?b?GyRCJEdKLE4lISIkKiRoJFMbKEIgMi4yLnggGyRCJFgkTiVaITwbKEI=?= =?iso-2022-jp?b?GyRCJThNNkYzJEskRCQkJEYbKEI=?= In-Reply-To: <20090729093451.ad0a31e0.henrich@debian.or.jp> References: <200907212358.n6LNw7gc039089@www262.sakura.ne.jp> <87iqhlwaob.wl%hitoht@gmail.com> <200907220534.n6M5YeZ4011235@www262.sakura.ne.jp> <200907232240.BAG13015.PENPPGZtUNWtFSP@I-love.SAKURA.ne.jp> <200907240506.n6O56iNr030508@www262.sakura.ne.jp> <200907270726.n6R7QKBL037671@www262.sakura.ne.jp> <20090729093451.ad0a31e0.henrich@debian.or.jp> Message-ID: <87r5w0udyz.wl%hitoht@gmail.com> On Wed, 29 Jul 2009 09:34:51 +0200, wrote: > > tomoyo-tools パッケージは TOMOYO 2.2 専用です。なので、 [Tomoyo-dev 1095] で > > 挙がっていた、 Recommends: linux-patch-tomoyo を削った状態でパッケージ申請を > > お願いします。 > > 　そうします。これから作業して申請するので入るのは…2ヶ月後ぐらいでしょうか。 > 　形が出来た所で hito さんチェックしていただけますか？ はい。 ちなみにUbuntu 9.10へ送り込むのをどうしようかというのもネックなの ですが、触った感じでは、ccstoolsでもbetter documentがあれば許容範囲 かなと思い始めました。 >> 中の人全般 ↓ 政治的というか、布教的な意味ではどうでしょうか。たとえば、2.x系を 積極的に押して行く計画があって、そこでtomoyo-toolsでないと困るとか、 ccstoolsでも構わないぜとかそういう話はありますか？ 率直に言うと、なんでいきなり分離が受け入れられたのか、外部からは およそ推定できないので、tomoyo-tools の必然性が論理的に解釈できない あたりに releng な人たち（とJamie）を説得する上で不安があります。 >> こっちは半田さん ↓ 対外的な論理としては、 　・本来 2.6.30 のリリースに間に合わせるべきユーザランドツールの 　　改変が遅れてました。ccstoolsでも動きますが、こっちならミス 　　リーディングが起きないのでこれ使ってね。 が一番通りが良さそうなのですが、これはそれなりに半田さん的な事実に 適合していますか？ From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Wed Jul 29 22:03:28 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Wed, 29 Jul 2009 22:03:28 +0900 Subject: [Tomoyo-dev 1146] Re: =?iso-2022-jp?b?Y2NzLXRvb2xzIBskQiRyGyhCIDEuNi54LzIuMi54IA==?= =?iso-2022-jp?b?GyRCJEdKLE4lISIkKiRoJFMbKEIgMi4yLnggGyRCJFgkTiVaITwbKEI=?= =?iso-2022-jp?b?GyRCJThNNkYzJEskRCQkJEYbKEI=?= In-Reply-To: <87r5w0udyz.wl%hitoht@gmail.com> References: <200907232240.BAG13015.PENPPGZtUNWtFSP@I-love.SAKURA.ne.jp> <200907240506.n6O56iNr030508@www262.sakura.ne.jp> <200907270726.n6R7QKBL037671@www262.sakura.ne.jp> <20090729093451.ad0a31e0.henrich@debian.or.jp> <87r5w0udyz.wl%hitoht@gmail.com> Message-ID: <200907292203.FGJ52605.ttNZUGNPPPPWESF@I-love.SAKURA.ne.jp> 　熊猫です。 > 　・本来 2.6.30 のリリースに間に合わせるべきユーザランドツールの > 　　改変が遅れてました。ccstoolsでも動きますが、こっちならミス > 　　リーディングが起きないのでこれ使ってね。 別に遅れていたわけではない（ ccs-tools-1.6.8 は TOMOYO 2.2.0 でも使えるように なっている）です。ソースコードを分離する必要性は感じていませんでしたが、 操作ミスや誤解に起因するバグ報告や質問が多かったから切り離しただけです。 From hitoht ＠ gmail.com Wed Jul 29 22:15:50 2009 From: hitoht ＠ gmail.com (hito) Date: Wed, 29 Jul 2009 22:15:50 +0900 Subject: [Tomoyo-dev 1147] Re: =?iso-2022-jp?b?Y2NzLXRvb2xzIBskQiRyGyhCIDEuNi54LzIuMi54IA==?= =?iso-2022-jp?b?GyRCJEdKLE4lISIkKiRoJFMbKEIgMi4yLnggGyRCJFgbKEI=?= =?iso-2022-jp?b?GyRCJE4lWiE8JThNNkYzJEskRCQkJEYbKEI=?= In-Reply-To: <200907292203.FGJ52605.ttNZUGNPPPPWESF@I-love.SAKURA.ne.jp> References: <200907232240.BAG13015.PENPPGZtUNWtFSP@I-love.SAKURA.ne.jp> <200907240506.n6O56iNr030508@www262.sakura.ne.jp> <200907270726.n6R7QKBL037671@www262.sakura.ne.jp> <20090729093451.ad0a31e0.henrich@debian.or.jp> <87r5w0udyz.wl%hitoht@gmail.com> <200907292203.FGJ52605.ttNZUGNPPPPWESF@I-love.SAKURA.ne.jp> Message-ID: <9292c1390907290615s5943698eq736f78dcf9fe94a4@mail.gmail.com> >> ・本来 2.6.30 のリリースに間に合わせるべきユーザランドツールの >> 改変が遅れてました。ccstoolsでも動きますが、こっちならミス >> リーディングが起きないのでこれ使ってね。 > 別に遅れていたわけではない（ ccs-tools-1.6.8 は TOMOYO 2.2.0 でも使えるように > なっている）です。ソースコードを分離する必要性は感じていませんでしたが、 > 操作ミスや誤解に起因するバグ報告や質問が多かったから切り離しただけです。 ふむ。ということは、 | 触った感じでは、ccstoolsでもbetter documentがあれば許容範囲 は半田さん的にはOKという理解でいいですか？ 言い換えると、tomoyo-toolsパッケージがUbuntu 9.10に入らなくても 「少なくとも半田さんは」OKでしょうか。 # OKじゃないなら今のうちに処置しないと間に合いません。 From from-tomoyo-dev ＠ i-love.sakura.ne.jp Thu Jul 30 09:11:19 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Thu, 30 Jul 2009 09:11:19 +0900 Subject: [Tomoyo-dev 1148] Re: =?iso-2022-jp?b?Y2NzLXRvb2xzIBskQiRyGyhCIDEuNi54LzIuMi54IA==?= =?iso-2022-jp?b?GyRCJEdKLE4lISIkKiRoJFMbKEIgMi4yLnggGyRCJFgbKEI=?= =?iso-2022-jp?b?GyRCJE4lWiE8JThNNkYzJEskRCQkJEYbKEI=?= In-Reply-To: <9292c1390907290615s5943698eq736f78dcf9fe94a4@mail.gmail.com> References: <200907232240.BAG13015.PENPPGZtUNWtFSP@I-love.SAKURA.ne.jp> <200907240506.n6O56iNr030508@www262.sakura.ne.jp> <200907270726.n6R7QKBL037671@www262.sakura.ne.jp> <20090729093451.ad0a31e0.henrich@debian.or.jp> <87r5w0udyz.wl%hitoht@gmail.com> <200907292203.FGJ52605.ttNZUGNPPPPWESF@I-love.SAKURA.ne.jp> <9292c1390907290615s5943698eq736f78dcf9fe94a4@mail.gmail.com> Message-ID: <200907300011.n6U0BJLq031533@www262.sakura.ne.jp> 　熊猫です。 > | 触った感じでは、ccstoolsでもbetter documentがあれば許容範囲 > は半田さん的にはOKという理解でいいですか？ 熊猫に better document は書けませんけどね。 > 言い換えると、tomoyo-toolsパッケージがUbuntu 9.10に入らなくても > 「少なくとも半田さんは」OKでしょうか。 > > # OKじゃないなら今のうちに処置しないと間に合いません。 別に構いませんが、 http://tomoyo.sourceforge.jp/2.2/ は既に tomoyo-tools を 使う記述になってしまっています。間に合わなかった場合、Ubuntu 9.10 ユーザに 対しては http://tomoyo.sourceforge.jp/en/2.2.x/ へ（あるいは Ubuntu 9.10 専用 ページを作って）誘導することになりますね。 From hitoht ＠ gmail.com Thu Jul 30 10:33:23 2009 From: hitoht ＠ gmail.com (hitoht ＠ gmail.com) Date: Thu, 30 Jul 2009 10:33:23 +0900 Subject: [Tomoyo-dev 1149] Re: =?iso-2022-jp?b?Y2NzLXRvb2xzIBskQiRyGyhCIDEuNi54LzIuMi54IA==?= =?iso-2022-jp?b?GyRCJEdKLE4lISIkKiRoJFMbKEIgMi4yLnggGyRCJFgkTiVaITwbKEI=?= =?iso-2022-jp?b?GyRCJThNNkYzJEskRCQkJEYbKEI=?= In-Reply-To: <200907300011.n6U0BJLq031533@www262.sakura.ne.jp> References: <200907232240.BAG13015.PENPPGZtUNWtFSP@I-love.SAKURA.ne.jp> <200907240506.n6O56iNr030508@www262.sakura.ne.jp> <200907270726.n6R7QKBL037671@www262.sakura.ne.jp> <20090729093451.ad0a31e0.henrich@debian.or.jp> <87r5w0udyz.wl%hitoht@gmail.com> <200907292203.FGJ52605.ttNZUGNPPPPWESF@I-love.SAKURA.ne.jp> <9292c1390907290615s5943698eq736f78dcf9fe94a4@mail.gmail.com> <200907300011.n6U0BJLq031533@www262.sakura.ne.jp> Message-ID: <87prbjuf8c.wl%hitoht@gmail.com> On Thu, 30 Jul 2009 09:11:19 +0900, wrote: > > 言い換えると、tomoyo-toolsパッケージがUbuntu 9.10に入らなくても > > 「少なくとも半田さんは」OKでしょうか。 > > > > # OKじゃないなら今のうちに処置しないと間に合いません。 > 別に構いませんが、 http://tomoyo.sourceforge.jp/2.2/ は既に tomoyo-tools を > 使う記述になってしまっています。間に合わなかった場合、Ubuntu 9.10 ユーザに > 対しては http://tomoyo.sourceforge.jp/en/2.2.x/ へ（あるいは Ubuntu 9.10 専用 > ページを作って）誘導することになりますね。 どっちにしろ各ディストリ *で* 専用のページ作らないと使ってもらえないので （TOMOYOだけでなく、あらゆるソフトウェアがそうです）、これはとくに問題に ならないハズです。 # migration policyがすげー不透明なあたりに問題とやるせなさを感じるんですが、 # これは「まだまだ開発中だから勘弁してね」の範疇かなぁ。