From: keiju@... (ÀÐÄͷ½¼ù ) Date: 1997-04-10T15:24:06+09:00 Subject: [ruby-list:2751] Re: security model けいじゅ@SHLジャパンです. In [ruby-list :02742 ] the message: "[ruby-list:2742] Re: security model ", on Apr/10 11:36(+0200) matz@caelum.co.jp (Yukihiro Matsumoto) writes: >|汚れているないに関わらずファイルへの書き込みは常に制限する必要はないの >|かな? > >オープンできれば書き込みは自由だと考えています.すでにオープ >ンしているラインに汚れた文字列を書き出す事は禁止した方が良い >ことのでしょうか? プログラムに埋め込まれている文字列(リテラル)は新たに生成される文字列と して扱われているのかな? それなら問題ないかも知れない. file = open(/tmp/foo) loop do file << "foo" end このプログラムでもある意味では危険だし... レベルが幾つになるか分からな いけど... >|あと, socket通信など 信頼できる相手との通信は汚れなくできればいいんで >|すけど, 信頼できるかどうか判断できないから無理ですよねえ... >無理ですね.安全レベルの低いスレッドで通信して,渡してもらう >しかないでしょう. ですねえ... >文字列の汚れの伝搬に付いてはまだ厳密に決めていません.でも, >あんまり要らないかなあともおもっています. >というのも,低いレベル(1とか2)はsetuidスクリプトでのうっかり >ミスの防止のためですから,あまり一生懸命伝搬しなくても良いよ >うにも思えます(もちろんdupとcloneでは伝搬します). >高いレベルではそのスレッド内部で生成される文字列全てが汚れて >いますから,文字列操作によってできた新しい文字列も当然汚れて >いるわけで,こちらについてもわざわざ伝搬する必要もない気がし >ます. うーん. そうなんでしょうか? file = "きれいな文字列" $SAFE = 2 file.sub!(/^$/, "汚れた文字列") sは新たに生成された文字列ではないですが, 明らかに汚れているように見え るんですが?? >|あと, 間接的に文字列生成のともなう, printf, << などは禁止する必要があ >|る? >汚れた文字列の出力は禁止していませんから,これは禁止していま >せん. この辺りは先に述べた書き込みとからみますけどね... >|* 環境変数の設定もここになるかな? >環境変数はキーも値もきれいな文字列の場合に変更できるようにし >ようと思っていましたが,一定のレベル以上の時には変更そのもの >をできなくした方が良いですかね? 両方汚れていないなら問題ないような気がします. >レベル0(デフォルト) > 外部から得た文字列は汚れている >レベル1(setuidチェックレベル) > 汚れた文字列で危険な操作を行う事はできない >レベル2 > さらに,いくつかの危険な操作(kill,fork)は全面禁止 >レベル3 > さらに,生成された文字列は全て汚れている >レベル4(アプレットレベル) > さらに,グローバル変数の値が変えられない >これならARGVの汚れも検出できるし,普段は制限無しで実行できそ >うでしょ? ARGVのよごれって本当に検出する目的についてですが, 他プロセスからforkで 呼ばれた時には, 汚れている可能性があるからですかね? でも, 良く考えると自分でそのコマンドに対して引数を渡す時は汚れていなく て良いと思うというか, 汚れられると不便な時が多いがするんですが? セキュリティモデルの目的が良く分かっていないのかなあ... このセキュリティモデルとは何のためのセキュリティなのでしょうか? 確認ですが, これから実行しようとしているrubyで書かれた良く分からないプ ログラムが悪さをさせないためのものなんですよね? 悪さ==何か? ってのも問 題になりますが... * 情報を盗む * ファイルに書き込む/改変 * OSへの悪影響 これらに対して, どのレベルでどのような制限が設けられるのかをはっきりさ せた方が良いのでは? __ .....................................石塚 圭樹@SHLジャパン(株)... ------------->アドレス変わりました!! e-mail: keiju@shljapan.co.jp <----