[ruby-dev:15168] Re: setuid and seteuid

永井＠知能．九工大です．

From: Tanaka Akira <[e-mail]>
Subject: [ruby-dev:15159] Re: setuid and seteuid
Date: Wed, 14 Nov 2001 13:54:20 +0900
Message-ID: <[e-mail]>
akr> In article <[e-mail]>,
akr>   [e-mail] writes:
akr> > なぜ「2つの独立した変数を想起」させてはダメなんでしょう？
akr> 全然独立してないからです。とくに Perl の場合は独立した変数 2つに対する
akr> 代入が特別な意味を持っているのが気に入りません。
akr> > setuid と seteuid という C の関数名も違和感がありますか？
akr> いいえ。(いや、考えてみると setuid は変かな。)

う〜む．
私には setuid や seteuid という関数名も，
同様に「2つの独立した変数を想起」させるような気がしますが，
そちらには異和感を感じないということは，
最初に身につけたものであるからなんでしょうか．
でも，「setuid は変かな」とも仰られていることからすると，
単なる「慣れ」というものなのでしょうか．

# 非特権ユーザ時に setuid が行う操作を考えると，
# 名前とはかなり遊離している感じがします．(^_^)

akr> > 「setuid や setreuid など，すべてを用意」するようにすると，
akr> > スクリプトのポータビリティが著しく低下しますが，
akr> > それは構わないとのお考えですか？
akr> もし、プログラマがポータビリティを低下させることをわかった上で使うなら
akr> なんの問題もないと思います。低レベルインターフェースには低レベルインター
akr> フェースの利点があり、ポータビリティは高レベルインターフェースで提供す
akr> ればいいでしょう。

今の Process モジュールに含めるメソッドの話は
この高レベルインターフェースの話をしているつもりです．
どうしても低レベルインターフェースが欲しければ，
別モジュールを構築する方が望ましいのではないかと思います．

というのも，私としては，
「Process モジュールに含まれているメソッドを用いて
作成したスクリプトであれば，能力的にサポートが不可能な環境でない限り，
ポータビリティのコントロールにあまり悩まなくてすむ」
というのを目指すのがいいのではないかと考えているためです．

その意味で，現在の 3 個のメソッドからなる案は

akr> 例えば、プログラマが権限を一時放棄しようと思った時に、
akr> * 最近の Unix なら(saved set-user-ID があるなら) があるなら effective
akr>   uid を設定し、
akr> * 4.3BSD 以前なら(saved set-user-ID がないなら)しょうがないので real
akr>   uid と effective uid を反転させて、
akr> 権限を一時的に放棄しようと思ったとします。このような状況は比較的想定し
akr> やすいと思うのですが、永井さんの案では saved set-user-ID の有無が判別
akr> できないため実装不能です。

という部分の抽象化は，指摘の通り，確かに不足であるように思えます．

つまり．．．
------------------------------
保存ユーザ ID の有無に影響されないだけの
ポータビリティを維持しようとすれば
Process.swap_uid(仮名)を使うようにして
4.3BSD の流儀で権限の一時放棄をしなければならない。
Process.euid=を使ってしまうと
保存ユーザ ID がない環境では権限の完全放棄になってしまう．
------------------------------
ということですよね？

確かに，例えば _POSIX_SAVED_IDS の値の利用などによる判別の上で
実行するような，高レベルメソッドを追加することが必要である気もしますね．
そのメソッドを

akr> Process.ユーザ権限の完全放棄
akr> Process.ユーザ権限の一時放棄 { ユーザ権限を放棄した状態で動作するコード }

の二つにして追加するかどうかですが，
swap_uid(仮名) の実装にも影響するので，
ちょっと考えさせてください．

# 今のところ，Process.uid= の互換性放棄 (setuid での実装) と，
# Process.ユーザ権限の一時放棄(変更？) の追加かなと思ってます．

また，保存ユーザ ID が存在するかどうかを
確実に判定する方法を考えねばなりませんね．
_POSIX_SAVED_IDS が使えればこれで判断できますが，
この定義が使える(存在する)という保証はない．
seteuid が定義されていれば，これは保存ユーザ ID の存在を
要求するはずなので，保存ユーザ ID は有りと言えるでしょうけれど，
逆はこれがないからと言って，保存ユーザ ID なしとは言えない．
テストプログラムを root 権限で実行してもらって
変更の可否で確かめるしかないんですかね？
どなたかいい手をご存知ありませんか？

akr> また、setreuid が気にいらないのは austin draft で(informative であって
akr> 規格の一部ではありませんが)will be deprecated or removed などとかいて
akr> あって将来性がないようだからです。実際、OpenBSD はコンパイル時に
akr> warning: this program uses setreuid(), which is deprecated. と警告を
akr> 吐きます。

たとえ deprecated と言われようとも，
保存ユーザ ID を変化させる setreuid がないと実現不可能なわけですから，
それを使うしかありません．(^_^)

