セキュリティモデルは結局〈制限リスト〉でしかない。〈安全性〉の定義は人によっても場合によっても違う。だから、「〈安全性〉を確保できる」と書いた時に、ruby の開発者と Ruby プログラマとの間で〈安全性〉の理解に差ができてしまう。ruby は「制限できる機能のリストを提供しているだけです」というスタンスでいるべきだと思う。
スクリプトを実行する上で機能を制限したい場合がある。system("rm -rf /") を呼べないようにしたいとか。ファイルへの読み書きをして欲しく無いとか。そういう時のために、機能を無効にするスイッチがあれば便利だ。IO.disable、 SAFE[:system].disable とかね。でも、こういったスイッチの粒度が細か過ぎると、機能をオフにし忘れる可能性がある。
そこで、ruby 側が制限したい機能の便利なリストを作って、「$SAFE レベル がこれならこれだけの機能が制限されます。」と保証する。Ruby プログラマはそのリストを眺めて、自分の目的にあっていそうな、$SAFE レベルを選ぶ。ただそれだけ。「80:20 の法則」に従って、機能の制限が必要になるケースの8割をカバーできるような「便利なリスト」を目指す。あとの2割は OS が提供する機能だとか別の手段で頑張ってもらう。「セキュリティモデルが提供する安全性とは何か」を考えるとドツボにハマってしまうと思う。
「ある $SAFE レベルで機能を制限した結果として、どのようなことが不可能になるか」を証明できないなら、保証するべきではない。そして、大抵の場合それは証明できないと思う。
〈制限リスト〉で制限できると言っておきながら、制限できていないならそれは脆弱性があるということになる。ので、上のようにセキュリティモデルをとらえ直したとしても、今回の件は脆弱性があったということになるんだと思う。その深刻度がどれだけかはまた別問題。
一人当たりに直すと平均…。
戦略商品「ウォークマンA」の上下をさかさまにして持つストリンガーたん。持ち直したストリンガーたん。AV Watch より。
3人中2人が間違えている。MYCOM PCより。持ち直したストリンガーたん。INTERNET Watchより。
Jobs が iPod の上下を間違えるところを想像できるかい?ソニーの携帯型オーディオが復活する日は遠そうだ。2ちゃんねるのスレより。
最近のコメント
