前田です。

Tanaka Akira wrote:
>>ライブラリでuntaintするということは、`You may not use data derived
>>from outside your program to affect something else outside your
>>program'という原則に反するということですが、その判断はどういう
>>指針にもとづいて行われるのでしょうか。
> 
> 
> untaint することがその原則に反すると述べた覚えはありません。スレッドを
> 読み返してみたのですが、私がそう述べた部分は見つけられませんでした。
> 
> 私が述べたどの部分からそのように思われましたか?

田中さんのメールからそう思ったのではなく、perlsec自体を読んで
そう思いました。

私の理解は以下のようなようなものでした。

* プログラムの外部に影響を与えるのに外部から取得したデータを使っては
  いけない(少なくとも偶然には)。
* そこで外部からのデータはtaintされ、外部に影響を与えるような操作に
  渡すとエラーになる。
* 意図的にそのような処理を行いたいケースもある(原則から外れるケース)。
  そのような場合はパターンマッチによってuntaintする。
  パターンマッチを行ったということは、ユーザが何をしているかわかった上で
  そのような処理を行ったと考えることができる(偶然そうなってしまったわけ
  ではない)ため、問題ない。

この理解は間違っているということでしょうか。

もしこの理解が間違っていて、untaintした場合でも外部への影響があってはな
らない、とすると、やはりアプリケーション全般を対象とする場合には制約が
厳しすぎるように思います。
もともとsetuidスクリプトのようなものを想定しているようなので、そういう
ものなのかもしれませんが、とすれば、Rubyの$SAFE == 1との比較対象として
は適切でないかもしれません。

Rubyの$SAFE == 1は、偶発的な事故を防ぐためのチェックを行うだけであり、
ユーザが意図的に行った操作は制限しないものだと思っています。

Tanaka Akira wrote:
>>>その手間には untaint すべきかどうかを判断する手間が含まれるわけですが、
>>>判断するには安全性の定義が必要です。
>>
>>ではPerlではどういう基準で判断されるのでしょう。
> 
> 
> 私が perlsec を読んだことから想像すると、`You may not use data derived
> from outside your program to affect something else outside your
> program' という原則に沿ってやるのではないかと思いました。

そのあとに`--at least, not by accident'というフレーズがあるので、
原則的には外部からのデータを使うべきではないけど、意図的に使いたい
時にはパターンマッチで意図を明示してuntaintしなさい、という話なの
だと理解していました。

-- 
前田 修吾