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

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

From: Tanaka Akira <[e-mail]>
Subject: [ruby-dev:15099] Re: setuid and seteuid
Date: Sat, 10 Nov 2001 16:01:33 +0900
Message-ID: <[e-mail]>
akr> 私は、Process.uid=, Process.euid= という API は捨てるべきだと思ってい
akr> ます。(非推奨、ということです。べつに消せとはいいません。)
akr> 
akr> 私は Programming Perl で ($<,$>) = ($>,$<); が setreuid を呼び出すとい
akr> う記述を見て非常に大きな違和感を感じた人間なので、同じように 2つの独立
akr> した変数を想起させる Process.uid=, Process.euid= にも同様な違和感を覚
akr> えます。

なぜ「2つの独立した変数を想起」させてはダメなんでしょう？
setuid と seteuid という C の関数名も違和感がありますか？
それとも Process.uid= はダメだけど，
Process.setuid なら OK というような話しでしょうか？

akr> In article <[e-mail]>,
akr>   [e-mail] writes:
akr> > # 統一しなくてもいいのなら，極論としては，
akr> > # setuid や setreuid など，すべてを用意するだけ用意して，
akr> > # それが存在しない環境では例外発生というのでも
akr> > # いいってことになりますよね．(^_^)
akr> という極論を提供し、さらに、良く使われるであろう 2つの用途
akr> * 権限の完全放棄(setuid)
akr> * 権限の一時放棄(seteuid ないしは setreuid)
akr> について統一した API を実装するライブラリを提供するのがいいだろう、と
akr> 思っています。

「setuid や setreuid など，すべてを用意」するようにすると，
スクリプトのポータビリティが著しく低下しますが，
それは構わないとのお考えですか？
また，統一 API は，具体的にはどのような形ででしょうか？
Process.uid= を setuid にすれば OK という話でしょうか？

検討結果の通り，Process.uid= の重要性は極めて低下 
(euid= と swap_id とで実装可能) していますから，
Process.uid= で setreuid を優先的に使うのが気に入らないというのなら，
setuid を優先的にしても構いません．
ただし，過去との互換性に問題が出ることになりますが，
その問題に目をつぶってでも変更するだけの意義はありますか？

akr> また、権限の一時放棄で setreuid を使う場合は、exec を行なうするメソッ
akr> ドにも手を入れて、exec 後に権限が残らないような方法を提供するのがいい
akr> だろうと思っています。つまり「詳解 UNIX プログラミング」の UUCP の例の
akr> 「execする前に実ユーザ ID を普通のユーザ ID に設定する必要がある」とい
akr> うところを自動的にやろう、というわけですが。

逆に exec 時に権限を残したいケースもあるでしょうから，
これはプログラマが責任を持つべき部分という気がします．

akr> suid-ruby に setreuid - それも SUSv2 からは読みとれないような仕様のや
akr> つ - が必要なのはそれはそうなのでしょう。しょうがないので使うしかない
akr> と思います。ただ、それが意図した挙動になっているかどうかはちゃんと確認
akr> したいところですし、ついでにいえば setresuid があるならそちらを使いた
akr> いですね。

その「意図した挙動になっているか」の検討のために，
長々と思考過程を書かねばならなかったわけですが．(^_^;

akr> また、私はこういう話は自明なくらいがちょうどいい、と思っています。なん
akr> せセキュリティの話ですから、比較的簡単に正しさが納得できるのが望ましい
akr> というわけです。つまり、長々と思考過程を書かないと議論できないような仕
akr> 様は個人的にはそれだけで失格です。このような観点から見ると、私の案は
akr> 
akr>   (極論を実装することにより)実行可能なことが C と同じになる。
akr>   これにより C でのセキュリティの議論・考察が再利用できる。
akr> 
akr> という利点があります。

いえ，この「C と同じになる」ができないというのが問題の根底です．
C での議論は「set-uid ビットが有効」というのが
前堤になっています．(よね？)

スクリプトに対して set-uid ビットが無効であるために，
正式に suid-ruby が作られるまでは，
setuid + seteuid では「一般ユーザでの権限の一時放棄」
(例えば foo と uucp の往復) が不可能です．
長々と思考過程を書く必要があった理由の一つは，この事実の確認です．

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

例えば，foo と bar (いずれも root ではない) の二つの権限で
動くデーモンを ruby で作りたいと思ったらどうでしょう？
suid-ruby がない現在は，root としてスクリプトを起動し，
その中で (実/実効/保存) = (foo/bar/bar) の状態を作り出した後，
不要なメソッドを潰してしまうということになると思います．

# 例えば Process.swap_uid だけを残して
# Process.uid= と Process.euid= を消すとかです．

そう考えると，
「では，必要な情况を作り出すのに最低限必要な
  メソッド集合はどのようなものか」
を検討する必要があります．
これが，長々と思考過程を書く必要があった理由の二つめです．
で，あの思考過程での検討の結果として残ったのが，あの 3 種です．
検討結果からは「Process.uid= もなくていい」だったと思いますが，
過去との互換性のために残した次第です．
まぁ，保存 ID を持ちながら，
setreuid が保存 ID に影響しないという環境が
想定外になっていたのは事実ですが．(^_^;

ちなみに，「保存 ID を持ちながら，
setreuid が保存 ID に影響しないという環境」については，
(r r r) からのスタートで，
--------------------------------------
(01) 1 1 1 : setuid(1)
(10) r 1 1 : 到達不能
(11) 1 r r : seteuid(1) + setreuid(1,r)
(12) 1 2 2 : 到達不能

(13) 2 1 1 : 到達不能
(14) 2 r r : seteuid(2) + setreuid(2,r)

(20) r r 1 : 到達不能
(21) r 1 r : seteuid(1) or setreuid(-1,1)
(22) 1 r 1 : 到達不能
(23) 1 1 r : setreuid(1,1)

(30) 1 1 2 : 到達不能
(31) 2 2 1 : 到達不能
(32) 1 2 1 : 到達不能

(40) 1 2 r : seteuid(1) + setreuid(1,r) + seteuid(2)
(41) 2 1 r : seteuid(2) + setreuid(2,r) + seteuid(1)
--------------------------------------
ということになります．
特徴としては，root で起動した際に
「特定ユーザの権限になる以外では，root 権限を放棄できない」
です．
suid-ruby で想定される (1 r r) から出発しても同じです．
正直なところ，能力不足で基準にはできないレベルと思います．

# やっぱり，「とりあえず実装してみよう！」なんですかね？(^_^;
# どうやって試験・確認するかも問題かも．
-- 
                                         永井 秀利 （九工大 知能情報）
                                             [e-mail]