# Perl でも，多分，それが必要だから使ってるんでしょう？

akr> もちろん、実装からそう簡単に関数が消えるとは思っていませんし、
akr> suid-ruby の都合上、まったく使わないことはできないでしょうが、必要ない
akr> ことにまで setreuid を使うことが規格の動向に沿う正しいやりかたであると
akr> は思えません。また、動向に沿わない、微妙な挙動に依存したコードは将来的
akr> に規格から見放されてしまう可能性もあります。
akr> 
akr> そのような可能性は十分に低いと判断して、必要ない状況でも setreuid を使
akr> えと Ruby ユーザ全員に強制するのもひとつのやりかたではありますが、私は
akr> もっとユーザが好き勝手に手段を選べるのが好みです。もちろん、永井さんが
akr> setreuid を使うことに反対するものではありませんが。

過去との互換性を捨てるというのであれば，
setreuid の使用を減らすことはできます．
Process.uid= を setuid に，Process.euid= を seteuid に
してしまう形です．
uid= を「{r,e,s}uid のすべてを指定値にする」と読めば，
それほどそぐわない名前でもない(resuid= では長いし)でしょう．
少なくとも，保存ユーザ ID に影響を与えない setreuid であるなら，
これをこれらの実装には使わないようにしなければなりませんね．

今，setreuid が存在するという前提を置きます．
存在する場合としない場合とは，完全な互換は取れませんので，
とりあえずは存在しない場合を無視した場合での
環境依存性を考えてみます．

Process.uid= に setreuid を使わないようにした場合，
互換性喪失の代わりに環境依存の減少という効果を得られます．
setuid はユーザ ID の概念が存在する環境なら，
まずどの環境でも存在すると考えてもいいでしょうし，
仕様は明確であるようです．
それに対し，setreuid(id,-1) での書き換えに成功するか否かの条件に
環境依存性があるようですから，これを使わないようにすることで
環境依存は減少すると思われます．

しかし，Process.euid= に setreuid を使わないようにした場合は，
逆に環境依存性が増大します．
setreuid が存在する環境で，setreuid の代わりとなる seteuid が
必ず存在するとは言えないためです．

と考えてみると，いずれにせよ setreuid を使わねばならない状況で，
過去との互換性を気にしなくてもいいなら，

  Process.uid=(id)
       特権ユーザであるなら setuid()
       それ以外は例外 (setuid() の euid のみの変更機能は捨てる)

  Process.euid=(id)
       setreuid(-1,id)

  Process.swap_id (仮名)
       setreuid(geteuid(),getuid())

とする方がいいのでしょうかね．

問題は，setreuid が保存ユーザ ID を変化させるか否かなんですが．．．

akr> しかし、seteuid が存在する世界では容易に実現できるわけですから、それと
akr> (完全にではないにしろ)同様なことを saved set-user-ID が存在しない世界
akr> で emulation するライブラリを用意したいと思う人がいてもいいと思います。
akr> ところが、永井さんの案でそういう判別が不可能で、そういうライブラリは実
akr> 現不能です。

fork して setuid して exec ですかね？
でも，これ，seteuid が存在する世界でも存在しない世界でも
問題はなさそうですから，ポータビリティを考えるなら，
どちらの世界でもこの形で起動するようにすればいいのかな？
もしそれで問題なければ，「判別」する必要はないですよね．

akr> > スクリプトに対して set-uid ビットが無効であるために，
akr> > 正式に suid-ruby が作られるまでは，
akr> > setuid + seteuid では「一般ユーザでの権限の一時放棄」
akr> > (例えば foo と uucp の往復) が不可能です．
akr> > 長々と思考過程を書く必要があった理由の一つは，この事実の確認です．
akr> よくわかりません。
akr> 「スクリプトに対して set-uid ビットが無効である」ため、Ruby スクリプト
akr> の実行(exec)によってあるユーザが他のユーザの権限を手に入れることは不可
akr> 能だと思うんですが。一時放棄もなにも放棄すべき権限を手に入れられないと
akr> いうだけの話なんじゃないでしょうか。
akr> 長々と思考過程を書く必要があったというなら、私は何を見落としているんで
akr> しょう?

前回書いたことのくり返しになりますが，例えば，
「nobody の権限と uucp の権限とを必要に応じて切替えつつ
動くようなプログラムをRuby スクリプトで作りたい」
というのを考えてください．

スクリプトの set-uid ビットが無効であるために，
suid-ruby が存在しなければ，通常の ruby を root 権限でスタートさせ，
まず最初に nobody の権限と uucp の権限とだけを取りうるように
実/実効/保存ユーザ ID を設定するようなスクリプトとするでしょう．
nobody の権限と uucp の権限とが可能な状態となると，
例えば (実/実効/保存) = (nobody/uucp/uucp)．
root 権限でスタートさせた時点では，(実/実効/保存) = (root/root/root)．
つまり，(root/root/root) ==> (nobody/uucp/uucp) とするような
ユーザ ID 変換のパスが存在するかどうかが問題です．

