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

In article <[e-mail]>,
  [e-mail] writes:

> なぜ「2つの独立した変数を想起」させてはダメなんでしょう？

全然独立してないからです。とくに Perl の場合は独立した変数 2つに対する
代入が特別な意味を持っているのが気に入りません。

> setuid と seteuid という C の関数名も違和感がありますか？

いいえ。(いや、考えてみると setuid は変かな。)

> それとも Process.uid= はダメだけど，
> Process.setuid なら OK というような話しでしょうか？

Process.setuid は実装と直接対応しており、(setuid(2) の意味を知っている
人には)意味がはっきりわかるので問題ありません。もし、Process.setuid の
中身が setuid(2) ならば、の話ですが。

> 「setuid や setreuid など，すべてを用意」するようにすると，
> スクリプトのポータビリティが著しく低下しますが，
> それは構わないとのお考えですか？

もし、プログラマがポータビリティを低下させることをわかった上で使うなら
なんの問題もないと思います。低レベルインターフェースには低レベルインター
フェースの利点があり、ポータビリティは高レベルインターフェースで提供す
ればいいでしょう。

例えば、プログラマが権限を一時放棄しようと思った時に、

* 最近の Unix なら(saved set-user-ID があるなら) があるなら effective
  uid を設定し、

* 4.3BSD 以前なら(saved set-user-ID がないなら)しょうがないので real
  uid と effective uid を反転させて、

権限を一時的に放棄しようと思ったとします。このような状況は比較的想定し
やすいと思うのですが、永井さんの案では saved set-user-ID の有無が判別
できないため実装不能です。

つまり、永井さんの案は中途半端に OS を隠蔽し、プログラマに常に 4.3BSD
の流儀で権限の一時放棄を行なうことを強制します。

ruid は基本的には実際にプロセスを起動したユーザを示すもので、みだりに
変えるべきものではないと私は思っていますが、そのような感覚をプログラム
に反映させようと思っても、4.3BSD の流儀を強制されてしまうのでそれがで
きません。

それに対し、私の案では Process.seteuid があればそれを使い、そうでなけ
れば Process.setreuid を使うというようにして上記のような要望を満たすこ
とができます。

> また，統一 API は，具体的にはどのような形ででしょうか？
> Process.uid= を setuid にすれば OK という話でしょうか？

名前は(まだ)考えてないので日本語で書きますが、

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

というようなものがあったらいいのではないかと思っています。

ユーザ権限の一時放棄の中身は上で書いたような seteuid または setreuid
で実現されるもので、setreuid を使った時には exec 関連に手を入れて
seteuid を使った時と同様に exec で権限が消えるようなものを想定していま
す。

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

Process.uid= と Process.euid= に関しては非推奨とし、実装は現在のまま、
ないしは、永井さんが思うような互換性を保った実装にしておけばいいと思い
ます。先に述べた通り、Process.uid= と Process.euid= は捨てるべきだと思っ
ているのであまり興味はありません。

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

もちろん、実装からそう簡単に関数が消えるとは思っていませんし、
suid-ruby の都合上、まったく使わないことはできないでしょうが、必要ない
ことにまで setreuid を使うことが規格の動向に沿う正しいやりかたであると
は思えません。また、動向に沿わない、微妙な挙動に依存したコードは将来的
に規格から見放されてしまう可能性もあります。

そのような可能性は十分に低いと判断して、必要ない状況でも setreuid を使
えと Ruby ユーザ全員に強制するのもひとつのやりかたではありますが、私は
もっとユーザが好き勝手に手段を選べるのが好みです。もちろん、永井さんが
setreuid を使うことに反対するものではありませんが。

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

はい。選択可能であるべきでしょう。

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

ところが、永井さんの案でそういう判別が不可能で、そういうライブラリは実
現不能です。

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

私が意図した確認というのは configure 時ないしは実行時に行なうものです。
所詮、SUSv2 などの仕様では保証されていない話で、いくら頭を捻っても想定
していない実装には出会ったらそれまでですから、実際に確認してセキュリティ
ホールになりかねない実装では確実にそれを検出してはねてしまうべきだと考
えました。

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

はい。起動時についてはそのとおりです。script かどうかで異なりますね。

再利用できるのは起動後の話です。わたしは Ruby 内の API について議論し
ているつもりなので、そちらに着目して述べました。

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

よくわかりません。

「スクリプトに対して set-uid ビットが無効である」ため、Ruby スクリプト
の実行(exec)によってあるユーザが他のユーザの権限を手に入れることは不可
能だと思うんですが。一時放棄もなにも放棄すべき権限を手に入れられないと
いうだけの話なんじゃないでしょうか。

長々と思考過程を書く必要があったというなら、私は何を見落としているんで
しょう?

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

あぁ、それはまったくもってとんでもないので考慮していませんでした。

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

# うぅむ。今、プログラミング Perl を見ても見当たらないのはなぜだろう?

> 例えば，foo と bar (いずれも root ではない) の二つの権限で
> 動くデーモンを ruby で作りたいと思ったらどうでしょう？
> suid-ruby がない現在は，root としてスクリプトを起動し，
> その中で (実/実効/保存) = (foo/bar/bar) の状態を作り出した後，
> 不要なメソッドを潰してしまうということになると思います．
> 
> # 例えば Process.swap_uid だけを残して
> # Process.uid= と Process.euid= を消すとかです．
> 
> そう考えると，
> 「では，必要な情况を作り出すのに最低限必要な
>   メソッド集合はどのようなものか」
> を検討する必要があります．
> これが，長々と思考過程を書く必要があった理由の二つめです．

よくわかりません。

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

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

もし、メソッドを潰すという Ruby レベルでの制限でセキュリティを実現しよ
うというなら「syscall って知ってますか?」とか「拡張ライブラリをどうし
ましょう?」などといった疑問が出てくるんですが、本当にそういうことを考
えているんですか?

例えば、だれかが POSIX モジュールとかいって POSIX で提供されている関数
群を全部直接提供する拡張ライブラリを書くと、それはセキュリティ的に問題
がある、ということになるんですか?

それに対して、私の案は単純です。C で提供されているシステムコールを直接 
Ruby スクリプトに提供することにより、C でできることはでき、できないこ
とはできないということが自明に成り立ち、セキュリティは OS が保証するこ
と以上でも以下でもないということになります。syscall を使おうが、拡張ラ
イブラリがどんなことをしようが、OS が保護するものは保護され、保護され
ないものは保護されない、というわけです。それで本当にいいのか、という点
は C 程度のことはできる、ということで満足しておき、それ以外のことは他
の機構でどうにかしてくれと割り切る、という立場をとるわけです。
-- 
[田中 哲][たなか あきら][Tanaka Akira]
「ふえろ! わかめちゃん作戦です$(C⊇」(Little Worker, 桂遊生丸)