[ruby-list:37418] Re: Secure「ではない」script の書き方

まつもと ゆきひろです

In message "[ruby-list:37417] Re: Secure「ではない」script の書き方"
    on 03/03/26, Taku Nakajima <[e-mail]> writes:

|>   1 汚染されたデータによる危険な操作の禁止
|>   2 プロセス関係の操作の禁止
|>   3 生成されるオブジェクトが汚染される
|>   4 信頼できないコードが実行できる
|
|確かにこの説明は「オブジェクト指向スクリプティング言語Ruby」に書いてあ
|りました(^^;
|
|この説明で、「何をすればよいか」はだいたいわかるんですが、「なぜそれを
|するのか」がもうひとつわかりません。untaintしてevalするようなライブラ
|リを配ろうとすると、すごく不安です。

え？ 書いたように思うんですが、簡潔過ぎるってことかな。

|レベル1はCGIを想定しています。
|レベル4については、外部から取得したプログラムのような信頼で
|きない、誰が書いたかわからないようなプログラムでも実行してよ
|いようなことしか許してはいけないレベルです。

|そこで、自分なりに「こういう説明がほしかった」というのをたたき台として
|書いてみますので、もし間違いや不足があったら指摘してください。

たたき台ありがとうございます。でも、檻のメタファーが適切かど
うかよくわからないのです。私のイメージだと檻はスレッド(とい
うか制御の流れ)にかかるもので、オブジェクトにかかるものでは
ないので。

檻($SAFEレベル)と汚染(taintフラグ)は区別した方が良いのではな
いかと思います。

|書きながら考えているうちに、長くなってしまいました。何が欲しかったかと
|言うと、次の3つです。
|
| * 各レベルごとに、このレベルでは何から何を守りたいのか

前にも書きましたが、檻として意味があるのはレベル1,2,4だけです。

    1: 信頼できないデータからプログラムを
    2: 同上(プロセス関係で制限が厳しい)
    4: 信頼できないプログラム(を実行中のスレッド)から他のスレッドを

| * 拡張ライブラリのメソッドに要求されること(どう実現するかを抜きにして)

 (a) 汚染されたオブジェクトから新しいオブジェクトを作るときに
     汚染を伝播すること。
 (b) 汚染されたデータをもとに「危険な」操作を行わないこと(※)
 (c) $SAFE>=4でグローバルな状態の変化を禁止すること
 (d) $SAFE>=4で汚染されてないオブジェクトの状態を参照すること
 (e) $SAFE>=4で汚染されてないオブジェクトの状態を更新すること

| * untaintしてもセキュリティモデルを壊さない条件

そのデータが信頼できること(※)。つまり、予想外の入力を含みセ
キュリティ上の問題を発生させないこと。

|この3点が、暗黙の合意があるのに明文化されてないことだと思います。

そうかなあ。(※)の部分に曖昧性があるのは確かですけど、一般論
としては言えないことだしなあ。

|それと、今さら言ってもしょうがないことですが、このように分析してみると
|他のレベルと比べて$SAFE=2だけが不明確というかややあいまいな気が・・・

ですね。自覚はあります。本人もなんで定義したのか忘れてますし。

|=== オブジェクトを生成するメソッド
|
|==== メソッドに求められる要件
|
|檻の中のオブジェクトが生成したオブジェクトが檻の外に出ないようにする。
|すなわち、このオブジェクトの生成に使用したオブジェクトが汚染されている
|場合、このオブジェクトは汚染された状態で生成される。
|
|==== それを(簡単に)実現する方法
|OBJ_INFECT()
|rb_obj_infect()

その通りでしょう。

|=== オブジェクトの内部状態を変更するメソッド
|
|==== メソッドに求められる要件
|
|$SAFE=4の時に、檻の外と中の相互作用がないようにする。つまり、自分と相
|手が檻の中にいるか(tainted?がONか)外にいるかをそれぞれチェックして、両
|者が一致してなければ、例外を発生させる

「自分と相手」というのがよくわからない(というか、そもそも檻
がよくわからない)のですが、「$SAFE >= 4 かつ汚染されていない」
ということなんですよね。

|==== Value以外の変数
|
|Value型以外の変数に、Rubyオブジェクトの内容を保存したり、逆に、変数か
|らRubyオブジェクトを生成する場合は、檻の外と中が通じてしまわないような
|配慮が必要です。例えば、RStringからchar*に保存して、後でそのchar*から
|RStringを作成するような場合です。
|
|この場合は、以下の2つのどちらかを行ないます。
|
|  * 元のオブジェクトのtainted?状態を何らかの形で保存する
|  * 変数から生成したオブジェクトをtainted?にする

変数というのがよくわからないのですが、以下のようなことが言え
るでしょう。

  * Data_Wrap_StructでラップされるようなT_DATAが参照するデー
    タからRubyオブジェクトを作る場合、元のオブジェクトが汚染
    されていれば新しいオブジェクトも汚染されている必要があり
    ます。

  * なんらかのAPIを呼び出した結果のデータからRubyオブジェク
    トを作る場合には、それが文字列の場合にはtaintするべきで
    す。文字列でなければtaintする意味はほとんどないでしょう。

  * Cのグローバル変数に格納したデータからRubyオブジェクトを
    作る場合、元のオブジェクトのtainted?状態を何らかの形で保
    存するような手段について考慮する必要があるかもしれません
    が、そもそもグローバル変数にデータを格納するのはあまりお
    勧めの設計ではありません。

|==== 環境への操作
|
|外部環境への操作は、セキュリティモデルに準じたチェックが必要です。
|
|例 クリップボードへの書きこみ … ファイルへの書きこみに準じる
|   Cレベルのグローバル変数の変更 … $SAFE=4では不可
|
|このチェックはSafeStringValue()で簡単に実現できます。

rb_secure(4)も使います。

|== untaintする前に
|
|$SAFE<=2では、任意のオブジェクトをuntaintすること、つまり檻から出すこ
|とができます。当然ですが、これは不注意に使うとセキュリティモデルに穴を
|開けることになります。
|
|untaintしてよいオブジェクトは以下のどちらかの条件に合ったもののみです。
|
|  * そのオブジェクトは外部由来のものではない
|
|    自分で作成したキャッシュデータのように、ファイルから読みこんでも、
|    スクリプト(開発者)の管理下にあるデータがあります。このようなオブジェ
|    クトはuntaintして、檻の外に出してかまいません。ただし、そのキャッ
|    シュが外部から変更されないことを(ディレクトリのアクセス権等で)確認
|    する(前提条件として明記する)必要があります。
|
|  * そのオブジェクトは外部環境の変更に使用されることはない
|
|    次のようにそのオブジェクトが一時的なオブジェクトで、用途が限定され
|    ている場合には、外部から来たオブジェクトをuntaintしてもかまいません。
|
|      eval %Q[puts '#{text.untaint}']

あと、フィルタリングしてまずい文字を含まないことが明らかな文
字列もuntaintして構いません。

                                まつもと ゆきひろ /:|)