で，「setuid + seteuid では，そのようなパスは存在しない」
という話です．

そりゃ，「setreuid は deprecated と言われるものなんで捨てる」 
で，上記のようなスクリプトの作成は「諦める」
というのも一つの選択であることは認めます．
ですが，かなりの環境では存在する setreuid を使えば
実現できるわけですから，私には捨てきれません．

akr> > もちろん，ruby のバイナリを様々なユーザ名義でコピーして，
akr> > それぞれに set-uid ビットを立てれば可能ではありますが，
akr> > そんなことをしたらとんでもないことになるのは明らかですよね．(^_^)
akr> あぁ、それはまったくもってとんでもないので考慮していませんでした。

ですよね．(^_^)

akr> ただ、Programming Perl に載っていた話ですが、C で記述される小さな
akr> wrapper を script ごとに生成する、という手があります。これならべつにと
akr> んでもないとは思いません。現時点で即座に実現しなければならないとしたら
akr> 使えるやりかただと思います。

う〜む．
でも，これだと「Ruby でお気楽プログラミング」という感じでは
なくなりますね．

# あんまりやりたくはないなぁ．．．

akr> suid-ruby があるかないかで異なるのは、起動時の話だけだと思います。
akr> 「(実/実効/保存) = (foo/bar/bar) の状態を作り出」す方法が、root で 
akr> ruby を起動した後に適当なシステムコールを呼ぶことによってそういう状態
akr> にするか、set-uid ビットを script にたてて suid-ruby を起動するか、と
akr> いう違いだけなんじゃないでしょうか。(しかも、suid-ruby というのは「適
akr> 当なシステムコールを呼ぶ」コードが組み込まれている setuid root な ruby 
akr> のことでしょう?)

suid-ruby でない場合の起動時 (root での起動を想定) は 
(root/root/root) ですが，suid-ruby の場合の起動時は 
(foo/root/root) です．
ですから，実装されているシステムコールの範囲で
(root/root/root) ==> (foo/bar/bar) と，
(foo/root/root) ==> (foo/bar/bar) とでは
到達可能性が違ってくる可能性がありますよね．

akr> メソッドを潰すというのがどう関係あるのかよくわかりません。また「最低限
akr> 必要なメソッド集合」を検討する必要がなぜあるのかもわかりません。

すみません．よけいなことを書いて，混乱させてしまいましたね．

「メソッドを潰す」というのは，
以後の操作の範囲はここまでにしようという意志表示に過ぎません．
セキュリティがどうのこうのではなく，
不用意な操作を誤って行いづらくするための安全弁のようなものです．(^_^;
まぁ，もし suid-ruby のセキュリティコントロールで，
「syscall , load は禁止だが，Process.<権限の一時変更> などは可」
などということにでもなったりしたら，「メソッドを潰す」ことで
さらに制約をコントロールできたりするでしょうけど，
そんなことを実現する意味があるのかまでは考えてません．(^_^;

で，「必要なメソッド集合」の方は，
色々ありにしてしまうと，ポータビリティが低下するので，
必要とされうる (実/実効/保存) の状態へ行きつける範囲で，
環境の違いを吸収したできるだけ少ない種類のメソッドに
絞ってしまいたいという考えです．
そうしておけば，プログラマがポータビリティを全く意識していなくても
ある程度のポータビリティが確保できるはずだと思うからです．

akr> それに対して、私の案は単純です。C で提供されているシステムコールを直接 
akr> Ruby スクリプトに提供することにより、C でできることはでき、できないこ
akr> とはできないということが自明に成り立ち、セキュリティは OS が保証するこ
akr> と以上でも以下でもないということになります。syscall を使おうが、拡張ラ
akr> イブラリがどんなことをしようが、OS が保護するものは保護され、保護され
akr> ないものは保護されない、というわけです。それで本当にいいのか、という点
akr> は C 程度のことはできる、ということで満足しておき、それ以外のことは他
akr> の機構でどうにかしてくれと割り切る、という立場をとるわけです。

う〜む．そこまで突き放しますか．．．
「余計な抽象化をするくらいならそのままの方がいい．
ポータビリティなどは自分で考えろ」ってことですよね．
システムコールや低レベルインターフェースメソッドを用意して，
そのことを承知の上でいじるのは自由ですから，
それを止める気はありません．
私としては，そういう形はできれば避けたいと思っているのですが．．．

低レベルインターフェースを別モジュールで作成するのなら，
そういうものであるのを承知で使うわけですから構いません．
ですが，同じ Process モジュールの中で
低レベルインターフェースと高レベルインターフェースとを
同列にインプリメントするべきではないと思います．
-- 
                                         永井 秀利 （九工大 知能情報）
                                             [e-mail]