[#26664] refactoring tcltklib.c (deleted ip check) — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>

山本です。

22 messages 2005/08/01
[#26665] Re: refactoring tcltklib.c (deleted ip check) — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/08/01

山本です。

[#26668] Re: refactoring tcltklib.c (deleted ip check) — Hidetoshi NAGAI <nagai@...> 2005/08/01

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

[#26678] Re: refactoring tcltklib.c (deleted ip check) — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/08/01

山本です。

[#26684] Re: refactoring tcltklib.c (deleted ip check) — Hidetoshi NAGAI <nagai@...> 2005/08/01

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

[#26686] Re: refactoring tcltklib.c (deleted ip check) — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/08/01

山本です。

[#26817] test/socket/test_tcp.rb freeze on windows — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>

山本です。

12 messages 2005/08/18

[#26829] cannot check EOF of pipe on windows — "U.Nakamura" <usa@...>

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

19 messages 2005/08/19
[#26830] Re: cannot check EOF of pipe on windows — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/08/19

山本です。

[#26831] Re: cannot check EOF of pipe on windows — "U.Nakamura" <usa@...> 2005/08/19

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

[#26832] Re: cannot check EOF of pipe on windows — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/08/19

山本です。

[#26836] Re: cannot check EOF of pipe on windows — nobuyoshi nakada <nobuyoshi.nakada@...> 2005/08/19

なかだです。

[#26872] irb -I/ruby -Iと$LOAD_PATH — akira yamada / やまだあきら <akira@...>

Debianユーザからruby -Iとirb -Iで

17 messages 2005/08/24
[#26873] Re: irb -I/ruby -Iと$LOAD_PATH — nobuyoshi nakada <nobuyoshi.nakada@...> 2005/08/24

なかだです。

[#26875] Re: irb -I/ruby -Iと$LOAD_PATH — akira yamada / やまだあきら <akira@...> 2005/08/24

nobuyoshi nakada wrote:

[#26885] Re: irb -I/ruby -Iと$LOAD_PATH — keiju@... (石塚圭樹) 2005/08/26

けいじゅ@いしつかです.

[#26897] fail on make install — KIMURA Koichi <kimura.koichi@...>

木村です。

28 messages 2005/08/29
[#26898] Re: fail on make install — "U.Nakamura" <usa@...> 2005/08/29

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

[#26903] Re: fail on make install — KIMURA Koichi <kbk@...> 2005/08/29

木村です。

[#26922] Re: fail on make install — KIMURA Koichi <kimura.koichi@...> 2005/08/30

木村です。

[#26926] Re: fail on make install — KIMURA Koichi <kimura.koichi@...> 2005/08/31

木村です。

[#26927] Re: fail on make install — "U.Nakamura" <usa@...> 2005/08/31

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

[#26928] Re: fail on make install — KIMURA Koichi <kimura.koichi@...> 2005/08/31

木村です。

[#26929] Re: fail on make install — "U.Nakamura" <usa@...> 2005/08/31

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

[#26930] Re: fail on make install — nobuyoshi nakada <nobuyoshi.nakada@...> 2005/08/31

なかだです。

[#26931] Re: fail on make install — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/08/31

山本です。

[#26933] Re: fail on make install — nobu@... 2005/08/31

なかだです。

[#26938] Re: fail on make install — nobuyoshi nakada <nobuyoshi.nakada@...> 2005/09/01

なかだです。

[#26939] Re: fail on make install — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/09/01

山本です。

[#26900] multiplying empty string — nobuyoshi nakada <nobuyoshi.nakada@...>

19 messages 2005/08/29
[#26904] Re: multiplying empty string — Yukihiro Matsumoto <matz@...> 2005/08/29

まつもと ゆきひろです

[#26907] Re: multiplying empty string — Tanaka Akira <akr@...17n.org> 2005/08/29

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

[#26909] Re: multiplying empty string — Yukihiro Matsumoto <matz@...> 2005/08/29

まつもと ゆきひろです

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

From: Tanaka Akira <akr@...17n.org>
Date: 2005-08-20 16:18:09 UTC
List: ruby-dev #26849
In article <4302A37D.2010801@ruby-lang.org>,
  Shugo Maeda <shugo@ruby-lang.org> writes:

>> その操作の量の違いは大きな違いではないでしょうか。
>
> その点については、同意します。
> 田中さんの主張は、「Perlの方が指針がはっきりしているため、Rubyよりも
> 好ましい」というものだと理解していましたので、それに対する反論として
> 上記のように書きました。
> taint機構の対象範囲の違いを軽視しているわけではありません。

どの操作が許可・禁止されるのかは指針から決まるので、この違いはまさに指
針に直結していると認識しています。

前田さんの提案では、操作の許可・禁止は安全性の指針以外の点から決まって
いるんでしょうか?  外界との全ての通信をデフォルトで禁止するという指針
自体ははっきりしていて、はっきりしていること自体には違いは無いと思って
いたのですが。

>> たくさんあればあるほど、判断に失敗する機会が増え、また判断自体は適切で
>> あったとしてもその判断がユーザが伝わらずに齟齬が生じて失敗する可能性が
>> 増えます。
>
> 前者に関しては、Perlでは何もチェックしないケースに対してチェックミス
> があったとしても、Perlより危険になることはないと考えます。

考えずに untaint することに慣れてしまうことに恐れを感じています。
untaint はセキュリティ機構を回避するものですから、untaint を呼ぶときに
はそれが適切であることを確信したいと思っています。

しかし、外界との通信のすべて (ほとんど?) に untaint が必要というのは、
ユーザが要求する安全性とは大きく離れていて、場当たり的に多くの untaint
を書かなければならず、考えずに untaint に慣れてしまいがちなのではない
だろうか、と考えています。

perl の指針は前田さんの案よりもデフォルトで緩く、ユーザが要求する安全
性と近いように感じているので、untaint を行うケースが少なく、untaint に
慣れてしまう可能性が低いんじゃないかと思っています。

> また、
>
>   def delete_files(list_filename)
>     open(list_filename) do |f|
>       for line in f
>         File.unlink(line.chomp.untaint)
>       end
>     end
>   end
>
> のようなメソッドがあった場合、Rubyではlist_filenameが汚染されていれば
> open操作で失敗するわけですが、Perlの場合には同様のコードだとopenの時点
> では処理が続行されてしまいます。
> 上記の例そのままのようなコードはあまりありそうにないように思われますが、
> たとえば、URLを引数に取って、そのURLから取得した情報をもとにプログラム
> の外部に影響を及ぼすような操作をすることは十分に考えられると思います。
> そのような際には安全なライブラリにするためには、汚染チェックを自前で
> 行ったエラーを発生させるようなコードを書かなければなりません。

これは delete_files の作者がどういう安全性を提供しようとするかによるの
ではないでしょうか。

perl の原則に従って、外部へ影響しないという安全性を提供しようとしたの
であれば、これは単に untaint を間違えて入れてしまったというバグでしょ
う。もし untaint を入れなければ、このメソッドは意図通りに失敗し、その
挙動は原則に従っているのでユーザはドキュメントを読まなくてもその挙動を
予想できます。

perl の原則から逸脱してドキュメントに記述した上で、delete_files の機能
を list_filename が taint でないときだけに提供しするのであれば、たしか
に自前で検査する必要がありそうです。これは外界からの情報の取り込みにお
ける結果に引数が taint だったかの情報が含まれないためですが、この点は
考えていませんでした。たしかにそこには利点がありそうです。

> Perlの方が判断が楽なので安全だとは、一概には言えないのではないでしょうか。

はい。どちらかがもう一方よりもすべてのケースで一方的に良いという結論が
出ることは期待していません。
(むろん、一方的に良い方法があるんだったらぜひその方法を推したいところ
ですが。)

したがって、両方 (もしくは、可能なら taint 機構としてあり得る様々な方
法) の利点・欠点を理解し、自分の感覚による重みをつけて判断したいと思っ
ているのですが、今のところ判断できるほどには理解できていません。その点
で前田さんがどう比較するか参考にしたいと思っているのですが... 理解に困
難さを感じています。
-- 
[田中 哲][たなか あきら][Tanaka Akira]

In This Thread