ruby-dev

In article <42DFA277.8010403@ruby-lang.org>,
  Shugo Maeda <shugo@ruby-lang.org> writes:

>> では、その安全性は他の安全性と比較して、どのような得失があるのでしょう
>> か?
>> 
>> たとえば、perl の taint 機構の安全性と比較して、どのような利点・欠点が
>> あるのでしょうか?
>
> perlsecをざっと眺めただけなのですが、Perlではライブラリがどのように
> 振る舞うべきだとされているのかが、わかりませんでした。
> 今回の議論の流れから、Perlではライブラリはuntaintに類する処理
> (Perlでは正規表現によって部分文字列を取り出すようですね)を
> 行わないと仮定して考えてみました。

その仮定は不適切だと思います。perlsec の

       Perl presumes that if you reference a substring using $1,
       $2, etc., that you knew what you were doing when you wrote the pattern.
       That means using a bit of thought--don't just blindly untaint anything,
       or you defeat the entire mechanism.  It's better to verify that the
       variable has only good characters (for certain values of "good") rather
       than checking whether it has any bad characters.  That's because it's
       far too easy to miss bad characters that you never thought of.

というあたりの記述から考えると、untaint は行われることが想定されていま
す。正規表現マッチと抱き合わせになっているのは、untaint が必要な時には
なるべく正規表現で validation させるように仕向ける仕掛けなのでしょう。

> 以下で「Rubyは〜」と書いている部分は、上記のポリシーを適用したRuby
> についての話です。
>
> まず、禁止される操作の範囲がRubyの方が広い(参照のみの操作も禁止される)
> ことについては、セキュリティ的には好ましいと思います。
> 一方、プログラムを書く手間が多少増えるのは欠点ですが、明示的に
> untaintすることによって回避できるので、さほど致命的ではありません。

その手間には untaint すべきかどうかを判断する手間が含まれるわけですが、
判断するには安全性の定義が必要です。

前田さんの案ではその定義はライブラリの作者が自由に決めるものだと理解し
ていますが、

* その定義を決定する手間
* 決定した定義に従って判断する手間
* 定義をユーザに伝える手間
* ユーザが定義を理解する手間

が十分に小さいのかどうかよくわかりません。

手間が多ければ多い程、失敗する機会が増え、セキュリティ問題が発生する可
能性も増えるわけですが、その手間は本当に十分に小さいのでしょうか?

とくに、ユーザが定義を理解する手間は、ライブラリの作者の意志で十分に手
間をかけるというわけにはいかないため、可能な限り小さくしたいところです。

perl のようにひとつの定義があるのであれば、基準を決定する手間はなく、
また、ユーザが既に定義を理解しているという期待も出来るわけですが、個々
のライブラリ毎に自由に決めるとすればそれも期待できません。

そして、その安全性を定義する自由度は実際に必要なのでしょうか?

私は taint 機構を避けてきたので経験がなくわからないのですが、perl がひ
とつの定義でやっているところからみて、実際のところそんなに自由度は必要
ない可能性もあると考えています。

taint 機構について十分に経験があるひとはそのような自由度が必要だと感じ
ているのでしょうか?

> 次にライブラリの振る舞いについてですが、Perlのようにライブラリは
> untaintに類する操作をしないということにすると、たしかにセキュリティ
> 上のリスクは低くなります。
> しかし、何らかの理由によって通常では禁止されている処理をさせたい
> 場合には、ユーザはライブラリが行っているのと同等の処理を自前で
> 実装するなど、かなりの苦労を強いられます。
> そういった場合、たとえば、「$SAFE == 1だとopen-uriが使えないから
> $SAFE = 0にしてしまおう」という反応も十分に考えられます。
> こうなってしまうと、セキュリティ面でもマイナスに働くことになります。
>
> というわけで、アプリケーション全般を対象とする場合には、できること
> を制限しないRubyのポリシーの方が好ましい、というのが私の意見です。

最初に述べたとおり前提が不適切で、そのような前提に基づいた比較では
ruby のほうが良いということは納得できません。
-- 
[田中 哲][たなか あきら][Tanaka Akira]

Thread

Prev Next

In This Thread

Prev Next