[#26468] $SAFE=1 の open-uri で redirect 時にエラー — Kazuhiko <kazuhiko@...>

かずひこです。

40 messages 2005/07/07
[#26469] Re: $SAFE=1 の open-uri で redirect 時にエラー — Tanaka Akira <akr@...17n.org> 2005/07/07

In article <m3zmsylimn.wl%kazuhiko@fdiary.net>,

[#26470] Re: $SAFE=1 の open-uri で redirect 時にエラー — Yukihiro Matsumoto <matz@...> 2005/07/07

まつもと ゆきひろです

[#26471] Re: $SAFE=1 の open-uri で redirect 時にエラー — Tanaka Akira <akr@...17n.org> 2005/07/07

In article <1120754832.716261.15867.nullmailer@x31.priv.netlab.jp>,

[#26472] Re: $SAFE=1 の open-uri で redirect 時にエラー — Yukihiro Matsumoto <matz@...> 2005/07/07

まつもと ゆきひろです

[#26475] Re: $SAFE=1 の open-uri で redirect 時にエラー — Tanaka Akira <akr@...17n.org> 2005/07/08

In article <1120762886.189058.18880.nullmailer@x31.priv.netlab.jp>,

[#26476] Re: $SAFE=1 の open-uri で redirect 時にエラー — Yukihiro Matsumoto <matz@...> 2005/07/08

まつもと ゆきひろです

[#26479] Re: $SAFE=1 の open-uri で redirect 時にエラー — Tanaka Akira <akr@...17n.org> 2005/07/08

In article <1120810939.815280.27104.nullmailer@x31.priv.netlab.jp>,

[#26483] Re: $SAFE=1 の open-uri で redirect 時にエラー — Yukihiro Matsumoto <matz@...> 2005/07/08

まつもと ゆきひろです

[#26485] Re: $SAFE=1 の open-uri で redirect 時にエラー — Shugo Maeda <shugo@...> 2005/07/08

前田です。

[#26486] Re: $SAFE=1 の open-uri で redirect 時にエラー — Yukihiro Matsumoto <matz@...> 2005/07/08

まつもと ゆきひろです

[#26525] Re: $SAFE=1 の open-uri で redirect 時にエラー — Tanaka Akira <akr@...17n.org> 2005/07/12

In article <42CF1918.5000603@ruby-lang.org>,

[#26493] can't handle \c\ — KIMURA Koichi <kbk@...>

木村です。

18 messages 2005/07/09
[#26496] Re: can't handle \c\ — "URABE Shyouhei aka. mput" <root@...> 2005/07/10

卜部でございます。

[#26574] SystemCallError.new("abc") => #<SystemCallError: unknown error - ab> — Tanaka Akira <akr@...17n.org>

次のように、メッセージの最後が切れます。

28 messages 2005/07/19
[#26576] Re: SystemCallError.new("abc") => #<SystemCallError: unknown error - ab> — Yukihiro Matsumoto <matz@...> 2005/07/19

まつもと ゆきひろです

[#26578] Re: SystemCallError.new("abc") => #<SystemCallError: unknown error - ab> — nobu@... 2005/07/19

なかだです。

[#26579] Re: SystemCallError.new("abc") => #<SystemCallError: unknown error - ab> — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/07/19

山本です。

[#26580] Re: SystemCallError.new("abc") => #<SystemCallError: unknown error - ab> — Yukihiro Matsumoto <matz@...> 2005/07/19

まつもと ゆきひろです

[#26586] Re: SystemCallError.new("abc") => #<SystemCallError: unknown error - ab> — nobuyoshi nakada <nobuyoshi.nakada@...> 2005/07/20

なかだです。

[#26587] Re: SystemCallError.new("abc") => #<SystemCallError: unknown error - ab> — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/07/20

山本です。

[#26589] Re: SystemCallError.new("abc") => #<SystemCallError: unknown error - ab> — nobu@... 2005/07/20

なかだです。

[#26597] Re: SystemCallError.new("abc") => #<SystemCallError: unknown error - ab> — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/07/21

山本です。

[#26599] Re: SystemCallError.new("abc") => #<SystemCallError: unknown error - ab> — nobuyoshi nakada <nobuyoshi.nakada@...> 2005/07/22

なかだです。

[#26628] show information of '--enable-pthread' — Hidetoshi NAGAI <nagai@...>

永井@知能.九工大です.

37 messages 2005/07/28
[#26632] Re: show information of '--enable-pthread' — Yukihiro Matsumoto <matz@...> 2005/07/28

まつもと ゆきひろです

[#26634] Re: show information of '--enable-pthread' — Hidetoshi NAGAI <nagai@...> 2005/07/28

永井@知能.九工大です.

[#26635] Re: show information of '--enable-pthread' — WATANABE Hirofumi <eban@...> 2005/07/28

わたなべです。

[#26645] Re: show information of '--enable-pthread' — "U.Nakamura" <usa@...> 2005/07/29

こんにちは、なかむら(う)です。

[#26646] Re: show information of '--enable-pthread' — Hidetoshi NAGAI <nagai@...> 2005/07/29

永井@知能.九工大です.

[#26658] Re: show information of '--enable-pthread' — Hidetoshi NAGAI <nagai@...> 2005/07/31

永井@知能.九工大です.

[#26659] Re: show information of '--enable-pthread' — Takahiro Kambe <taca@...> 2005/07/31

In message <20050731.094203.74726476.nagai@ai.kyutech.ac.jp>

[#26662] Re: show information of '--enable-pthread' — Hidetoshi NAGAI <nagai@...> 2005/07/31

永井@知能.九工大です.

[#26663] Re: show information of '--enable-pthread' — "U.Nakamura" <usa@...> 2005/07/31

こんにちは、なかむら(う)です。

[#26669] Re: show information of '--enable-pthread' — Hidetoshi NAGAI <nagai@...> 2005/08/01

永井@知能.九工大です.

[ruby-dev:26558] Re: $SAFE=1 の open-uri で redirect 時にエラー

From: Tanaka Akira <akr@...17n.org>
Date: 2005-07-17 17:32:24 UTC
List: ruby-dev #26558
In article <42D7C230.7030509@ruby-lang.org>,
  Shugo Maeda <shugo@ruby-lang.org> writes:

> それでは、逆に安全だと判断したケース(たとえばschemeがhttpでGET/HEADのみ)
> だけuntaintするようにすればよいのではないでしょうか。

なぜ「schemeがhttpでGET/HEADのみ」というのを安全と判断するのでしょう?

前田さんが [ruby-dev:26484] で示唆したように、その場合でも情報漏洩の危
険性はありますよね。 

安全性の基準はなんでしょう?

> # open-uriには無限ループの検出機構はないんですっけ。
> それも心配ということであれば、$SAFE >= 1ではredirect先のURLが取り出せる
> ような例外を発生させる、という仕様でもよいと思います。

心配すべきかどうかがよくわからないのです。

たとえば、ユーザは情報漏洩の可能性を自分で防がなければならないと考える
人が多いでしょうか、それともライブラリが防いでくれると考える人が多いで
しょうか?

それによって心配したほうがいいかどうかが変化すると思います。

> taint機構は、($SAFE == 1では)完全な安全性を提供するものではなく、
> なるべくうっかりミスを減らすためのものだと思います。

安全性っていろいろあると思うんですが、taint機構が想定する安全性って何
でしょう?

たとえば、情報漏洩を防ぐことはその安全性に含まれるでしょうか?

> ライブラリの仕様(この場合はredirectされる条件)が明らかになっている
> のであれば、それをどう使うかは基本的にアプリケーションプログラマの
> 責任ではないでしょうか。
> もちろん、File.unlinkのように危険性があきらかであれば排除するのが
> 望ましいと思いますが、ライブラリ側ですべての危険性を考慮するのは
> 難しいのではないかと思います。

私の疑問は、ライブラリの仕様としてどういう安全性を提供すべきだろうか、
というところです。open-uri が提供する安全性は、taint 機構が提供する安
全性とは独立に定義することも出来ますが、その間にギャップがあると、

* taint 機構の安全性から open-uri の安全性を類推したユーザが危険な使い
  かたをしてしまう

* 提供する安全性が異なるライブラリを組み合わせた場合に、ユーザがギャッ
  プを埋めるために書かなければならないコードが増え、失敗してセキュリティ
  問題が発生する可能性も増える

* ギャップが大きい程、私が書かなければならないコード・ドキュメントが増
  え、私の注意深さもより必要になり、私が失敗してセキュリティ問題が発生
  する可能性も増える

というような問題が生じるように思います。

taint 機構が提供する安全性と open-uri が提供する安全性が一致していれば
そういう問題は起きないわけです。

というわけでまずは taint 機構が提供する安全性を理解したいのですが、そ
の安全性って何なんでしょう?

>> 根本的なところで、taint 機構が対象としている危険性とはなにか、というと
>> ころがよくわかりません。
>> 
>> perl が参考にならないか、と思って perlsec を読んでみたりもしたのですが、
>> あっちは read mode の open が許されていたり、想定されている危険性が違っ
>> ている気がしました。

たとえば、perlsec の最初のほうに

       You may not use data derived from outside your program to affect some-
       thing else outside your program--at least, not by accident.

という記述で始まるパラグラフがあります。これは perl の taint 機構が何
を禁止するかという方針を (未定義な安全性とか危険性という言葉を使わずに) 
表現しています。たとえば、read mode な open はファイル名が taint であっ
ても許されるというのはこの説明から理解できます。また、perl は秘密情報
を読み込むことは禁止しておらず、taint 機構が有効だからといって情報漏洩
はとくに防がれないということもわかります。

それに対して、Ruby の taint 機構には (少なくとも私は) そのような明示的
な説明を見た覚えがありません。マニュアルには

  ひとつ目は、信用できない入力をもとに作られたオブジェクトを「汚染されている」と
  みなし、「危険な操作」の引数として使えないようにすることです。悪意あるデータに
  よって、プログラムが意図しない動作をする事を防ぐことを目的としています。

という記述がありますが、ここでの「危険な操作」という言葉はとくに定義さ
れていません。もちろんその後に危険な操作のリストはあげられていますが、
なぜ、それらの操作を危険とみなすのかの説明はなく、結局どういう操作を危
険とみなすのかという方針がわかりません。

しかたがないので、危険な操作のリストから ruby の方針を推測すると、read
mode の open とか 1.9 で ENV[] が禁止されているところからみて、ruby で
は秘密情報を内部に取り込むことによる情報漏洩の可能性も危険性として考え
ているのではないだろうかと感じられます。

そうすると、open-uri で redirect を行うというのは、秘密情報を取り込ん
でしまう可能性を生むわけですから、禁止するのは妥当かもしれないとも思う
わけです。

でも、結局のところ、ruby の taint 機構で危険だとされる操作がなぜ危険と
みなされるかという方針の説明がないため、確信に至ることができません。

そういう taint 機構の安全性の方針ってどこかに説明されていないんですか
ね?
-- 
[田中 哲][たなか あきら][Tanaka Akira]

In This Thread