From from-tomoyo-users @ I-love.SAKURA.ne.jp Mon Mar 8 00:37:52 2010 From: from-tomoyo-users @ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Mon, 8 Mar 2010 00:37:52 +0900 Subject: [Tomoyo-dev 1224] =?iso-2022-jp?b?VE9NT1lPIExpbnV4IBskQiROGyhCIExvYWRhYmxlIEtlcm5l?= =?iso-2022-jp?b?bCBNb2R1bGUgGyRCMj0kSyREJCQkRhsoQg==?= Message-ID: <201003080037.BCC35444.ZUtPSPVFNPTtSGNPT@I-love.SAKURA.ne.jp>  熊猫です。  組込み Linux システムではカーネル本体を置くための専用パーティションが 存在するようで、そのパーティションサイズに納まるようにカーネルコンフィグを調整 する必要があります。 Silicon Linux の CAT760 では、 TOMOYO パッチを当てた場合 カーネル本体が工場出荷時設定のパーティションサイズに納まりきらなくなりました。 もちろん、パーティションサイズを変更することは可能なのですが、ローダブル カーネルモジュールを使えるようなカーネルコンフィグになっているので、 TOMOYO の処理をカーネルモジュール化できないか検討してみました。  TOMOYO の処理を呼び出すためのフックと TOMOYO が必要とする変数や関数にカーネル モジュールからアクセスできるようにするための宣言と /sbin/ccs-init を呼び出す コードだけをカーネル本体に埋め込んでおき、残りはカーネルモジュールとして initramfs または /sbin/ccs-init の中からロードできるようにしようと考えています。 ---------------------------------------- Original: -rw-r--r-- 1 root root 800592 Mar 6 22:00 /boot/vmlinuz-2.6.32.9 -rwxr-xr-x 1 root root 2308884 Mar 6 22:00 vmlinux Patched + Disabled: -rw-r--r-- 1 root root 800624 Mar 6 22:11 /boot/vmlinuz-2.6.32.9 -rwxr-xr-x 1 root root 2308994 Mar 6 22:11 vmlinux Patched + Module: -rw-r--r-- 1 root root 801936 Mar 6 22:14 /boot/vmlinuz-2.6.32.9 -rw-r--r-- 1 root root 134435 Mar 6 22:14 /lib/modules/2.6.32.9/kernel/security/ccsecurity/ccsecurity.ko -rwxr-xr-x 1 root root 2309770 Mar 6 22:14 vmlinux Patched + Built-in: -rw-r--r-- 1 root root 847952 Mar 6 22:16 /boot/vmlinuz-2.6.32.9 -rwxr-xr-x 1 root root 2415359 Mar 6 22:16 vmlinux ---------------------------------------- Original: -rw-r--r-- 1 root root 689061 Mar 7 23:09 /boot/vmlinuz-2.4.37.9 -rwxr-xr-x 1 root root 2038317 Mar 7 23:09 vmlinux Patched + Disabled: -rw-r--r-- 1 root root 689172 Mar 7 23:11 /boot/vmlinuz-2.4.37.9 -rwxr-xr-x 1 root root 2038317 Mar 7 23:11 vmlinux Patched + Module: -rw-r--r-- 1 root root 690157 Mar 7 23:13 /boot/vmlinuz-2.4.37.9 -rw-r--r-- 1 root root 144050 Mar 7 23:13 /lib/modules/2.4.37.9/kernel/security/ccsecurity/ccsecurity.o -rwxr-xr-x 1 root root 2043191 Mar 7 23:13 vmlinux Patched + Built-in: -rw-r--r-- 1 root root 738181 Mar 7 23:14 /boot/vmlinuz-2.4.37.9 -rwxr-xr-x 1 root root 2161366 Mar 7 23:14 vmlinux ----------------------------------------  まだ細かい部分の調整が必要ですが、カーネルモジュール化することにより、圧縮 されたカーネル本体のファイルサイズは約1KBしか増加しないことを確認できました。 ( revision 3501 )  このやり方は LSM が提供する security_ops と同様です。そのため、今までは直接 TOMOYO の処理が呼び出されていたものが、変数を経由して間接的に TOMOYO の処理を 呼び出すようになります。そのため、 (1)オーバーヘッドが若干増える可能性がある (2)関数へのポインタを悪意あるカーネルモジュールにより改ざんされる可能性がある というデメリットがあります。しかし、 (3)カーネル本体のサイズ増加を抑えることができる (4)カーネルコマンドラインで指定することにより TOMOYO の処理を登録させない    ようにすることができる というメリットもあります。  ということで、 1.7.2 では(カーネル本体の再コンパイルが必要という問題は 解決できませんが)カーネルモジュールとして切り離してコンパイルする方法にも 対応しようと思います。もし「カーネルモジュール化に対応されると困る」という方が いらっしゃいましたらお知らせください。反対する人が居なければ 1.7.2 で採用 しようと思います。  また、現在 Debian Squeeze で TOMOYO 2.2 を有効にする話が進んでいます。 最後のネックはカーネル本体のサイズ制限のようです。 http://osdir.com/ml/debian-bugs-dist/2010-02/msg08758.html LSM が提供する security_ops への登録がカーネルモジュールからは行えないように なっているため、使う可能性のある全てのセキュリティモジュールをカーネル本体に 組み込まなければいけない(しかし、全て組み込んでも1個しか有効にできない) という状況が続いています。将来もカーネル本体のサイズがネックになることは十分に 考えられるので、 TOMOYO 2.x についても 1.7.2 の手法で Loadable Kernel Module 化 するパッチを提案したいと思います。果たして LSM-ML の人たちが受け入れてくれるか どうかは不明ですけれど・・・。 From from-tomoyo-users @ I-love.SAKURA.ne.jp Mon Mar 22 10:52:29 2010 From: from-tomoyo-users @ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Mon, 22 Mar 2010 10:52:29 +0900 Subject: [Tomoyo-dev 1225] Re: =?iso-2022-jp?b?W3RvbW95by11c2VycyA3MDldIFJlOlVidW50dSA=?= =?iso-2022-jp?b?GyRCTVEkTiVhJT8lUSVDJTEhPCU4JEgbKEIgQVBUIBskQiVsJV0bKEI=?= =?iso-2022-jp?b?GyRCJTglSCVqJHI6bkAuJDckXiQ3JD8hIxsoQg==?= In-Reply-To: <200912260927.EGD51016.TPNSSttZGNPUVPFTP@I-love.SAKURA.ne.jp> References: <200912252331.BHH95336.ZPPGNTUTttFPVSSPN@I-love.SAKURA.ne.jp> <200912260927.EGD51016.TPNSSttZGNPUVPFTP@I-love.SAKURA.ne.jp> Message-ID: <201003221052.IFE90609.UPFtNNSTPPPZSTVGt@I-love.SAKURA.ne.jp>  熊猫です。 Tetsuo Handa さんは書きました: > YUM レポジトリの場合は、メタ情報ファイルは http://tomoyo.sourceforge.jp/ から、 > パッケージファイルはダウンロードサーバからダウンロードされるように .htaccess を > 使って振り分けをしていました。しかし、 APT レポジトリではそのような振り分けが > できないのです。 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=79002 に > あるように、現時点では apt-get でダウンロードする場合には HTTP 302 応答を > 処理してくれないためです。 > > そこで、 > > (1) http://tomoyo.sourceforge.jp/ に全部置く > >   自由にディレクトリ構成を選べる。 >   Subversion でアップロードできる。 > >   ダウンロードが遅い。 >   Subversion レポジトリが膨張する。 >   ダウンロード件数にカウントできない。 > > (2)ダウンロードサーバに全部置く > >   ダウンロードが速い。 >   HTTPでアップロードできる。 > >   自由にディレクトリ構成を選べない。 >   ダウンロード件数にメタ情報ファイルの件数も含まれてしまうため不正確になる。 >  ↑の「ダウンロード件数にメタ情報ファイルの件数も含まれてしまう」という部分は 間違いでした。ダウンロードサーバ( osdn.dl.sourceforge.jp など)から直接 ダウンロードした場合にはダウンロード件数としてカウントされていませんでした。 http://sourceforge.jp/frs/redir.php を経由してダウンロードした場合のみ カウントされるという仕様のようです。 > (3)第3のサーバに全部置く > >   自由にディレクトリ構成を選べる。 > >   ダウンロード件数にカウントできない。 >   (会社からもアクセスできるように)SSHを使わずにアップロードできる方法が >   必要になる。 > > の何れかを選ぶ必要に迫られ、(2)にしました。  いろいろ実験してみた結果、 tomoyo.sourceforge.jp では Apache の mod_rewrite が利用できるので、   RedirectMatch (.*)/(.*)\.rpm http://sourceforge.jp/frs/redir.php?f=/tomoyo/44403/$2.rpm の代わりに   RewriteEngine On   RewriteRule (.*)\.deb /cgi-bin/download.cgi?f=/tomoyo/45071/$1.deb [L] という内容の .htaccess を用意して、 http://tomoyo.sourceforge.jp/cgi-bin/download.cgi?f=/tomoyo/45071/$1.deb が http://sourceforge.jp/frs/redir.php?f=/tomoyo/45071/$1.deb というリクエストを 発行して、その処理結果を返すようにしてやることにより、 apt-get に対して HTTP 302 応答を返さないようにできることが判明しました。 ( download.cgi のソースは http://sourceforge.jp/projects/tomoyo/svn/view/branches/download.c?view=markup&revision=3523&root=tomoyo です。)  ということで、 download.cgi を使うことで自由にディレクトリ構成を選びながら、 パッケージ本体はダウンロードサーバ上に置くことができるようになりました。 残る問題は、 http://tomoyo.sourceforge.jp/ からのダウンロード速度が 100〜150KB/秒程度までしか出せないという点ですね。せっかくダウンロード サーバからなら数MB/秒が可能なのに、 tomoyo.sourceforge.jp を経由させることが ボトルネックになってしまうのは残念です。 バイナリ rpm/deb パッケージのユーザがどれくらいいるのかは知りたいけれど、 バイナリ deb パッケージのダウンロードが遅くなるのは避けたいです。  サイズの大きいパッケージ本体はダウンロードサーバに、サイズの小さいメタ情報 ファイルは Subversion に置くことができるようになったので、  (1) mod_rewrite が利用可能になっている  (2) download.cgi を動作させることができる  (3) cron で svn update が動作するようになっている  (4) http://tomoyo.sourceforge.jp/ よりも高速にダウンロードできる という条件を満たすことができる第3のサーバが見つかれば全て解決なのですけれど。 From from-tomoyo-users @ I-love.SAKURA.ne.jp Sat Mar 27 01:24:58 2010 From: from-tomoyo-users @ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 27 Mar 2010 01:24:58 +0900 Subject: [Tomoyo-dev 1226] Re: =?iso-2022-jp?b?VE9NT1lPIExpbnV4IDEuNy4xIBskQiROSVQ2cTlnGyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <200912200018.AIB21313.TtNPTUSNPZVPPSGFt@I-love.SAKURA.ne.jp> References: <200912200018.AIB21313.TtNPTUSNPZVPPSGFt@I-love.SAKURA.ne.jp> Message-ID: <201003270124.CHC64593.VTTtPPUPNSZFStNGP@I-love.SAKURA.ne.jp>  熊猫です。 TOMOYO Linux 1.7.0 および 1.7.1 に、 IPv6 アドレスを記憶しておくためのメモリ 割り当て要求が失敗した場合にメモリ破壊が発生する不具合が発見されました。 メモリ破壊が発生するとカーネルクラッシュを引き起こす可能性があります。 この不具合を修正するためのパッチを以下に示します。 --- 1.7.1p2/security/ccsecurity/memory.c +++ 1.7.1p3/security/ccsecurity/memory.c @@ -118,10 +118,11 @@ const struct in6_addr *ccs_get_ipv6_addr atomic_set(&ptr->users, 1); list_add_tail(&ptr->list, &ccs_address_list); entry = NULL; + error = 0; } mutex_unlock(&ccs_policy_lock); kfree(entry); - return ptr ? &ptr->addr : NULL; + return !error ? &ptr->addr : NULL; } /* The list for "struct ccs_name_entry". */ この(セキュリティ上の問題となる)不具合および別の(セキュリティ上の問題には ならない)不具合を修正したものを TOMOYO 1.7.1p3 としてアップロードしました。 http://sourceforge.jp/frs/redir.php?f=/tomoyo/43375/ccs-patch-1.7.1-20100326.tar.gz MD5: 9999f1a70ee5ee3d1a6c6e8e56d0e4b5