Tetsuo Handa
from-****@I-lov*****
2007年 9月 15日 (土) 10:57:44 JST
熊猫です。 > 原田： > sleepについては、まだ説明を聞いていないがtomoyo-devで > 説明して欲しい。alt_execやsleepについては > 何が何でも採用しないというわけではないが、 > tomoyo-devでの同意は必要。 sleep 機能とは、ポリシー違反を発生させたプロセスに対して、 そのプロセスを一定時間スリープ状態にするというペナルティを与えるものです。 http://marc.info/?l=linux-security-module&m=118916470210794&w=2 のスレッドの中で 登場した tar-baby と呼ばれる機能に似ています。 「ポリシーにより許可されていないプログラムの実行が無限ループの中で要求されてしまうことにより ＣＰＵ使用率が１００％になるのを防ぐ」という目的を達成するには最も単純な対処法です。 しかし、 alt_exec 機能であれば、「Linuxカーネルベース不正侵入検知システム」 （ http://www.selinux.gr.jp/selinux-users-ml/200401.month/261.html http://www.itmedia.co.jp/enterprise/articles/0406/03/news011.html ）みたいに 単純にエラーを返すだけでなく追加のアクションを起こすことができます。 > 原田： > それは理解しているが、被害を回避できることが保証されるのは、 > 「強制アクセス制御が有効」なだけでなく、適切に設定されている > 場合という条件がつく。その条件は満たされていることを > 仮定すべきではなく、リスクを可能な限り回避するという > 考え方からはやはり望ましくないと思う。 だから、デフォルトでは sleep 機能や alt_exec 機能は無効に設定してあり、 1.5.0 に取り込んだとしても 1.4.3 と同じように使えます。 追加のアクションを起こせることのメリットとリスクを理解した上で使えば良い機能なのです。 > 原田： > メールで書いた状態フラグはおおがかりな仕組みではなく、 > 単純にはエラーコードの追加を想定しており、カーネル内のフラグの > 新設およびそのデーモンの監視は考えていない。 仮に、強制アクセス制御のポリシーにより拒否された場合は EPERM ではなく EMACPERMDENIED というエラーを 返すようにした場合、ユーザランドのプログラムは EMACPERMDENIED の場合には特別な対処 （例えばプロセスを強制終了させる）をするように作成されていなければならなくなります。 全てのプログラムがそのような特別な対処をするように作成されているはずが無いですし、 特別な対処を行っているプログラムであっても、（シェルコードにより /bin/sh の実行が要求されているという時点で） 既にバッファオーバーフローにより制御を失っていると考えられます。 エラーコードを追加したとして、そのエラーコードをユーザランドに届けたところで、役に立つとは思えません。 > 原田： > 仮に提案を採用してexecの無限ループによる呼び出しによる > CPU100%を回避することができたとして、無限ループによる > 呼び出し（攻撃）による攻撃はexecに限らない。 > さらに言えばDOS攻撃はMACでは防げないから、 > execの失敗のみ対処するのはどうかと思う。 多くの場合、攻撃者の狙いは 「標的のマシンのＣＰＵ使用率を１００％にすることで正常なサービスを提供できないようにする」ことではなく 「標的のマシンで /bin/sh を実行することで（改ざんや漏洩、踏み台の設置などの）悪事を働く」ことであると 考えられます。（もし、ＣＰＵ使用率を１００％にすることだけが狙いなら、強制アクセス制御は無力です。） しかし、「強制アクセス制御が /bin/sh の実行を拒否したことが原因で標的のマシンのＣＰＵ使用率が １００％になってしまい、正常なサービスが提供できなくなる」ことは 攻撃者の当初の目的を防ぐことができるとしても、管理者にとっては嬉しいことではありません。 だから、最低でも sleep 機能を、できれば alt_exec 機能も 1.5.0 に採用したいのです。
TOMOYO
Fork