From from-tomoyo-dev @ I-love.SAKURA.ne.jp Sun Feb 1 20:29:22 2009 From: from-tomoyo-dev @ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 1 Feb 2009 20:29:22 +0900 Subject: [Tomoyo-dev 926] Re: =?iso-2022-jp?b?GyRCRjNGfjxqPWc9cSRLGyhCIEdlbnRvbyA=?= =?iso-2022-jp?b?GyRCJHJESTJDGyhC?= In-Reply-To: <200812232058.GFJ65195.UWNtPSPPEZNPGFt@I-love.SAKURA.ne.jp> References: <87tz8zo2qn.fsf@yue.localnetwork> <200812201754.HDB90610.UNEPPWtGSZNtPPF@I-love.SAKURA.ne.jp> <87tz8vwjth.fsf@yue.localnetwork> <200812231544.DFJ73931.PNPPPUSGZWttEFN@I-love.SAKURA.ne.jp> <200812232058.GFJ65195.UWNtPSPPEZNPGFt@I-love.SAKURA.ne.jp> Message-ID: <200902012029.IHI48461.NPZPtPUEtWFPNGS@I-love.SAKURA.ne.jp>  熊猫です。 tomoyo-users-en 39 が未解決ではありますが、 Hardened Gentoo 用のパッチを branches/ から trunk/ に移動しました。他のパッチの命名規則に合わせるために ファイル名を ccs-patch-2.6.27+grsecurity-2.1.12-2.6.27.10.diff から ccs-patch-2.6.27-grsecurity-2.1.12-2.6.27.10.diff に変更しました。 ところで、 tags/htdocs/repos/gentoo-overlay/sys-kernel/ccs-sources/ には 2.6.23 向けの ebuild ファイルがありません。 ccs-patch-2.6.23-gentoo-r9.diff はもう使わないということでしょうか? From from-tomoyo-users @ i-love.sakura.ne.jp Mon Feb 2 13:43:02 2009 From: from-tomoyo-users @ i-love.sakura.ne.jp (Tetsuo Handa) Date: Mon, 02 Feb 2009 13:43:02 +0900 Subject: [Tomoyo-dev 927] =?iso-2022-jp?b?VE9NT1lPIExpbnV4IDEuNi42IBskQiRyJWolaiE8JTkbKEI=?= =?iso-2022-jp?b?GyRCJDckXiQ3JD8hIxsoQg==?= Message-ID: <200902020443.n124h2Ym067446@www262.sakura.ne.jp>  熊猫です。  1.6.6 は 1.6.0 〜 1.6.5 に存在していた不具合を3件修正したものです。 修正1:  MAX_GRANT_LOG および MAX_REJECT_LOG が機能していなかったため、  アクセスログを読み出してやらなかった場合にメモリ不足に陥り  システムがクラッシュしてしまう不具合を修正しました。  1.6.5 で混入した不具合です。 修正2:  SYAORAN ファイルシステムにおいて、アクセスが許可されたときに  エラーメッセージが表示され、拒否されたときにエラーメッセージが  表示されないようになっていた不具合を修正しました。  1.6.0 で混入した不具合です。 修正3:  あるパス名に対して allow_read/write という許可だけを与えた場合、  読み書きモードでのオープンは許可されるものの、読み込み専用モードでの  オープンと書き込み専用モードでのオープンが拒否されてしまうという  不具合を修正しました。  1.6.0 で混入した不具合です。 ccs-patch-1.6.6-20090202.tar.gz MD5: cceb1731d3720030eac34ed128848b32 ccs-tools-1.6.6-20090202.tar.gz MD5: ee6900297b263bebe19156c32c652f36  これからバイナリパッケージを作成していきます。  よろしくお願いします。 From naota @ elisp.net Mon Feb 2 19:05:17 2009 From: naota @ elisp.net (Naohiro Aota) Date: Mon, 02 Feb 2009 19:05:17 +0900 Subject: [Tomoyo-dev 928] Re: =?iso-2022-jp?b?GyRCRjNGfjxqPWc9cSRLGyhCIEdlbnRvbyA=?= =?iso-2022-jp?b?GyRCJHJESTJDGyhC?= In-Reply-To: <200902012029.IHI48461.NPZPtPUEtWFPNGS@I-love.SAKURA.ne.jp> (Tetsuo Handa's message of "Sun, 1 Feb 2009 20:29:22 +0900") References: <87tz8zo2qn.fsf@yue.localnetwork> <200812201754.HDB90610.UNEPPWtGSZNtPPF@I-love.SAKURA.ne.jp> <87tz8vwjth.fsf@yue.localnetwork> <200812231544.DFJ73931.PNPPPUSGZWttEFN@I-love.SAKURA.ne.jp> <200812232058.GFJ65195.UWNtPSPPEZNPGFt@I-love.SAKURA.ne.jp> <200902012029.IHI48461.NPZPtPUEtWFPNGS@I-love.SAKURA.ne.jp> Message-ID: <87ocxli276.fsf@yue.localnetwork> Tetsuo Handa writes: >  熊猫です。 > > tomoyo-users-en 39 が未解決ではありますが、 Hardened Gentoo 用のパッチを > branches/ から trunk/ に移動しました。他のパッチの命名規則に合わせるために > ファイル名を ccs-patch-2.6.27+grsecurity-2.1.12-2.6.27.10.diff から > ccs-patch-2.6.27-grsecurity-2.1.12-2.6.27.10.diff に変更しました。 ありがとうございます。一応、ぼくも手元の環境を hardened にして kvm をいれ ようとしているのですが、まず kvm が入らない状態でつまってます… :( ;; 最近、いそがしくてなかなか反応できなくてすみません。 > ところで、 tags/htdocs/repos/gentoo-overlay/sys-kernel/ccs-sources/ には > 2.6.23 向けの ebuild ファイルがありません。 > ccs-patch-2.6.23-gentoo-r9.diff はもう使わないということでしょうか? ccs-sources は基本的に gentoo-sources のマスク状況、サポート状況などに従 うようにしています。 gentoo-sources のほうで 2.6.23 向けの ebuild がなく なってしまったので ccs-sources のほうも削除しました。 そういうわけなので、 ebuild で ccs-patch-2.6.23-gentoo-r9.diff を使うことはないと思いますし、 自分でパッチをあてようと思ったユーザが、 ccs-patch-2.6.23-gentoo-r9.diff があることを期待することもおそらくないと思います。 -- 青田 From takedakn @ nttdata.co.jp Mon Feb 2 19:50:38 2009 From: takedakn @ nttdata.co.jp (Kentaro Takeda) Date: Mon, 02 Feb 2009 19:50:38 +0900 Subject: [Tomoyo-dev 929] =?utf-8?q?Ubuntu_8=2E04=2E2_+_TOMOYO_Linux_1=2E6=2E6_LiveCD?= =?utf-8?b?44KS5YWs6ZaL44GX44G+44GX44Gf?= In-Reply-To: <48CA4509.9010505@nttdata.co.jp> References: <20080827112934.75089.qmail@web10604.mail.bbt.yahoo.co.jp> <48BC9A5B.506@nttdata.co.jp> <012201c90cc3$89c75d70$89fea8c0@netdom1.local> <48BD2B55.4080905@nttdata.co.jp> <48CA4509.9010505@nttdata.co.jp> Message-ID: <4986CFFE.3060103@nttdata.co.jp> 武田です。 TOMOYO Linux 1.6.6に対応したUbuntu 8.04.2ベースの LiveCDを公開しました。 8.04.2リリース直後のためほとんどほとんどありませんでしたが、 いつもどおり本日の最新版にアップデートをかけています。 Ekiga(ソフトフォン)を削除していますが、削除しなくても 700MBにおさまったかも。 日本語ページ: http://tomoyo.sourceforge.jp/wiki/?TomoyoLive 英語ページ: http://tomoyo.sourceforge.jp/wiki-e/?TomoyoLive (ファイルへの直リンク) ■Ubuntu 8.04.2 本家DesktopCDベース: http://tomoyo.sourceforge.jp/incoming/ubuntu-8.04.2-desktop-i386-tomoyo-1.6.6.iso 日本語RemixCDベース: http://tomoyo.sourceforge.jp/incoming/ubuntu-ja-8.04.2-desktop-i386-tomoyo-1.6.6.iso ハッシュ値は以下の通りです。 *MD5SUM f6e5dcb78de713787f01001ed4a849e0 ubuntu-8.04.2-desktop-i386-tomoyo-1.6.6.iso 076bd088cd957dd60d581323d5f3fcce ubuntu-ja-8.04.2-desktop-i386-tomoyo-1.6.6.iso *SHA1SUM 68e5e56ec4f9fafaddb13dbade84a7eb87000256 ubuntu-8.04.2-desktop-i386-tomoyo-1.6.6.iso bbd1d665619d242d0ab9c0a32fa888cd4c8fd456 ubuntu-ja-8.04.2-desktop-i386-tomoyo-1.6.6.iso *SHA256SUM db9e3761990894a2cf3be3d3719267bdba8cc55bc211289e08687000afabf61c ubuntu-8.04.2-desktop-i386-tomoyo-1.6.6.iso bbb5ad06732bedd2edd4ee45bed79fe1da78c7028cbda89b4ea30f0fb6451b4e ubuntu-ja-8.04.2-desktop-i386-tomoyo-1.6.6.iso お試しください。 -- 武田健太郎 PGP公開鍵はこちら https://sourceforge.jp/users/takedakn/ -------------- next part -------------- $B%F%-%9%H7A<00J30$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B... $B%U%!%$%kL>(B: signature.asc $B7?(B: application/pgp-signature $B%5%$%:(B: 258 $B%P%$%H(B $B @ bL@(B: OpenPGP digital signature URL: http://lists.sourceforge.jp/mailman/archives/tomoyo-dev/attachments/20090202/d7d33ae7/attachment.pgp From from-tomoyo-dev @ I-love.SAKURA.ne.jp Mon Feb 2 21:35:35 2009 From: from-tomoyo-dev @ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Mon, 2 Feb 2009 21:35:35 +0900 Subject: [Tomoyo-dev 930] Re: =?iso-2022-jp?b?GyRCRjNGfjxqPWc9cSRLGyhCR2VudG9vGyRCJHIbKEI=?= =?iso-2022-jp?b?GyRCREkyQxsoQg==?= In-Reply-To: <87ocxli276.fsf@yue.localnetwork> References: <87tz8vwjth.fsf@yue.localnetwork> <200812231544.DFJ73931.PNPPPUSGZWttEFN@I-love.SAKURA.ne.jp> <200812232058.GFJ65195.UWNtPSPPEZNPGFt@I-love.SAKURA.ne.jp> <200902012029.IHI48461.NPZPtPUEtWFPNGS@I-love.SAKURA.ne.jp> <87ocxli276.fsf@yue.localnetwork> Message-ID: <200902022135.HIE32988.tPPNPZtEFNWUPSG@I-love.SAKURA.ne.jp>  熊猫です。 Naohiro Aota さんは書きました: > ありがとうございます。一応、ぼくも手元の環境を hardened にして kvm をいれ > ようとしているのですが、まず kvm が入らない状態でつまってます… :( 熊猫の環境では emerge -C kvm USE="-sdl" emerge =app-emulation/kvm-82 でインストールできたと思います。 > ;; 最近、いそがしくてなかなか反応できなくてすみません。 大丈夫ですよ。 > ccs-sources は基本的に gentoo-sources のマスク状況、サポート状況などに従 > うようにしています。 gentoo-sources のほうで 2.6.23 向けの ebuild がなく > なってしまったので ccs-sources のほうも削除しました。 そういうわけなので、 > ebuild で ccs-patch-2.6.23-gentoo-r9.diff を使うことはないと思いますし、 > 自分でパッチをあてようと思ったユーザが、 ccs-patch-2.6.23-gentoo-r9.diff > があることを期待することもおそらくないと思います。 なるほど。では、元々差分が 1c1 < This is TOMOYO Linux patch for kernel 2.6.23.17. > This is TOMOYO Linux patch for Gentoo Linux. 3c3 < Source code for this patch is http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.23.17.tar.bz2 > Source code for this patch is "emerge gentoo-sources" 933c933 < + printk(KERN_INFO "Hook version: 2.6.23.17 2008/10/30\n"); > + printk(KERN_INFO "Hook version: 2.6.23-gentoo-r9 2008/10/30\n"); だけなので、必要になったらバニラカーネル用のを当ててもらうということに したいと思います。( ccs-patch-\*.diff 同士を比較するために以下のような スクリプトを使っています。) #! /bin/sh diff "$@" | grep -v '^[<>] diff' | grep -v '^[<>] ---' | grep -v '^[<>] +++' | grep -vF -- '---' | grep -v '^[<>] @@' From hiroshi.shinji @ gmail.com Sun Feb 8 22:59:46 2009 From: hiroshi.shinji @ gmail.com (Hiroshi Shinji) Date: Sun, 8 Feb 2009 22:59:46 +0900 Subject: [Tomoyo-dev 931] =?iso-2022-jp?b?L2V0Yy9jY3MvbWFuYWdlci5jb25mIBskQiRLJEQkJCRGGyhC?= Message-ID: 宍道です。 /etc/ccs/manager.conf には、ポリシーの設定変更可能なプログラムを 記述することになってます。で、起動時に /proc/ccs/manager に 反映されます。 が、私の環境ではこの manager.conf に、そのプログラム名 (ccstools へのリンク名)を記述しても利用することができません。 # ls -la /usr/sbin/ | grep ccstools lrwxrwxrwx 1 root root 8 Feb 7 01:21 ccs-auditd -> ccstools lrwxrwxrwx 1 root root 8 Feb 7 01:21 ccs-queryd -> ccstools -rwx------ 1 root root 84980 Feb 7 01:35 ccstools lrwxrwxrwx 1 root root 8 Feb 7 01:21 ccstree -> ccstools lrwxrwxrwx 1 root root 8 Feb 7 01:21 checkpolicy -> ccstools lrwxrwxrwx 1 root root 8 Feb 7 01:21 domainmatch -> ccstools lrwxrwxrwx 1 root root 8 Feb 7 01:21 editpolicy -> ccstools lrwxrwxrwx 1 root root 8 Feb 7 01:21 editpolicy_offline -> ccstools lrwxrwxrwx 1 root root 8 Feb 7 01:21 findtemp -> ccstools lrwxrwxrwx 1 root root 8 Feb 7 01:21 ld-watch -> ccstools lrwxrwxrwx 1 root root 8 Feb 7 01:21 loadpolicy -> ccstools lrwxrwxrwx 1 root root 8 Feb 7 01:21 pathmatch -> ccstools lrwxrwxrwx 1 root root 8 Feb 7 01:21 patternize -> ccstools lrwxrwxrwx 1 root root 8 Feb 7 01:21 savepolicy -> ccstools lrwxrwxrwx 1 root root 8 Feb 7 01:21 setlevel -> ccstools lrwxrwxrwx 1 root root 8 Feb 7 01:21 setprofile -> ccstools lrwxrwxrwx 1 root root 8 Feb 7 01:21 sortpolicy -> ccstools # cat /proc/ccs/manager /usr/sbin/loadpolicy /usr/sbin/editpolicy /usr/sbin/setlevel /usr/sbin/setprofile /usr/sbin/ld-watch /usr/sbin/ccs-queryd # editpolicy /sbin/init /sbin/getty /bin/login /bin/sh /usr/sbin/editpolicy ( /usr/sbin/ccstools ) is not permitted to update policies. You need to register this program to /proc/ccs/manager to run this program. # しかたがないので、実体(上記の場合 /usr/sbin/ccstools)のみを manager.conf に記述して、editpolicy などを使えるようにしています。 これって、私の環境だけですかねぇ? 他の環境では、普通に使えていますか? よろしくお願いします。 -- 宍道 洋 hiroshi.shinji @ gmail.com http://d.hatena.ne.jp/hshinji/ From from-tomoyo-dev @ I-love.SAKURA.ne.jp Mon Feb 9 06:46:02 2009 From: from-tomoyo-dev @ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Mon, 9 Feb 2009 06:46:02 +0900 Subject: [Tomoyo-dev 932] Re: =?iso-2022-jp?b?L2V0Yy9jY3MvbWFuYWdlci5jb25mIBskQiRLJEQbKEI=?= =?iso-2022-jp?b?GyRCJCQkRhsoQg==?= In-Reply-To: References: Message-ID: <200902090646.FHF43790.tNPFNPPWPEtUGSZ@I-love.SAKURA.ne.jp>  熊猫です。 Hiroshi Shinji さんは書きました: > が、私の環境ではこの manager.conf に、そのプログラム名 > (ccstools へのリンク名)を記述しても利用することができません。 /etc/ccs/manager.conf にパス名を記述する場合は、シンボリックリンクではなく シンボリックリンクを解決した後のパス名を記述してください。(これは、ファイルに 関するアクセス制御でシンボリックリンクを解決した後のパス名を記述するのと 同じ理由です。シンボリックリンクを解決後の dentry と vfsmount からパス名を 逆算しているため、シンボリックリンクを利用したことを知る術がありません。) デフォルト設定では「 /usr/lib/ccs/ 以下にある ccstools のハードリンクへの シンボリックリンク」が作成されるので、「 /usr/lib/ccs/ 以下にある ccstools の ハードリンク」を指定します。宍道さんの環境の場合、「 /usr/sbin/ 以下にある ccstools へのシンボリックリンク」を作成されているので、「 ccstools のパス名」 (つまり /usr/sbin/ccstools )を指定してください。 > # editpolicy > /sbin/init /sbin/getty /bin/login /bin/sh > /usr/sbin/editpolicy ( /usr/sbin/ccstools ) is not permitted to update > policies. このエラーメッセージは「ドメイン名(プログラム名)is not permitted to update policies. 」という書式であり、ドメイン名に関しては alias 構文により シンボリックリンクを解決する前のパス名を指定することが可能です。 ドメイン名で指定する方が、そのドメインに到達しないと設定を変更できないため、 MAC_FOR_FILE=enforcing なプロファイルが割り当てられていないドメインから 不正に実行される可能性を低くすることができます。(尤も、MAC_FOR_FILE=enforcing なプロファイルが割り当てられていないドメインがあるのは望ましくないのですが。) From from-tomoyo-users @ i-love.sakura.ne.jp Mon Feb 9 13:31:57 2009 From: from-tomoyo-users @ i-love.sakura.ne.jp (Tetsuo Handa) Date: Mon, 09 Feb 2009 13:31:57 +0900 Subject: [Tomoyo-dev 933] Re: =?iso-2022-jp?b?VE9NT1lPIExpbnV4IDEuNi42IBskQiRyJWolaiE8GyhC?= =?iso-2022-jp?b?GyRCJTkkNyReJDckPyEjGyhC?= In-Reply-To: <200902020443.n124h2Ym067446@www262.sakura.ne.jp> References: <200902020443.n124h2Ym067446@www262.sakura.ne.jp> Message-ID: <200902090431.n194Vvg9080102@www262.sakura.ne.jp>  熊猫です。 >  これからバイナリパッケージを作成していきます。  全部の 1.6.6 バイナリパッケージのコンパイルが完了しました。 http://sourceforge.jp/projects/tomoyo/releases/?package_id=5026 From haradats @ nttdata.co.jp Thu Feb 12 14:38:45 2009 From: haradats @ nttdata.co.jp (Toshiharu Harada) Date: Thu, 12 Feb 2009 14:38:45 +0900 Subject: [Tomoyo-dev 934] Fwd: [TOMOYO #15 0/8] TOMOYO Linux References: Message-ID: <4E2E622D-3721-4997-988D-EB500A2F48C7@nttdata.co.jp> Jamesのツリーに入ったぜ。 Begin forwarded message: > 差出人: James Morris > 日時: 2009年2月12日 14:34:16:JST > 宛先: Kentaro Takeda > Cc: linux-security-module at vger.kernel.org, linux-kernel at vger.kernel.org > , akpm at linux-foundation.org, haradats at nttdata.co.jp > 件名: Re: [TOMOYO #15 0/8] TOMOYO Linux > > On Thu, 5 Feb 2009, Kentaro Takeda wrote: > >> TOMOYO Linux is a name-based MAC extension (LSM module) for the >> Linux kernel. >> > > Applied to > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security- > testing-2.6#next > > Please fix the following issue detected by sparse: > > $ make C=2 SUBDIRS=security/tomoyo CF="-D__cold__=" > CHECK security/tomoyo/common.c > CHECK security/tomoyo/realpath.c > CHECK security/tomoyo/tomoyo.c > security/tomoyo/tomoyo.c:110:8: warning: symbol 'buf' shadows an > earlier one > security/tomoyo/tomoyo.c:100:7: originally declared here > > The fix is not obvious. You should be running sparse, too. > > I also fixed up the link order so security=tomoyo works when > root_plug is > enabled. > > > - James > -- > James Morris > From yocto1 @ gmail.com Thu Feb 12 22:23:29 2009 From: yocto1 @ gmail.com (yocto) Date: Thu, 12 Feb 2009 22:23:29 +0900 Subject: [Tomoyo-dev 935] Re: Fwd: [TOMOYO #15 0/8] TOMOYO Linux In-Reply-To: <4E2E622D-3721-4997-988D-EB500A2F48C7@nttdata.co.jp> References: <4E2E622D-3721-4997-988D-EB500A2F48C7@nttdata.co.jp> Message-ID: <8f3c749a0902120523h28b41c48xfa6dc555b861f7fe@mail.gmail.com> \(^o^)/ !(^^)! (^_^)v 2009/02/12 14:38 Toshiharu Harada : > Jamesのツリーに入ったぜ。 From haradats @ gmail.com Thu Feb 12 22:29:37 2009 From: haradats @ gmail.com (Toshiharu Harada) Date: Thu, 12 Feb 2009 22:29:37 +0900 Subject: [Tomoyo-dev 936] Re: Fwd: [TOMOYO #15 0/8] TOMOYO Linux In-Reply-To: <8f3c749a0902120523h28b41c48xfa6dc555b861f7fe@mail.gmail.com> References: <4E2E622D-3721-4997-988D-EB500A2F48C7@nttdata.co.jp> <8f3c749a0902120523h28b41c48xfa6dc555b861f7fe@mail.gmail.com> Message-ID: <9d732d950902120529i183c6d4g3994dd552782c294@mail.gmail.com> どうもありがとうございます。今ひとつぴんときませんが、 Linusのツリーに入ると、もっと実感がわくかもしれません。 2009/02/12 22:23 yocto : > \(^o^)/ !(^^)! (^_^)v > > 2009/02/12 14:38 Toshiharu Harada : >> Jamesのツリーに入ったぜ。 -- Toshiharu Harada haradats @ gmail.com From from-tomoyo-dev @ I-love.SAKURA.ne.jp Sat Feb 14 21:25:21 2009 From: from-tomoyo-dev @ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 14 Feb 2009 21:25:21 +0900 Subject: [Tomoyo-dev 937] =?iso-2022-jp?b?VWJ1bnR1IBskQiRYJE4bKEIgVE9NT1lPIBskQiROOkYbKEI=?= =?iso-2022-jp?b?GyRCRHMwRhsoQg==?= Message-ID: <200902142125.HCH13535.NttWZPEPPSUNPFG@I-love.SAKURA.ne.jp>  熊猫です。  以前、 Ubuntu のMLで TOMOYO を紹介したところ、セキュリティ専門家に 「これ以上 out-of-mainline MAC を導入することに興味はない」と却下され そこで止まっていました。 https://lists.ubuntu.com/archives/kernel-team/2008-August/002965.html その後も mainline への提案活動を続け、昨年8月時点とは状況が 変わってきていると思うので、再提案しても良い時期なのではと思います。 何かアイデアはありますか? From hitoht @ gmail.com Sat Feb 14 21:49:41 2009 From: hitoht @ gmail.com (hito) Date: Sat, 14 Feb 2009 21:49:41 +0900 Subject: [Tomoyo-dev 938] Re: =?iso-2022-jp?b?VWJ1bnR1IBskQiRYJE4bKEIgVE9NT1lPIBskQiROGyhC?= =?iso-2022-jp?b?GyRCOkZEczBGGyhC?= In-Reply-To: <200902142125.HCH13535.NttWZPEPPSUNPFG@I-love.SAKURA.ne.jp> References: <200902142125.HCH13535.NttWZPEPPSUNPFG@I-love.SAKURA.ne.jp> Message-ID: <9292c1390902140449r37e9d9d2g87c72941aa58d59d@mail.gmail.com> > 以前、 Ubuntu のMLで TOMOYO を紹介したところ、セキュリティ専門家に > 「これ以上 out-of-mainline MAC を導入することに興味はない」と却下され > そこで止まっていました。 > https://lists.ubuntu.com/archives/kernel-team/2008-August/002965.html > その後も mainline への提案活動を続け、昨年8月時点とは状況が > 変わってきていると思うので、再提案しても良い時期なのではと思います。 > 何かアイデアはありますか? ちょっと前提を整理させてください。 9.04のFeature freezeは終わった(Merge windowはすでに閉じてしまった)ので、 やるとすると9.10になります。 Q1: 9.10は2.6.29 or 2.6.30になるはずなのですが、「それって2.6.31とか32で 入るんでしょ?」とか言われた場合はどうやって抵抗しましょうか? (腹案としては「AppArmorはMainlineにつっこまれることはないし使いにくいんで TOMOYOに乗り換えようよ、どうせもうすぐLinusのツリーに入るし、10.04 LTSで いきなり入れるのヤでそ、9.10でテストしとこうよAppArmor捨てて」って説得する、 だったりしますが……) Q2: Ubuntuには複数のEditionがありますが、Desktop / Serverの両方に入れたいですか? もしやるなら、比較的独自の新機能を入れることに熱心なServer Teamを説得して AppArmorに対する優位性を示して、Kernel Teamを説得する、てな流れになると 思います(UbuntuのServer Teamは最近Debianに対する優位性を確保するために 独自の新機能を実装しまくりなので目はあるかと思います)。 言い換えると、Server Editionにだけ入れるのは目がありそう、そこからDesktopも 巻き込む、とかそんな感じで進めるのが妥当そうなのですが、この場合だと Desktop には入らない可能性もあります。 From from-tomoyo-dev @ I-love.SAKURA.ne.jp Sat Feb 14 22:07:36 2009 From: from-tomoyo-dev @ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 14 Feb 2009 22:07:36 +0900 Subject: [Tomoyo-dev 939] Re: =?iso-2022-jp?b?VWJ1bnR1IBskQiRYJE4bKEIgVE9NT1lPIBskQiROGyhC?= =?iso-2022-jp?b?GyRCOkZEczBGGyhC?= In-Reply-To: <9292c1390902140449r37e9d9d2g87c72941aa58d59d@mail.gmail.com> References: <200902142125.HCH13535.NttWZPEPPSUNPFG@I-love.SAKURA.ne.jp> <9292c1390902140449r37e9d9d2g87c72941aa58d59d@mail.gmail.com> Message-ID: <200902142207.IBC98855.ENZPFUWPPtGNtPS@I-love.SAKURA.ne.jp>  熊猫です。 > Q1: 9.10は2.6.29 or 2.6.30になるはずなのですが、「それって2.6.31とか32で > 入るんでしょ?」とか言われた場合はどうやって抵抗しましょうか? 「入るけれど(1)まだまだ機能が限定されている(2) AppArmor や SELinux と 共存できるようにしたいので 1.6 系を提案する」です。 > (腹案としては「AppArmorはMainlineにつっこまれることはないし使いにくいんで > TOMOYOに乗り換えようよ、どうせもうすぐLinusのツリーに入るし、10.04 LTSで > いきなり入れるのヤでそ、9.10でテストしとこうよAppArmor捨てて」って説得する、 > だったりしますが……) AppArmor と TOMOYO の重複箇所が多いのは事実ですが、別に排他的に存在する義務は 無いと思います。熊猫としては「 SELinux を捨てて TOMOYO に乗り換える」とか 「 AppArmor を捨てて TOMOYO に乗り換える」という提案はしたくないです。 > Q2: Ubuntuには複数のEditionがありますが、Desktop / Serverの両方に入れたいですか? > > もしやるなら、比較的独自の新機能を入れることに熱心なServer Teamを説得して > AppArmorに対する優位性を示して、Kernel Teamを説得する、てな流れになると > 思います(UbuntuのServer Teamは最近Debianに対する優位性を確保するために > 独自の新機能を実装しまくりなので目はあるかと思います)。 へぇ〜。 Desktop Team と Server Team って別なんですか。 > > 言い換えると、Server Editionにだけ入れるのは目がありそう、そこからDesktopも > 巻き込む、とかそんな感じで進めるのが妥当そうなのですが、この場合だと > Desktop には入らない可能性もあります。 > TOMOYO はサーバ用途が得意なので、 Server Edition を先に狙うのでOKです。 デスクトップ用途のポリシーは(例えばブラウザからメーラーやオフィスソフトを 呼び出すなど複雑であるため)ある程度 TOMOYO に慣れてノウハウを蓄積してからに なると思います。 From hitoht @ gmail.com Sat Feb 14 23:09:05 2009 From: hitoht @ gmail.com (hito) Date: Sat, 14 Feb 2009 23:09:05 +0900 Subject: [Tomoyo-dev 940] Re: =?iso-2022-jp?b?VWJ1bnR1IBskQiRYJE4bKEIgVE9NT1lPIBskQiROGyhC?= =?iso-2022-jp?b?GyRCOkZEczBGGyhC?= In-Reply-To: <200902142207.IBC98855.ENZPFUWPPtGNtPS@I-love.SAKURA.ne.jp> References: <200902142125.HCH13535.NttWZPEPPSUNPFG@I-love.SAKURA.ne.jp> <9292c1390902140449r37e9d9d2g87c72941aa58d59d@mail.gmail.com> <200902142207.IBC98855.ENZPFUWPPtGNtPS@I-love.SAKURA.ne.jp> Message-ID: <9292c1390902140609o6a2c7f23h2287bd79d9e33369@mail.gmail.com> >> Q1: 9.10は2.6.29 or 2.6.30になるはずなのですが、「それって2.6.31とか32で >> 入るんでしょ?」とか言われた場合はどうやって抵抗しましょうか? > 「入るけれど(1)まだまだ機能が限定されている(2) AppArmor や SELinux と > 共存できるようにしたいので 1.6 系を提案する」です。 ぬぬぬ。1.6系なら、「いずれMainlineになるの確定だからプリフライトしようよ」 じゃロジックとしてダメということになりますね。 # 「Mainlineに入れた実績があるからこれから1.6系の機能も入るよきっと、 # プリフライトしない?」でもいけるかな……。 確認なのですが、 ・1.6系が蹴られるなら2系でもいい。 ・どうしても1.6系がいい。 のどちらでしょうか? 前者なら比較的戦いやすいですが、後者はとても大変(たぶん無理)かと思います。 あまりリソースの多くない(Kernel Teamのcoreは数名)環境で、いつMainlineに 入るのかが分からないものを入れてもらうのは相当大変です。 別の話ではありますが、-rt(Realtime Kernel)なぞ8.10では「いったん休憩、使いたい 人は8.04のカーネル使い続けてね」という豪快な展開になりましたし。 >> (腹案としては「AppArmorはMainlineにつっこまれることはないし使いにくいんで >> TOMOYOに乗り換えようよ、どうせもうすぐLinusのツリーに入るし、10.04 LTSで >> いきなり入れるのヤでそ、9.10でテストしとこうよAppArmor捨てて」って説得する、 >> だったりしますが……) > AppArmor と TOMOYO の重複箇所が多いのは事実ですが、別に排他的に存在する義務は > 無いと思います。熊猫としては「 SELinux を捨てて TOMOYO に乗り換える」とか > 「 AppArmor を捨てて TOMOYO に乗り換える」という提案はしたくないです。 ええと、テクニカルな面では排他ではないのですが、リソース面ではほぼ 排他である、と考えて頂いた方がいいと思います。Canonical社員の中で Kernelと戦える人は少ないので、  ・TOMOYOを追加サポートするリソースを捻出するだけの理由 が必要になります。 言い換えると「AppArmorでいーじゃん」という悪魔の発言を覆せるだけの *技術にとどまらない* 説得力がないと以前と同じことになるかと。 そして、「もうすぐMainline」は割とこの種の説得力がある気が……。 まぁそのあたりの取捨選択はUbuntuのcore-devやTech boardの人たちの 判断なので、提案時点では「TOMOYO足さない?」と聞いてもいいような 気はします。 ただ、最終的な判断として「AppArmor捨てて乗り換え」になるかなー、ぐらいの 情報は入れ込んでおくことが必要です。 # ていうか、TOMOYOが入ったら、結果としてAppArmor捨てになる可能性は # 大変高いです。 >> Q2: Ubuntuには複数のEditionがありますが、Desktop / Serverの両方に入れたいですか? >> >> もしやるなら、比較的独自の新機能を入れることに熱心なServer Teamを説得して >> AppArmorに対する優位性を示して、Kernel Teamを説得する、てな流れになると >> 思います(UbuntuのServer Teamは最近Debianに対する優位性を確保するために >> 独自の新機能を実装しまくりなので目はあるかと思います)。 > へぇ〜。 Desktop Team と Server Team って別なんですか。 はい。おおまかには、  ・Desktop Team = GNOMEとかいろいろなものをがんばって統合する。  ・Server Team = 気合いの入った独自機能を実装しまくる。 という違いがあります(この一年ぐらいでServer Teamがそういう文化になった)。 >> 言い換えると、Server Editionにだけ入れるのは目がありそう、そこからDesktopも >> 巻き込む、とかそんな感じで進めるのが妥当そうなのですが、この場合だと >> Desktop には入らない可能性もあります。 >> > TOMOYO はサーバ用途が得意なので、 Server Edition を先に狙うのでOKです。 > デスクトップ用途のポリシーは(例えばブラウザからメーラーやオフィスソフトを > 呼び出すなど複雑であるため)ある程度 TOMOYO に慣れてノウハウを蓄積してからに > なると思います。 まぁServer Editionはscreen-profilesとかpython-vmbuilderとかufwとか Encrypted Private Directoryとか、あげくの果てには/etc/の下は毎日 自動的にVCS(Bzr)にコミットして任意の時点に戻れるようにするぜー (っていうのがデフォルトで動作)とかいう、古いUnix使いにはどん引きな 新機能も実装しやがるので、 「プロファイリング用を兼ねてTOMOYOどうよ? なんかパッチは日本に 住んでる白黒の生き物がちゃんと作ってくれるみたいだし」 とか言うと取り込んでくれる……かなぁと思います。 あと、9.04はKernel Team大忙しなので(ちょっと実装する機能が豪快)、 提案するならしばらく待った方がいいと思います。今提案しても「知らん」 の一言で終わらされそうです。 From from-tomoyo-dev @ I-love.SAKURA.ne.jp Sun Feb 15 00:42:06 2009 From: from-tomoyo-dev @ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 15 Feb 2009 00:42:06 +0900 Subject: [Tomoyo-dev 941] Re: =?iso-2022-jp?b?VWJ1bnR1IBskQiRYJE4bKEIgVE9NT1lPIBskQiROGyhC?= =?iso-2022-jp?b?GyRCOkZEczBGGyhC?= In-Reply-To: <9292c1390902140609o6a2c7f23h2287bd79d9e33369@mail.gmail.com> References: <200902142125.HCH13535.NttWZPEPPSUNPFG@I-love.SAKURA.ne.jp> <9292c1390902140449r37e9d9d2g87c72941aa58d59d@mail.gmail.com> <200902142207.IBC98855.ENZPFUWPPtGNtPS@I-love.SAKURA.ne.jp> <9292c1390902140609o6a2c7f23h2287bd79d9e33369@mail.gmail.com> Message-ID: <200902150042.CBF73985.GFNESPPZWPUPttN@I-love.SAKURA.ne.jp>  熊猫です。 > 前者なら比較的戦いやすいですが、後者はとても大変(たぶん無理)かと思います。 > あまりリソースの多くない(Kernel Teamのcoreは数名)環境で、いつMainlineに > 入るのかが分からないものを入れてもらうのは相当大変です。 2.2 系は「ファイルの制御のみ」「アクセスログ機能なし」「アップデート時の対話的 処理なし」なので、アクセス制御用途としては力不足だと考えています。 > 言い換えると「AppArmorでいーじゃん」という悪魔の発言を覆せるだけの > *技術にとどまらない* 説得力がないと以前と同じことになるかと。 > そして、「もうすぐMainline」は割とこの種の説得力がある気が……。 はい。「もうすぐMainline」が今回の再提案の理由です。 「 TOMOYO 1.6 のサブセットである TOMOYO 2.2 に必要なフックが 2.6.29-rc1 で 追加され、 TOMOYO 2.2 自体ももうじきメインライン入りする見込みであり、 メインライン入り後は順次 TOMOYO 1.6 の機能を移植していく予定なので、 TOMOYO 1.6 が使えなくなる心配はかなり小さい」というのが 1.6 系を推す理由です。 8.10 で custom binary 作成機能が除外されてしまったのは痛手です。 https://lists.ubuntu.com/archives/kernel-team/2008-September/003066.html 現状では、 linux-headers パッケージ等が競合してしまうので気軽に TOMOYO を インストールできないのです。 最低限 custom binary 作成機能が復活すれば、「標準カーネルは Canonical が サポート、 TOMOYO カーネルは熊猫がサポート」という方法も可能です。 generic と server は TOMOYO 無効で構わないから、カーネルコンフィグを弄るだけで TOMOYO 有効なカーネルを生成できる状況( TOMOYO パッチ適用済みソース)まで 持ち込めると、パッケージの競合問題が解決するので、熊猫のサポートがだいぶ楽に なります。 > 「プロファイリング用を兼ねてTOMOYOどうよ? なんかパッチは日本に > 住んでる白黒の生き物がちゃんと作ってくれるみたいだし」 > とか言うと取り込んでくれる……かなぁと思います。 「パッチは日本に住んでる白黒の生き物がちゃんと作ってくれるみたいだし」 ということは、熊猫以外のどなたかからコンタクトしていただけるということですか? > あと、9.04はKernel Team大忙しなので(ちょっと実装する機能が豪快)、 > 提案するならしばらく待った方がいいと思います。今提案しても「知らん」 > の一言で終わらされそうです。 今コンタクトするとしたら kernel-team ML への投稿ではなく 別のルート( core-dev や Tech board ?)を使うことになりそうですね。 From hitoht @ gmail.com Sun Feb 15 22:39:23 2009 From: hitoht @ gmail.com (hito) Date: Sun, 15 Feb 2009 22:39:23 +0900 Subject: [Tomoyo-dev 942] Re: =?iso-2022-jp?b?VWJ1bnR1IBskQiRYJE4bKEIgVE9NT1lPIBskQiROGyhC?= =?iso-2022-jp?b?GyRCOkZEczBGGyhC?= In-Reply-To: <200902150042.CBF73985.GFNESPPZWPUPttN@I-love.SAKURA.ne.jp> References: <200902142125.HCH13535.NttWZPEPPSUNPFG@I-love.SAKURA.ne.jp> <9292c1390902140449r37e9d9d2g87c72941aa58d59d@mail.gmail.com> <200902142207.IBC98855.ENZPFUWPPtGNtPS@I-love.SAKURA.ne.jp> <9292c1390902140609o6a2c7f23h2287bd79d9e33369@mail.gmail.com> <200902150042.CBF73985.GFNESPPZWPUPttN@I-love.SAKURA.ne.jp> Message-ID: <9292c1390902150539k1f3dedc6u630fa704f9e281c1@mail.gmail.com> >> 言い換えると「AppArmorでいーじゃん」という悪魔の発言を覆せるだけの >> *技術にとどまらない* 説得力がないと以前と同じことになるかと。 >> そして、「もうすぐMainline」は割とこの種の説得力がある気が……。 > はい。「もうすぐMainline」が今回の再提案の理由です。 > 「 TOMOYO 1.6 のサブセットである TOMOYO 2.2 に必要なフックが 2.6.29-rc1 で > 追加され、 TOMOYO 2.2 自体ももうじきメインライン入りする見込みであり、 > メインライン入り後は順次 TOMOYO 1.6 の機能を移植していく予定なので、 > TOMOYO 1.6 が使えなくなる心配はかなり小さい」というのが 1.6 系を推す理由です。 うう。  ・Mainlineに入ったのは2系。  ・1.6系はこれから。 というのがロジック的な弱さになるので、そこを突かれそうです。 「でも、まだ入ってないんだよね? Mainlineに入ったら考えるよ」と 言われた場合はどうしましょう。 自分はこれを覆せるだけの説得力を確保できていない気がします。 「ベースは入れた実績があって、これからがんがん機能拡張する フェーズにあるのでプリフライトせぇへん?」という戦術もアリですが、 「それって入らない可能性もあるってことだよね?」と返されて終わり そうな予感がします。 # 「なんとかなるよ、絶対大丈夫だよ」とか主張しても、たぶん # 納得してもらえません(←知らないのにわざわざググってネタ拾うなよ > 8.10 で custom binary 作成機能が除外されてしまったのは痛手です。 > https://lists.ubuntu.com/archives/kernel-team/2008-September/003066.html > 現状では、 linux-headers パッケージ等が競合してしまうので気軽に TOMOYO を > インストールできないのです。 ええと、実は/binary-custom.d/があっても、これを使って作ったパッケージを 公式に突っ込むことはできなかったりします。 # バグというか、これ「手元で好き勝手に作れる」だけで、余計な何かを # ビルドしてくれやがって問題を起こすので、PPAとかUniverse/Mainには # 入れられないのです……。 > 最低限 custom binary 作成機能が復活すれば、「標準カーネルは Canonical が > サポート、 TOMOYO カーネルは熊猫がサポート」という方法も可能です。 > > generic と server は TOMOYO 無効で構わないから、カーネルコンフィグを弄るだけで > TOMOYO 有効なカーネルを生成できる状況( TOMOYO パッチ適用済みソース)まで > 持ち込めると、パッケージの競合問題が解決するので、熊猫のサポートがだいぶ楽に > なります。 ふむ。これの場合でも実はKernel Teamのソースメンテナンス上の問題は あるので、何らかの譲歩を引き出さないとダメってことですよね。 ちょっと確認なのですが、目標レベルでは  ・手段は問わず、TOMOYO有効なパッケージを作れればOK で、その手段として  ・カーネルコンフィグを弄るだけでTOMOYO 有効なカーネルを生成できる   状況( TOMOYO パッチ適用済みソース) ですよね? このアプローチがダメでも、「TOMOYOパッチ適用されてないソースでも、 パッケージングが妥当なコストでできる」ならOKですよね? >> 「プロファイリング用を兼ねてTOMOYOどうよ? なんかパッチは日本に >> 住んでる白黒の生き物がちゃんと作ってくれるみたいだし」 >> とか言うと取り込んでくれる……かなぁと思います。 > 「パッチは日本に住んでる白黒の生き物がちゃんと作ってくれるみたいだし」 > ということは、熊猫以外のどなたかからコンタクトしていただけるということですか? ちょっとこの辺は中の人と相談して、どうするのがいいのか聞いてみますですよ。 >> あと、9.04はKernel Team大忙しなので(ちょっと実装する機能が豪快)、 >> 提案するならしばらく待った方がいいと思います。今提案しても「知らん」 >> の一言で終わらされそうです。 > 今コンタクトするとしたら kernel-team ML への投稿ではなく > 別のルート( core-dev や Tech board ?)を使うことになりそうですね。 いや、その辺も忙しいので、どっちにしろ今は厳しいです。今やっても9.04に 入ることはないので意味がないですし。3〜4月になったらMark Shuttleworthが 9.10のリリース目標を提示するはずなので、そのタイミングで ・Server TeamのMLに体験可能な状態でTOMOYOを提案してみる。 ・Server Teamが乗り気になったらKernel TeamにServer用カーネルに  入れたりせえへん?と聞いてみる。 ・ダメなら非Canonical("Universe")扱いで入れてもらえないかREVUに  投げる。 ぐらいが妥当な戦略かと思います。 # ってことは9.04用の何かが必要なのか > 自分 From takedakn @ nttdata.co.jp Mon Feb 16 14:25:39 2009 From: takedakn @ nttdata.co.jp (Kentaro Takeda) Date: Mon, 16 Feb 2009 14:25:39 +0900 Subject: [Tomoyo-dev 943] =?utf-8?b?Q2VudE9TIDUuMiArIFRPTU9ZTyAxLjYuNiBMaXZlQ0TjgpLlhaw=?= =?utf-8?b?6ZaL44GX44G+44GX44Gf?= Message-ID: <4998F8D3.7030601@nttdata.co.jp> 武田@です。 CentOS 5.2ベースにTOMOYO Linux 1.6.6を搭載したLiveCDを公開しました。 本日の最新版にアップデートをかけた上で、容量の都合上 Ekigaとk3b(CD/DVDライティングソフト)を削除しています。 日本語ページ: http://tomoyo.sourceforge.jp/wiki/?TomoyoLive 英語ページ: http://tomoyo.sourceforge.jp/wiki-e/?TomoyoLive (ファイルへの直リンク) http://tomoyo.sourceforge.jp/incoming/CentOS-5.2-i386-TOMOYO-1.6.6-LiveCD.iso ハッシュ値は以下の通りです。 *MD5SUM 943cb02e585edf729bc1116df63307e9 CentOS-5.2-i386-TOMOYO-1.6.6-LiveCD.iso *SHA1SUM e47ad1d635b1bf28b601ed5949ea56bd1182bf04 CentOS-5.2-i386-TOMOYO-1.6.6-LiveCD.iso *SHA256SUM eb002c87948ea7223b2ab32a267f1f928be55c9b785b455258ae07ad786c724c CentOS-5.2-i386-TOMOYO-1.6.6-LiveCD.iso お試しください。 -- 武田健太郎 (Kentaro Takeda) takedakn @ nttdata.co.jp 株式会社NTTデータ 技術開発本部 SIアーキテクチャ開発センタ -------------- next part -------------- $B%F%-%9%H7A<00J30$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B... $B%U%!%$%kL>(B: signature.asc $B7?(B: application/pgp-signature $B%5%$%:(B: 258 $B%P%$%H(B $B @ bL@(B: OpenPGP digital signature URL: http://lists.sourceforge.jp/mailman/archives/tomoyo-dev/attachments/20090216/276b3a1e/attachment.pgp From from-tomoyo-users @ I-love.SAKURA.ne.jp Tue Feb 17 19:55:59 2009 From: from-tomoyo-users @ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Tue, 17 Feb 2009 19:55:59 +0900 Subject: [Tomoyo-dev 944] =?iso-2022-jp?b?VE9NT1lPIExpbnV4IBskQiROMytILz51NjcbKEI=?= Message-ID: <200902171955.IFE95329.NPPNTZGtVSPFPSTtU@I-love.SAKURA.ne.jp> 熊猫です。 1.6.7 に向けての開発状況( revision 2179 )です。 カーネルに関して (1) if 節で execute_handler か否かを指定できるようになります。 某案件で、「プリンタに送られたデータを全てログファイルにも保存しておく」 という要件がありました。 execute_handler を使ってパイプやソケットの通信 内容を tee してやれば良いわけですが、「どのような操作を行うか事前に把握 できない」ブラックリスト的な設定を要求されたため、ドメイン遷移ツリーを 設計することができず、 execute_handler として動作する「通信内容傍受 プログラム」と非 execute_handler として動作する「 cat や grep のような 普通のプログラム」とを keep_domain された同一ドメイン上で動作させる必要が 生じてしまいました。 そこで、 if 節を拡張して「 if task.type=execute_handler 」および 「 if task.type!=execute_handler 」という条件指定をサポートすることにより、 同一ドメインで動作するプログラムであっても、「通信内容傍受プログラム」 だけがログファイルなどへの書き込みができるような状態を実現できるように しました。 (2) 学習時に if task.type=execute_handler が自動的に付与されるようになります。 学習モードでは if 節は付与されません。しかし、 execute_handler か否かを 無視して学習すると、 execute_handler でなくてもアクセス可能なポリシーが 生成されてしまい、 (1) の利点を活用しにくくなります。 そこで、 execute_handler として動作するプログラムによって学習された ポリシーには自動的に if task.type=execute_handler が付与されるように しました。 (3) if 節でファイル種別やパーミッションも指定できるようになります。 「 setuid や setgid されたプログラムの実行を禁止したい」という要望が 出た場合への備えとして、ファイルの種別や DAC のパーミッションを考慮した アクセス制御を行うために「 if path1.type=file 」や「 if path1.mode=0644 」 などの指定をサポートしました。(仕様は末尾に書きます。) (4) アクセスログに割り当てられるメモリの上限をバイト単位でも制限できるように なります。 従来、アクセスログ割り当てられるメモリの上限は MAX_GRANT_LOG および MAX_REJECT_LOG パラメータを使用して「件数」で制限していました。しかし、 「バイト数」でも制限できる方が便利なので、 /proc/ccs/meminfo から上限を 指定できるようにしました。例えば # echo Dynamic: 1048576 > /proc/ccs/meminfo のように指定すると、アクセスログに割り当てられるメモリの上限を1MBに 制限できます。 ツールに関して (1) ccs-editpolicy で編集可能なポリシーの種類が増えます。 従来は「システムポリシー」「例外ポリシー」「ドメインポリシー」の3種類しか 編集できませんでした。しかし、「プロファイル」「マネージャ」「メモリ上限 制限」も編集できるようになります。従来の Tab キーによる切り替え順序は 維持したまま、 w キーでウィンドウを選択できるようになります。 ccs-editpolicy の起動時に p を指定するとプロファイル編集画面を、 m を指定するとマネージャ編集画面を、 q を指定するとメモリ上限編集画面を 初期画面に指定することができます。 (2) ccs-editpolicy で閲覧モードが追加されます。 ccs-editpolicy の起動時に readonly と指定すると、読み込み専用モードで 動作します。また、 refresh=秒数 を指定すると、指定された秒数で自動 再読み込みが行われるようになります。 (3) ccs-init からメモリ上限を設定できるようになります。 新しく /etc/ccs/meminfo.base および /etc/ccs/meminfo.conf が 追加されました。 従来、 /etc/ccs/ccs-post-init で行っていた #! /bin/sh echo Private: 10485760 > /proc/ccs/meminfo echo Shared: 10485760 > /proc/ccs/meminfo という処理を Private: 10485760 Shared: 10485760 Dynamic: 10485760 のように /etc/ccs/meminfo.conf という設定ファイルに記述できます。 (4) ccs-loadpolicy でロード可能なポリシーの種類が増えます。 ccs-loadpolicy q で /proc/ccs/meminfo への書き込みが可能になります。 # echo Dynamic: 10485760 | ccs-loadpolicy -q のように使います。 −−−−−−−−−− 1.6.7 で指定できるようになる if 節の内容について プロセス種別の指定 task.type=execute_handler プロセスは execute_handler として動作している task.type!=execute_handler プロセスは普通のプロセスとして動作している ファイル種別の指定 path1.type=file path1 は通常のファイルである path1.type=directory path1 はディレクトリである path1.type=fifo path1 は FIFO である path1.type=socket path1 はソケットである path1.type=symlink path1 はシンボリックリンクである path1.type=block path1 はブロックデバイスファイルである path1.type=char path1 はキャラクタデバイスファイルである path1.type!=file path1 は通常のファイルではない path1.type!=directory path1 はディレクトリではない path1.type!=fifo path1 は FIFO ではない path1.type!=socket path1 はソケットではない path1.type!=symlink path1 はシンボリックリンクではない path1.type!=block path1 はブロックデバイスファイルではない path1.type!=char path1 はキャラクタデバイスファイルではない path1.parent や path2.parent は常にディレクトリなので、 path1.parent.type や path2.parent.type という指定はサポートしません。 ファイルの保存されているデバイス番号の指定 path1.major=数値1-数値2 path1 のメジャー番号部分が「数値1〜数値2」である path1.minor=数値1-数値2 path1 のマイナー番号部分が「数値1〜数値2」である path1.major!=数値1-数値2 path1 のメジャー番号部分が「数値1〜数値2」ではない path1.minor!=数値1-数値2 path1 のマイナー番号部分が「数値1〜数値2」ではない path1.parent や path2.parent のデバイスは常に path1 と同一なので、 path1.parent や path2.parent という指定はサポートしません。 デバイスファイル属性の指定 path1.dev_major=数値1-数値2 path1 のデバイスメジャー番号部分が「数値1〜数値2」である path1.dev_minor=数値1-数値2 path1 のデバイスマイナー番号部分が「数値1〜数値2」である path1.dev_major!=数値1-数値2 path1 のデバイスメジャー番号部分が「数値1〜数値2」ではない path1.dev_minor!=数値1-数値2 path1 のデバイスマイナー番号部分が「数値1〜数値2」ではない path1.type=block または path1.type=char に対してのみ有効です。 パーミッション指定 path1.perm=数値1-数値2 path1 のパーミッションが「数値1〜数値2」である path1.perm!=数値1-数値2 path1 のパーミッションが「数値1〜数値2」ではない path1.perm=setuid path1 に関して setuid ビットが on である path1.perm!=setuid path1 に関して setuid ビットが off である path1.perm=setgid path1 に関して setgid ビットが on である path1.perm!=setgid path1 に関して setgid ビットが off である path1.perm=sticky path1 に関して sticky ビットが on である path1.perm!=sticky path1 に関して sticky ビットが off である path1.perm=owner_read path1 に関して owner に対する read ビットが on である path1.perm!=owner_read path1 に関して owner に対する read ビットが off である path1.perm=owner_write path1 に関して owner に対する write ビットが on である path1.perm!=owner_write path1 に関して owner に対する write ビットが off である path1.perm=owner_execute path1 に関して owner に対する execute ビットが on である path1.perm!=owner_execute path1 に関して owner に対する execute ビットが off である path1.perm=group_read path1 に関して group に対する read ビットが on である path1.perm!=group_read path1 に関して group に対する read ビットが off である path1.perm=group_write path1 に関して group に対する write ビットが on である path1.perm!=group_write path1 に関して group に対する write ビットが off である path1.perm=group_execute path1 に関して group に対する execute ビットが on である path1.perm!=group_execute path1 に関して group に対する execute ビットが off である path1.perm=others_read path1 に関して others に対する read ビットが on である path1.perm!=others_read path1 に関して others に対する read ビットが off である path1.perm=others_write path1 に関して others に対する write ビットが on である path1.perm!=others_write path1 に関して others に対する write ビットが off である path1.perm=others_execute path1 に関して others に対する execute ビットが on である path1.perm!=others_execute path1 に関して others に対する execute ビットが off である path1 だけでなく path1.parent や path2.parent も指定可能です。 「数値1」と「数値2」が同じ値の場合、「-数値2」の部分は省略可能です。 数値を 8 進数で指定する場合には 0 から始まるようにしてください。 (例: path1.perm=0644 ) 例えば allow_read/write /dev/null if path1.type=char path1.major=1 path1.minor=3 path1.perm=0666 という指定をした場合、「パス名が /dev/null 」「ファイル種別がキャラクタ デバイスファイル」「デバイスメジャー番号が 1 」「デバイスマイナー番号が 3 」 「パーミッションが 0666 」の場合のみ「読み書きモードでのオープンを許可する」 という意味になります。 まだ 1.6.7 としてリリースされていないので仕様の修正が可能です。 動作テストも兼ねて、試してくださると嬉しいです。 From from-tomoyo-users @ i-love.sakura.ne.jp Wed Feb 18 09:33:21 2009 From: from-tomoyo-users @ i-love.sakura.ne.jp (Tetsuo Handa) Date: Wed, 18 Feb 2009 09:33:21 +0900 Subject: [Tomoyo-dev 945] Re: [TOMOYO #15 0/8] TOMOYO Linux In-Reply-To: References: Message-ID: <200902180033.n1I0XLlx066466@www262.sakura.ne.jp>  熊猫です。 linux-next のツリーに入りました。 http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=d30e380874faca98ed90a751aeafc06013acbee9 ・・・ということは、7月頃リリース予定の 2.6.30 に含まれるようになる?