Toshiharu Harada
harad****@gmail*****
2007年 9月 10日 (月) 18:16:17 JST
原田です。 07/09/10 に from-****@i-lov*****<from-****@i-lov*****> さんは書きました: > 新機能についてのコメント募集です。 > > 強制アクセス制御を使えば、バッファオーバーフローに > シェルコード(と呼ばれる悪意あるプログラム)を流し込んで > /bin/sh を起動されてしまうことを防止することができます。 > > しかし、シェルコードが無限ループの中で /bin/sh の実行を要求した場合、 > ( /bin/sh の実行に成功すれば無限ループは終了するのですが) > /bin/sh の実行を拒否したことで無限ループが終了しなくなってしまうため、 > CPU使用率100%の状態がずっと続いてしまうという副作用が生じてしまいます。 > > そこで、 /bin/sh の実行を拒否する代わりに何か別のプログラムを実行することにより > 攻撃を受け流すことができないかと(先週の金曜日にあったBoFに参加して)思いました。 発案の内容を以下のように理解しました。 ・execveの失敗の際に、ポリシーで定義があれば 登録されていた別のプログラムを実行する ・そのことにより、exploit攻撃の副作用として CPU100%となることを防ぐことができ、 それ以外の応用も可能である > 試作してみたところ、技術的には実現できることが判りました。 > やっていることは、ファイルの先頭が #! で始まるプログラムを実行する場合に > fs/binfmt_script.c で定義されている load_script() が行う処理とほとんど同じです。 > > ----- パッチ始まり ----- ここでパッチが含まれているのはちょっと変な気がしました。 「こんなに簡単に(少ないパッチ)でできる」という ことかもしれませんが、それは発案の内容の有意性や 機能の採用とは独立だと思うからです。 > ----- パッチ終わり ----- > > 上記のパッチでは全てのドメインに対してプログラムの実行が拒否された場合に /bin/logit というプログラムを > 実行するようにハードコーディングされていますが、実際にはプロファイル単位で /bin/logit 実行するかどうかを > 指定できるようにして、実行するプログラムもポリシーファイルで指定するようにします。 > /bin/logit の内容は任意で、例えば以下のような内容でも構いません。 > > ----- /bin/logit の例始まり ----- > #! /bin/sh > echo "DOMAIN=" $1 > shift > echo "You don't have permission to call ""$@" > env > exit 1 > ----- /bin/logit の例終わり ----- > > 上記のようなプログラムを利用して、「 touch /etc/f* 」という操作をしようとして > /usr/bin/touch コマンドの実行が拒否された場合、以下のような情報を取得することができるようになります。 > > ----- /bin/logit から得られた情報 ----- > DOMAIN= <kernel> /sbin/getty /bin/login /bin/bash > You don't have permission to call /usr/bin/touch /etc/fdmount.conf /etc/fonts /etc/fstab /etc/fstab~ > HZ=100 > TERM=linux > SHELL=/bin/bash > HUSHLOGIN=FALSE > USER=root > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/root/ccstools > MAIL=/var/mail/root > PWD=/root > LANG=C > HOME=/root > SHLVL=2 > LANGUAGE=ja_JP:ja:en_GB:en > LOGNAME=root > _=/usr/bin/env > ----- /bin/logit から得られた情報 ----- > > このように、 /proc/ccs/reject_log から得られる「 /bin/touch というコマンドの実行が拒否された」という > 情報だけではなく、「 /bin/touch というコマンドに指定したコマンドラインパラメータや環境変数など」の情報も > 取得できるという利点があります。 > また、 /bin/logit の中からメールを送るようにしたり、クライアントのIPアドレスなどを取得して > ファイアウォールのルールを変更したり攻撃元の情報を他のホストと共有したりする用途にも使えます。 > 普段はサービスを提供するサーバとして動作していながら、 > シェルコードを注ぎ込まれた時だけ攻撃内容を記録するセンサーとして動作します。 > シェルコード内の無限ループから /bin/sh の実行が要求された場合にも、 > /bin/true 等の無害なプログラムを実行するなり情報収集するなりしてプロセスが終了するので、 > CPU使用率100%の状態がずっと続いてしまうという副作用を回避できます。 > > ユーザが要求したプログラムとは異なるプログラムが実行されるというのを気持ち悪く思う人が多いようですが、 > 管理者が「〜〜の場合には・・・を代わりに実行する」ようにポリシーで指示した上で上記のように動作するのであれば、 > 何かの役に立つのではないかと思います。 > > http://marc.info/?l=linux-security-module&m=118916470210794&w=2 > > 皆さんはどう思われますか? 私も気持ち悪く感じた一人です。その気持ち悪さがどこから くるのか考えてみました。 ・ひとつには、根津さんが指摘しているようにそのような 機能を持つことはリファレンスモニターや現在 セキュアOSとして認識されている範疇を「超える」ことがあります。 別に超えてはいけないという決まりはありませんが、 超えてしまうことに「気持ち悪さ」を感じます。 ・万一、代わりに実行させるプログラム自体が有害な場合には、 大きな影響が出ます。(勿論そうならないよう配慮は するでしょうけれども) やるにしても、直接execするのではなく、何らかの 状態フラグとして実現して、それを利用者が利用する形が 望ましい気がします。 ・「CPU100%を回避する」が最大の狙いと認識していますが、 それは必ずしも/bin/shを無限ループでexecするだけではないので、 少なくともそれだけが導入の理由にはならないと思います。 以上です。 -- Toshiharu Harada harad****@gmail*****