t.pira
piras****@gmail*****
2007年 3月 7日 (水) 10:13:25 JST
熊猫さん こちらではご無沙汰しております。ぴらさかです。 MAX_ACCEPT_FILES の仕様変更案について。 > 対象にした上で MAX_ACCEPT_ENTRY というパラメータに変更した方が良いのではないかという提案がありました。 個人的には賛成ですね。ファイルのアクセス許可数しか、 上限が設定できていなかったのは違和感がありましたので。。。 > 容易に数千〜数万件ものアクセス許可が学習されてしまうため、上限を設けるべきなのではという意見です。 上記の理由と同じく、この案にも基本的にいいと思います。 しかし、注意しなくてはいけないこともあるのではないでしょうか？ 例えば sshd をチョッとでも学習していると <kernel> /usr/sbin/sshd allow_network TCP accept [IP Address] 48467 allow_network TCP accept [IP Address] 58561 .... などと allow_network が多く学習されていきます。リモートからの接続元ポート番号は 1024 から 65535 までありえるので、デフォルトの MAX_ACCEPT_ENTRY の値（今 回も多分 1024？）は簡単に超えてしまう可能性がありますね。 このケースの場合は allow_network TCP accept [IP Address] 1024-65535 とパターン化してあげれば良いのですが、これを怠ると 他の学習内容を取りこぼしてしまうことになってしまいます。 そこで、MAX_ACCEPT_ENTRY 値に達したあとの取りこぼしてしまう 学習があったときは、error_log にでもワーニングメッセージが出力 される仕組みになっていればいいと思います。 ぴら 07/03/06 に Tetsuo Handa <from-****@i-lov*****> さんは書きました: > > 熊猫です。 > > > ・プログラム実行時に使われるインタプリタ（スクリプトの場合は > > ファイルの先頭行の #! で指定されているプログラム）に対する > > アクセス許可のチェックをした方が良いのではないか？ > > > > →対象となるプログラムは /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-dev mailing list > tomoy****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -------------- next part -------------- HTMLの添付ファイルを保管しました...다운로드
TOMOYO
Fork