Tetsuo Handa
from-****@I-lov*****
2007年 3月 6日 (火) 22:28:05 JST
熊猫です。 > ・プログラム実行時に使われるインタプリタ（スクリプトの場合は > ファイルの先頭行の #! で指定されているプログラム）に対する > アクセス許可のチェックをした方が良いのではないか？ > > →対象となるプログラムは /bin/sh /bin/bash /lib/ld-linux.so.2 /usr/bin/python くらいしか見当たりませんが、 > #! /bin/rm とかいう変な指定をされた場合にそのまま /bin/rm がインタプリタとして使えてしまうのは > （強制アクセス制御によりポリシーで許可されている振る舞い以外はできないけれど）気持ち悪いので、 > （共有ライブラリと同様に）インタプリタについても読み込み権限をチェックするように修正中です。 上記項目の修正が終わりました。 > ・ allow_bind と allow_connect 構文は機能的に allow_network 構文の > サブセットになっており、もはや出番の無い構文なので削除します。 > > ・読み込み専用モードでマウントされていることが原因で書き込みアクセス要求が > EROFS エラーで失敗した場合に要求されたパス名を表示する機能は > フックを掛ける場所が多くてメンテナンスが大変な割に出番が少ないので削除します。 > > ・「プロセスが自発的に権限を放棄することができる機能」は > ユーザランドアプリケーションのソースコードに修正を加えることが難しいので削除します。 上記項目の削除が終わりました。 > Kernel compatibililty routines for e.g. 32 bit syscall support on 64 bit kernels. > という機能（http://tomoyo.sourceforge.jp/cgi-bin/lxr/find?string=compat）がありますが、 > この機能に対する TOMOYO のフックが抜けていることが判りました。 具体的にはマウント制限機能が「64 ビットカーネル上で動作する 32 ビットプログラム」および 「mount(2) 以外にマウントする方法を持ついくつかのアーキテクチャ」で働いていなかったようです。 マウント制限機能のチェック箇所を sys_mount() から do_mount() の中に移動しました。 > フックを追加したいのですが、 64 ビット対応マシンが無いためテストができません。 今日到着した ThinkPad が x86_64 だそうですので、明日以降試してみます。 以上の修正が行われたものが http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/?rev=115&root=tomoyo として登録されています。 次は [Tomoyo-dev 17] のパッチを適用する予定です。 1.3.2 までは、学習モード使用時に自動的に追加されるアクセス許可の上限を設定するパラメータとして MAX_ACCEPT_FILES を使用していますが、この設定の対象範囲はファイルに関するアクセス許可 （ MAC_FOR_FILE で制御されるもの）だけになっています。 これを、 MAC_FOR_FILE だけでなく MAC_FOR_NETWORK MAC_FOR_CAPABILITY MAC_FOR_SIGNAL MAC_FOR_ARGV0 も 対象にした上で MAX_ACCEPT_ENTRY というパラメータに変更した方が良いのではないかという提案がありました。 MAX_ACCEPT_FILES パラメータは、不特定多数のファイルを読み書きするようなドメインに対して メモリの浪費とレスポンスの悪化を防止するための安全装置として用意されています。 MAC_FOR_NETWORK で学習されるアクセス許可も、不特定多数のアドレスやポートと通信するようなドメインでは 容易に数千〜数万件ものアクセス許可が学習されてしまうため、上限を設けるべきなのではという意見です。 いかがでしょうか？皆様のご意見をお待ちしています。
TOMOYO
Fork