From: Taku Nakajima <tnakajima@...>
Date: 2003-03-25T13:47:01+09:00
Subject: [ruby-list:37414] Re: Secure「ではない」script の書き方


中島@ブレーンです。

At Mon, 24 Mar 2003 17:42:03 +0900,
Yukihiro Matsumoto wrote:
> 
> まつもと ゆきひろです
> 
> In message "[ruby-list:37405] Re: Secure「ではない」script の書き方"
>     on 03/03/24, Taku Nakajima <tnakajima@brain-tokyo.jp> writes:
> 
> |strscanでまさにそのような例を発見しました。同じようなことをしても標準
> |のRegexpクラスでは汚染が伝染するのに、StringScannerでは伝染しません。
> 
> 手元では伝染します。たぶん、あおきさんが最近対応してるのでは？

1.8.0-preview2で試してみたら、確かに伝染するようになってました。

> |私は最後の行でtrueが出てほしいと思うのですが、それが正しいかどうかは確
> |信がありません。このような場合の指針のようなものはあるのでしょうか？
> 
> 拡張ライブラリを書く人はできれば以下のことに留意してください。
> 
>   * 部分文字列を得る場合にはrb_str_substr()などを使う
>     (strscanもそうすれば良かったのではないかと)
> 
>   * あるオブジェクトに基づいて別のオブジェクトを作るときには、
>     OBJ_INFECT()を呼ぶように
> 
>   * グローバルな状態を変更するメソッドではrb_secure(4)を呼ぶ
> 
>   * ローカルな状態(インスタンス変数とか)を変更するメソッドで
>     はselfがtaintでなければrb_secure(4)を呼ぶ。
> 
>     うーん、これを1ステップで行うマクロが欲しいか

ありがとうございます。だいぶわかってきましたが、もうちょっと聞きたいこ
とがあります。具体的には、amritaでセキュリティーエラーが発生するケース
があって、どう対処すべきかということですが、一般的な問題が含まれている
ような気もします。

まず、amritaの問題について説明します。amritaのテンプレートは、単純化し
てしまえばprintfのフォーマット指定文字列のようなものです。だから、

  tainted_string='aaabbb%d'.taint
  $SAFE=1
  printf(tainted_string, 10)

が許されるとしたら、

  t = TemplateFile.new (テンプレートファイル)
  $SAFE=1
  t.expand(STDOUT, :xxx=>111)

も許されるべきではないかと思います。実際に、mod_rubyのsafeレベルのデフォ
ルトが1ですから、テンプレートをファイルから読みこんでそれを返すという
ごく一般的な操作を許さないと面倒です。

しかし、現状の実装ではt.expandの中でテンプレートファイルから作成した文
字列をeval していますので、セキュリティーエラーが発生します。

私は次のようにしようと思っています。

  (1) amrita内部のevalの使用個所を調べて、このevalで意図されないコード
      が実行されないことを確認する。

  (2) evalする文字列をuntaintしてからevalする

  (3) 「私を信じますか？」オプションを用意して信じる人だけ(2)を有効にする

これでいいのか悩んでいるのですが、この問題を一般化すると、

  (A) 汚染はどのような時に伝染すべきか？
  (B) 各safelevelで許される操作とは何か？
  (C) 各safelevelで汚染されたオブジェクトを使用して実行してもよい操作とは何か？

ということになるのではないかと思います。まつもとさんの指針で言うと

>   * あるオブジェクトに基づいて別のオブジェクトを作るときには、
>     OBJ_INFECT()を呼ぶように

は(A)に関するルールで

>   * グローバルな状態を変更するメソッドではrb_secure(4)を呼ぶ

は(B)に関するルール($safeではグローバルな状態を変更してはいけない)にな
ります。

それで、(A)はわかるのですが、(B)(C)については「オブジェクト指向スクリ
プト言語Ruby」や「プログラミングRuby」を見ても、現在のRubyが持っている
機能に関してそれぞれ個別に、これはよい、これはダメと列挙されているだけ
のような気がします。抽象的なレベルの方針がもうひとつわかりません。

拡張ライブラリは、当然、現在のrubyの処理系にない機能を追加するのですか
ら、それぞれの機能ごとに

  (B) この機能はどのsafelevelまで許すのか？
  (C) 汚染されたオブジェクトをを使用する時、この機能はどのsafelevelまで許すのか？

ということを考えなくてはなりません。現在は、amritaのケースのように
「amritaはprintfに似てる、だからprintfに合わせればいいのか？」という感
じで、既存の個別のルールを全部ながめながら、いろいろ考えて決定する必要
があります。

だから、できれば各safelevelについて、抽象的に簡潔に「このレベルの意味
はこうです」というようなガイドラインのようなものがほしいような気がしま
す。なんとなく、暗黙のガイドラインがすでにあるような気がするので、でき
れば、それを明文化していただけるとありがたいです。

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