ruby-dev

前田です。

Tanaka Akira wrote:
>>>その方針によって実現されるのはどのような安全性ですか?
>>
>>「アプリケーションが、意図せずに、外部からの入力をもとに、外部の資源
>>にアクセスすること」を防ぐことができると考えています。
> 
> 
> なるほど。これは安全性のひとつの定義として理解できます。
> 
> では、その安全性は他の安全性と比較して、どのような得失があるのでしょう
> か?
> 
> たとえば、perl の taint 機構の安全性と比較して、どのような利点・欠点が
> あるのでしょうか?

perlsecをざっと眺めただけなのですが、Perlではライブラリがどのように
振る舞うべきだとされているのかが、わかりませんでした。
今回の議論の流れから、Perlではライブラリはuntaintに類する処理
(Perlでは正規表現によって部分文字列を取り出すようですね)を
行わないと仮定して考えてみました。
以下で「Rubyは〜」と書いている部分は、上記のポリシーを適用したRuby
についての話です。

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

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

というわけで、アプリケーション全般を対象とする場合には、できること
を制限しないRubyのポリシーの方が好ましい、というのが私の意見です。
もう少し限定された環境(たとえばsetuidされている場合など)を想定すれば
Perlのポリシーの方が望ましいかもしれません。
Rubyでも、現状あまり使われていない$SAFE == 2を、そのような環境用の
セキュリティレベルに対応させる(たとえばライブラリでは$SAFE == 2では
例外を発生させるuntaintを使う)といった方策も考えられると思います。

-- 
前田 修吾

Thread

Prev Next

In This Thread

Prev Next