Toshiharu Harada
harad****@gmail*****
2007年 9月 14日 (金) 19:14:06 JST
原田です。 本件について本日、3名（原田、半田、武田）で話をしましたので 情報共有のため投稿します。半田さんの発言の部分は 代筆になりますが、誤っていたら訂正ください。＞半田さん 07/09/10 に Toshiharu Harada<harad****@gmail*****> さんは書きました: > 原田です。 > > 07/09/10 に from-****@i-lov*****<from-****@i-lov*****> > さんは書きました: > > 新機能についてのコメント募集です。 > > > > 強制アクセス制御を使えば、バッファオーバーフローに > > シェルコード（と呼ばれる悪意あるプログラム）を流し込んで > > /bin/sh を起動されてしまうことを防止することができます。 > > > > しかし、シェルコードが無限ループの中で /bin/sh の実行を要求した場合、 > > （ /bin/sh の実行に成功すれば無限ループは終了するのですが） > > /bin/sh の実行を拒否したことで無限ループが終了しなくなってしまうため、 > > ＣＰＵ使用率１００％の状態がずっと続いてしまうという副作用が生じてしまいます。 > > > > そこで、 /bin/sh の実行を拒否する代わりに何か別のプログラムを実行することにより > > 攻撃を受け流すことができないかと（先週の金曜日にあったＢｏＦに参加して）思いました。 > > 発案の内容を以下のように理解しました。 > ・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 の中からメールを送るようにしたり、クライアントのＩＰアドレスなどを取得して > > ファイアウォールのルールを変更したり攻撃元の情報を他のホストと共有したりする用途にも使えます。 > > 普段はサービスを提供するサーバとして動作していながら、 > > シェルコードを注ぎ込まれた時だけ攻撃内容を記録するセンサーとして動作します。 > > シェルコード内の無限ループから /bin/sh の実行が要求された場合にも、 > > /bin/true 等の無害なプログラムを実行するなり情報収集するなりしてプロセスが終了するので、 > > ＣＰＵ使用率１００％の状態がずっと続いてしまうという副作用を回避できます。 > > > > ユーザが要求したプログラムとは異なるプログラムが実行されるというのを気持ち悪く思う人が多いようですが、 > > 管理者が「〜〜の場合には・・・を代わりに実行する」ようにポリシーで指示した上で上記のように動作するのであれば、 > > 何かの役に立つのではないかと思います。 > > > > http://marc.info/?l=linux-security-module&m=118916470210794&w=2 > > > > 皆さんはどう思われますか？ > > 私も気持ち悪く感じた一人です。その気持ち悪さがどこから > くるのか考えてみました。 > > ・ひとつには、根津さんが指摘しているようにそのような > 機能を持つことはリファレンスモニターや現在 > セキュアOSとして認識されている範疇を「超える」ことがあります。 > 別に超えてはいけないという決まりはありませんが、 > 超えてしまうことに「気持ち悪さ」を感じます。 半田： そもそもTOMOYO は TCSEC 等に準拠することを目的として 開発されたものではなく、「セキュリティを強化したＯＳ」ではあっても 「セキュアＯＳ」ではないので（超えても気にすることはない）。 原田： 「気持ち悪い」は有意な判断基準や理由にはならないが、 LKMLを含め提案してもらう際には、既存の概念で 整理、理解できないのは不利に働くことを懸念していた。 > ・万一、代わりに実行させるプログラム自体が有害な場合には、 > 大きな影響が出ます。（勿論そうならないよう配慮は > するでしょうけれども） 半田： 強制アクセス制御が無い世界なら壊滅的な影響を受けるが、 TOMOYO はシステムワイドに強制アクセス制御ができる。 例え代わりに実行させるプログラム自体が有害であったとしても、 そのプログラムは何れかのドメインに属しており、強制アクセス制御が 有効な状態を維持できる。 原田： それは理解しているが、被害を回避できることが保証されるのは、 「強制アクセス制御が有効」なだけでなく、適切に設定されている 場合という条件がつく。その条件は満たされていることを 仮定すべきではなく、リスクを可能な限り回避するという 考え方からはやはり望ましくないと思う。 > やるにしても、直接execするのではなく、何らかの > 状態フラグとして実現して、それを利用者が利用する形が > 望ましい気がします。 半田： 状態フラグを扱うには /proc/ccs/ インタフェースやポリシー構文／パーサの 仕様変更およびユーザランドで動くデーモンプロセスの新規作成が 必要になるため、それこそ sleep や alt_exec の何倍もの大改造が必要に なる。 必要最小限のトリガ機能だけをカーネル内に搭載し、後の処理を利用者に 任せるのは、状態フラグをデーモンで監視することよりもずっと利用者に とって利用しやすい方法。 原田： メールで書いた状態フラグはおおがかりな仕組みではなく、 単純にはエラーコードの追加を想定しており、カーネル内のフラグの 新設およびそのデーモンの監視は考えていない。 > ・「CPU100%を回避する」が最大の狙いと認識していますが、 > それは必ずしも/bin/shを無限ループでexecするだけではないので、 > 少なくともそれだけが導入の理由にはならないと思います。 原田： 仮に提案を採用してexecの無限ループによる呼び出しによる CPU100%を回避することができたとして、無限ループによる 呼び出し（攻撃）による攻撃はexecに限らない。 さらに言えばDOS攻撃はMACでは防げないから、 execの失敗のみ対処するのはどうかと思う。 半田： alt_exec は使い勝手向上のための新機能ではなく、 全ての強制アクセス制御の実装に於いて生じる副作用（バグ）を 軽減するためのバグフィックスであり、是非導入すべき。 mlには書いていないがsleepという機能も考えている。 原田： sleepについては、まだ説明を聞いていないがtomoyo-devで 説明して欲しい。alt_execやsleepについては 何が何でも採用しないというわけではないが、 tomoyo-devでの同意は必要。 （ここにて議論は時間切れ） ということで、皆さんの意見を聞き議論したいので、 メールしました。発言されていない方も意見を お聞かせください。なお、ここで提案されている内容は メインライン提案ではなくTOMOYOの1系が対象です。 念のため。 -- Toshiharu Harada harad****@gmail*****
TOMOYO
Fork