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

中島@ブレーンです。

あいまいな問題提起とループしたような議論につきあっていただき、ありがと
うございます。

おかげさまで、だんだんRubyのセキュリティモデルが理解できてきましたが、
同時に、説明されてない(と私が感じていた)部分もはっきりしてきました。時
間ができたら、今回のやりとりをもとにどこかにまとめて書いてみようと思い
ます。

とりあえず、以下は質問ではなくて感想とひとり言です。

> |この説明で、「何をすればよいか」はだいたいわかるんですが、「なぜそれを
> |するのか」がもうひとつわかりません。untaintしてevalするようなライブラ
> |リを配ろうとすると、すごく不安です。
> 
> え？ 書いたように思うんですが、簡潔過ぎるってことかな。
> 
> |レベル1はCGIを想定しています。
> |レベル4については、外部から取得したプログラムのような信頼で
> |きない、誰が書いたかわからないようなプログラムでも実行してよ
> |いようなことしか許してはいけないレベルです。

ここで言いたかったのは、レベル1,4はわかるけどレベル2,3の「目的」または
「意図」がわからないということです。

より本質的には、今それを(レベル2が存在する目的を)理解すべきかそうでな
いのかがわからない、ということが問題だったと思います。

> |そこで、自分なりに「こういう説明がほしかった」というのをたたき台として
> |書いてみますので、もし間違いや不足があったら指摘してください。
> 
> たたき台ありがとうございます。でも、檻のメタファーが適切かど
> うかよくわからないのです。私のイメージだと檻はスレッド(とい
> うか制御の流れ)にかかるもので、オブジェクトにかかるものでは
> ないので。

メタファーがピンと来るか来ないかは感覚的なものですが、この場合は、私と
まつもとさんの間に、問題意識のズレがあるような気がします。

私は、セキュリティモデルの全体像が見えないことが問題だと感じて、全体像
を説明するために、檻というメタファーを使いました。

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

檻($SAFEレベル)と汚染(taintフラグ)は協調して何かを実現しているはずです。
ですから、両者の共通目的とはそもそも何なんだ、という説明が最初に必要だ
と思います。前回のメールを書きながら、ようやくそれがわかったんですが、
この二つの目的は

  「自分の書いたコードの一部を信頼できないケース」

に対応することです。そして、セキュリティモデルが実現しているのは

  「プログラムを信頼できる部分と信頼できない部分に分割する」

ということだと思います。私は、このようなトップレベルの説明がまずあって、
汚染の伝染や各セーフレベルの制限の説明は、この説明にぶらさがっていくべ
きだと思います。次のような感じです。

  信頼できないコードが生成したオブジェクトは信頼できません。信頼できな
  いオブジェクトはtainted?フラグでマークされます。そのような信頼できな
  いオブジェクトは「隔離」された状態で別に管理されます。

  $SAFE=1では、信頼できない部分が「悪さ」をしないように監視されます。
  「悪さ」とは意図されないファイルの作成など、プログラムの外部に対する
  操作です。$SAFE=4になると、プログラム内部のオブジェクトに触ることも
  「悪さ」と見なされます。

このレベルの説明では檻というメタファーはかなりしっくりくると自分では感
じます。ただ、さらにこれをブレークダウンして詳細を説明していくとだんだ
んと破綻してきます。

ですから、檻と言うのは実装に添って詳細を説明するのにはふさわしくないメ
タファーですが、上のレベルの概要説明には使えそうな気がします。どちらに
せよ、こういうのはピンと来る人だけ読めばよいものですから、まずはこれで
やってみます。

> |書きながら考えているうちに、長くなってしまいました。何が欲しかったかと
> |言うと、次の3つです。
> |
> | * 各レベルごとに、このレベルでは何から何を守りたいのか
> 
> 前にも書きましたが、檻として意味があるのはレベル1,2,4だけです。
> 
>     1: 信頼できないデータからプログラムを
>     2: 同上(プロセス関係で制限が厳しい)

確かにレベル2は自プロセスを守っているんですが、「何から」かと言うと、
信頼できない(外部由来)のデータからだけでなく、外部に由来しないコードか
らも守っていると思います。例えば、forkが汚染に関係なく無条件に禁止され
ています。これは明かに外部と関係ない所にも敵がいるという感覚だと思いま
す。

ここがレベル2のわかりにくさではないかと。つまり、レベル1→2に限って、
「何から何を」の「何を」と「何から」が両方変化します。このことで、この
レベルの「意味」を直感的に把握するのが難しくなってると思います。

