From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Mon Dec 3 21:05:48 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Mon, 3 Dec 2007 21:05:48 +0900 Subject: [Tomoyo-dev 710] =?iso-2022-jp?b?MS41LjIgGyRCJE4laiVqITwlOT1gSHckS0Z+JGokXiQ5GyhC?= Message-ID: <200712032105.GCI78187.ZNSPGNtPPWFEtUP@I-love.SAKURA.ne.jp> 　熊猫です。 　1.5.1 のリリース後に見つかった不具合３箇所を修正したものを 1.5.2 としてリリースすることにしましたので現在準備中です。 　修正した内容は以下の３点です。 (1) AddReservedEntry() の中で down() を呼ばずに up() を呼んでいた。 　　学習モードで呼ばれる関数ではないので実害はありません。 (2) ReadTable() で行末の改行文字が切り落とされてしまうケースが見つかった。 　　if (snprintf(str, size, format, ...) >= size) のようにすべきところを 　　if (snprintf(str, size, format, ...) > size) のようにしてしまっていました。 　　ポリシー策定中の期間のみ影響します。ポリシー策定完了後には影響しません。 (3) GetEXE() の中で down_read() を呼ばずにアクセスしていた。 　　マウント制限などの下記の５項目を有効にしている場合と 　　/proc/ccs/ インタフェースに書き込む場合に影響を受けます。 　　2.x にもある不具合ですが、ほとんどのユーザは下記の５項目を無効にしているので、 　　/proc/ccs/ インタフェースに書き込みを行わない限りこの不具合に遭遇することは無いでしょう。 　　　DENY_CONCEAL_MOUNT 　　　RESTRICT_CHROOT 　　　RESTRICT_MOUNT 　　　RESTRICT_UNMOUNT 　　　RESTRICT_PIVOT_ROOT (3) の不具合はポリシー策定完了後にも影響するため、なるべく早めに修正しておくべきであるとの判断から、 上記 (1) 〜 (3) を修正したものを直ちにリリースすることにしました。 　1.5.1 パッケージのコンパイルが終わったところに 突然のアップデート予告となってしまい申し訳ございません。＞ hito さん、やまねさん From yocto1 ＠ gmail.com Wed Dec 5 23:52:16 2007 From: yocto1 ＠ gmail.com (yocto) Date: Wed, 05 Dec 2007 23:52:16 +0900 Subject: [Tomoyo-dev 711] Re: =?iso-2022-jp?b?MS41LjIgGyRCJE4laiVqITwlOT1gSHckS0Z+JGobKEI=?= =?iso-2022-jp?b?GyRCJF4kORsoQg==?= In-Reply-To: <200712032105.GCI78187.ZNSPGNtPPWFEtUP@I-love.SAKURA.ne.jp> References: <200712032105.GCI78187.ZNSPGNtPPWFEtUP@I-love.SAKURA.ne.jp> Message-ID: <4756bb23.07035a0a.6950.2952@mx.google.com> クスノです。 下記変更履歴ですが、「アクセス権がありません」となります。 http://sourceforge.jp/projects/tomoyo/document/ccs-patch_1.5.2-20071205_-_Changes/ http://sourceforge.jp/projects/tomoyo/document/ccs-tools_1.5.2-20071205_-_Changes/ Tetsuo Handa wrote: > 　熊猫です。 > > 　1.5.1 のリリース後に見つかった不具合３箇所を修正したものを > 1.5.2 としてリリースすることにしましたので現在準備中です。 > > 　修正した内容は以下の３点です。 > > (1) AddReservedEntry() の中で down() を呼ばずに up() を呼んでいた。 > > 　　学習モードで呼ばれる関数ではないので実害はありません。 > > (2) ReadTable() で行末の改行文字が切り落とされてしまうケースが見つかった。 > > 　　if (snprintf(str, size, format, ...) >= size) のようにすべきところを > 　　if (snprintf(str, size, format, ...) > size) のようにしてしまっていました。 > > 　　ポリシー策定中の期間のみ影響します。ポリシー策定完了後には影響しません。 > > (3) GetEXE() の中で down_read() を呼ばずにアクセスしていた。 > > 　　マウント制限などの下記の５項目を有効にしている場合と > 　　/proc/ccs/ インタフェースに書き込む場合に影響を受けます。 > 　　2.x にもある不具合ですが、ほとんどのユーザは下記の５項目を無効にしているので、 > 　　/proc/ccs/ インタフェースに書き込みを行わない限りこの不具合に遭遇することは無いでしょう。 > > 　　　DENY_CONCEAL_MOUNT > 　　　RESTRICT_CHROOT > 　　　RESTRICT_MOUNT > 　　　RESTRICT_UNMOUNT > 　　　RESTRICT_PIVOT_ROOT > > (3) の不具合はポリシー策定完了後にも影響するため、なるべく早めに修正しておくべきであるとの判断から、 > 上記 (1) 〜 (3) を修正したものを直ちにリリースすることにしました。 > > 　1.5.1 パッケージのコンパイルが終わったところに > 突然のアップデート予告となってしまい申し訳ございません。＞ hito さん、やまねさん > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev From haradats ＠ gmail.com Thu Dec 6 00:08:59 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Thu, 6 Dec 2007 00:08:59 +0900 Subject: [Tomoyo-dev 712] Re: =?iso-2022-jp?b?MS41LjIgGyRCJE4laiVqITwlOT1gSHckS0Z+JGobKEI=?= =?iso-2022-jp?b?GyRCJF4kORsoQg==?= In-Reply-To: <4756bb23.07035a0a.6950.2952@mx.google.com> References: <200712032105.GCI78187.ZNSPGNtPPWFEtUP@I-love.SAKURA.ne.jp> <4756bb23.07035a0a.6950.2952@mx.google.com> Message-ID: <9d732d950712050708v7db561bdvbec6e3c34690c67a@mail.gmail.com> 本当ですね。 状況を確認してみて解決しなければSF.jpに報告します。 07/12/05 に yocto さんは書きました: > クスノです。 > > 下記変更履歴ですが、「アクセス権がありません」となります。 > > http://sourceforge.jp/projects/tomoyo/document/ccs-patch_1.5.2-20071205_-_Changes/ > http://sourceforge.jp/projects/tomoyo/document/ccs-tools_1.5.2-20071205_-_Changes/ -- Toshiharu Harada haradats ＠ gmail.com From from-tomoyo-dev ＠ i-love.sakura.ne.jp Thu Dec 6 09:10:43 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Thu, 06 Dec 2007 09:10:43 +0900 Subject: [Tomoyo-dev 713] Re: =?iso-2022-jp?b?MS41LjIgGyRCJE4laiVqITwlOT1gSHckS0Z+JGobKEI=?= =?iso-2022-jp?b?GyRCJF4kORsoQg==?= In-Reply-To: <9d732d950712050708v7db561bdvbec6e3c34690c67a@mail.gmail.com> References: <200712032105.GCI78187.ZNSPGNtPPWFEtUP@I-love.SAKURA.ne.jp> <4756bb23.07035a0a.6950.2952@mx.google.com> <9d732d950712050708v7db561bdvbec6e3c34690c67a@mail.gmail.com> Message-ID: <200712060010.lB60AhGg038112@www262.sakura.ne.jp> 　熊猫です。 > > 下記変更履歴ですが、「アクセス権がありません」となります。 1.5.1 のときもそうだったのですが、デフォルトで Member Access （ログインしないとアクセスできない設定）に なってしまうようです。 Public Access に変更しました。 ありがとうございます。 1.5.0 まではデフォルトで Public Access になっていたのですが、 どうして Member Access になってしまったのか不思議です。 http://sourceforge.jp/tracker/index.php?func=detail&aid=11176&group_id=1&atid=113 From from-tomoyo-dev ＠ i-love.sakura.ne.jp Thu Dec 6 09:23:16 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Thu, 06 Dec 2007 09:23:16 +0900 Subject: [Tomoyo-dev 714] =?iso-2022-jp?b?SVNPIBskQiUkJWEhPCU4JE5DViQtPmw9aiRLJEQkJCRGGyhC?= Message-ID: <200712060023.lB60NGAL041051@www262.sakura.ne.jp> 　熊猫です。 http://sourceforge.jp/forum/forum.php?forum_id=13405 によると そう遠くない未来に、容量制限を開始しそうな感じです。 現在 tomoyo.sourceforge.jp には Ubuntu の ISO イメージが置かれており、 かなりの容量を使っています。 yum/apt 用のレポジトリの話も含めて、 増え続けるファイルの置き場所について そろそろ考えなければいけない時期かもしれませんね。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Thu Dec 6 20:35:08 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Thu, 6 Dec 2007 20:35:08 +0900 Subject: [Tomoyo-dev 715] Re: =?iso-2022-jp?b?MS41LjEgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <20071025000044.27966b07.henrich@debian.or.jp> References: <200710172027.HJE48918.NGFtEPWPPPNZUSt@I-love.SAKURA.ne.jp> <200710230551.l9N5pnF0093814@www262.sakura.ne.jp> <20071024224539.a9743274.henrich@debian.or.jp> <200710242328.GFE65104.ZGSNFPWPPEPtUNt@I-love.SAKURA.ne.jp> <20071025000044.27966b07.henrich@debian.or.jp> Message-ID: <200712062035.HIC81783.tGPUZEPNFNPtPWS@I-love.SAKURA.ne.jp> 　熊猫です。 > > ありがとうございます。 /etc/apt/sources.list にはディレクトリ名の後に > > testing/updates main とか testing main contrib non-free とか書いてありますが、 > > 上記のアドレスの後はどのように書けばよろしいのでしょうか？ > > 　すいません、 > > deb http://www.mithril-linux.org/~henrich/debian/package/ ./ > deb-src http://www.mithril-linux.org/~henrich/debian/package/ ./ > > 　でした。 > 再度質問です。 先月、パッチが入ったという話がありましたが、 http://packages.qa.debian.org/c/ccspatch/news/20071104T155739Z.html コンパイル済みパッケージもあるのでしょうか？ http://tomoyo.sourceforge.jp/ja/1.5.x/install.html に記述したいのですが、 コンパイル済みパッケージは mithril-linux.org にしか存在しないのでしょうか？ From henrich ＠ debian.or.jp Thu Dec 6 21:25:54 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Thu, 6 Dec 2007 21:25:54 +0900 Subject: [Tomoyo-dev 716] Re: =?iso-2022-jp?b?MS41LjEgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <200712062035.HIC81783.tGPUZEPNFNPtPWS@I-love.SAKURA.ne.jp> References: <200710172027.HJE48918.NGFtEPWPPPNZUSt@I-love.SAKURA.ne.jp> <200710230551.l9N5pnF0093814@www262.sakura.ne.jp> <20071024224539.a9743274.henrich@debian.or.jp> <200710242328.GFE65104.ZGSNFPWPPEPtUNt@I-love.SAKURA.ne.jp> <20071025000044.27966b07.henrich@debian.or.jp> <200712062035.HIC81783.tGPUZEPNFNPtPWS@I-love.SAKURA.ne.jp> Message-ID: <20071206212554.d0fb96a1.henrich@debian.or.jp> On Thu, 6 Dec 2007 20:35:08 +0900 Tetsuo Handa wrote: > 再度質問です。 > > 先月、パッチが入ったという話がありましたが、 　ところが、ちょうどその時に build の総元締 ftpmaster サーバの 　RAID5 がクラッシュしてしまって中途半端な状態なようです。 > http://packages.qa.debian.org/c/ccspatch/news/20071104T155739Z.html > コンパイル済みパッケージもあるのでしょうか？ 　現在ありません。 　実現はかなり難しいですね。kernel team を説得するだけの材料を 　出さないといけません。 From henrich ＠ debian.or.jp Thu Dec 6 21:29:06 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Thu, 6 Dec 2007 21:29:06 +0900 Subject: [Tomoyo-dev 717] Re: =?iso-2022-jp?b?MS41LjIgGyRCJE4laiVqITwlOT1gSHckS0Z+JGobKEI=?= =?iso-2022-jp?b?GyRCJF4kORsoQg==?= In-Reply-To: <200712032105.GCI78187.ZNSPGNtPPWFEtUP@I-love.SAKURA.ne.jp> References: <200712032105.GCI78187.ZNSPGNtPPWFEtUP@I-love.SAKURA.ne.jp> Message-ID: <20071206212906.93085b59.henrich@debian.or.jp> On Mon, 3 Dec 2007 21:05:48 +0900 Tetsuo Handa wrote: > 　1.5.1 のリリース後に見つかった不具合３箇所を修正したものを > 1.5.2 としてリリースすることにしましたので現在準備中です。 　1.5.2 を確認しました。ccs-editpolicy_offline の man が無いようです。 　あと man のファイルがそのまま man/man8/hoge.gz で置かれてますが、 　これはトップディレクトリで make した際に生成される方が良いと 　思います。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Thu Dec 6 21:36:00 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Thu, 6 Dec 2007 21:36:00 +0900 Subject: [Tomoyo-dev 718] Re: =?iso-2022-jp?b?MS41LjEgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <20071206212554.d0fb96a1.henrich@debian.or.jp> References: <20071024224539.a9743274.henrich@debian.or.jp> <200710242328.GFE65104.ZGSNFPWPPEPtUNt@I-love.SAKURA.ne.jp> <20071025000044.27966b07.henrich@debian.or.jp> <200712062035.HIC81783.tGPUZEPNFNPtPWS@I-love.SAKURA.ne.jp> <20071206212554.d0fb96a1.henrich@debian.or.jp> Message-ID: <200712062136.DBC09309.PZPPENtGPFUWNtS@I-love.SAKURA.ne.jp> 　熊猫です。 > 　ところが、ちょうどその時に build の総元締 ftpmaster サーバの > 　RAID5 がクラッシュしてしまって中途半端な状態なようです。 おやおや、それは大変ですね。 > 　現在ありません。 > 　実現はかなり難しいですね。kernel team を説得するだけの材料を > 　出さないといけません。 では、とりあえず 1.5.2 のバイナリパッケージはどうしましょう？ やまねさんの方で作成いただけるならお願いしたいですし、 時間的に余裕がないようであれば熊猫の Lenny 環境で作成することもできます。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Thu Dec 6 21:44:29 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Thu, 6 Dec 2007 21:44:29 +0900 Subject: [Tomoyo-dev 719] Re: =?iso-2022-jp?b?MS41LjIgGyRCJE4laiVqITwlOT1gSHckS0Z+JGobKEI=?= =?iso-2022-jp?b?GyRCJF4kORsoQg==?= In-Reply-To: <20071206212906.93085b59.henrich@debian.or.jp> References: <200712032105.GCI78187.ZNSPGNtPPWFEtUP@I-love.SAKURA.ne.jp> <20071206212906.93085b59.henrich@debian.or.jp> Message-ID: <200712062144.FHI05799.NPZPUNPPtGESWFt@I-love.SAKURA.ne.jp> 　熊猫です。 > 　1.5.2 を確認しました。ccs-editpolicy_offline の man が無いようです。 シンボリックリンクを張るのを忘れました。（＾＾； > 　あと man のファイルがそのまま man/man8/hoge.gz で置かれてますが、 > 　これはトップディレクトリで make した際に生成される方が良いと > 　思います。 はい、 help2man がインストールされていればそれが良いと思いますが、 help2man がインストールされているとは限らないので、 cp でインストールできる形にしています。 help2man がインストールされていれば、 ccs-tools-1.5.2-20071205.tar.gz を展開して ccstools/man ディレクトリに移動してから make することで更新することができます。 From henrich ＠ debian.or.jp Thu Dec 6 22:23:47 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Thu, 6 Dec 2007 22:23:47 +0900 Subject: [Tomoyo-dev 720] Re: =?iso-2022-jp?b?MS41LjEgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <200712062136.DBC09309.PZPPENtGPFUWNtS@I-love.SAKURA.ne.jp> References: <20071024224539.a9743274.henrich@debian.or.jp> <200710242328.GFE65104.ZGSNFPWPPEPtUNt@I-love.SAKURA.ne.jp> <20071025000044.27966b07.henrich@debian.or.jp> <200712062035.HIC81783.tGPUZEPNFNPtPWS@I-love.SAKURA.ne.jp> <20071206212554.d0fb96a1.henrich@debian.or.jp> <200712062136.DBC09309.PZPPENtGPFUWNtS@I-love.SAKURA.ne.jp> Message-ID: <20071206222347.b5d1414b.henrich@debian.or.jp> On Thu, 6 Dec 2007 21:36:00 +0900 Tetsuo Handa wrote: > では、とりあえず 1.5.2 のバイナリパッケージはどうしましょう？ > やまねさんの方で作成いただけるならお願いしたいですし、 > 時間的に余裕がないようであれば熊猫の Lenny 環境で作成することもできます。 　現在、審査待ちなのでそれが終われば upload してもらいます。 　http://ftp-master.debian.org/new.html　で Debian にパッケージが入る 　までの新規パッケージ待ち状況が確認できます。 From from-tomoyo-dev ＠ i-love.sakura.ne.jp Fri Dec 7 17:12:23 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Fri, 07 Dec 2007 17:12:23 +0900 Subject: [Tomoyo-dev 721] =?iso-2022-jp?b?MS41LjIgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4kORsoQg==?= In-Reply-To: <200712032105.GCI78187.ZNSPGNtPPWFEtUP@I-love.SAKURA.ne.jp> References: <200712032105.GCI78187.ZNSPGNtPPWFEtUP@I-love.SAKURA.ne.jp> Message-ID: <200712070812.lB78CNxE071900@www262.sakura.ne.jp> 　熊猫です。 　長期的な置き場所を決めるには少し時間が掛かるかもしれないので 現行どおり sf.jp のリリース物件に置くという仮定で 1.5.2 のコンパイルを始めたいと思います。 http://tomoyo.sourceforge.jp/wiki/?HowToMakeKernelPackage CentOS 5.1 用カーネルのコンパイルには --without kabichk が必要になりましたのでご注意ください。 　締め切りはありませんので無理はしないでくださいね。 From henrich ＠ debian.or.jp Fri Dec 7 23:38:58 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Fri, 7 Dec 2007 23:38:58 +0900 Subject: [Tomoyo-dev 722] Re: =?iso-2022-jp?b?MS41LjIgGyRCJE4laiVqITwlOT1gSHckS0Z+JGobKEI=?= =?iso-2022-jp?b?GyRCJF4kORsoQg==?= In-Reply-To: <200712062144.FHI05799.NPZPUNPPtGESWFt@I-love.SAKURA.ne.jp> References: <200712032105.GCI78187.ZNSPGNtPPWFEtUP@I-love.SAKURA.ne.jp> <20071206212906.93085b59.henrich@debian.or.jp> <200712062144.FHI05799.NPZPUNPPtGESWFt@I-love.SAKURA.ne.jp> Message-ID: <20071207233858.56205940.henrich@debian.or.jp> On Thu, 6 Dec 2007 21:44:29 +0900 Tetsuo Handa wrote: > > 　1.5.2 を確認しました。ccs-editpolicy_offline の man が無いようです。 > シンボリックリンクを張るのを忘れました。（＾＾； 　ん、これはどこからどこへの、ですか？ > > 　あと man のファイルがそのまま man/man8/hoge.gz で置かれてますが、 > > 　これはトップディレクトリで make した際に生成される方が良いと > > 　思います。 > はい、 help2man がインストールされていればそれが良いと思いますが、 > help2man がインストールされているとは限らないので、 cp でインストールできる形にしています。 > help2man がインストールされていれば、 ccs-tools-1.5.2-20071205.tar.gz を展開して > ccstools/man ディレクトリに移動してから make することで更新することができます。 　それこそ、ビルド環境に必要なソフトとして明示すればいいだけだと思います。 　大元の source にはビルド時に生成されるファイルは含まないようにする方が 　私は理にかなっていると思います。 　 　gcc が入っていないシステムのために compile ずみのファイルを含むことが 　無いのと同様に。 　もう１点、パッケージをビルドしていて警告が出ました。 dpkg-shlibdeps: warning: debian/tomoyo-ccstools/usr/lib/ccs/misc/falsh shouldn't be linked with libncurses.so.5 (it uses none of its symbols). 　Makefile では falsh: falsh.c /usr/include/curses.h /usr/include/readline/readline.h $(CC) $(CFLAGS) -o falsh falsh.c -lncurses -lreadline 　ですが、false.c では、include curses.h していません。 　 　＃私は C でまともに hello, world すら書けない人なので、この指摘が的外れ 　　であればその旨言ってください。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Fri Dec 7 23:55:06 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Fri, 7 Dec 2007 23:55:06 +0900 Subject: [Tomoyo-dev 723] Re: =?iso-2022-jp?b?MS41LjIgGyRCJE4laiVqITwlOT1gSHckS0Z+JGobKEI=?= =?iso-2022-jp?b?GyRCJF4kORsoQg==?= In-Reply-To: <20071207233858.56205940.henrich@debian.or.jp> References: <200712032105.GCI78187.ZNSPGNtPPWFEtUP@I-love.SAKURA.ne.jp> <20071206212906.93085b59.henrich@debian.or.jp> <200712062144.FHI05799.NPZPUNPPtGESWFt@I-love.SAKURA.ne.jp> <20071207233858.56205940.henrich@debian.or.jp> Message-ID: <200712072355.EDJ65663.PtWSGPNtPEPZFUN@I-love.SAKURA.ne.jp> 　熊猫です。 > > シンボリックリンクを張るのを忘れました。（＾＾； > > 　ん、これはどこからどこへの、ですか？ ccs-editpolicy_offline.gz から ccs-editpolicy.gz へのシンボリックリンクです。 （ところで man ccs-editpolicy_offline ってする人は居るのかな？） > 　もう１点、パッケージをビルドしていて警告が出ました。 > dpkg-shlibdeps: warning: debian/tomoyo-ccstools/usr/lib/ccs/misc/falsh shouldn't be linked with libncurses.so.5 (it uses none of its symbols). > > 　Makefile では > > falsh: falsh.c /usr/include/curses.h /usr/include/readline/readline.h > $(CC) $(CFLAGS) -o falsh falsh.c -lncurses -lreadline > > 　ですが、false.c では、include curses.h していません。 > > 　 > 　＃私は C でまともに hello, world すら書けない人なので、この指摘が的外れ > 　　であればその旨言ってください。 的外れかどうかは判りませんが、 readline ライブラリは内部で ncurses ライブラリを参照しているので、 .c ファイルの中から #include をしていないからと言って ncurses ライブラリとリンクされるべきではないという警告は 無視して構いません。実際、 -lncurses を削るとリンクエラーになるはずです。 #include を falsh.c の中で明示すればこの警告は消えるのかも？ From yocto1 ＠ gmail.com Sat Dec 8 16:40:26 2007 From: yocto1 ＠ gmail.com (yocto) Date: Sat, 08 Dec 2007 16:40:26 +0900 Subject: [Tomoyo-dev 724] Re: =?iso-2022-jp?b?MS41LjIgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <200712070812.lB78CNxE071900@www262.sakura.ne.jp> References: <200712032105.GCI78187.ZNSPGNtPPWFEtUP@I-love.SAKURA.ne.jp> <200712070812.lB78CNxE071900@www262.sakura.ne.jp> Message-ID: <475a4a6b.16538c0a.1dfc.10d8@mx.google.com> クスノです。 下記置きました。 kernel-image-2.4.27-10sarge5-ccs-i586_1.5.2_i386.deb kernel-image-2.6.8-16sarge7-ccs-i586_1.5.2_i386.deb linux-image-2.6.18-13etch4-ccs-i586_1.5.2_i386.deb from-tomoyo-dev ＠ i-love.sakura.ne.jp wrote: > 　熊猫です。 > > 　長期的な置き場所を決めるには少し時間が掛かるかもしれないので > 現行どおり sf.jp のリリース物件に置くという仮定で 1.5.2 のコンパイルを始めたいと思います。 > > http://tomoyo.sourceforge.jp/wiki/?HowToMakeKernelPackage > > CentOS 5.1 用カーネルのコンパイルには --without kabichk が必要になりましたのでご注意ください。 > > 　締め切りはありませんので無理はしないでくださいね。 > > _______________________________________________ > 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 Sat Dec 8 18:29:57 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 8 Dec 2007 18:29:57 +0900 Subject: [Tomoyo-dev 725] Re: =?iso-2022-jp?b?MS41LjIgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <475a4a6b.16538c0a.1dfc.10d8@mx.google.com> References: <200712032105.GCI78187.ZNSPGNtPPWFEtUP@I-love.SAKURA.ne.jp> <200712070812.lB78CNxE071900@www262.sakura.ne.jp> <475a4a6b.16538c0a.1dfc.10d8@mx.google.com> Message-ID: <200712081829.AGH87072.GZPPWPtFPNStENU@I-love.SAKURA.ne.jp> 　熊猫です。 > クスノです。 > > 下記置きました。 毎度（ Wiki の方も）ありがとうございます。 更新しました。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat Dec 8 21:00:20 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 8 Dec 2007 21:00:20 +0900 Subject: [Tomoyo-dev 726] =?iso-2022-jp?b?V2lraSAbJEI5UyRpJDckWCROQlA6diRLJEQkJCRGGyhC?= Message-ID: <200712082100.BGE30705.NZPPEPWFPUSNttG@I-love.SAKURA.ne.jp> 　熊猫です。 日本語版 Wiki の Menubar ページが荒らされ、左側のメニューバーのリンク先が 中国語の不審なページへのリンクへと改ざんされていたので修復しました。 ページ内で IFRAME を使用していることから、 Internet Explorer を狙って 悪意あるソフトウェアをインストールさせるための攻撃サイトだと推測されます。 過去にも英語版 Wiki のページが荒らされ、 VBScript を使って 悪意あるソフトウェアをインストールさせるための攻撃サイトへのリンクが 仕組まれてたことが何度か発生しています。 パスワードによるページの凍結をしていますが、 ページを新規作成されたり今回のように凍結漏れのページが狙われたりしていることから、 誰でも書き込みできる状態で使うのは避けるべきだと思います。 不便になるけど Wiki を使わないようにするか、 ログインしないと編集できないタイプの Wiki に移行すべきと考えます。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sun Dec 9 22:33:43 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 9 Dec 2007 22:33:43 +0900 Subject: [Tomoyo-dev 727] =?iso-2022-jp?b?VWJ1bnR1IDYuMTAgGyRCTVElKyE8JU0laxsoQg==?= In-Reply-To: <200710020902.l9292SSF015549@www262.sakura.ne.jp> References: <9292c1390704100312u5a6b3fa2jddc1432247f357ba@mail.gmail.com> <200710020902.l9292SSF015549@www262.sakura.ne.jp> Message-ID: <200712092233.CJJ56723.PNFUPSNtPGtZPEW@I-love.SAKURA.ne.jp> 　熊猫です。 　Ubuntu 6.10 で /lib/firmware/ を含む TOMOYO Linux 1.5.2 カーネルパッケージの作成に成功したのでメモを残しておきます。 flavour として . を含むものは指定できないようなので tomoyo1.5.2 ではなく ccs となっています。 環境変数 AUTOBUILD を指定しないことと、 config.$flavour と vars.$flavour を作ることというのがコツのようですね。 curl 'http://pgp.nic.ad.jp/pks/lookup?op=get&search=0x17063E6D' | gpg --import cd /usr/src/ apt-get install linux-kernel-devel fakeroot build-essential apt-get build-dep linux-image-2.6.17-12-generic apt-get source linux-image-2.6.17-12-generic cd linux-source-2.6.17-2.6.17.1/ wget http://osdn.dl.sourceforge.jp/tomoyo/27219/ccs-patch-1.5.2-20071205.tar.gz tar -zxf ccs-patch-1.5.2-20071205.tar.gz patch -p1 < patches/ccs-patch-2.6.17.14-ubuntu1.diff cat debian/config/i386/config.generic config.ccs > debian/config/i386/config.generic-ccs cat debian/config/vars.generic > debian/config/i386/vars.generic-ccs chmod +x debian/post-install chmod -R +x debian/bin/ export CONCURRENCY_LEVEL=`grep -c '^processor' /proc/cpuinfo` debian/rules binary-debs flavours=generic-ccs From from-tomoyo-dev ＠ i-love.sakura.ne.jp Mon Dec 10 11:26:34 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Mon, 10 Dec 2007 11:26:34 +0900 Subject: [Tomoyo-dev 728] Re: =?iso-2022-jp?b?V2lraSAbJEI5UyRpJDckWCROQlA6diRLJEQkJCRGGyhC?= In-Reply-To: <200712082100.BGE30705.NZPPEPWFPUSNttG@I-love.SAKURA.ne.jp> References: <200712082100.BGE30705.NZPPEPWFPUSNttG@I-love.SAKURA.ne.jp> Message-ID: <200712100226.lBA2QYmV011470@www262.sakura.ne.jp> 　熊猫です。 > 不便になるけど Wiki を使わないようにするか、 > ログインしないと編集できないタイプの Wiki に移行すべきと考えます。 　PukiWiki 1.4 では Basic 認証による閲覧及び編集の制限が可能であることが判明したので、この機能を使いたいと思います。 http://pukiwiki.sourceforge.jp/?Q%EF%BC%86A%2F%E9%81%8B%E5%96%B6#yad2594f From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Mon Dec 10 21:45:24 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Mon, 10 Dec 2007 21:45:24 +0900 Subject: [Tomoyo-dev 729] =?iso-2022-jp?b?VWJ1bnR1IDcuMDQgGyRCTVElKyE8JU0laxsoQg==?= In-Reply-To: <200712092233.CJJ56723.PNFUPSNtPGtZPEW@I-love.SAKURA.ne.jp> References: <9292c1390704100312u5a6b3fa2jddc1432247f357ba@mail.gmail.com> <200710020902.l9292SSF015549@www262.sakura.ne.jp> <200712092233.CJJ56723.PNFUPSNtPGtZPEW@I-love.SAKURA.ne.jp> Message-ID: <200712102145.JFH52633.UtPGZPtFNPEWPNS@I-love.SAKURA.ne.jp> 　熊猫です。 　Ubuntu 7.04 で /lib/firmware/ を含む TOMOYO Linux 1.5.2 カーネルパッケージの作成に成功したので メモを残しておきます・・・と言っても、 6.10 と同じ手順でした。 ただし、 CONFIG_DEBUG_INFO=y となっているのでディスクの空き領域が十分あることを確認してから コンパイルするように注意してください。 curl 'http://pgp.nic.ad.jp/pks/lookup?op=get&search=0x17063E6D' | gpg --import cd /usr/src/ apt-get install linux-kernel-devel fakeroot build-essential apt-get build-dep linux-image-2.6.20-16-generic apt-get source linux-image-2.6.20-16-generic cd linux-source-2.6.20-2.6.20/ wget http://osdn.dl.sourceforge.jp/tomoyo/27219/ccs-patch-1.5.2-20071205.tar.gz tar -zxf ccs-patch-1.5.2-20071205.tar.gz patch -p1 < patches/ccs-patch-2.6.20.3-ubuntu1.diff cat debian/config/i386/config.generic config.ccs > debian/config/i386/config.generic-ccs cat debian/config/vars.generic > debian/config/i386/vars.generic-ccs chmod +x debian/post-install chmod -R +x debian/bin/ export CONCURRENCY_LEVEL=`grep -c '^processor' /proc/cpuinfo` debian/rules binary-debs flavours=generic-ccs ＃誰でもコンパイルできるように、 deb パッケージを使うディストリビューション用の手順を書いています。 ＃ rpm パッケージを使うディストリビューションでは rpmbuild 以外の操作は無いですから。 From henrich ＠ debian.or.jp Mon Dec 10 23:18:14 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Mon, 10 Dec 2007 23:18:14 +0900 Subject: [Tomoyo-dev 730] Re: =?iso-2022-jp?b?MS41LjEgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <20071206222347.b5d1414b.henrich@debian.or.jp> References: <20071024224539.a9743274.henrich@debian.or.jp> <200710242328.GFE65104.ZGSNFPWPPEPtUNt@I-love.SAKURA.ne.jp> <20071025000044.27966b07.henrich@debian.or.jp> <200712062035.HIC81783.tGPUZEPNFNPtPWS@I-love.SAKURA.ne.jp> <20071206212554.d0fb96a1.henrich@debian.or.jp> <200712062136.DBC09309.PZPPENtGPFUWNtS@I-love.SAKURA.ne.jp> <20071206222347.b5d1414b.henrich@debian.or.jp> Message-ID: <20071210231814.cd839986.henrich@debian.or.jp> On Thu, 6 Dec 2007 22:23:47 +0900 Hideki Yamane wrote: > 　現在、審査待ちなのでそれが終われば upload してもらいます。 > 　http://ftp-master.debian.org/new.html　で Debian にパッケージが入る > 　までの新規パッケージ待ち状況が確認できます。 　Debian Official Repository に入りました。 　http://packages.debian.org/search?keywords=tomoyo&searchon=names&suite=all§ion=all 　新しいパッケージポリシー対応作業などもするので、アップデートは 　もう少し後になります。 From haradats ＠ gmail.com Mon Dec 10 23:32:24 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Mon, 10 Dec 2007 23:32:24 +0900 Subject: [Tomoyo-dev 731] Re: =?iso-2022-jp?b?MS41LjEgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <20071210231814.cd839986.henrich@debian.or.jp> References: <20071024224539.a9743274.henrich@debian.or.jp> <200710242328.GFE65104.ZGSNFPWPPEPtUNt@I-love.SAKURA.ne.jp> <20071025000044.27966b07.henrich@debian.or.jp> <200712062035.HIC81783.tGPUZEPNFNPtPWS@I-love.SAKURA.ne.jp> <20071206212554.d0fb96a1.henrich@debian.or.jp> <200712062136.DBC09309.PZPPENtGPFUWNtS@I-love.SAKURA.ne.jp> <20071206222347.b5d1414b.henrich@debian.or.jp> <20071210231814.cd839986.henrich@debian.or.jp> Message-ID: <9d732d950712100632o2fe76a7ap50e6866e3bf6252c@mail.gmail.com> やまね様、 07/12/10 に Hideki Yamane さんは書きました: > On Thu, 6 Dec 2007 22:23:47 +0900 > 　Debian Official Repository に入りました。 > http://packages.debian.org/search?keywords=tomoyo&searchon=names&suite=all§ion=all > > 新しいパッケージポリシー対応作業などもするので、アップデートは > もう少し後になります。 どうもありがとうございました。前回は行き違い（というか勘違い）があり 失礼しました。 利用できるようになりましたら、各所で紹介しますので よろしくお願い致します（自分用のEtchの端末もスタンバイできてます :-）。 -- Toshiharu Harada haradats ＠ gmail.com From yocto1 ＠ gmail.com Mon Dec 10 23:35:43 2007 From: yocto1 ＠ gmail.com (yocto) Date: Mon, 10 Dec 2007 23:35:43 +0900 Subject: [Tomoyo-dev 732] Re: =?iso-2022-jp?b?MS41LjEgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <20071210231814.cd839986.henrich@debian.or.jp> References: <200712062136.DBC09309.PZPPENtGPFUWNtS@I-love.SAKURA.ne.jp> <20071206222347.b5d1414b.henrich@debian.or.jp> <20071210231814.cd839986.henrich@debian.or.jp> Message-ID: <475d4ec1.4b27360a.5a09.443b@mx.google.com> クスノです。 すばらしい!(^^)! Hideki Yamane wrote: > On Thu, 6 Dec 2007 22:23:47 +0900 > Hideki Yamane wrote: > > 　現在、審査待ちなのでそれが終われば upload してもらいます。 > > 　http://ftp-master.debian.org/new.html　で Debian にパッケージが入る > > 　までの新規パッケージ待ち状況が確認できます。 > > 　Debian Official Repository に入りました。 > 　http://packages.debian.org/search?keywords=tomoyo&searchon=names&suite=all§ion=all > > 　新しいパッケージポリシー対応作業などもするので、アップデートは > 　もう少し後になります。 > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev From haradats ＠ gmail.com Tue Dec 11 13:43:45 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Tue, 11 Dec 2007 13:43:45 +0900 Subject: [Tomoyo-dev 733] Re: =?iso-2022-jp?b?MS41LjEgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <20071210231814.cd839986.henrich@debian.or.jp> References: <20071024224539.a9743274.henrich@debian.or.jp> <200710242328.GFE65104.ZGSNFPWPPEPtUNt@I-love.SAKURA.ne.jp> <20071025000044.27966b07.henrich@debian.or.jp> <200712062035.HIC81783.tGPUZEPNFNPtPWS@I-love.SAKURA.ne.jp> <20071206212554.d0fb96a1.henrich@debian.or.jp> <200712062136.DBC09309.PZPPENtGPFUWNtS@I-love.SAKURA.ne.jp> <20071206222347.b5d1414b.henrich@debian.or.jp> <20071210231814.cd839986.henrich@debian.or.jp> Message-ID: <9d732d950712102043j1acfbf35kaff3014c96b86f6c@mail.gmail.com> 原田です。 07/12/10 に Hideki Yamane さんは書きました: > On Thu, 6 Dec 2007 22:23:47 +0900 > Hideki Yamane wrote: > > 現在、審査待ちなのでそれが終われば upload してもらいます。 > > http://ftp-master.debian.org/new.html　で Debian にパッケージが入る > > までの新規パッケージ待ち状況が確認できます。 > > 　Debian Official Repository に入りました。 > http://packages.debian.org/search?keywords=tomoyo&searchon=names&suite=all§ion=all > > 新しいパッケージポリシー対応作業などもするので、アップデートは > もう少し後になります。 試してみました。 ・Etchを最小構成でVMwareに導入（デスクトップ等を指定して 　実行したところ途中で失敗しました） ・/etc/apt/sources.listで、EtchをUnstableに置換 ・/etc/apt/soruces.listの"security"をコメントアウト ・sudo apt-get update ・sudo apt-get dist-upgrade この状態で、linux-umage-2.6-686のみ"kept back"されてしまうため 2.6.22カーネルは入りません。 ・apt-cache search tomoyoで以下をパッケージを確認。 　　kernel-patch-tomoyo 　　tomoyo-ccstools ・sudo apt-get install kernel-patch-tomoyo 　　/usr/src/kernel-patches/all/{apply,unpatch}にtomoyoが作成されます。 　　/usr/srcにlinux-source-2.6.23.tar.bz2が置かれます。 ・sudo apt-get install tomoyo-ccstools 　　/etc/ccs配下に 　　　exception_policy.conf 　　　manager.conf 　　　profile.conf 　が生成されました。 カーネルのビルドはまだ行っていませんが、とりあえず経過報告です。 -- Toshiharu Harada haradats ＠ gmail.com From from-tomoyo-dev ＠ i-love.sakura.ne.jp Tue Dec 11 13:52:41 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Tue, 11 Dec 2007 13:52:41 +0900 Subject: [Tomoyo-dev 734] Re: =?iso-2022-jp?b?MS41LjEgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <20071210231814.cd839986.henrich@debian.or.jp> References: <20071024224539.a9743274.henrich@debian.or.jp> <200710242328.GFE65104.ZGSNFPWPPEPtUNt@I-love.SAKURA.ne.jp> <20071025000044.27966b07.henrich@debian.or.jp> <200712062035.HIC81783.tGPUZEPNFNPtPWS@I-love.SAKURA.ne.jp> <20071206212554.d0fb96a1.henrich@debian.or.jp> <200712062136.DBC09309.PZPPENtGPFUWNtS@I-love.SAKURA.ne.jp> <20071206222347.b5d1414b.henrich@debian.or.jp> <20071210231814.cd839986.henrich@debian.or.jp> Message-ID: <200712110452.lBB4qfNc032353@www262.sakura.ne.jp> 　熊猫です。 Hideki Yamane wrote: > 　Debian Official Repository に入りました。 > 　http://packages.debian.org/search?keywords=tomoyo&searchon=names&suite=all§ion=all > > 　新しいパッケージポリシー対応作業などもするので、アップデートは > 　もう少し後になります。 　ありがとうございます。 http://debian.fam.cx/index.php?AptGet#content_1_70 経由 http://bjorn.haxx.se/debian/testing.pl?package=kernel-patch-tomoyo をしてみたら # ccspatch has no old version in testing (trying to add, not update) # ccspatch is only 1 days old. It must be 10 days old to go in. となりました。 クリスマスまで待てば testing から取り出せるようになるということですね。 　現在 Lenny のカーネルは 2.6.22-2 のようですが http://bjorn.haxx.se/debian/testing.pl?package=linux-source-2.6.23 によると もうじき apt-get dist-upgrade すると 2.6.23-1 がインストールされるようになるのでしょうか？ From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Wed Dec 12 21:16:27 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Wed, 12 Dec 2007 21:16:27 +0900 Subject: [Tomoyo-dev 735] =?iso-2022-jp?b?VWJ1bnR1IDcuMTAgGyRCTVElKyE8JU0laxsoQg==?= In-Reply-To: <200712102145.JFH52633.UtPGZPtFNPEWPNS@I-love.SAKURA.ne.jp> References: <9292c1390704100312u5a6b3fa2jddc1432247f357ba@mail.gmail.com> <200710020902.l9292SSF015549@www262.sakura.ne.jp> <200712092233.CJJ56723.PNFUPSNtPGtZPEW@I-love.SAKURA.ne.jp> <200712102145.JFH52633.UtPGZPtFNPEWPNS@I-love.SAKURA.ne.jp> Message-ID: <200712122116.ACD64069.tZGtNWPEPPFNPUS@I-love.SAKURA.ne.jp> 　熊猫です。 　Ubuntu 7.10 での /lib/firmware/ を含む TOMOYO Linux 1.5.2 カーネルパッケージの作成手順のメモです。 curl 'http://pgp.nic.ad.jp/pks/lookup?op=get&search=0x191FCD8A' | gpg --import curl 'http://pgp.nic.ad.jp/pks/lookup?op=get&search=0x60E80B5B' | gpg --import cd /usr/src/ apt-get install linux-kernel-devel fakeroot build-essential apt-get build-dep linux-image-2.6.22-14-generic apt-get source linux-image-2.6.22-14-generic apt-get install linux-headers-2.6.22-14 apt-get build-dep linux-ubuntu-modules-2.6.22-14-generic apt-get source linux-ubuntu-modules-2.6.22-14-generic cd linux-source-2.6.22-2.6.22 wget http://osdn.dl.sourceforge.jp/tomoyo/27219/ccs-patch-1.5.2-20071205.tar.gz tar -zxf ccs-patch-1.5.2-20071205.tar.gz mkdir -p debian/binary-custom.d/ccs/patchset awk ' BEGIN { flag = 0; } { if ($1 == "diff" && index($0, "Makefile") == 0) flag = 1; if (flag) print $0; } ' patches/ccs-patch-2.6.22.9-ubuntu1.diff > debian/binary-custom.d/ccs/patchset/ubuntu-7.10.patch cd debian/binary-custom.d/ccs/ cat ../../config/i386/config ../../config/i386/config.generic ../../../config.ccs > config.i386 sed -i -e 's:CONFIG_DEBUG_INFO=.*:# CONFIG_DEBUG_INFO is not set:' -- config.i386 touch rules cd ../../../ awk ' BEGIN { flag = 0; print ""; } { if ($1 == "Package:" ) { if (index($0, "-generic") > 0) flag = 1; else flag = 0; }; if (flag) print $0; } ' debian/control.stub | sed -e 's:-generic:-ccs:' > debian/control.stub.ccs cat debian/control.stub.ccs >> debian/control.stub debian/rules debian/control export CONCURRENCY_LEVEL=`grep -c '^processor' /proc/cpuinfo` debian/rules custom-binary-ccs cd .. dpkg -i linux-headers-2.6.22-14-ccs_2.6.22-14.46_i386.deb cd linux-ubuntu-modules-2.6.22-2.6.22 awk ' BEGIN { flag = 0; print ""; } { if ($1 == "Package:" ) { if (index($0, "-generic") > 0) flag = 1; else flag = 0; }; if (flag) print $0; } ' debian/control.stub | sed -e 's:-generic:-ccs:' > debian/control.stub.ccs cat debian/control.stub.ccs >> debian/control.stub debian/rules debian/control # sed -i -e 's:virtual$:virtual ccs:' debian/rules.d/i386.mk sed -i -e 's:flavours.*:flavours = ccs:' debian/rules.d/i386.mk debian/rules binary-indep binary-arch cd .. 最後の debian/rules binary-indep binary-arch の途中でエラーが発生しますが、 以下の３ファイルは作成されているはずなので足りると思います。 linux-image-2.6.22-14-ccs_2.6.22-14.46_i386.deb linux-headers-2.6.22-14-ccs_2.6.22-14.46_i386.deb linux-ubuntu-modules-2.6.22-14-ccs_2.6.22-14.37_i386.deb Ubuntu 7.10 では /lib/firmware/ の内容は linux-ubuntu-modules に含まれていますので、 linux-image と linux-ubuntu-modules の両方をインストールしてください。 なお、 Ubuntu 7.10 用カーネルに関しては hito さんが作成したバイナリパッケージもあり、 apt からインストールできます。 http://lists.sourceforge.jp/mailman/archives/tomoyo-dev/2007-November/000687.html From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Fri Dec 14 22:00:49 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Fri, 14 Dec 2007 22:00:49 +0900 Subject: [Tomoyo-dev 736] TOMOYO Linux's security goal Message-ID: <200712142200.CFC30217.WtNPPPPNFUSGtEZ@I-love.SAKURA.ne.jp> 　熊猫です。 　近いうちに LSM-ML に TOMOYO Linux's security goal という内容を 投稿したいと考えています。 （ http://d.hatena.ne.jp/himainu/20071029#1193664088 ） 　現時点の内容を http://I-love.SAKURA.ne.jp/tomoyo/sg2.txt に置いてあります。 　ちょっと難しい内容かもしれませんがコメントがありましたらどうぞ。 （ SELinux についての内容も含むので selinux-users に投げるのもありかなぁ？） From haradats ＠ gmail.com Sun Dec 16 13:03:31 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Sun, 16 Dec 2007 13:03:31 +0900 Subject: [Tomoyo-dev 737] Re: TOMOYO Linux's security goal In-Reply-To: <200712142200.CFC30217.WtNPPPPNFUSGtEZ@I-love.SAKURA.ne.jp> References: <200712142200.CFC30217.WtNPPPPNFUSGtEZ@I-love.SAKURA.ne.jp> Message-ID: <9d732d950712152003k71ed4eebn5a21c8cffcdf533b@mail.gmail.com> Linux Weather Forecastのエントリー http://www.linux-foundation.org/en/Linux_Weather_Forecast/security にあるTOMOYO Linux（とAppArmor）の記述がその後全然更新されて いないのを残念に思っています。 更新をしている4つのセキュアLinuxプロジェクトの比較表 http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison を紹介した上で、TOMOYO Linuxについて、書かれている 下記項目2点についての見解を含めて、議論をしましょうか。 > Forecast: TOMOYO Linux has only recently surfaced on the wider > mailing lists; its reception has not been entirely friendly. This project's > developers have some work to do if they are (1) to get past the same > obstacles which have slowed AppArmor, and (2) show that their project is > sufficiently different from AppArmor to merit inclusion as yet another > security framework. 07/12/14 に Tetsuo Handa さんは書きました: > 　熊猫です。 > > 近いうちに LSM-ML に TOMOYO Linux's security goal という内容を > 投稿したいと考えています。 > （ http://d.hatena.ne.jp/himainu/20071029#1193664088 ） > > 現時点の内容を > http://I-love.SAKURA.ne.jp/tomoyo/sg2.txt に置いてあります。 > > ちょっと難しい内容かもしれませんがコメントがありましたらどうぞ。 > （ SELinux についての内容も含むので selinux-users に投げるのもありかなぁ？） -- Toshiharu Harada haradats ＠ gmail.com From ynakam ＠ hitachisoft.jp Mon Dec 17 08:24:03 2007 From: ynakam ＠ hitachisoft.jp (Yuichi Nakamura) Date: Mon, 17 Dec 2007 08:24:03 +0900 Subject: [Tomoyo-dev 738] Re: TOMOYO Linux's security goal In-Reply-To: <200712142200.CFC30217.WtNPPPPNFUSGtEZ@I-love.SAKURA.ne.jp> References: <200712142200.CFC30217.WtNPPPPNFUSGtEZ@I-love.SAKURA.ne.jp> Message-ID: <20071217081718.DA71.YNAKAM@hitachisoft.jp> 熊猫さん お疲れ様です。 中村です。 > （ http://d.hatena.ne.jp/himainu/20071029#1193664088 ） リンクありがとうございます。 > 　現時点の内容を > http://I-love.SAKURA.ne.jp/tomoyo/sg2.txt に置いてあります。 なぜか、某所のフィルタリングにはじかれてアクセスできませんでした。 可能ならば、 sourceforgeのページなどにアップして頂けると助かります。 もしくは、このＭＬに送信とか。 -- Yuichi Nakamura Hitachi Software Engineering Co., Ltd. Japan SELinux Users Group(JSELUG): http://www.selinux.gr.jp/ SELinux Policy Editor: http://seedit.sourceforge.net/ From from-tomoyo-dev ＠ i-love.sakura.ne.jp Mon Dec 17 09:13:42 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Mon, 17 Dec 2007 09:13:42 +0900 Subject: [Tomoyo-dev 739] Re: TOMOYO Linux\'s security goal In-Reply-To: <20071217081718.DA71.YNAKAM@hitachisoft.jp> References: <200712142200.CFC30217.WtNPPPPNFUSGtEZ@I-love.SAKURA.ne.jp> <20071217081718.DA71.YNAKAM@hitachisoft.jp> Message-ID: <200712170013.lBH0DgVu094600@www262.sakura.ne.jp> 　熊猫です。 > 可能ならば、 > sourceforgeのページなどにアップして頂けると助かります。 > もしくは、このＭＬに送信とか。 では、ここに貼り付けます。 <<< Footnotes >>> の前２節分がちょっと違うなぁと感じています。 抽象化しているかどうかというよりも、 non-analyzable なのは実体ではなく手段で制御しているから、 すると、 non-modularizable になるのは手段ではなく実体で制御しているから なのかなぁと。 non-analyzable の話は Security-anti-pattern で出てきた話です。 non-modularizable とは、ある実体に対するラベルの変更の影響範囲が ポリシー全体に及んでしまうため、部分的な更新ができないという話です。 −−−−−−−−−− TOMOYO Linux's Security Goal (draft) Tetsuo Handa <<< About TOMOYO Linux >>> TOMOYO Linux is a DIY tool for understanding and protecting your system. You can write policy from scratch. You can do troubleshooting by yourself. TOMOYO Linux will record the system's activities and generate policy that always perfectly fits for the system's activities. <<< About TOMOYO Linux's security goal >>> The TOMOYO Linux's security goals are that: * Make the all subject's all access requests that will occur at least once during the lifetime of the kernel known in advance. * Let the administrator understand what access requests will each subject raise in his/her system and write policy which only allows expected and desirable access requests for his/her needs. To do so, TOMOYO Linux attempts to make the system where everything is prearranged in an easy-to-understand way. TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications that the system hosts. The threat is that an attacker can cause a vulnerable application to do something unexpected and undesirable. TOMOYO Linux addresses this threat by recording all applications' behaviors in the test environment and forcing all applications behave within recorded behaviors in the production environment. TOMOYO Linux has a concept of "process invocation history" (in short, PIH). The PIH is a developmental lineage of a process. When a process executes a program, the process creates a copy with fork() and replace the copy with execve(). TOMOYO Linux appends the pathname of the executed program to the PIH of the replaced process, and associates process's PIH (stored in task_struct) with a domain. As a result, the context switching (a.k.a. domain transition) is unidirectional. This rule allows administrator distinguish and manage fine-grained context. Domain transition forms tree structure like a directory tree of filesystems. Each domain has different set of permissions that are essential for that domain. <<< About exceptions in TOMOYO Linux >>> TOMOYO Linux switches the context of a process whenever a process executes a program, but there are two exceptions. Administrator may relocate domain of a process if PIH is not meaningful for that process (e.g. daemon programs). This exception allows administrator restart daemon programs. Administrator may suppress domain transition if domain transition is not meaningful for that process (e.g. programs called within /etc/init.d/ scripts). This exception reduces memory usage for policy. TOMOYO Linux can apply access control over all userspace applications, but administrator can also apply access control over only specific userspace applications if he/she wishes so. TOMOYO Linux supports "delayed enforcing mode" that allows administrator interactively judge whether an request which is not defined in the policy should be permitted or rejected. This mode helps administrator adjust the policy after software updates. <<< Problems with userland applications >>> SELinux FAQ says that | The security of an unmodified Linux system depends on the correctness of the | kernel, all the privileged applications, and each of their configurations. | A problem in any one of these areas may allow the compromise of the entire | system. In contrast, the security of a modified system based on the Security- | enhanced Linux kernel depends primarily on the correctness of the kernel and | its security policy configuration. But it is not always true. An application who is permitted to access block device file can leak arbitrary information (*1). An application who is permitted to do DNS query can leak arbitrary information (*2). An application who is permitted to create a hard link of an object can have a part in revoking appropriate label from the object (*3). An application who has OS command injection vulnerability can yield unexpected output (*4). An application can pass arbitrary amount of information to executed program via parameters to execve() (*5). Changing policy without rebooting the system can leak information (*6). After all, the security of a modified system still depends on primarily correctness of applications and users' operations. So, I don't spend all time and all money for OS level security. TOMOYO Linux doesn't give any assurance about information flow because I don't want responsible official to blindly accept the statement "We can assure that there is no possibility of leaking information if you use our implementation and policy configuration certified by formal analysis." so that responsible official shall not complain "I believed that use of your implementation and policy can prevent leaking information. Why my confidential report flowed out?" when an incident occured. It is very very difficult for non-security people to properly understand the coverage and degree of assurance. <<< TOMOYO Linux's approach >>> I consider OS level security as "one of securities". No matter how strongly access control is enforced in kernel space, it can't keep all information under control. TOMOYO Linux is not intended to provide assurance for the contents of an object. TOMOYO Linux is intended to provide assurance for available means. Requests for file access are described using means to access a file (i.e. canonicalized pathname). Requests for network access are described using means to access a socket (i.e. operation / protocol / IP address / port number). TOMOYO Linux didn't introduce abstraction layer to files since it makes difficult to selectively add/remove permissions. Let's have an assumption that one wants to allow executing only /usr/bin/md5sum . Introducing a rule "/bin/* and /usr/bin/* have bin_t" and forcing users to describe policy using this rule makes it difficult to allow executing only /usr/bin/md5sum . If you divide the rule into two rules "/usr/bin/md5sum has md5sum_t" and "/bin/* and /usr/bin/* except /usr/bin/md5sum have bin_t" so that you can allow executing only /usr/bin/md5sum , you have to arrange an accommodation among the whole policy because other application might need to execute /usr/bin/md5sum too. Let's have an assumption that one wants to allow opening only /etc/fstab for reading. Introducing a rule "/etc/* have etc_t" and forcing users to describe policy using this rule makes it difficult to allow opening only /etc/fstab for reading. You have to arrange an accommodation among the whole policy if you want to change rules to remove redundant permissions so that you can allow opening only /etc/fstab for reading. Changing the rules also affects to the PIH of TOMOYO Linux if PIH is described using the rules. You will have to discard policy generated by TOMOYO Linux if you change the rules. So, TOMOYO Linux doesn't use such rules. Use of pathnames makes the policy non-analyzable, but use of abstraction layer makes the policy non-modularizable. TOMOYO Linux chose the former approach so that users can allow executing only /usr/bin/md5sum without the risk of also executing /bin/cat in case of OS command injection vulnerability exists. Label is a kind of abstraction layer except that labeling to inode is a daunting task because multiple pathnames may corresponds to one inode. <<< Footnotes >>> (*1) For example, /usr/sbin/smartd opens disk device (e.g. /dev/hda) for reading and sends reports using /bin/mail . Thus, if /usr/sbin/smartd were a Trojan horse, it is possible to leak all information stored in that disk device to third parties. Similarly, /bin/mount opens disk device (e.g. /dev/hda1) and updates /etc/mtab . Thus, if /bin/mount were a Trojan horse, it is possible to write the first line of /etc/shadow (i.e. root's password) to /etc/mtab . (*2) Let's have an assumption that users need to use proxy authentication to access to internet via http protocol. A user will run $ export http_proxy="http://:@:" before running $ curl http://www.kernel.org/ If is "USER" and is "a ＠ PASS@WORD", he/she will run $ export http_proxy="http://USER:a ＠ PASS@WORD@:" With this configuration, running $ curl http://www.kernel.org/ will leak part of the password information (i.e. PASS ＠ WORD@ ) to DNS servers because the application interprets the first @ as the delimiter for part. RFC1738 forbids to use @ character for and while authentication system accepts @ character for . The application should have either aborted if multiple @ characters appeared in http_proxy environment variable or interpreted the last @ as the delimiter for part. This leakage is unintentional because this is an application's design error or user's operational mistakes. But, of course, there are intentional leakage too. A malicious user who wants to leak secret information to competitor can run $ nslookup . DNS server can't know is confidential data and will forward query to competitor's DNS server. (*3) Let's have an assumption that /home partition is not separated from / partition and the policy forbids opening shadow_t files (i.e. /etc/shadow) but the policy doesn't forbid creating hard link of shadow_t files. A non-root user can create hard link of shadow_t files and wait for root user to create /.autorelabel and reboot the system. (Login as user "demo".) [demo ＠ tomoyo ~]$ ln /etc/shadow [demo ＠ tomoyo ~]$ ls -Z /etc/shadow shadow -r-------- root root system_u:object_r:shadow_t:s0 /etc/shadow -r-------- root root system_u:object_r:shadow_t:s0 shadow [demo ＠ tomoyo ~]$ passwd Changing password for user demo. Changing password for demo (current) UNIX password: New UNIX password: Retype new UNIX password: passwd: all authentication tokens updated successfully. [demo ＠ tomoyo ~]$ su - Password: [root ＠ tomoyo ~]# touch /.autorelabel [root ＠ tomoyo ~]# reboot (Wait for completion of reboot, then login as user "demo".) [demo ＠ tomoyo ~]$ ls -Z /etc/shadow shadow -r-------- root root system_u:object_r:shadow_t:s0 /etc/shadow -r-------- root root system_u:object_r:default_t:s0 shadow The /home/demo/shadow lost shadow_t label. The trigger of changing label are creation of /.autorelabel and rebooting the system, but creation of hard link of /etc/shadow and execution of /usr/bin/passwd (to split hard linked object) are complicity in a crime. (*4) Let's have an assumption that the following CGI (say, test.sh) is executed and permissions to execute /usr/bin/md5sum (which is bin_t) from this CGI is given. #! /bin/sh read echo "Content-type: text/plain" echo "" eval md5sum $REPLY You can run $ echo "/etc/fstab" | ./test.sh Content-type: text/plain b6b8d9a26bdea67cdbda41788e402621 /etc/fstab But you can also run $ echo "/etc/fstab; cat /etc/fstab" | ./test.sh Content-type: text/plain b6b8d9a26bdea67cdbda41788e402621 /etc/fstab LABEL=/ / ext3 noatime,nodiratime 1 1 LABEL=/boot /boot ext3 noatime,nodiratime 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 Of course, the author of this CGI intended to print only MD5 of a file and never intended to print the whole contents of a file. But we couldn't follow the author's will because /bin/cat and /usr/bin/md5sum had same label and both programs read from somewhere and write to somewhere. If the file contains password information, can you accept this accident? We can't avoid this accident unless we give different labels to /bin/cat and /usr/bin/md5sum . (*5) Some implementation checks whether file descriptors are permitted to be inherited to execve()ed program. But they don't check argv[] and envp[] passed to execve() requests. If a file descriptor refers to a regular file opened for reading, a malicious process can pass the (almost all) contents of the file through argv[] or envp[] because kernel 2.6.23 with MMU can receive arrays of strings up to 128kB each. But the kernel can't know the meaning of these strings. This makes meaningless to forbid inheriting (for example) /etc/fstab's decriptor using policy because malicious process can pass the contents of /etc/fstab through argv[] or envp[]. (*6) Let's have an assumption that you have two policies (P1) "allow app1 to read from /etc/shadow, but don't allow app1 to write to /tmp/shadow" (P2) "allow app1 to write to /tmp/shadow, but don't allow app1 to read from /etc/shadow" and you want to assure "The contents of /etc/shadow will never be flowed out to /tmp/shadow". The app1's source is something like int main(int argc, char *argv[]) { char buf[16384]; FILE *fp = fopen("/etc/shadow", "r"); int len = fread(buf, 1, sizeof(buf), fp); fclose(fp); sleep(10); fp = fopen("/tmp/shadow", "w"); fwrite(buf, 1, len, fp); fclose(fp); return 0; } Obviously, P1 and P2 are exclusive and app1 won't be able to copy /etc/shadow to /tmp/shadow . But if the following sequence happens Load P1. -> Start app1 -> Switch from P1 to P2 while app1 is sleeping at sleep(10) -> Wait for app1 to terminate app1 is able to copy /etc/shadow to /tmp/shadow through buf[]. To avoid such case, killing app1 (or killing all processes through reboot) is needed when we change policy but we still wants to assure "The contents of /etc/shadow will never be flowed out to /tmp/shadow". It is impossible to assign label to information outside the kernel. TOMOYO Linux doesn't check permissions for files after files are opened because it is too late to revert already read/written data when policy has changed after files are opened. Instead, TOMOYO Linux attempts to keep processes under control as hard as possible until files are opened. From ynakam ＠ hitachisoft.jp Mon Dec 17 14:19:24 2007 From: ynakam ＠ hitachisoft.jp (Yuichi Nakamura) Date: Mon, 17 Dec 2007 14:19:24 +0900 Subject: [Tomoyo-dev 740] Re: TOMOYO Linux\'s security goal In-Reply-To: <200712170013.lBH0DgVu094600@www262.sakura.ne.jp> References: <20071217081718.DA71.YNAKAM@hitachisoft.jp> <200712170013.lBH0DgVu094600@www262.sakura.ne.jp> Message-ID: <20071217140007.DA99.YNAKAM@hitachisoft.jp> 中村です。 ざっと見ました。SELinuxに完全に喧嘩売ってますねｗ 細かいところだと、 > that always perfectly fits for the system's activities. "always perfectly" という表現は、技術文書としては強すぎる表現な気がしますが、 どうなのでしょう？ > The TOMOYO Linux's security goals are that: > > * Make the all subject's all access requests that will occur at least once > during the lifetime of the kernel known in advance. > > * Let the administrator understand what access requests will each subject > raise in his/her system and write policy which only allows expected and > desirable access requests for his/her needs. これらは、「Security goal」なのでしょうか？ Security goalを実現するための、手段なような気がします。 下のほうにある >TOMOYO Linux is intended to protect the whole system from attackers exploiting >vulnerabilities in applications that the system hosts. >The threat is that an attacker can cause a vulnerable application to do >something unexpected and undesirable. がSecurity goal?? あ、あと > [demo ＠ tomoyo ~]$ ln /etc/shadow > [demo ＠ tomoyo ~]$ ls -Z /etc/shadow shadow > -r-------- root root system_u:object_r:shadow_t:s0 /etc/shadow > -r-------- root root system_u:object_r:shadow_t:s0 shadow > [demo ＠ tomoyo ~]$ passwd > Changing password for user demo. > Changing password for demo > (current) UNIX password: > New UNIX password: > Retype new UNIX password: > passwd: all authentication tokens updated successfully. > [demo ＠ tomoyo ~]$ su - > Password: > [root ＠ tomoyo ~]# touch /.autorelabel > [root ＠ tomoyo ~]# reboot > > (Wait for completion of reboot, then login as user "demo".) > > [demo ＠ tomoyo ~]$ ls -Z /etc/shadow shadow > -r-------- root root system_u:object_r:shadow_t:s0 /etc/shadow > -r-------- root root system_u:object_r:default_t:s0 shadow ですが、passwdコマンド無しでも、 再現しましたよ。 targetedポリシで対処するならば、 unconfined_tから、link permissionを 全部切ってしまうのでしょうかねぇ。 ちなみに、SELinux Policy Editorでは、 リラベル時に、簡易なハードリンク検出やってます。 ハードリンクの可能性があるときは、リラベルを飛ばします。 Dan Walshあたりは、 autorelabelやrestoreconは、 「自分のやろうとしていることを理解してやること」 と言っていた気がしますが、現実的ではないですね。 暗号を使うときに、 「暗号のアルゴリズムを理解して使え」 と言っているようなものかも。 -- Yuichi Nakamura Hitachi Software Engineering Co., Ltd. Japan SELinux Users Group(JSELUG): http://www.selinux.gr.jp/ SELinux Policy Editor: http://seedit.sourceforge.net/ From from-tomoyo-dev ＠ i-love.sakura.ne.jp Mon Dec 17 14:49:43 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Mon, 17 Dec 2007 14:49:43 +0900 Subject: [Tomoyo-dev 741] Re: TOMOYO Linux\'s security goal In-Reply-To: <20071217140007.DA99.YNAKAM@hitachisoft.jp> References: <20071217081718.DA71.YNAKAM@hitachisoft.jp> <200712170013.lBH0DgVu094600@www262.sakura.ne.jp> <20071217140007.DA99.YNAKAM@hitachisoft.jp> Message-ID: <200712170549.lBH5nhqr059341@www262.sakura.ne.jp> 　熊猫です。 ＞ざっと見ました。SELinuxに完全に喧嘩売ってますねｗ そう？（＾ｘ＾； SELinux でも苦手な部分があることを示しておかないと、 「 SELinux でやればいいじゃん」という話に持っていかれそうなので。 ＞"always perfectly" ＞という表現は、技術文書としては強すぎる表現な気がしますが、 ＞どうなのでしょう？ そうですね。では、 always だけにしようと思います。 ＞これらは、「Security goal」なのでしょうか？ のつもりです。それを実現するための手段の説明を始めるために To do so, の節があります。 ＞ですが、passwdコマンド無しでも、 ＞再現しましたよ。 あれ？これは最近の Fedora では passwd コマンドと組み合わせないと再現しないと思います。 ４〜５ヶ月前くらいまでは # ln /etc/shadow ~/ # touch /.autorelabel # reboot だけで剥奪できましたが、最近 restorecon の仕様が変化したのか、 yum -y update を行った後では剥奪できなくなっていました。 （そのため、ネットワークセキュリティ Expert 7 の操作例は既に古くなっています。） ＞targetedポリシで対処するならば、 ＞unconfined_tから、link permissionを ＞全部切ってしまうのでしょうかねぇ。 ハードリンクだけ切っても仕方ないと思います。 リネームでも（ DAC が許可すれば）同じことを起こせます。 ＞「自分のやろうとしていることを理解してやること」 ＞と言っていた気がしますが、現実的ではないですね。 全てのファイルがあるべき場所にあるべき名前で存在しているのを どうやって保証するのでしょうね？ ということで、次の版です。 <<< Footnotes >>> の前３節分を統合して non-analyzable とか non-modularizable とかいう言葉を使わないようにしました。 −−−−− TOMOYO Linux's Security Goal (draft) Tetsuo Handa <<< About TOMOYO Linux >>> TOMOYO Linux is a DIY tool for understanding and protecting your system. You can write policy from scratch. You can do troubleshooting by yourself. TOMOYO Linux will record the system's activities and generate policy that always fits for the system's activities. <<< About TOMOYO Linux's security goal >>> The TOMOYO Linux's security goals are that: * Make the all subject's all access requests that will occur at least once during the lifetime of the kernel known in advance. * Let the administrator understand what access requests will each subject raise in his/her system and write policy which only allows expected and desirable access requests for his/her needs. To do so, TOMOYO Linux attempts to make the system where everything is prearranged in an easy-to-understand way. TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications that the system hosts. The threat is that an attacker can cause a vulnerable application to do something unexpected and undesirable. TOMOYO Linux addresses this threat by recording all applications' behaviors in the test environment and forcing all applications behave within recorded behaviors in the production environment. TOMOYO Linux has a concept of "process invocation history" (in short, PIH). The PIH is a developmental lineage of a process. When a process executes a program, the process creates a copy with fork() and replace the copy with execve(). TOMOYO Linux appends the pathname of the executed program to the PIH of the replaced process, and associates process's PIH (stored in task_struct) with a domain. As a result, the context switching (a.k.a. domain transition) is unidirectional. This rule allows administrator distinguish and manage fine-grained context. Domain transition forms tree structure like a directory tree of filesystems. Each domain has different set of permissions that are essential for that domain. <<< About exceptions in TOMOYO Linux >>> TOMOYO Linux switches the context of a process whenever a process executes a program, but there are two exceptions. Administrator may relocate domain of a process if PIH is not meaningful for that process (e.g. daemon programs). This exception allows administrator restart daemon programs. Administrator may suppress domain transition if domain transition is not meaningful for that process (e.g. programs called within /etc/init.d/ scripts). This exception reduces memory usage for policy. TOMOYO Linux can apply access control over all userspace applications, but administrator can also apply access control over only specific userspace applications if he/she wishes so. TOMOYO Linux supports "delayed enforcing mode" that allows administrator interactively judge whether an request which is not defined in the policy should be permitted or rejected. This mode helps administrator adjust the policy after software updates. <<< Problems with userland applications >>> SELinux FAQ says that | The security of an unmodified Linux system depends on the correctness of the | kernel, all the privileged applications, and each of their configurations. | A problem in any one of these areas may allow the compromise of the entire | system. In contrast, the security of a modified system based on the Security- | enhanced Linux kernel depends primarily on the correctness of the kernel and | its security policy configuration. But it is not always true. An application who is permitted to access block device file can leak arbitrary information (*1). An application who is permitted to do DNS query can leak arbitrary information (*2). An application who is permitted to create a hard link of an object can have a part in revoking appropriate label from the object (*3). An application who has OS command injection vulnerability can yield unexpected output (*4). An application can pass arbitrary amount of information to executed program via parameters to execve() (*5). Changing policy without rebooting the system can leak information (*6). After all, the security of a modified system still depends on primarily correctness of applications and users' operations. So, I don't spend all time and all money for OS level security. TOMOYO Linux doesn't give any assurance about information flow because I don't want responsible official to blindly accept the statement "We can assure that there is no possibility of leaking information if you use our implementation and policy configuration certified by formal analysis." so that responsible official shall not complain "I believed that use of your implementation and policy can prevent leaking information. Why my confidential report flowed out?" when an incident occured. It is very very difficult for non-security people to properly understand the coverage and degree of assurance. <<< TOMOYO Linux's approach >>> I consider OS level security as "one of securities". No matter how strongly access control is enforced in kernel space, it can't keep all information under control. TOMOYO Linux is not intended to provide assurance for the contents of an object. TOMOYO Linux is intended to provide assurance for available means. Requests for file access are described using means to access a file (i.e. canonicalized pathname). Requests for network access are described using means to access a socket (i.e. operation / protocol / IP address / port number). TOMOYO Linux didn't introduce abstraction layer to files since it makes difficult to selectively add/remove permissions. Let's have an assumption that one wants to allow executing only /usr/bin/md5sum . Introducing a rule "/bin/* and /usr/bin/* have bin_t" and forcing users to describe policy using this rule makes it difficult to allow executing only /usr/bin/md5sum . If you divide the rule into two rules "/usr/bin/md5sum has md5sum_t" and "/bin/* and /usr/bin/* except /usr/bin/md5sum have bin_t" so that you can allow executing only /usr/bin/md5sum , you have to arrange an accommodation among the whole policy because other application might need to execute /usr/bin/md5sum too. Let's have an assumption that one wants to allow opening only /etc/fstab for reading. Introducing a rule "/etc/* have etc_t" and forcing users to describe policy using this rule makes it difficult to allow opening only /etc/fstab for reading. You have to arrange an accommodation among the whole policy if you want to change rules to remove redundant permissions so that you can allow opening only /etc/fstab for reading. Changing the rules also affects to the PIH of TOMOYO Linux if PIH is described using the rules. You will have to discard policy generated by TOMOYO Linux if you change the rules. TOMOYO Linux doesn't use such rules so that users can allow executing only /usr/bin/md5sum without the risk of also executing /bin/cat in case of OS command injection vulnerability exists. <<< Footnotes >>> (*1) For example, /usr/sbin/smartd opens disk device (e.g. /dev/hda) for reading and sends reports using /bin/mail . Thus, if /usr/sbin/smartd were a Trojan horse, it is possible to leak all information stored in that disk device to third parties. Similarly, /bin/mount opens disk device (e.g. /dev/hda1) and updates /etc/mtab . Thus, if /bin/mount were a Trojan horse, it is possible to write the first line of /etc/shadow (i.e. root's password) to /etc/mtab . (*2) Let's have an assumption that users need to use proxy authentication to access to internet via http protocol. A user will run $ export http_proxy="http://:@:" before running $ curl http://www.kernel.org/ If is "USER" and is "a ＠ PASS@WORD", he/she will run $ export http_proxy="http://USER:a ＠ PASS@WORD@:" With this configuration, running $ curl http://www.kernel.org/ will leak part of the password information (i.e. PASS ＠ WORD@ ) to DNS servers because the application interprets the first @ as the delimiter for part. RFC1738 forbids to use @ character for and while authentication system accepts @ character for . The application should have either aborted if multiple @ characters appeared in http_proxy environment variable or interpreted the last @ as the delimiter for part. This leakage is unintentional because this is an application's design error or user's operational mistakes. But, of course, there are intentional leakage too. A malicious user who wants to leak secret information to competitor can run $ nslookup . DNS server can't know is confidential data and will forward query to competitor's DNS server. (*3) Let's have an assumption that /home partition is not separated from / partition and the policy forbids opening shadow_t files (i.e. /etc/shadow) but the policy doesn't forbid creating hard link of shadow_t files. A non-root user can create hard link of shadow_t files and wait for root user to create /.autorelabel and reboot the system. (Login as user "demo".) [demo ＠ tomoyo ~]$ ln /etc/shadow [demo ＠ tomoyo ~]$ ls -Z /etc/shadow shadow -r-------- root root system_u:object_r:shadow_t:s0 /etc/shadow -r-------- root root system_u:object_r:shadow_t:s0 shadow [demo ＠ tomoyo ~]$ passwd Changing password for user demo. Changing password for demo (current) UNIX password: New UNIX password: Retype new UNIX password: passwd: all authentication tokens updated successfully. [demo ＠ tomoyo ~]$ su - Password: [root ＠ tomoyo ~]# touch /.autorelabel [root ＠ tomoyo ~]# reboot (Wait for completion of reboot, then login as user "demo".) [demo ＠ tomoyo ~]$ ls -Z /etc/shadow shadow -r-------- root root system_u:object_r:shadow_t:s0 /etc/shadow -r-------- root root system_u:object_r:default_t:s0 shadow The /home/demo/shadow lost shadow_t label. The trigger of changing label are creation of /.autorelabel and rebooting the system, but creation of hard link of /etc/shadow and execution of /usr/bin/passwd (to split hard linked object) are complicity in a crime. (*4) Let's have an assumption that the following CGI (say, test.sh) is executed and permissions to execute /usr/bin/md5sum (which is bin_t) from this CGI is given. #! /bin/sh read echo "Content-type: text/plain" echo "" eval md5sum $REPLY You can run $ echo "/etc/fstab" | ./test.sh Content-type: text/plain b6b8d9a26bdea67cdbda41788e402621 /etc/fstab But you can also run $ echo "/etc/fstab; cat /etc/fstab" | ./test.sh Content-type: text/plain b6b8d9a26bdea67cdbda41788e402621 /etc/fstab LABEL=/ / ext3 noatime,nodiratime 1 1 LABEL=/boot /boot ext3 noatime,nodiratime 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 Of course, the author of this CGI intended to print only MD5 of a file and never intended to print the whole contents of a file. But we couldn't follow the author's will because /bin/cat and /usr/bin/md5sum had same label and both programs read from somewhere and write to somewhere. If the file contains password information, can you accept this accident? We can't avoid this accident unless we give different labels to /bin/cat and /usr/bin/md5sum . (*5) Some implementation checks whether file descriptors are permitted to be inherited to execve()ed program. But they don't check argv[] and envp[] passed to execve() requests. If a file descriptor refers to a regular file opened for reading, a malicious process can pass the (almost all) contents of the file through argv[] or envp[] because kernel 2.6.23 with MMU can receive arrays of strings up to 128kB each. But the kernel can't know the meaning of these strings. This makes meaningless to forbid inheriting (for example) /etc/fstab's decriptor using policy because malicious process can pass the contents of /etc/fstab through argv[] or envp[]. (*6) Let's have an assumption that you have two policies (P1) "allow app1 to read from /etc/shadow, but don't allow app1 to write to /tmp/shadow" (P2) "allow app1 to write to /tmp/shadow, but don't allow app1 to read from /etc/shadow" and you want to assure "The contents of /etc/shadow will never be flowed out to /tmp/shadow". The app1's source is something like int main(int argc, char *argv[]) { char buf[16384]; FILE *fp = fopen("/etc/shadow", "r"); int len = fread(buf, 1, sizeof(buf), fp); fclose(fp); sleep(10); fp = fopen("/tmp/shadow", "w"); fwrite(buf, 1, len, fp); fclose(fp); return 0; } Obviously, P1 and P2 are exclusive and app1 won't be able to copy /etc/shadow to /tmp/shadow . But if the following sequence happens Load P1. -> Start app1 -> Switch from P1 to P2 while app1 is sleeping at sleep(10) -> Wait for app1 to terminate app1 is able to copy /etc/shadow to /tmp/shadow through buf[]. To avoid such case, killing app1 (or killing all processes through reboot) is needed when we change policy but we still wants to assure "The contents of /etc/shadow will never be flowed out to /tmp/shadow". It is impossible to assign label to information outside the kernel. TOMOYO Linux doesn't check permissions for files after files are opened because it is too late to revert already read/written data when policy has changed after files are opened. Instead, TOMOYO Linux attempts to keep processes under control as hard as possible until files are opened. <<< Presentation materials about TOMOYO Linux >>> OLS2007: TOMOYO Linux BoF http://sourceforge.jp/projects/tomoyo/document/ols2007-tomoyo-20070629.pdf PacSec2007: TOMOYO Linux: A Practical Method to Understand and Protect Your Own Linux Box http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf ELC2007: TOMOYO Linux - A Lightweight and Manageable Security System for PC and Embedded Linux http://sourceforge.jp/projects/tomoyo/document/elc2007-presentation-20070418-for_linux.pdf (for Linux) http://sourceforge.jp/projects/tomoyo/document/elc2007-presentation-20070418.pdf (for Windows) From from-tomoyo-dev ＠ i-love.sakura.ne.jp Fri Dec 21 09:23:53 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Fri, 21 Dec 2007 09:23:53 +0900 Subject: [Tomoyo-dev 742] Re: TOMOYO Linux security goal In-Reply-To: <200712170549.lBH5nhqr059341@www262.sakura.ne.jp> References: <20071217081718.DA71.YNAKAM@hitachisoft.jp> <200712170013.lBH0DgVu094600@www262.sakura.ne.jp> <20071217140007.DA99.YNAKAM@hitachisoft.jp> <200712170549.lBH5nhqr059341@www262.sakura.ne.jp> Message-ID: <200712210023.lBL0NrkH042730@www262.sakura.ne.jp> 　熊猫です。 　途中経過です。 BLP モデルのような情報の流れを保証するなんて現実にはできっこないから TOMOYO ではそういうことには注力していないということを書きたいけど、 情報フローの話を始めると話が長くなってしまうので、これから大きく 方向転換するかもしれません。 ---------- TOMOYO Linux Security Goal (draft) This document is intended to specify the security goal that TOMOYO Linux is trying to achieve, so that users can evaluate whether TOMOYO Linux will meet their needs, and kernel developers can evaluate whether TOMOYO Linux deserved to be in-tree. This document is *not* a general purpose explanation of how TOMOYO Linux works. 1. About TOMOYO Linux Project Homepage: http://tomoyo.sourceforge.jp/index.html.en Project Wiki: http://elinux.org/TomoyoLinux TOMOYO Linux is a DIY tool for understanding and protecting your system. TOMOYO Linux policy definitions are absolutely readable to Linux users, and TOMOYO Linux supports unique policy learning mechanism which automatically gathers information and arranges the results as policy definitions. These things made it possible for users to write policy from scratch. Troubleshooting can be done by users. We put some TOMOYO Linux policy examples on our web site. http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/etch/domain_policy.conf?v=policy-sample 2. TOMOYO Linux Security Goal The TOMOYO Linux's security goal is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool for security professional but for average users and administrators. 3. Our Approach To meet the above goal, TOMOYO Linux attempts to make the system where everything is prearranged in an easy-to-understand way. * Make the all subject's all access requests that will occur at least once during the lifetime of the kernel known in advance. * Let the administrator understand what access requests will each subject raise in his/her system and write policy which only allows expected and desirable access requests for his/her needs. Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications that the system hosts. The threat is that an attacker can cause a vulnerable application to do something unexpected and undesirable. TOMOYO Linux addresses this threat by recording all applications' behaviors in the test environment and forcing all applications behave within recorded behaviors in the production environment. TOMOYO Linux has a unique concept of "process invocation history" (in short, PIH). The PIH is a developmental lineage of a process. When a process executes a program, the process creates a copy with fork() and replace the copy with execve(). TOMOYO Linux appends the pathname of the executed program to the PIH of the replaced process, and associates process's PIH (stored in task_struct) with a domain. As a result, the context switching (a.k.a. domain transition) is unidirectional. This rule allows administrator distinguish and manage fine-grained context. Domain transition forms tree structure like a directory tree of filesystems. Each domain has different set of permissions that are essential for that domain. 4. Inevitable Problems Regarding Confidentiality SELinux FAQ says that | The security of an unmodified Linux system depends on the correctness of the | kernel, all the privileged applications, and each of their configurations. | A problem in any one of these areas may allow the compromise of the entire | system. In contrast, the security of a modified system based on the Security- | enhanced Linux kernel depends primarily on the correctness of the kernel and | its security policy configuration. But it is not always true. Admiring the advantages of mandatory access control, we think it is impossible to guarantee perfect confidentiality. Keeping all userspace information under control is impossible. Here are examples. An application that is permitted to access block device file can leak arbitrary information. (See *1 in Appendix) An application that is permitted to do DNS query can leak arbitrary information. (*2) An application can pass arbitrary amount of information to executed program via parameters to execve() . (*3) Changing policy without rebooting the system can leak information. (*4) After all, we believe that the security (especially confidentiality) of a modified system still depends on primarily correctness of applications and users' operations. 5. Problems with SELinux and Answers with TOMOYO Linux. SELinux can perform very fine grained access control, but there are still pitfalls that can lead to unexpected results. For example, An application that is permitted to create a hard link of an object can have a part in revoking appropriate label from the object. (*5) An application that has OS command injection vulnerability can yield unexpected output. (*6) TOMOYO Linux doesn't introduce abstraction layer to files since it makes difficult to selectively add/remove permissions. Let's have an assumption that one wants to allow executing only /usr/bin/md5sum . Introducing a rule "/bin/* and /usr/bin/* have bin_t" and forcing users to describe policy using this rule makes it difficult to allow executing only /usr/bin/md5sum . If you divide the rule into two rules "/usr/bin/md5sum has md5sum_t" and "/bin/* and /usr/bin/* except /usr/bin/md5sum have bin_t" so that you can allow executing only /usr/bin/md5sum , you have to arrange an accommodation among the whole policy because other application might need to execute /usr/bin/md5sum too. Let's have an assumption that one wants to allow opening only /etc/fstab for reading. Introducing a rule "/etc/* have etc_t" and forcing users to describe policy using this rule makes it difficult to allow opening only /etc/fstab for reading. You have to arrange an accommodation among the whole policy if you want to change rules to remove redundant permissions so that you can allow opening only /etc/fstab for reading. Changing the rules also affects to the PIH of TOMOYO Linux if PIH is described using the rules. You will have to discard policy generated by TOMOYO Linux if you change the rules. TOMOYO Linux doesn't use such rules so that users can allow executing only /usr/bin/md5sum without the risk of also executing /bin/cat in case of OS command injection vulnerability exists. Policy-based Mandatory Access Control can limit permissions given to programs/users, but malicious programs/users can still request nasty things at entry point (i.e. execve()/open() time) within given permissions. TOMOYO Linux is not designed to control permissions after entry point, but is designed to minimize permissions given to programs/users at entry point. TOMOYO Linux considers OS level security as "one of securities" and wants users not to spend all time and all money for OS level security. Authors: Tetsuo Handa Toshiharu Harada Kentaro Takeda Appendix 1 - Usability features of TOMOYO Linux TOMOYO Linux switches the context of a process whenever a process executes a program, but there are two exceptions. Administrator may relocate domain of a process if PIH is not meaningful for that process (e.g. daemon programs). This exception allows administrator restart daemon programs. Administrator may suppress domain transition if domain transition is not meaningful for that process (e.g. programs called within /etc/init.d/ scripts). This exception reduces memory usage for policy. TOMOYO Linux can apply access control over all userspace applications, but administrator can also apply access control over only specific userspace applications if he/she wishes so. TOMOYO Linux supports "delayed enforcing mode" that allows administrator interactively judge whether a request which is not defined in the policy should be permitted or rejected. This mode helps administrator adjust the policy after software updates. Appendix 2 - Examples (*1) For example, /usr/sbin/smartd opens disk device (e.g. /dev/hda) for reading and sends reports using /bin/mail . Thus, if /usr/sbin/smartd were a Trojan horse, it is possible to leak all information stored in that disk device to third parties. Similarly, /bin/mount opens disk device (e.g. /dev/hda1) and updates /etc/mtab . Thus, if /bin/mount were a Trojan horse, it is possible to write the first line of /etc/shadow (i.e. root's password) to /etc/mtab . (*2) Let's have an assumption that users need to use proxy authentication to access to internet via http protocol. A user will run $ export http_proxy="http://:@:" before running $ curl http://www.kernel.org/ If is "USER" and is "a ＠ PASS@WORD", he/she will run $ export http_proxy="http://USER:a ＠ PASS@WORD@:" With this configuration, running $ curl http://www.kernel.org/ will leak part of the password information (i.e. PASS ＠ WORD@ ) to DNS servers because the application interprets the first @ as the delimiter for part. RFC1738 forbids using @ character for and while authentication system accepts @ character for . The application should have either aborted if multiple @ characters appeared in http_proxy environment variable or interpreted the last @ as the delimiter for part. This leakage is unintentional because this is an application's design error or user's operational mistakes. But, of course, there is intentional leakage too. A malicious user who wants to leak secret information to competitor can run $ nslookup . DNS server can't know is confidential data and will forward query to competitor's DNS server. (*3) Some implementation checks whether file descriptors are permitted to be inherited to execve()ed program. But they don't check argv[] and envp[] passed to execve() requests. If a file descriptor refers to a regular file opened for reading, a malicious process can pass the (almost all) contents of the file through argv[] or envp[] because kernel 2.6.23 with MMU can receive arrays of strings up to 128kB each. But the kernel can't know the meaning of these strings. This breaks guarantee that an administrator can stop propagation of the content of (e.g.) /etc/fstab by forbidding inheritance of the file's descriptor using policy because malicious process can pass the contents of /etc/fstab through argv[] or envp[]. (*4) Let's have an assumption that you have two policies (P1) "allow app1 to read from /etc/shadow, but don't allow app1 to write to /tmp/shadow" (P2) "allow app1 to write to /tmp/shadow, but don't allow app1 to read from /etc/shadow" and you want to assure "The contents of /etc/shadow will never be flowed out to /tmp/shadow". The app1's source is something like int main(int argc, char *argv[]) { char buf[16384]; FILE *fp = fopen("/etc/shadow", "r"); int len = fread(buf, 1, sizeof(buf), fp); fclose(fp); sleep(10); fp = fopen("/tmp/shadow", "w"); fwrite(buf, 1, len, fp); fclose(fp); return 0; } Obviously, P1 and P2 are exclusive and app1 won't be able to copy /etc/shadow to /tmp/shadow . But if the following sequence happens Load P1. -> Start app1 -> Switch from P1 to P2 while app1 is sleeping at sleep(10) -> Wait for app1 to terminate app1 is able to copy /etc/shadow to /tmp/shadow through buf[]. To avoid such case, killing app1 (or killing all processes through reboot) is needed when we change policy but we still wants to assure "The contents of /etc/shadow will never be flowed out to /tmp/shadow". It is impossible to assign label to information outside the kernel. Since it is too late to revert already read/written data when policy has changed after files are opened, TOMOYO Linux doesn't check permissions for files after files are opened. Instead, TOMOYO Linux attempts to keep processes under control as hard as possible until files are opened. (*5) Let's have an assumption that /home partition is not separated from / partition and the policy forbids opening shadow_t files (i.e. /etc/shadow) but the policy doesn't forbid creating hard link of shadow_t files. A non-root user can create hard link of shadow_t files and wait for root user to create /.autorelabel and reboot the system. (Login as user "demo".) [demo ＠ tomoyo ~]$ ln /etc/shadow [demo ＠ tomoyo ~]$ ls -Z /etc/shadow shadow -r-------- root root system_u:object_r:shadow_t:s0 /etc/shadow -r-------- root root system_u:object_r:shadow_t:s0 shadow [demo ＠ tomoyo ~]$ passwd Changing password for user demo. Changing password for demo (current) UNIX password: New UNIX password: Retype new UNIX password: passwd: all authentication tokens updated successfully. [demo ＠ tomoyo ~]$ su - Password: [root ＠ tomoyo ~]# touch /.autorelabel [root ＠ tomoyo ~]# reboot (Wait for completion of reboot, then login as user "demo".) [demo ＠ tomoyo ~]$ ls -Z /etc/shadow shadow -r-------- root root system_u:object_r:shadow_t:s0 /etc/shadow -r-------- root root system_u:object_r:default_t:s0 shadow The /home/demo/shadow lost shadow_t label. The trigger of changing label are creation of /.autorelabel and rebooting the system, but creation of hard link of /etc/shadow and execution of /usr/bin/passwd (to split hard linked object) are complicity in a crime. (*6) Let's have an assumption that the following CGI (say, test.sh) is executed and permissions to execute /usr/bin/md5sum (which is bin_t) from this CGI is given. #! /bin/sh read echo "Content-type: text/plain" echo "" eval md5sum $REPLY You can run $ echo "/etc/fstab" | ./test.sh Content-type: text/plain b6b8d9a26bdea67cdbda41788e402621 /etc/fstab But you can also run $ echo "/etc/fstab; cat /etc/fstab" | ./test.sh Content-type: text/plain b6b8d9a26bdea67cdbda41788e402621 /etc/fstab LABEL=/ / ext3 noatime,nodiratime 1 1 LABEL=/boot /boot ext3 noatime,nodiratime 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 Of course, the author of this CGI intended to print only MD5 of a file and never intended to print the whole contents of a file. But we couldn't follow the author's will because /bin/cat and /usr/bin/md5sum had same label and both programs read from somewhere and write to somewhere. If the file contains password information, can you accept this accident? We can't avoid this accident unless we give different labels to /bin/cat and /usr/bin/md5sum . Appendix 3 - Presentation slides - PacSec2007: TOMOYO Linux: "A Practical Method to Understand and Protect Your Own Linux Box" http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf - OLS2007: "TOMOYO Linux BoF" http://sourceforge.jp/projects/tomoyo/document/ols2007-tomoyo-20070629.pdf - ELC2007: "TOMOYO Linux - A Lightweight and Manageable Security System for PC and Embedded Linux" http://sourceforge.jp/projects/tomoyo/document/elc2007-presentation-20070418-for_linux.pdf From haradats ＠ nttdata.co.jp Fri Dec 21 10:32:06 2007 From: haradats ＠ nttdata.co.jp (Toshiharu Harada) Date: Fri, 21 Dec 2007 10:32:06 +0900 Subject: [Tomoyo-dev 743] Re: TOMOYO Linux security goal In-Reply-To: <200712210023.lBL0NrkH042730@www262.sakura.ne.jp> References: <20071217081718.DA71.YNAKAM@hitachisoft.jp> <200712170013.lBH0DgVu094600@www262.sakura.ne.jp> <20071217140007.DA99.YNAKAM@hitachisoft.jp> <200712170549.lBH5nhqr059341@www262.sakura.ne.jp> <200712210023.lBL0NrkH042730@www262.sakura.ne.jp> Message-ID: <476B1796.1000501@nttdata.co.jp> 原田です。 On 12/21/2007 9:23 AM, from-tomoyo-dev ＠ i-love.sakura.ne.jp wrote: > 　熊猫です。 > > 　途中経過です。 > BLP モデルのような情報の流れを保証するなんて現実にはできっこないから > TOMOYO ではそういうことには注力していないということを書きたいけど、 > 情報フローの話を始めると話が長くなってしまうので、これから大きく > 方向転換するかもしれません。 昨日も「中の人」会議を行ったわけですが、実は「BLP モデルのような情報の流れを 保証するなんて現実にはできっこない」という主張こそが （TOMOYO Linuxにも独立で）、熊猫さんが一番言いたいこと、主張したいこと じゃないかと私は感じています（ほとんど確信に近いです）。 もし、それが事実だとしたら、長くなろうがどんな議論が起ころうが StephanやLinusが怒ろうが（笑）、言いたいことをいうべきです。 そうしなければ、熊猫さんはきっと納得、満足できないでしょう。 ただ、セキュリティゴールは当然TOMOYO Linuxのセキュリティゴールですから、 TOMOYO Linuxより広いスコープの議論を展開すると、タイトルと中身が 異なり、TOMOYO固有の話題とより広い話題が混在し、おかしなことになります。 そもそもセキュリティゴールを投稿してという呼びかけ自体が されている経緯は、 > THe only way I can think of to get out of this mess is to > have the submitter of the security model give a description of what his > protection model is (and unless it's silly, not argue about that), and > then only focus on how the code manages to achieve this model, to make > sure there's no big gaps in it, within its own goals/reference. からもわかるように、「それぞれの実装、モデルに閉じて議論しないと、 まとまらないでぐちゃぐちゃになる」ですから、それに全く逆行します。 と言っている間に、AppArmorが投稿していますね・・・。 > ---------- > > TOMOYO Linux Security Goal (draft) > > This document is intended to specify the security goal that TOMOYO Linux is > trying to achieve, so that users can evaluate whether TOMOYO Linux will meet > their needs, and kernel developers can evaluate whether TOMOYO Linux deserved > to be in-tree. This document is *not* a general purpose explanation of how > TOMOYO Linux works. > > 1. About TOMOYO Linux > > Project Homepage: http://tomoyo.sourceforge.jp/index.html.en > Project Wiki: http://elinux.org/TomoyoLinux > > TOMOYO Linux is a DIY tool for understanding and protecting your system. > TOMOYO Linux policy definitions are absolutely readable to Linux users, > and TOMOYO Linux supports unique policy learning mechanism which automatically > gathers information and arranges the results as policy definitions. > These things made it possible for users to write policy from scratch. > Troubleshooting can be done by users. > We put some TOMOYO Linux policy examples on our web site. > > http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/etch/domain_policy.conf?v=policy-sample > > 2. TOMOYO Linux Security Goal > > The TOMOYO Linux's security goal is to provide "MAC that covers practical > requirements for most users and keeps usable for most administrators". > TOMOYO Linux is not a tool for security professional but for average users and > administrators. > > 3. Our Approach > > To meet the above goal, TOMOYO Linux attempts to make the system where > everything is prearranged in an easy-to-understand way. > > * Make the all subject's all access requests that will occur at least once > during the lifetime of the kernel known in advance. > > * Let the administrator understand what access requests will each subject > raise in his/her system and write policy which only allows expected and > desirable access requests for his/her needs. > > Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from > attackers exploiting vulnerabilities in applications that the system hosts. > The threat is that an attacker can cause a vulnerable application to do > something unexpected and undesirable. TOMOYO Linux addresses this threat by > recording all applications' behaviors in the test environment and forcing all > applications behave within recorded behaviors in the production environment. > > TOMOYO Linux has a unique concept of "process invocation history" > (in short, PIH). The PIH is a developmental lineage of a process. > When a process executes a program, the process creates a copy with fork() and > replace the copy with execve(). > TOMOYO Linux appends the pathname of the executed program to the PIH > of the replaced process, and associates process's PIH (stored in task_struct) > with a domain. > As a result, the context switching (a.k.a. domain transition) is unidirectional. > This rule allows administrator distinguish and manage fine-grained context. > Domain transition forms tree structure like a directory tree of filesystems. > Each domain has different set of permissions that are essential for that domain. > > 4. Inevitable Problems Regarding Confidentiality > > SELinux FAQ says that > | The security of an unmodified Linux system depends on the correctness of the > | kernel, all the privileged applications, and each of their configurations. > | A problem in any one of these areas may allow the compromise of the entire > | system. In contrast, the security of a modified system based on the Security- > | enhanced Linux kernel depends primarily on the correctness of the kernel and > | its security policy configuration. > But it is not always true. > > Admiring the advantages of mandatory access control, we think it is impossible > to guarantee perfect confidentiality. Keeping all userspace information under > control is impossible. Here are examples. > > An application that is permitted to access block device file can leak > arbitrary information. (See *1 in Appendix) > > An application that is permitted to do DNS query can leak > arbitrary information. (*2) > > An application can pass arbitrary amount of information to executed program > via parameters to execve() . (*3) > > Changing policy without rebooting the system can leak information. (*4) > > After all, we believe that the security (especially confidentiality) of > a modified system still depends on primarily correctness of applications > and users' operations. > > 5. Problems with SELinux and Answers with TOMOYO Linux. > > SELinux can perform very fine grained access control, but there are still > pitfalls that can lead to unexpected results. > For example, > > An application that is permitted to create a hard link of an object can have > a part in revoking appropriate label from the object. (*5) > > An application that has OS command injection vulnerability can yield > unexpected output. (*6) > > TOMOYO Linux doesn't introduce abstraction layer to files since it makes > difficult to selectively add/remove permissions. > > Let's have an assumption that one wants to allow executing > only /usr/bin/md5sum . > Introducing a rule "/bin/* and /usr/bin/* have bin_t" and forcing users to > describe policy using this rule makes it difficult to allow executing > only /usr/bin/md5sum . > > If you divide the rule into two rules "/usr/bin/md5sum has md5sum_t" and > "/bin/* and /usr/bin/* except /usr/bin/md5sum have bin_t" so that you can allow > executing only /usr/bin/md5sum , you have to arrange an accommodation among > the whole policy because other application might need to execute > /usr/bin/md5sum too. > > Let's have an assumption that one wants to allow opening only /etc/fstab > for reading. > Introducing a rule "/etc/* have etc_t" and forcing users to describe policy > using this rule makes it difficult to allow opening only /etc/fstab for reading. > You have to arrange an accommodation among the whole policy if you want to > change rules to remove redundant permissions so that you can allow opening > only /etc/fstab for reading. > > Changing the rules also affects to the PIH of TOMOYO Linux if PIH is described > using the rules. You will have to discard policy generated by TOMOYO Linux > if you change the rules. > > TOMOYO Linux doesn't use such rules so that users can allow executing > only /usr/bin/md5sum without the risk of also executing /bin/cat in case of > OS command injection vulnerability exists. > > Policy-based Mandatory Access Control can limit permissions given to > programs/users, but malicious programs/users can still request nasty things > at entry point (i.e. execve()/open() time) within given permissions. > TOMOYO Linux is not designed to control permissions after entry point, > but is designed to minimize permissions given to programs/users at entry point. > > TOMOYO Linux considers OS level security as "one of securities" and wants users > not to spend all time and all money for OS level security. > > Authors: > Tetsuo Handa > Toshiharu Harada > Kentaro Takeda > > Appendix 1 - Usability features of TOMOYO Linux > > TOMOYO Linux switches the context of a process whenever a process executes > a program, but there are two exceptions. > Administrator may relocate domain of a process if PIH is not meaningful > for that process (e.g. daemon programs). > This exception allows administrator restart daemon programs. > Administrator may suppress domain transition if domain transition is not > meaningful for that process (e.g. programs called within /etc/init.d/ scripts). > This exception reduces memory usage for policy. > > TOMOYO Linux can apply access control over all userspace applications, > but administrator can also apply access control over only specific userspace > applications if he/she wishes so. > > TOMOYO Linux supports "delayed enforcing mode" that allows administrator > interactively judge whether a request which is not defined in the policy > should be permitted or rejected. > This mode helps administrator adjust the policy after software updates. > > Appendix 2 - Examples > > (*1) > > For example, /usr/sbin/smartd opens disk device (e.g. /dev/hda) for reading and > sends reports using /bin/mail . Thus, if /usr/sbin/smartd were a Trojan horse, > it is possible to leak all information stored in that disk device > to third parties. > Similarly, /bin/mount opens disk device (e.g. /dev/hda1) and updates /etc/mtab . > Thus, if /bin/mount were a Trojan horse, it is possible to write the first line > of /etc/shadow (i.e. root's password) to /etc/mtab . > > (*2) > > Let's have an assumption that users need to use proxy authentication to access > to internet via http protocol. A user will run > > $ export http_proxy="http://:@:" > > before running > > $ curl http://www.kernel.org/ > > If is "USER" and is "a ＠ PASS@WORD", he/she will run > > $ export http_proxy="http://USER:a ＠ PASS@WORD@:" > > With this configuration, running > > $ curl http://www.kernel.org/ > > will leak part of the password information (i.e. PASS ＠ WORD@ ) to > DNS servers because the application interprets the first @ as the delimiter for > part. > RFC1738 forbids using @ character for and > while authentication system accepts @ character for . > The application should have either aborted if multiple @ characters appeared in > http_proxy environment variable or interpreted the last @ as the delimiter > for part. > > This leakage is unintentional because this is an application's design error > or user's operational mistakes. > > But, of course, there is intentional leakage too. > > A malicious user who wants to leak secret information to competitor can run > > $ nslookup . > > DNS server can't know is confidential data and will forward query > to competitor's DNS server. > > (*3) > > Some implementation checks whether file descriptors are permitted to be > inherited to execve()ed program. But they don't check argv[] and envp[] passed > to execve() requests. > If a file descriptor refers to a regular file opened for reading, a malicious > process can pass the (almost all) contents of the file through argv[] or envp[] > because kernel 2.6.23 with MMU can receive arrays of strings up to 128kB each. > But the kernel can't know the meaning of these strings. > This breaks guarantee that an administrator can stop propagation of the content > of (e.g.) /etc/fstab by forbidding inheritance of the file's descriptor using > policy because malicious process can pass the contents of /etc/fstab through > argv[] or envp[]. > > (*4) > > Let's have an assumption that you have two policies > > (P1) "allow app1 to read from /etc/shadow, but don't allow app1 to write to > /tmp/shadow" > (P2) "allow app1 to write to /tmp/shadow, but don't allow app1 to read from > /etc/shadow" > > and you want to assure "The contents of /etc/shadow will never be flowed out > to /tmp/shadow". > > The app1's source is something like > > int main(int argc, char *argv[]) { > char buf[16384]; > FILE *fp = fopen("/etc/shadow", "r"); > int len = fread(buf, 1, sizeof(buf), fp); > fclose(fp); > sleep(10); > fp = fopen("/tmp/shadow", "w"); > fwrite(buf, 1, len, fp); > fclose(fp); > return 0; > } > > Obviously, P1 and P2 are exclusive and app1 won't be able to copy /etc/shadow > to /tmp/shadow . > But if the following sequence happens > > Load P1. -> Start app1 -> Switch from P1 to P2 while app1 is sleeping at sleep(10) -> Wait for app1 to terminate > > app1 is able to copy /etc/shadow to /tmp/shadow through buf[]. > To avoid such case, killing app1 (or killing all processes through reboot) > is needed when we change policy but we still wants to assure "The contents of > /etc/shadow will never be flowed out to /tmp/shadow". > > It is impossible to assign label to information outside the kernel. Since it is > too late to revert already read/written data when policy has changed after > files are opened, TOMOYO Linux doesn't check permissions for files after files > are opened. > Instead, TOMOYO Linux attempts to keep processes under control as hard as > possible until files are opened. > > (*5) > > Let's have an assumption that /home partition is not separated from / partition > and the policy forbids opening shadow_t files (i.e. /etc/shadow) > but the policy doesn't forbid creating hard link of shadow_t files. > A non-root user can create hard link of shadow_t files and wait for root user > to create /.autorelabel and reboot the system. > > (Login as user "demo".) > > [demo ＠ tomoyo ~]$ ln /etc/shadow > [demo ＠ tomoyo ~]$ ls -Z /etc/shadow shadow > -r-------- root root system_u:object_r:shadow_t:s0 /etc/shadow > -r-------- root root system_u:object_r:shadow_t:s0 shadow > [demo ＠ tomoyo ~]$ passwd > Changing password for user demo. > Changing password for demo > (current) UNIX password: > New UNIX password: > Retype new UNIX password: > passwd: all authentication tokens updated successfully. > [demo ＠ tomoyo ~]$ su - > Password: > [root ＠ tomoyo ~]# touch /.autorelabel > [root ＠ tomoyo ~]# reboot > > (Wait for completion of reboot, then login as user "demo".) > > [demo ＠ tomoyo ~]$ ls -Z /etc/shadow shadow > -r-------- root root system_u:object_r:shadow_t:s0 /etc/shadow > -r-------- root root system_u:object_r:default_t:s0 shadow > > The /home/demo/shadow lost shadow_t label. > The trigger of changing label are creation of /.autorelabel and rebooting > the system, but creation of hard link of /etc/shadow and execution of > /usr/bin/passwd (to split hard linked object) are complicity in a crime. > > (*6) > > Let's have an assumption that the following CGI (say, test.sh) is executed and > permissions to execute /usr/bin/md5sum (which is bin_t) from this CGI is given. > > #! /bin/sh > read > echo "Content-type: text/plain" > echo "" > eval md5sum $REPLY > > You can run > > $ echo "/etc/fstab" | ./test.sh > Content-type: text/plain > > b6b8d9a26bdea67cdbda41788e402621 /etc/fstab > > But you can also run > > $ echo "/etc/fstab; cat /etc/fstab" | ./test.sh > Content-type: text/plain > > b6b8d9a26bdea67cdbda41788e402621 /etc/fstab > LABEL=/ / ext3 noatime,nodiratime 1 1 > LABEL=/boot /boot ext3 noatime,nodiratime 1 2 > none /dev/pts devpts gid=5,mode=620 0 0 > none /dev/shm tmpfs defaults 0 0 > none /proc proc defaults 0 0 > none /sys sysfs defaults 0 0 > > Of course, the author of this CGI intended to print only MD5 of a file and > never intended to print the whole contents of a file. > But we couldn't follow the author's will because /bin/cat and /usr/bin/md5sum > had same label and both programs read from somewhere and write to somewhere. > If the file contains password information, can you accept this accident? > We can't avoid this accident unless we give different labels to /bin/cat and > /usr/bin/md5sum . > > Appendix 3 - Presentation slides > > - PacSec2007: TOMOYO Linux: "A Practical Method to Understand and Protect Your > Own Linux Box" > http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf > > - OLS2007: "TOMOYO Linux BoF" > http://sourceforge.jp/projects/tomoyo/document/ols2007-tomoyo-20070629.pdf > > - ELC2007: "TOMOYO Linux - A Lightweight and Manageable Security System > for PC and Embedded Linux" > http://sourceforge.jp/projects/tomoyo/document/elc2007-presentation-20070418-for_linux.pdf -- 原田季栄 (Toshiharu Harada) haradats ＠ nttdata.co.jp From henrich ＠ debian.or.jp Sat Dec 22 00:14:29 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Sat, 22 Dec 2007 00:14:29 +0900 Subject: [Tomoyo-dev 744] Re: =?iso-2022-jp?b?MS41LjEgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <200712110452.lBB4qfNc032353@www262.sakura.ne.jp> References: <20071024224539.a9743274.henrich@debian.or.jp> <200710242328.GFE65104.ZGSNFPWPPEPtUNt@I-love.SAKURA.ne.jp> <20071025000044.27966b07.henrich@debian.or.jp> <200712062035.HIC81783.tGPUZEPNFNPtPWS@I-love.SAKURA.ne.jp> <20071206212554.d0fb96a1.henrich@debian.or.jp> <200712062136.DBC09309.PZPPENtGPFUWNtS@I-love.SAKURA.ne.jp> <20071206222347.b5d1414b.henrich@debian.or.jp> <20071210231814.cd839986.henrich@debian.or.jp> <200712110452.lBB4qfNc032353@www262.sakura.ne.jp> Message-ID: <20071222001429.70249147.henrich@debian.or.jp> 　やまねです。 　ここ暫く不調な上に仕事の方が色々重なってほとんど作業してませんが、 　とりあえず、経過報告を。 On Tue, 11 Dec 2007 13:52:41 +0900 from-tomoyo-dev ＠ i-love.sakura.ne.jp wrote: > クリスマスまで待てば testing から取り出せるようになるということですね。 　そのあと 1.5.2 への更新をしたので、クリスマス後ですね。 　http://packages.qa.debian.org/c/ccstools.html 　あと、Ubuntu にも取り込まれてました。sync したのが少し前の様です。 　http://packages.ubuntu.com/hardy/admin/tomoyo-ccstools > 　現在 Lenny のカーネルは 2.6.22-2 のようですが > http://bjorn.haxx.se/debian/testing.pl?package=linux-source-2.6.23 によると > もうじき apt-get dist-upgrade すると 2.6.23-1 がインストールされるようになるのでしょうか？ 　もうじきかもしれませんが、まだですね。 　2.6.23 は明示的に入れる必要があるかと。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat Dec 22 11:42:25 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 22 Dec 2007 11:42:25 +0900 Subject: [Tomoyo-dev 745] Re: =?iso-2022-jp?b?MS41LjEgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <20071222001429.70249147.henrich@debian.or.jp> References: <200712062136.DBC09309.PZPPENtGPFUWNtS@I-love.SAKURA.ne.jp> <20071206222347.b5d1414b.henrich@debian.or.jp> <20071210231814.cd839986.henrich@debian.or.jp> <200712110452.lBB4qfNc032353@www262.sakura.ne.jp> <20071222001429.70249147.henrich@debian.or.jp> Message-ID: <200712221142.BDD82325.tPPEPPSNFWGNtZU@I-love.SAKURA.ne.jp> 　熊猫です。 > 　やまねです。 > 　ここ暫く不調な上に仕事の方が色々重なってほとんど作業してませんが、 > 　とりあえず、経過報告を。 ありがとうございます。 年末年始の忙しい時ですので無理しないでくださいね。 > > クリスマスまで待てば testing から取り出せるようになるということですね。 > > 　そのあと 1.5.2 への更新をしたので、クリスマス後ですね。 > 　http://packages.qa.debian.org/c/ccstools.html なるほど。了解です。 kernel-patch-tomoyo の方には２つほど要望が出ているようですね。 http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=src&data=kernel-patch-tomoyo&pend-exc=fixed&pend-exc=done > 　あと、Ubuntu にも取り込まれてました。sync したのが少し前の様です。 > 　http://packages.ubuntu.com/hardy/admin/tomoyo-ccstools おぉ！ > > 　現在 Lenny のカーネルは 2.6.22-2 のようですが > > http://bjorn.haxx.se/debian/testing.pl?package=linux-source-2.6.23 によると > > もうじき apt-get dist-upgrade すると 2.6.23-1 がインストールされるようになるのでしょうか？ > > 　もうじきかもしれませんが、まだですね。 > 　2.6.23 は明示的に入れる必要があるかと。 今見たら candidate is 0 days old になっていたので年が明けてからですね。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat Dec 22 16:52:13 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 22 Dec 2007 16:52:13 +0900 Subject: [Tomoyo-dev 746] Re: TOMOYO Linux security goal In-Reply-To: <476B1796.1000501@nttdata.co.jp> References: <200712170013.lBH0DgVu094600@www262.sakura.ne.jp> <20071217140007.DA99.YNAKAM@hitachisoft.jp> <200712170549.lBH5nhqr059341@www262.sakura.ne.jp> <200712210023.lBL0NrkH042730@www262.sakura.ne.jp> <476B1796.1000501@nttdata.co.jp> Message-ID: <200712221652.JJE56214.SZPtUNPGNWPEtFP@I-love.SAKURA.ne.jp> 　熊猫です。 　Security Goal ですが、 TOMOYO Linux でできることを列挙するという 方向に変更しようかと思います。以下に思いつくままに列挙してみましたが、 コメントや列挙漏れなどありますでしょうか？ ---------- <<< What can you do with TOMOYO Linux? >>> Create policy from scratch. You want to use ready-made policy files supplied by somebody else because testing all paths needed for your usage sounds boring? OK, then you can choose other implementations that provide ready-made policy files, but you should check whether these files contain enough permissions for your usage or not. It is inevitable thing to test all paths needed for your usage if you want to use white listing access control. Also, ready-made policy files tend to contain redundant permissions for your usage which often leads to serious problem. TOMOYO Linux is a DIY tool for understanding and protecting your Linux box. TOMOYO Linux's "learning mode" will automatically generate policy files with necessary and sufficient permissions for you. Understand all possible requests. TOMOYO Linux reports what is happening within your Linux box. You can have the security of knowing that no unexpected requests arise, if you have tested all paths needed for your usage. Please remember, I'm not saying that "You can have the security of knowing that no unexpected results happen". Although TOMOYO Linux attempts to filter the request as hard as possible, TOMOYO Linux can't guarantee the result. Analyze system's behavior. TOMOYO Linux resembles to /usr/bin/strace . TOMOYO Linux reports what programs are executed from each program and what files/networks are accessed by each program. You can use TOMOYO Linux for analyzing application's behavior if you want to know "which configuration file does this daemon read?", "what port numbers does this daemon require?" and so on. This helps debugging program's behaviors and writing manuals. TOMOYO Linux is also applicable for educational use. Provide per application firewall. It is userland applications' businesses to perform pathname based access control, but they sometimes make mistakes which are known as OS command injection vulnerability or buffer overflow vulnerability. TOMOYO Linux assists this access control in kernel space to reduce the damage by restricting pathnames which each application can request. TOMOYO Linux can perform TCP_Wrapper-like simple stateless TCP/IP packet filtering based on IPv4/v6 address and ports. TOMOYO Linux can restrict the list of environment variable's name passed to execve() so that some dangerous environment variable (e.g. LD_PRELOAD) won't be passed freely. TOMOYO Linux also supports conditional permissions. You can use uid/gid etc. of a process to restrict the combination of user and accessible resources. Provide support for multi-call binary applications without patches. A multi-call binary (e.g. /sbin/busybox) changes behaviors according to the invocation name (in other words, argv[0] passed to execve()). Users specify the invocation name using symbolic links or hard links. TOMOYO Linux allows administrators to give execute permission and define PIH using the pathname of a symbolic link, if the combination of the pathname of a symbolic link and the pathname of the entity pointed by the symbolic link is registered in the policy file. You can use symbolic links as if they are hard links. TOMOYO Linux supports restricting the combination of path-to-executable-or-symbolic-link and basename-of-argv[0] so that users can't pass different argv[0] from path-to-executable-or-symbolic-link freely. Please remember, I'm not saying that "TOMOYO Linux can control all multi-call binary programs' behaviors" because some multi-call binary programs support overriding the default behavior determined by the basename of argv[0] using rest of command line parameters (i.e. argv[1] to argv[argc - 1]). If TOMOYO Linux attempts to restrict all argv[] elements passed to execve(), the system will become too inconvenient and frustrating to use. Give different set of permissions to the same application. There are some non-executable applications (e.g. Java's class files). Such applications use the same program for executing (e.g. Java Runtime Environment). Since TOMOYO Linux has PIH, you can give different set of permissions for each application by separating PIH for each application. Since I'm not a software distributor, it is too hard to maintain patches for utilizing TOMOYO Linux specific expansion. Therefore, I'm not providing APIs to switch context like AppArmor's change_hat()/change_profile() for now. I'd like to introduce APIs to switch context when distributors get ready to support TOMOYO Linux specific extension (in other words, after TOMOYO Linux is merged into mainline). Provide DMZ for remote logins. Recently, password brute-force attacks against SSH service are increasing. But TOMOYO Linux's PIH can provide a room for deploying DMZ. Why password or public-key authentication is possible for only once? Why not give normal users a chance to beat back attackers who logged in through brute force attacks? You can deploy extra login authentications that the only normal user knows how to pass. Provide simple RBAC-like administrative task division. TOMOYO Linux's PIH forms a tree structure. This means that you can split one tree into several subtrees and associate each subtree with each administrative task. You can give each subtree necessary and sufficient permissions for each administrative task. You can deploy custom authentication at the entry point of each subtree so that one administrator cannot proceed to other administrator's subtrees. And more... (Your imagination makes new usage.) From hitoht ＠ gmail.com Sat Dec 22 18:43:55 2007 From: hitoht ＠ gmail.com (hito) Date: Sat, 22 Dec 2007 18:43:55 +0900 Subject: [Tomoyo-dev 747] Re: =?iso-2022-jp?b?MS41LjEgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <200712221142.BDD82325.tPPEPPSNFWGNtZU@I-love.SAKURA.ne.jp> References: <200712062136.DBC09309.PZPPENtGPFUWNtS@I-love.SAKURA.ne.jp> <20071206222347.b5d1414b.henrich@debian.or.jp> <20071210231814.cd839986.henrich@debian.or.jp> <200712110452.lBB4qfNc032353@www262.sakura.ne.jp> <20071222001429.70249147.henrich@debian.or.jp> <200712221142.BDD82325.tPPEPPSNFWGNtZU@I-love.SAKURA.ne.jp> Message-ID: <9292c1390712220143l654d4777od755b38ee342971a@mail.gmail.com> > > 　あと、Ubuntu にも取り込まれてました。sync したのが少し前の様です。 > > 　http://packages.ubuntu.com/hardy/admin/tomoyo-ccstools > おぉ！ しかし、案の定Kernel側への反映はないのであった。使えないぢゃんっorz えーと、しばらくしたら本家にチャレンジするので、もうちょっとお待ちください。 あと、linux-image更新に伴う新しいバイナリもちょびっとお待ちください。 From henrich ＠ debian.or.jp Tue Dec 25 01:31:02 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Tue, 25 Dec 2007 01:31:02 +0900 Subject: [Tomoyo-dev 748] Re: =?iso-2022-jp?b?MS41LjEgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <9292c1390712220143l654d4777od755b38ee342971a@mail.gmail.com> References: <200712062136.DBC09309.PZPPENtGPFUWNtS@I-love.SAKURA.ne.jp> <20071206222347.b5d1414b.henrich@debian.or.jp> <20071210231814.cd839986.henrich@debian.or.jp> <200712110452.lBB4qfNc032353@www262.sakura.ne.jp> <20071222001429.70249147.henrich@debian.or.jp> <200712221142.BDD82325.tPPEPPSNFWGNtZU@I-love.SAKURA.ne.jp> <9292c1390712220143l654d4777od755b38ee342971a@mail.gmail.com> Message-ID: <20071225013102.7080997b.henrich@debian.or.jp> On Sat, 22 Dec 2007 18:43:55 +0900 hito wrote: > > > 　あと、Ubuntu にも取り込まれてました。sync したのが少し前の様です。 > > > 　http://packages.ubuntu.com/hardy/admin/tomoyo-ccstools > > おぉ！ > > しかし、案の定Kernel側への反映はないのであった。使えないぢゃんっorz 　http://packages.ubuntu.com/hardy/devel/kernel-patch-tomoyo 　にもあるようです。 From takedakn ＠ nttdata.co.jp Tue Dec 25 16:22:42 2007 From: takedakn ＠ nttdata.co.jp (Kentaro Takeda) Date: Tue, 25 Dec 2007 16:22:42 +0900 Subject: [Tomoyo-dev 749] =?iso-2022-jp?b?GyRCJWwlXSU4JUglaiRYJE48aCRqOX4kXyROOD0+dSRLGyhC?= =?iso-2022-jp?b?GyRCJEQkJCRGGyhC?= Message-ID: <4770AFC2.10100@nttdata.co.jp> 武田です。 主にやまねさん、hitoさんにご協力いただいた結果、 いくつかのレポジトリにTOMOYO関連のパッケージが入ってきています。 大変喜ばしい限りです。X-D 現状を調べて1つの表にまとめてみました。 添付ファイルの.xlsファイルをご参照ください。 バグや追加、変更などありましたら宜しくお願いいたします。 徐々に手をつけてはいますが、一通り状況が落ち着いたら、 利用手順としてレポジトリの参照方法をまとめたいと思っています。 -- 武田健太郎 (Kentaro Takeda) takedakn ＠ nttdata.co.jp 株式会社NTTデータ 技術開発本部 SIアーキテクチャ開発センタ -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: tomoyo-packages.xls 型: application/vnd.ms-excel サイズ: 30208 バイト 説明: 無し URL: http://lists.sourceforge.jp/mailman/archives/tomoyo-dev/attachments/20071225/cefb5f82/attachment.xls From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Tue Dec 25 21:48:30 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Tue, 25 Dec 2007 21:48:30 +0900 Subject: [Tomoyo-dev 750] Re: TOMOYO Linux security goal In-Reply-To: <200712221652.JJE56214.SZPtUNPGNWPEtFP@I-love.SAKURA.ne.jp> References: <20071217140007.DA99.YNAKAM@hitachisoft.jp> <200712170549.lBH5nhqr059341@www262.sakura.ne.jp> <200712210023.lBL0NrkH042730@www262.sakura.ne.jp> <476B1796.1000501@nttdata.co.jp> <200712221652.JJE56214.SZPtUNPGNWPEtFP@I-love.SAKURA.ne.jp> Message-ID: <200712252148.FIE09327.PPGtUNEtZWFPNSP@I-love.SAKURA.ne.jp> 　熊猫です。 　投稿しました。お疲れ様でした。 http://lkml.org/lkml/2007/12/25/18 　一足先に投稿された AppArmor のスレッドは完全にスルーされていますね。 この時期にソースを投げてもコメントが付きそうにないので、今回はこれだけです。 年が明けてからパッチを投げたいと思います。 　余談ですが、ページの上の方に [forward] というリンクがあるのに気がつきました。 これをクリックすると、指定したメールアドレス宛てにメッセージを転送してくれます。 熊猫は lkml を Daily Digest モードで購読しているので Cc: してくれないと 個々の投稿の References: を抽出することができず、こちらから返信できないという状況でした。 しかし、このリンク経由で References: を抽出できるようになったので、 Cc: してくれなかった場合でも返信できるようになったわけです。