From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Tue Apr 1 21:21:28 2008 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Tue, 1 Apr 2008 21:21:28 +0900 Subject: [Tomoyo-dev 780] =?iso-2022-jp?b?MS42LjAgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4kORsoQg==?= Message-ID: <200804012121.HHI23184.SNtFNtPPEPZWPGU@I-love.SAKURA.ne.jp> 　熊猫です。 　Wiki のコンパイル手順を更新したので 1.6.0 のコンパイルを始めたいと思います。 よろしくお願いします。 http://tomoyo.sourceforge.jp/wiki/?HowToMakeKernelPackage Debian Etch 以外はコピー＆ペーストで作成可能なシェルスクリプトにできましたが、 Etch は Sarge と同じ手順ではうまくいきませんでした。 Lenny ではどういう手順でコンパイルしているのでしょうか？＞やまねさん [TOMOYO-dev 777] の件、 mandriva.org の Thomas Backlund さんが TOMOYO パッチとツールを作成されたようですね。 LKML にも投稿されている方なので、 TOMOYO のスレッドも 読んでいただけているのかもしれません。 From henrich ＠ debian.or.jp Sat Apr 5 12:27:40 2008 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Sat, 5 Apr 2008 12:27:40 +0900 Subject: [Tomoyo-dev 781] Re: =?iso-2022-jp?b?MS42LjAgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <200804012121.HHI23184.SNtFNtPPEPZWPGU@I-love.SAKURA.ne.jp> References: <200804012121.HHI23184.SNtFNtPPEPZWPGU@I-love.SAKURA.ne.jp> Message-ID: <20080405122740.c2cc3760.henrich@debian.or.jp> On Tue, 1 Apr 2008 21:21:28 +0900 Tetsuo Handa wrote: > 　Wiki のコンパイル手順を更新したので > 1.6.0 のコンパイルを始めたいと思います。 > よろしくお願いします。 　ccstools ですが、README.ccs COPYING.ccs　を /usr/lib/ccs にコピー 　しているのはなぜでしょう？ドキュメント系ファイルなら /usr/share/doc/ 　じゃないですか？ 　配布時に同梱がしてある必要はあると思いますが、インストールされる 　必要はないのではないかと＞COPYING.ccs 　 > Debian Etch 以外はコピー＆ペーストで作成可能なシェルスクリプトにできましたが、 > Etch は Sarge と同じ手順ではうまくいきませんでした。 > Lenny ではどういう手順でコンパイルしているのでしょうか？＞やまねさん 　すいません、ここしばらくはOSCやら仕事やら他の作業やら旅行やらで 　kernel compile してません。 　Lenny は使ってないのですが (sid が常用環境なので）、やり方的には $ sudo aptitude install linux-source-2.6.24 linux-patch-tomoyo $ tar xjf /usr/src/linux-source-2.6.24.tar.bz2 $ cd linux-source-2.6.24/ $ fakeroot make-kpkg --added_patches tomoyo --initrd --revision 1.6.0.ccs --append_to_version ccs kernel_image 　こんな感じで build できます（オプションは適当）。 　必要なのは --added_patches tomoyo の指定と最後に作るターゲット kernel_image 　ですね。 　ただ、tomoyo 回りの config の確認をされますね。デフォルト値をそのまま 　使ってくれないかな？ From nao.aota ＠ gmail.com Sun Apr 6 21:55:31 2008 From: nao.aota ＠ gmail.com (Naohiro Aota) Date: Sun, 06 Apr 2008 21:55:31 +0900 Subject: [Tomoyo-dev 782] =?iso-2022-jp?b?GyRCJUYlOSU/ITw7MjJDNHVLPhsoQg==?= Message-ID: <87ve2v6t30.fsf@gmail.com> TOMOYO-dev のほうでははじめましての青田(SF.jp のアカウントは nawota)です。 SELinux を覚えないとなぁ、でも難しいなぁ、と悩んでいるうちに簡単に自力で 整備できる TOMOYO に出会い、そのわかりやすさ(とその名前 ;-))にひかれてい るうちにGentoo 用のパッケージまで作っていました。TOMOYO-users のほうでも 書いた通り、今 Gentoo 用のパッケージを置いている場所があまりよい状態とは 言えないため、 Gentoo で TOMOYO を使っている方々によりよいパッケージを提 供する場所を TOMOYO のスペースをお借りして設置したいと思い参加を希望した 次第です。 今のところパッケージしか作れそうにないですが、そのうち他のところでも貢献 できたらと思っております。 # とは言ってもカーネルは全くわからないので、 ccs-editpolicy なんかの身近 # なところを狙っています :-) -- 青田 From haradats ＠ gmail.com Sun Apr 6 22:03:11 2008 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Sun, 6 Apr 2008 22:03:11 +0900 Subject: [Tomoyo-dev 783] Re: =?iso-2022-jp?b?GyRCJUYlOSU/ITw7MjJDNHVLPhsoQg==?= In-Reply-To: <87ve2v6t30.fsf@gmail.com> References: <87ve2v6t30.fsf@gmail.com> Message-ID: <9d732d950804060603l1cd41c06hc4e2f5bf0e602fc3@mail.gmail.com> 青田様、 原田です。tomoyo-devへようこそ。 このメールを送信する前にSF.jpのtomoyoプロジェクトに 開発者としてメンバー登録を行いました。 Gentooのパッケージの作成、配布場所等については、 プロジェクトのリリース管理者である半田さん、武田君と 調整ください。 どうぞよろしくお願いいたします。 08/04/06 に Naohiro Aota さんは書きました: > TOMOYO-dev のほうでははじめましての青田(SF.jp のアカウントは nawota)です。 > > SELinux を覚えないとなぁ、でも難しいなぁ、と悩んでいるうちに簡単に自力で > 整備できる TOMOYO に出会い、そのわかりやすさ(とその名前 ;-))にひかれてい > るうちにGentoo 用のパッケージまで作っていました。TOMOYO-users のほうでも > 書いた通り、今 Gentoo 用のパッケージを置いている場所があまりよい状態とは > 言えないため、 Gentoo で TOMOYO を使っている方々によりよいパッケージを提 > 供する場所を TOMOYO のスペースをお借りして設置したいと思い参加を希望した > 次第です。 > > 今のところパッケージしか作れそうにないですが、そのうち他のところでも貢献 > できたらと思っております。 > > # とは言ってもカーネルは全くわからないので、 ccs-editpolicy なんかの身近 > # なところを狙っています :-) -- Toshiharu Harada haradats ＠ gmail.com From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Tue Apr 8 22:05:49 2008 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Tue, 8 Apr 2008 22:05:49 +0900 Subject: [Tomoyo-dev 784] Re: =?iso-2022-jp?b?GyRCJUYlOSU/ITw7MjJDNHVLPhsoQg==?= In-Reply-To: <87ve2v6t30.fsf@gmail.com> References: <87ve2v6t30.fsf@gmail.com> Message-ID: <200804082205.IDJ90173.ttWSUNPPNEFZPPG@I-love.SAKURA.ne.jp> 　熊猫です。 　tomoyo-dev へようこそ。＞青田さん > 言えないため、 Gentoo で TOMOYO を使っている方々によりよいパッケージを提 > 供する場所を TOMOYO のスペースをお借りして設置したいと思い参加を希望した > 次第です。 場所としては、 http://tomoyo.sourceforge.jp/repos/gentoo/ みたいなディレクトリを 作ることになるかと思います。 また、管理するには subversion を使いますが、 ssh で shell.sourceforge.jp に ログインできるように公開鍵を登録する必要があります。まずは http://sourceforge.jp/projects/sourceforge/document/how_to_use_subversion にあるとおり、 sourceforge.jp にログインしてからアカウント管理画面へ行って ssh 公開鍵を登録してください。登録してから数分待つと、 ssh を使って shell.sourceforge.jp に ログインすることができるようになります。 $ ssh shell.sourceforge.jp Enter passphrase for key '/home/ユーザ名/.ssh/鍵ファイル名': ログインできれば次は subversion 環境の構築です。 以下はその手順ですが、その前にディレクトリ名を決めて作成しなければいけませんので とりあえずご希望のディレクトリ名と ssh ログインできるまでの設定をお願いします。 熊猫の場合は kumaneko ユーザとしてログインして ~/SVN というディレクトリを作成後、 ~/SVN/ というディレクトリに移動してから $ svn checkout svn+ssh://svn.sourceforge.jp/svnroot/tomoyo というコマンドを実行することで subversion 環境を作りました。 gentoo 向け ebuid の管理だけなら全体を同期させる必要はないので、 $ svn checkout svn+ssh://svn.sourceforge.jp/svnroot/tomoyo/tags/htdocs/repos/gentoo みたいに必要な部分だけを取り出すことで、トラフィックを減らすことができます。 From nao.aota ＠ gmail.com Thu Apr 10 22:22:46 2008 From: nao.aota ＠ gmail.com (Naohiro Aota) Date: Thu, 10 Apr 2008 22:22:46 +0900 Subject: [Tomoyo-dev 785] Re: =?iso-2022-jp?b?GyRCJUYlOSU/ITw7MjJDNHVLPhsoQg==?= In-Reply-To: <200804082205.IDJ90173.ttWSUNPPNEFZPPG@I-love.SAKURA.ne.jp> (Tetsuo Handa's message of "Tue, 8 Apr 2008 22:05:49 +0900") References: <87ve2v6t30.fsf@gmail.com> <200804082205.IDJ90173.ttWSUNPPNEFZPPG@I-love.SAKURA.ne.jp> Message-ID: <87abk17sk9.fsf@gmail.com> 返信遅れましてすみません。 svn+ssh://nawota ＠ svn.sourceforge.jp/svnroot/tomoyo/trunk を checkout で きることまで確認しました。 Tetsuo Handa writes: >> 言えないため、 Gentoo で TOMOYO を使っている方々によりよいパッケージを提 >> 供する場所を TOMOYO のスペースをお借りして設置したいと思い参加を希望した >> 次第です。 > > 場所としては、 http://tomoyo.sourceforge.jp/repos/gentoo/ みたいなディレクトリを > 作ることになるかと思います。 > > また、管理するには subversion を使いますが、 ssh で shell.sourceforge.jp に > ログインできるように公開鍵を登録する必要があります。まずは > http://sourceforge.jp/projects/sourceforge/document/how_to_use_subversion > にあるとおり、 sourceforge.jp にログインしてからアカウント管理画面へ行って > ssh 公開鍵を登録してください。登録してから数分待つと、 ssh を使って shell.sourceforge.jp に > ログインすることができるようになります。 > > $ ssh shell.sourceforge.jp > Enter passphrase for key '/home/ユーザ名/.ssh/鍵ファイル名': > > ログインできれば次は subversion 環境の構築です。 > 以下はその手順ですが、その前にディレクトリ名を決めて作成しなければいけませんので > とりあえずご希望のディレクトリ名と ssh ログインできるまでの設定をお願いします。 ディレクトリ名は、 gentoo-overlay あるいは、長過ぎるようでしたら gentoo でいかがでしょうか。 -- 青田 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat Apr 12 22:55:28 2008 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 12 Apr 2008 22:55:28 +0900 Subject: [Tomoyo-dev 786] Re: =?iso-2022-jp?b?GyRCJUYlOSU/ITw7MjJDNHVLPhsoQg==?= In-Reply-To: <87abk17sk9.fsf@gmail.com> References: <87ve2v6t30.fsf@gmail.com> <200804082205.IDJ90173.ttWSUNPPNEFZPPG@I-love.SAKURA.ne.jp> <87abk17sk9.fsf@gmail.com> Message-ID: <200804122255.DHD51012.FtNWPGNZUSEPPtP@I-love.SAKURA.ne.jp> 　熊猫です。 > svn+ssh://nawota ＠ svn.sourceforge.jp/svnroot/tomoyo/trunk を checkout で > きることまで確認しました。 　了解です。 > ディレクトリ名は、 gentoo-overlay あるいは、長過ぎるようでしたら gentoo > でいかがでしょうか。 　では、 http://tomoyo.sourceforge.jp/repos/gentoo-overlay/ を作成しましたのでご利用ください。 このディレクトリは svn checkout svn+ssh://nawota ＠ svn.sourceforge.jp/svnroot/tomoyo/tags/htdocs/repos/gentoo-overlay で取得できます。 ファイルの追加は「 svn add ファイル名」で、 レポジトリへの反映は「 svn commit -m "コメント（無くてもＯＫ）" 」でできます。 http://tomoyo.sourceforge.jp/ への反映は cron で行っているので最大１時間後になります。 　よろしくお願いします。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat Apr 12 23:20:04 2008 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 12 Apr 2008 23:20:04 +0900 Subject: [Tomoyo-dev 787] Re: =?iso-2022-jp?b?MS42LjAgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <20080405122740.c2cc3760.henrich@debian.or.jp> References: <200804012121.HHI23184.SNtFNtPPEPZWPGU@I-love.SAKURA.ne.jp> <20080405122740.c2cc3760.henrich@debian.or.jp> Message-ID: <200804122320.DJB26079.PESFUPtPNPWtNGZ@I-love.SAKURA.ne.jp> 　熊猫です。 > 　Lenny は使ってないのですが (sid が常用環境なので）、やり方的には > > $ sudo aptitude install linux-source-2.6.24 linux-patch-tomoyo > $ tar xjf /usr/src/linux-source-2.6.24.tar.bz2 > $ cd linux-source-2.6.24/ > $ fakeroot make-kpkg --added_patches tomoyo --initrd --revision 1.6.0.ccs --append_to_version ccs kernel_image > > 　こんな感じで build できます（オプションは適当）。 > 　必要なのは --added_patches tomoyo の指定と最後に作るターゲット kernel_image > 　ですね。 なるほど。 > 　ただ、tomoyo 回りの config の確認をされますね。デフォルト値をそのまま > 　使ってくれないかな？ config.ccs を .config に追記すればプロンプト表示を抑制できると思います。 .config のコピー元になるファイルが debian/ ディレクトリ内にあるのではないかと思います。 最近は対応ディストリビューションが増えてきたので ccs-patch-\*.tar.gz に含まれる .spec ファイルの占めるサイズも無視できなくなってきました。 ccs-patch-1.6.0-20080401.tar.gz は１ＭＢ近くあります。 なので、 .spec ファイルを同梱するのではなく http://tomoyo.sourceforge.jp/wiki/?HowToMakeKernelPackage にあるスクリプトのように deb パッケージに関してはカーネルをビルドするためのスクリプトを、 rpm パッケージに関しては .src.rpm に含まれる .spec ファイルにパッチを当てて カーネルをビルドするためのスクリプトを同梱する方が良いのではないかと思っています。 patch コマンドはパッチファイルの中に含まれる”パッチではない行を無視する”という性質を持っているので、 ccs-patch-\*.diff を #! /bin/sh で始まるシェルスクリプトにしてしまい、 patch -p0 < $0 で 適用するなんていう方法も可能なので、ビルドスクリプトとパッチを一体化させることも技術的には可能ですが ・・・ちょっと奇妙な使い方ですかね。 来週は原田さんと武田さんが ELC2008 に参加するためサンフランシスコへ出張します。 戻ってくるまでにはカーネル 2.6.25 もリリースされているでしょうから、戻ってきてから TOMOYO Linux 1.5.4 および 1.6.1 としてリリースしたいと思います。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat Apr 12 23:31:14 2008 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 12 Apr 2008 23:31:14 +0900 Subject: [Tomoyo-dev 788] Re: =?iso-2022-jp?b?MS42LjAgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <20080405122740.c2cc3760.henrich@debian.or.jp> References: <200804012121.HHI23184.SNtFNtPPEPZWPGU@I-love.SAKURA.ne.jp> <20080405122740.c2cc3760.henrich@debian.or.jp> Message-ID: <200804122331.BID78176.WtPPPUStNZGNEPF@I-love.SAKURA.ne.jp> 　熊猫です。 > 　配布時に同梱がしてある必要はあると思いますが、インストールされる > 　必要はないのではないかと＞COPYING.ccs ccs-tools-\*.rpm / ccs-tools-\*.deb でインストールするときに COPYING.ccs をコピーする必要は無いのでしょうか？ > 　ccstools ですが、README.ccs COPYING.ccs　を /usr/lib/ccs にコピー > 　しているのはなぜでしょう？ドキュメント系ファイルなら /usr/share/doc/ > 　じゃないですか？ COPYING.ccs をコピーする必要が無いとしたら、 COPYING.ccs と README.ccs を 置くためだけに /usr/share/doc/tomoyo/ ディレクトリを作成するのは変な気がします。 オフライン向けドキュメントの内容が充実してから /usr/share/doc/tomoyo/ ディレクトリを作成すれば良いと思います。 From henrich ＠ debian.or.jp Sun Apr 13 19:23:54 2008 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Sun, 13 Apr 2008 19:23:54 +0900 Subject: [Tomoyo-dev 789] Re: =?iso-2022-jp?b?MS42LjAgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <200804122331.BID78176.WtPPPUStNZGNEPF@I-love.SAKURA.ne.jp> References: <200804012121.HHI23184.SNtFNtPPEPZWPGU@I-love.SAKURA.ne.jp> <20080405122740.c2cc3760.henrich@debian.or.jp> <200804122331.BID78176.WtPPPUStNZGNEPF@I-love.SAKURA.ne.jp> Message-ID: <20080413192354.53f74f0c.henrich@debian.or.jp> On Sat, 12 Apr 2008 23:31:14 +0900 Tetsuo Handa wrote: > COPYING.ccs をコピーする必要が無いとしたら、 COPYING.ccs と README.ccs を > 置くためだけに /usr/share/doc/tomoyo/ ディレクトリを作成するのは変な気がします。 　Debian パッケージの changelog.Debian.gz と copyright ファイルが 　置かれる必要があります。COPYING.ccs の内容は copyright ファイル 　がカバーします。 -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp From haradats ＠ gmail.com Sun Apr 20 15:39:48 2008 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Sat, 19 Apr 2008 23:39:48 -0700 Subject: [Tomoyo-dev 790] LWN.net "TOMOYO Linux and pathanme-based security" by Jonathan Corbert Message-ID: <9d732d950804192339t683eceeewbba83f9dfb8a77c8@mail.gmail.com> 原田です。こんにちは。 ELC2008に参加していた2008/4/14にLWN.netにJonathanの書いた件名の タイトルを持つ記事が掲載されました。TOMOYO Linuxのメインライン化に 深い影響を持つためここに日本語訳をつけて紹介します。 オリジナルの記事は、下記で参照できます。1つめのリンクが開けない場合は 2つめで参照ください。この記事を書いたJonathanはTOMOYO Linuxの 最初の海外での発表になったELC2007でTOMOYO Linuxの発表を聞きに きてくれました。今もそのときの驚きを覚えています。今回この記事を 日本語に訳してみて、単なるレポート以上のもの、期待を感じました。 その期待に応えたいと思います。 http://lwn.net/Articles/277833/ http://lwn.net/SubscriberLink/277833/20faea932562b2aa/ -- 8< -- 8< -- "TOMOYO Linux and pathanme-based security" by Jonathan Corbert 「TOMOYO Linuxとpaname方式のセキュリティ」 It takes a certain kind of courage to head down a road when one can plainly see the unpleasant fate which befell those who went before. So one might think that the fate of AppArmor would deter others from following a similar path. The developers of TOMOYO Linux(*1) are not easily put off, though. Despite having a security subsystem which shares a number of features with AppArmor, these developers are pushing forward in an attempt to get their code into the mainline. かつて同じ道を歩んだものが不愉快な結末を迎えているとき、その同じ道を歩むことには ある種の勇気が必要だ。だから、AppArmorの件はあとで同じ道を歩もうとするものを 思いとどませるだろうと考えただろう。しかし、TOMOYO Linuxの開発者達は簡単には 追い払えない。AppArmorと共通する多くの機能を持つセキュリティサブシステムで あるにもかかわらず、彼らは自分たちのコードをメインラインにいれようとしている。 AppArmor, remember, is a Linux security module which uses pathnames to make security decisions. So it is entirely conceivable that two different security policies could apply to the same file if that file is accessed by way of two different names. This approach helps make AppArmor easier to administer than SELinux, but it has given AppArmor major problems in the review process for a few reasons: AppArmorについて思い出してみよう。それは、pathnameを要素としてセキュリティの 判断を行うLinuxのセキュリティモジュールだ。容易に思いつくことは、2つ（以上）の 「名前」によりアクセスされるファイルについては、2つ（以上）の異なるセキュリティ ポリシーが適用されることだ。pathnameを用いるというアプローチはAppArmorを SELinuxより容易に習熟できるものにすることに貢献しているが、コードのレビュー時に いくつかの重要な（方式上の）問題点を指摘されている。 There has been strong resistance to the addition of any new security modules at all, to the point that proposals to remove the LSM framework altogether have been floated. そもそも新しいセキュリティモジュールの追加自体について強い抵抗が存在し続け、 LSMフレークワークを取り除いてしまうという提案すら行われた。 Some security developers see a pathname-based mechanism as being fundamentally insecure. SELinux developers, in particular, have been very strongly against pathname-based security. To these developers, security policies should apply directly to objects　(or to labels attached directly to objects) rather than to names given to objects. あるセキュリティ関連の開発者達は、pathnameに基づく機構は、根本的に セキュリティ上欠陥があると見ている。その中でもSELinuxの開発者は、 pathnameに基づくセキュリティに非常に強く反対している。彼らにとって、 セキュリティポリシーとは、それらオブジェクトへの「名前」に対してではなく、 オブジェクト（あるいはそれらオブジェクトに割り当てられたラベル）に対して 適用されるべきものだ。 The current Linux security module hooks, not being developed with pathname-based　security in mind, do not provide sufficient information to the low-level file operation hooks.　So AppArmor had to reconstruct pathnames within its security hooks. The method chosen for this reconstruction was, one might say, not universally admired. If the TOMOYO Linux developers are serious about getting their code into the mainline, they will need to have answers to these objections. 現行のLSMのフックは、pathnameの利用について考慮しておらず、pathnameを 用いたセキュリティシステムで必要な低レベルのフックを備えていない。だから、 AppArmorは彼ら自身が提案するパッチの中でそのフックを用意しなければならなかった。 その方法は、どうもあまり評判が良くなかった。もし、TOMOYO Linuxの開発者達が、 本気で彼らのコードをメインラインにいれようとするなら、彼らはこれらの（同じ） 反対に対する答えを持つ必要がある。 As it happens, the first two obstructions have mostly gone away. Casey Schaufler's persistence finally resulted in the merging of the SMACK security module for 2.6.25; it is the only such module, other than SELinux, ever to get into the mainline. Now that SMACK has paved the way, talk of removing the LSM framework (which had been strongly vetoed by Linus in any case) has ended and the next security module should have an easier time of it. 偶然にも最初の2つの障害はほとんど消えてしまった。Casey Schauflerの執念 （的な活動）はついにSMACKを2.6.26のモジュールにマージさせた。それは、 かつてSELinux以外でマージされた唯一のモジュールである。SMACKが道を 開いた以上、LSMフレームワークを取り去るという議論は終わった（いずれにしても それはLinusが強力に否定していたが）。そして次のセキュリティモジュールは SMACKよりはやりやすいだろう。 Linus has also decreed that pathname-based security modules are entirely acceptable for inclusion into the kernel. So, while some developers remain highly skeptical of this approach, their skepticism cannot, on its own, be used as a reason to keep a pathname-based security module out. Pathname-based approaches appear to be "secure enough" for a number of applications, and there are some advantages(*2) to using that approach. Linusはpathnameに基づくセキュリティモジュールをカーネルにいれることは全く 問題ないとの見解を示している。だから、ある開発者達が、pathanmeに基づく セキュリティについて、今も深く懐疑的であったとしてもpathnameであることだけが 採用しない理由にはならない。pathnameに基づくアプローチは、多くの アプリケーションにとっては許容範囲（セキュリティ上問題ない）ことがわかっており、 その方法の利点も存在する。 All of the above is moot, though, if the TOMOYO Linux developers are unable to implement　pathname-based access control in a way which passes muster(*3). The recent TOMOYO Linux　patch took a different approach to this problem: since the LSM hooks do not provide the needed information, the developers just added a new set of hooks, outside of LSM, for use by TOMOYO　Linux. And, while they were at it, they added new hooks at all enforcement points. This was　not a popular decision, to say the least. The whole idea behind LSM was to have a single set of hooks for all security modules; if every module now adds its own set of hooks, that purpose　will have been defeated and the kernel will turn into a big mess of security hooks. Duplicating　the LSM framework is not the way to get a security module into the mainline. しかし、もし、TOMOYO Linuxの開発者達が合格レベルのpathnameに基づく アクセス制御を実装することができなければ、これらすべてのことはまだ議論の 余地がある。最近のTOMOYO Linuxのパッチはここで述べた課題、LSMに 必要なフックがない、について「TOMOYO Linuxがが使うためのフックの セットをLSM以外に作る」という方法をとった。そして、その際にエンフォース （制御）を行う場所に新しいフックを追加した。これは少なくとも あまり一般的に行われる判断ではない。LSMの背後にある考えは、 セキュリティモジュールに対してして単一のフックセットを提供するということだ。 もし、すべてのモジュールが独自のフックを追加したら、LSMの目的は失われ、 セキュリティフックはゴミためのようになる。LSMフレームワークを複数持つことは セキュリティモジュールがメインラインに入るための道ではない。 So, somehow, the TOMOYO Linux developers will need to implement pathname-based security in a different way. The most obvious thing to do would be to modify the existing hooks to supply the requisite information (being a pointer to the vfsmount structure). The problem here is that, at the point where the LSM hooks are called, that structure is not available; it is only used at the higher levels of the virtual filesystem code. So either some core VFS functions would have to be changed (so the vfsmount pointer could be passed into them), or a new set of hooks would need to be placed at a level where that pointer is available. It appears(*4) that the second approach - adding new hooks in the namespace code - will be taken for the next version of the patch. だから、TOMOYO Linuxの開発者達は、なんとかpathnameに基づくセキュリティを違う 方法で実装しなければならない。もっともわかりやすいのは、既存のフックに 必要な情報（vfsmount構造体へのポインタ）を追加することだろう。その場合の問題点は、 LSMフックが呼ばれた場合、その構造体を参照できないことだ。それはファイル システムの仮想化(VFS)の上位でしか使われていない。なので、主要なVFS関数の いくつかを（vfsmountポインターが渡るように）変えるか、あるいはそのポインターが 見えているところに必要なフックを追加するかの方法が考えられる。2つめの アプローチ、namespaceの部分にフックを追加する、が次のパッチで採用されそうだ。 As the TOMOYO Linux developers work through this problem, they are likely to be closely watched by the (somewhat reduced in number) AppArmor group. There appears to be a resurgence of interest in getting AppArmor merged, so we will probably see AppArmor put forward again in the near future. That will be even more likely if TOMOYO Linux is able to solve the pathname problem in a way which survives review and gets into the kernel. TOMOYO Linuxの開発者達がこの問題の解決に取り組んでいる間、彼らは （規模が縮小した）AppArmorのチームからも注意深く見守られるだろう。 AppArmorの復活への興味も見られるから、我々は将来再びAppArmorの提案を 見ることになるかもしれない。それはTOMOYO Linuxがレビューを生き残れる 方法でpathnameの問題を解決し、カーネルに入ればさらに確実となる。 *1 http://elinux.org/TomoyoLinux *2 http://lwn.net/Articles/277842/ *3 http://lwn.net/Articles/276603/ *4 http://lwn.net/Articles/277846/ -- Toshiharu Harada haradats ＠ gmail.com From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sun Apr 20 16:26:59 2008 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 20 Apr 2008 16:26:59 +0900 Subject: [Tomoyo-dev 791] Re: =?iso-2022-jp?b?MS42LjAgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <200804012121.HHI23184.SNtFNtPPEPZWPGU@I-love.SAKURA.ne.jp> References: <200804012121.HHI23184.SNtFNtPPEPZWPGU@I-love.SAKURA.ne.jp> Message-ID: <200804201626.DDH51550.FPUtZPNWtPGNSEP@I-love.SAKURA.ne.jp> 　熊猫です。 バックポートされた関数と衝突してコンパイルエラーになったり 起動時の初期化が遅すぎてカーネルパニックになってしまったりしていた ccs-patch-1.6.0-20080401.tar.gz ですが、現在各ディストリビューション用の バイナリパッケージを作成して「コンパイルエラーが起きないこと」「初期化が 最初のプログラムの実行要求よりも早く行われていること」を確認中です。 現時点で、以下のバイナリパッケージについて確認が完了しました。 Subversion での最新パッチは revision 1117 です。 RHL9 - FC3 - FC4 - FC5 - FC6 - F7 kernel-2.6.23.15-80_tomoyo_1.6.0.fc7.i586.rpm F8 kernel-2.6.24.4-64_tomoyo_1.6.0.fc8.i586.rpm SUSE10.1 kernel-default-2.6.16.54-0.2.5_tomoyo_1.6.0.i586.rpm SUSE10.2 kernel-default-2.6.18.8-0.9_tomoyo_1.6.0.i586.rpm SUSE10.3 kernel-default-2.6.22.17-0.1_tomoyo_1.6.0.i586.rpm CentOS4.6 kernel-smp-2.6.9-67.0.7.EL_tomoyo_1.6.0.i586.rpm CentOS5.1 kernel-2.6.18-53.1.14.el5_tomoyo_1.6.0.i686.rpm AX2 kernel-smp-2.6.9-42.21AX_tomoyo_1.6.0.i686.rpm AX3 kernel-2.6.18-8.16AX_tomoyo_1.6.0.i686.rpm A9-2.4 kernel-2.4.31-a9-3-tomoyo_1.6.0.tar.gz A9-2.6 kernel-2.6.12.3-a9-13-tomoyo_1.6.0.tar.gz Sarge-2.4 kernel-image-2.4.27-4-686-smp-ccs1.6.0_2.4.27-10sarge7_i386.deb Sarge-2.6 kernel-image-2.6.8-4-686-smp-ccs1.6.0_2.6.8-17sarge1_i386.deb Sarge-2.4 kernel-pcmcia-modules-2.4.27-4-686-smp-ccs1.6.0_2.4.27-10sarge7_i386.deb Etch linux-image-2.6.18-18etch1-ccs-i586_1.6.0_i386.deb Lenny - Vine4.2 kernel-2.6.16-0vl76.33_tomoyo_1.6.0.i586.rpm TL10S kernel-smp64G-2.6.8-14.i686.rpm TL11S - Ubuntu6.06 linux-image-2.6.15-51-686-ccs1.6.0_2.6.15-51.66_i386.deb Ubuntu6.06 linux-restricted-modules-2.6.15-51-686-ccs1.6.0_2.6.15.12-51.2_i386.deb Ubuntu6.10 linux-image-2.6.17-12-generic-ccs1.6.0_2.6.17.1-12.44_i386.deb Ubuntu6.10 linux-restricted-modules-2.6.17-12-generic-ccs1.6.0_2.6.17.9-12.4_i386.deb Ubuntu7.04 linux-image-2.6.20-16-generic-ccs1.6.0_2.6.20-16.35_i386.deb Ubuntu7.04 linux-restricted-modules-2.6.20-16-generic-ccs1.6.0_2.6.20.6-16.30_i386.deb Ubuntu7.10 linux-headers-2.6.22-14-ccs1.6.0_2.6.22-14.52_i386.deb Ubuntu7.10 linux-image-2.6.22-14-ccs1.6.0_2.6.22-14.52_i386.deb Ubuntu7.10 linux-ubuntu-modules-2.6.22-14-ccs1.6.0_2.6.22-14.37_i386.deb Gentoo - specs ディレクトリの内容について、 rpm パッケージに関しては ソースのダウンロードから spec ファイルを作成するまでを行うスクリプトで置き換えられました。 http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/1.6.x/ccs-patch/specs/?root=tomoyo また、 deb パッケージに関しては、ソースのダウンロードからコンパイルまでを行うスクリプトが追加されました。 なので、ディレクトリ名はもはや specs ではないかもしれませんね。でも、 scripts ディレクトリだと ソースツリーと衝突してしまうので、変更するとしたら build-scripts または patches/scripts ですかね？ ドキュメントの方は、 http://tomoyo.sourceforge.jp/ja/1.6.x/new-policy-reference.html を http://tomoyo.sourceforge.jp/en/1.6.x/new-policy-reference.html へ反映中です。 反映が完了したら http://tomoyo.sourceforge.jp/ja/1.6.x/policy-reference.html および http://tomoyo.sourceforge.jp/en/1.6.x/policy-reference.html に移動させる予定です。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Wed Apr 23 21:22:55 2008 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Wed, 23 Apr 2008 21:22:55 +0900 Subject: [Tomoyo-dev 792] Re: =?iso-2022-jp?b?MS42LjAgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <200804201626.DDH51550.FPUtZPNWtPGNSEP@I-love.SAKURA.ne.jp> References: <200804012121.HHI23184.SNtFNtPPEPZWPGU@I-love.SAKURA.ne.jp> <200804201626.DDH51550.FPUtZPNWtPGNSEP@I-love.SAKURA.ne.jp> Message-ID: <200804232122.EFG48995.PZtPNtENSGPPWUF@I-love.SAKURA.ne.jp> 　熊猫です。 　Ubuntu 8.04 に対応しました。 コンパイル手順は 7.10 と同じでした。 LiveCD の iso がダウンロードできるようになったら TOMOYO Linux 1.6.0 カーネルで作成予定です。 　new-policy-reference.html の反映が終わったので policy-reference.html をアップデートしました。 　Lenny と Gentoo 以外はバイナリパッケージによる確認ができましたので、 install.html および analysis.html にバイナリパッケージの ダウンロードＵＲＬを追加しました。 gcc 3.2.2 の inline 関数展開時の地雷を踏んでしまったので、 もう１ヶ所修正が入りました。現在のリビジョンは 1132 です。 その他、 ccs-patch-\*.diff を scripts/checkpatch.pl で エラーや警告が出ないようにコーディングスタイルを修正中です。 　あとは、 1st-step のページを更新したら 各所のリンクを 1.5.x → 1.6.x に更新する予定です。 From haradats ＠ nttdata.co.jp Thu Apr 24 18:18:45 2008 From: haradats ＠ nttdata.co.jp (Toshiharu Harada) Date: Thu, 24 Apr 2008 18:18:45 +0900 Subject: [Tomoyo-dev 793] =?iso-2022-jp?b?GyRCJWElJCVzJWklJCVzMj1EczBGJE4lOSVGITwlPyU5GyhC?= Message-ID: <48105075.9070208@nttdata.co.jp> 原田です。 さきほどLKMLに下記の記事を投稿しました。 http://lkml.org/lkml/2008/4/24/24 この記事は、4/4に行った7回目(version 1.6)の投稿の （実質的な）お詫びと8回目の予告になっていますが、 その背景にある意図と狙いについて説明します。 7回目の提案では、あえてLSMを使わない提案をしたわけですが、 案の定？Stephenから即座に「理解できない、どういうつもりだ？」という メール（私信）をもらい、またLKMLのスレッドでも「気持ちは わかるが・・・」と「たしなめられて（この表現がまさに ぴったりな気がします）」います。 しかし、そのことにより「場が動き」ました。 StephenからはこれまでAppArmorもTOMOYOも提案して いなかったLSMへのTOMOYOのためのフックの追加という 方法（「Option 2」）を提案され、LWN.netのJonathanは先日 ご紹介したTOMOYOやpathname-baseのMACを応援していると しか思えない（反論がでにくくなるように書いてくれて いるように思えます）記事を書いていただきました。 http://lwn.net/Articles/277833/ 実は、7回目の提案については、必ずしも自暴自棄で 行ったわけではなく、「独自のフック」についても ちゃんとした狙い、理由がありました。しかし、映画「十戒」 （ちょっと古いですが）で海が割れる有名なシーンを思わせるような この一連の流れを受けて、ここはとりあえず一度謝り、 ・あるべき姿（LSMという標準を乗っ取り、じゃなくて則り）に立ち返り、 ・いただいたコメント（パッチのサイズを小さくする）を反映した上で、 ・ネ申（Stephen様）より授かった方法でパッチを作成し、 ・Jonathan様がまとめてくださった流れに沿ってあきらめず今後も挑戦します 　（決意表明） という投稿なのです（深いですねぇ）。そう思ってもう一度 読んでみてください（笑）。 http://lkml.org/lkml/2008/4/24/24 この後の予定ですが、まず少し（数日）この「進め方」自体に ついての意見、反論がないかを見ます。もしそこで問題がなければ、 あとは、パッチに対するフィードバックを直し続けるだけです。 その意味で今回の投稿への反響は重要なポイントです。 個人的な予想としては、今回はStephen様から提示されたoptionを 採用しているためLSMやSELinux関係者からはコードの内容以外には あまり指摘を受けない（実際熊猫博士によるともともとの内容としても LSMやSELinux的に影響しないところだそうです）と予想しています。 そうすると問題は、VFSやファイルシステム周り、というか 半田さんの宿敵と言われている（私が勝手にそう思っているだけと いう説もあります）"Al Viro"ですが、Option 2はそれらへの 変更（影響）は少ないので、なんとか突破できないかと思っています。 ちなみにAppArmorや今までTOMOYOが提案していた方法は、 Option 1に相当します。TOMOYOとしてはOption 1でも良いのですが、 過去の提案はことごとく反対されるか結論があいまいに なっており、それがOption 2を選択した一番の理由（本音）です。 これまでのメインライン化のあゆみについては、tomoyo-devの 秋元さん(matthew/matthew238)がブログで解説を書いてくださっています。 是非ご覧ください。 http://esashi.mobi/~matthew/wordpress/archives/category/tomoyo-linux/ みじんも楽観はしていませんが、これからやろうとしていることは 少なくとも自分たちだけで考えたことではありません。そこが違いです。 是非今後もご注目ください。 -- 原田季栄 (Toshiharu Harada) haradats ＠ nttdata.co.jp -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: tomoyo-option.png 型: image/png サイズ: 38062 バイト 説明: 無し URL: http://lists.sourceforge.jp/mailman/archives/tomoyo-dev/attachments/20080424/d8885d3f/attachment.png From nao.aota ＠ gmail.com Tue Apr 29 10:48:09 2008 From: nao.aota ＠ gmail.com (Naohiro Aota) Date: Tue, 29 Apr 2008 10:48:09 +0900 Subject: [Tomoyo-dev 794] Creating manager policy on 64bit system Message-ID: <87d4o9qvmu.fsf@gmail.com> 青田です。 また Gentoo 特有の話かもしれませんが 64bit のマシンでは、 /usr/lib が % ls -ld /usr/lib lrwxrwxrwx 1 root root 5 2008-04-22 07:54 /usr/lib -> lib64 というふうに lib64 へのシンボリックリンクになっています。 (32bit 用のライ ブラリと分けるためですね) このために manager.conf が正しく生成されていま せん。以下のように realpath を使えばよりポータブルになるのではないでしょ うか? -- 青田 Index: 1.6.x/ccs-tools/ccstools/init_policy.sh =================================================================== --- 1.6.x/ccs-tools/ccstools/init_policy.sh (リビジョン 1155) +++ 1.6.x/ccs-tools/ccstools/init_policy.sh (作業コピー) @@ -450,12 +450,13 @@ if [ ! -r /etc/ccs/manager.conf ]; then echo Creating manager policy. - echo /usr/lib/ccs/loadpolicy > /etc/ccs/manager.conf - echo /usr/lib/ccs/editpolicy >> /etc/ccs/manager.conf - echo /usr/lib/ccs/setlevel >> /etc/ccs/manager.conf - echo /usr/lib/ccs/setprofile >> /etc/ccs/manager.conf - echo /usr/lib/ccs/ld-watch >> /etc/ccs/manager.conf - echo /usr/lib/ccs/ccs-queryd >> /etc/ccs/manager.conf + ccs_libdir=`realpath /usr/lib/ccs` + echo ${ccs_libdir}/loadpolicy > /etc/ccs/manager.conf + echo ${ccs_libdir}/editpolicy >> /etc/ccs/manager.conf + echo ${ccs_libdir}/setlevel >> /etc/ccs/manager.conf + echo ${ccs_libdir}/setprofile >> /etc/ccs/manager.conf + echo ${ccs_libdir}/ld-watch >> /etc/ccs/manager.conf + echo ${ccs_libdir}/ccs-queryd >> /etc/ccs/manager.conf fi if [ ! -r /etc/ccs/profile.conf ]; then Index: 1.6.x/ccs-tools/ccstools/tomoyo_init_policy.sh =================================================================== --- 1.6.x/ccs-tools/ccstools/tomoyo_init_policy.sh (リビジョン 1155) +++ 1.6.x/ccs-tools/ccstools/tomoyo_init_policy.sh (作業コピー) @@ -449,12 +449,13 @@ if [ ! -r /etc/tomoyo/manager.conf ]; then echo Creating manager policy. - echo /usr/lib/ccs/loadpolicy > /etc/tomoyo/manager.conf - echo /usr/lib/ccs/editpolicy >> /etc/tomoyo/manager.conf - echo /usr/lib/ccs/setlevel >> /etc/tomoyo/manager.conf - echo /usr/lib/ccs/setprofile >> /etc/tomoyo/manager.conf - echo /usr/lib/ccs/ld-watch >> /etc/tomoyo/manager.conf - echo /usr/lib/ccs/ccs-queryd >> /etc/tomoyo/manager.conf + ccs_libdir=`realpath /usr/lib/ccs` + echo ${ccs_libdir}/loadpolicy > /etc/tomoyo/manager.conf + echo ${ccs_libdir}/editpolicy >> /etc/tomoyo/manager.conf + echo ${ccs_libdir}/setlevel >> /etc/tomoyo/manager.conf + echo ${ccs_libdir}/setprofile >> /etc/tomoyo/manager.conf + echo ${ccs_libdir}/ld-watch >> /etc/tomoyo/manager.conf + echo ${ccs_libdir}/ccs-queryd >> /etc/tomoyo/manager.conf fi if [ ! -r /etc/tomoyo/profile.conf ]; then From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Tue Apr 29 11:13:57 2008 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Tue, 29 Apr 2008 11:13:57 +0900 Subject: [Tomoyo-dev 795] Re: Creating manager policy on 64bit system In-Reply-To: <87d4o9qvmu.fsf@gmail.com> References: <87d4o9qvmu.fsf@gmail.com> Message-ID: <200804291113.IED05791.UWPEFPStZGPNNtP@I-love.SAKURA.ne.jp> 　熊猫です。 > また Gentoo 特有の話かもしれませんが 64bit のマシンでは、 /usr/lib が > > % ls -ld /usr/lib > lrwxrwxrwx 1 root root 5 2008-04-22 07:54 /usr/lib -> lib64 > > というふうに lib64 へのシンボリックリンクになっています。 (32bit 用のライ > ブラリと分けるためですね) このために manager.conf が正しく生成されていま > せん。以下のように realpath を使えばよりポータブルになるのではないでしょ > うか? 　情報提供ありがとうございます。 /usr/lib が /usr/lib32 または /usr/lib64 を指すシンボリックリンクとして存在しているならば 32bit 用のライブラリと分けるために使えますが、 /usr/lib32 が無いのに /usr/lib64 だけがあるとしたら 分けられないような気がしますが・・・。それはともかく、 ccs-tools の make install 時に /usr/lib64 にインストールされてしまう以上、 realpath で判断する必要がありますね。 反映しておきました。 From nao.aota ＠ gmail.com Tue Apr 29 19:40:19 2008 From: nao.aota ＠ gmail.com (Naohiro Aota) Date: Tue, 29 Apr 2008 19:40:19 +0900 Subject: [Tomoyo-dev 796] Re: Creating manager policy on 64bit system In-Reply-To: <200804291113.IED05791.UWPEFPStZGPNNtP@I-love.SAKURA.ne.jp> (Tetsuo Handa's message of "Tue, 29 Apr 2008 11:13:57 +0900") References: <87d4o9qvmu.fsf@gmail.com> <200804291113.IED05791.UWPEFPStZGPNNtP@I-love.SAKURA.ne.jp> Message-ID: <878wyxq6zw.fsf@gmail.com> Tetsuo Handa writes: >> また Gentoo 特有の話かもしれませんが 64bit のマシンでは、 /usr/lib が >> >> % ls -ld /usr/lib >> lrwxrwxrwx 1 root root 5 2008-04-22 07:54 /usr/lib -> lib64 >> >> というふうに lib64 へのシンボリックリンクになっています。 (32bit 用のライ >> ブラリと分けるためですね) このために manager.conf が正しく生成されていま >> せん。以下のように realpath を使えばよりポータブルになるのではないでしょ >> うか? > > 　情報提供ありがとうございます。 > /usr/lib が /usr/lib32 または /usr/lib64 を指すシンボリックリンクとして存在しているならば > 32bit 用のライブラリと分けるために使えますが、 /usr/lib32 が無いのに /usr/lib64 だけがあるとしたら > 分けられないような気がしますが・・・。それはともかく、 ccs-tools の make install 時に > /usr/lib64 にインストールされてしまう以上、 realpath で判断する必要がありますね。 > 反映しておきました。 早速の対応ありがとうございます。書いてはいないだけで、もちろん /usr/lib32 も存在していますよ。 ;) -- 青田