> |それと、今さら言ってもしょうがないことですが、このように分析してみると
> |他のレベルと比べて$SAFE=2だけが不明確というかややあいまいな気が・・・
> 
> ですね。自覚はあります。本人もなんで定義したのか忘れてますし。

ここに同意していただいて、ようやっと「自分はセキュリティモデルを把握し
た」という実感が出て、少し安心できました。

と言うことは、「不安」なるものの大きな要因は、レベル2が把握できてない
ことだったんですが、Rubyに関して細部が理解できない為に不安になるという
のは初めての経験でした。

これがこの問題の特異な所ではないかと思います。

例えば、私はamritaの拡張モジュールを書きはじめる時点では、Ruby本のマン
デルブロのサンプル程度の知識(関数的なメソッドならどうにか書ける)しかな
かったんですが、クラスやモジュールはもちろん複雑な継承関係を使う必要の
あるamrita拡張モジュールを書くことに、ほとんど不安がありませんでした。

それで、実際に調べながら書いてみて、(RHGの助けもありますが)大きな手戻
りもなく書くことができました。

それができたのは、ここに関してはトップレベルの理解があったからだと思い
ます。だから、何か知らないことがあっても「それを今知る必要があるかない
か」ということは、常にわかっていたような気がします。

セキュリティモデルに関しては、そういう感覚が全くなくて、知らないことや
理解できないことがあった時に、「今それを理解する必要があるのか」という
ことがわからなくって、迷子になってるような気がします。

私にとってはRubyの設計思想の中でここで一番理解しにくい所で、誰かがもう
少し説明した方がよいような気がします。(まずは自分でやってみます)

> | * 拡張ライブラリのメソッドに要求されること(どう実現するかを抜きにして)
> 
>  (a) 汚染されたオブジェクトから新しいオブジェクトを作るときに
>      汚染を伝播すること。
>  (b) 汚染されたデータをもとに「危険な」操作を行わないこと(※)
>  (c) $SAFE>=4でグローバルな状態の変化を禁止すること
>  (d) $SAFE>=4で汚染されてないオブジェクトの状態を参照すること
>  (e) $SAFE>=4で汚染されてないオブジェクトの状態を更新すること

よくわかりました。

ただ、これを見ると「なぜここに$SAFE>=4というチェックがあるのに、
$SAFE>=2や$SAFE>=3というチェックが一切出てこないんだろう」ということが
謎になります。こういう言いがかりのような疑問がズルズル出てきて消えない
のが、悩みのタネで・・・

> | * untaintしてもセキュリティモデルを壊さない条件
> 
> そのデータが信頼できること(※)。つまり、予想外の入力を含みセ
> キュリティ上の問題を発生させないこと。
> 
> |この3点が、暗黙の合意があるのに明文化されてないことだと思います。
> 
> そうかなあ。(※)の部分に曖昧性があるのは確かですけど、一般論
> としては言えないことだしなあ。

「危険な操作」とか「信頼できるデータ」という言葉の指すものが曖昧である
ということは問題ではありません。その説明では全体のイメージがわかないと
いうことが問題なんです。

例えば、拡張モジュールを書く時、私はメモリの管理やGCについては「普通は
一時変数上のオブジェクトは考えなくてよい」と理解していました。この時、
この「普通」という言葉が何を意味しているのか詳細は理解していませんでし
たが、この言葉(とrubyのGCに関する概要説明)でRubyのメモリ管理については、
非常にくっきりとしたイメージが私の中にできたのです。

そして、後に、volatileの問題を調べて「普通」の意味の詳細もだいたい理解
しましたが、最初のくっきりしたイメージには変化がありません。

この「くっきりとしたイメージがわきあがる」ことを別の言葉で言うと「驚き
最小の原則」になるかと思いますが、これが私のとってRubyの一番の魅力です。
詳細を知る前からイメージがくっきりしていて、詳細を知ってからもイメージ
がぶれない。

このセキュリティモデル関連の問題は、私にとってはRubyを始めてから最初の
「驚き」なのかもしれません。変な話ですが、これまでRubyについて新しいこ
とを知っても一切「驚き」がないんです。全部、「ふ〜ん、そんなもんだろう
と思ってたよ」という感じで納得できてしまうんです。

--
「stableでなければ生きていけない。unstableでなければ生きてる意味がない」
中島 拓 (株)ブレーン 研究部 ([e-mail])
http://www.brain-tokyo.jp/research/amrita/