_ うーん、 Sendmail に穴か……。こんなにデカいパッチだと手で当てるのもやめておいた方がいいな。つーか、これは enbug が怖くて実際に exploit が出回るのを確認できるまで適用を躊躇するには十分のデカさだ。しかも 8.13 と 8.12 にしかパッチが出てねぇ。それ以前のバージョンは死ねと。前いた会社ではまだ 8.11 のホストが動いてるはずなんだけどだいじょうぶかな。あっちでは sendmail 関係はほとんどわしひとりでめんどうを見てたので、残ってる人は経験値があんまり高くないんだよなぁ（それでも世間一般並みはあるはずだけど）。
_ ただ、こういう穴があっても、個人的には「だから sendmail は捨て」とは思わない。長期的な展望ではたしかに乗り換えた方がいいかもしれない。でも短期的に見ると、たとえ世間的に安全という評価が与えられているものでも、いざトラブルの発生時に対処方法がわからないようなものに乗り換えるぐらいならば、安全でないと言われていてもトラブルにすぐ対処できるものを使い続ける方がまだマシ。「トラブルに対処できない」というのも十分にセキュリティリスクだ。セキュリティインシデントが重要なのは言うまでもないが、インシデントレスポンスもそれと同じぐらい重要だということを忘れてはならない。逆に言えば、もし sendmail を使ってるけど自分じゃメンテできないというのであれば、即刻捨てましょう。sendmail に限ったことではなく、qmail でも postfix でも同じ。理解していないのなら、「あなた自身」がセキュリティホールです。
_ 以上、あくまで「短期的」な視点で見た場合。長期的視野に立てば、しょっちゅう穴が見つかるものは zero day attack がこわいし、sendmail 批判派の意見ももっともなので、やっぱり将来的には乗り換える方向で検討した方がいいと思う。Sendmail X が次に控えてるので 8.x は先細りしそうだし。
_ この前は qmail は捨てと書いて、今日は sendmail はまだ戦える、という。これ、世間的な意見では逆だわな。qmail はもう寿命が尽きてるのをムリヤリ延命してる状態だけど、ちゃんとメンテが続いている sendmail は先は長くないにしてもまだ寿命は来ていないという程度のこと。sendmail も寿命は見えつつあるので、準備はしておいた方はいいんじゃないかな。まだあと数年は大丈夫だとは思うけど（根拠なし）。
_ なんかすごいなー。
福岡県柳川市消防本部（竹下敏郎消防長）のコンピューターに、大量の迷惑メールが送りつけられたため、火災を消防団員や市民らに知らせるメール配信サービスができなくなった。どの程度かというと、今月上旬から断続的に数万通だそうで。平均すると1分あたり数通……って、それのどこが大量やねんっ。1分に数通届くだけで限界に達して送信できなくなるってどんなシステムだ。_ 内部的にどんなしくみなのかはわからんが、
対策として、アドレス変更も検討しているという。そんなアホみたいな対策したってダメだよ。たったこれっぽっちの spam であっぷあっぷになるようなシステムは、いっそ発注先のベンダごと切り捨てなきゃ。yanasho119.jp の MX につないでみたところによると MTA は これのようだが、さすがにこいつをふつーに使うだけでみんなそうなるなんてことはないよな、まさか。_ spam を社会悪として警告していくのは重要なことだとは思うんだけど、しかしこの記事は擁護する気にちっともなれないお粗末さだ。
_ まず、suexec を有効にした apache を用意する。そしたら次に /usr/bin/whoami を /home/hoge/public_html/whoami にコピーしておく（/usr/bin/id でもいい）。ファイルの所有者は hoge にしといてください。で、こういう CGI を用意する。
この CGI を suexec で実行されない場所（SuExecUserGroup の設定がなく、public_html でもないところ）におく。#!/bin/sh user=hoge group=`groups $user | awk '{print $1}'` cmd=whoami echo "Content-Type: text/plain" echo "" /usr/bin/$cmd cd /home/$user/public_html /usr/local/apache2/bin/suexec "~$user" "$group" "$cmd"_ この CGI にアクセスすると、ブラウザに表示されるのは次の2行。
1行目は /usr/bin/whoami の実行結果。apache の動作ユーザである apache が出力される。2行目は suexec の実行結果。ユーザがスイッチして hoge が出力される。apache hoge_ suexec の効かない場所に置いたはずの CGI から、suexec コマンドを直接呼び出すことでユーザのスイッチができちゃったわけだ。apache ユーザが hoge ユーザになりすましてコマンドを実行しちゃえるので、これは一般的には危険とされる行為。危険だが、利便性のために条件を厳しく限定した上で認めちゃうのが suexec。だからこういう結果になるのは実はセキュリティホールではなく、suexec の仕様どおり（仕様の悪用だが）。なお、この CGI は suexec が有効な場所に置いて実行すると失敗する。限定した条件からはずれるためで、これも仕様どおり。
_ 上の CGI では public_html の下、URL でいえば /~hoge/ の下にあるものを実行したけど、ほんのちょっとの修正（どう修正するかは書かない）で /~hoge/ ではなくバーチャルホストのパスにあるバイナリ/スクリプトを suexec で呼び出すことも可能。
_ さらに、CGI ではなく PHP でも同じことが可能。CGI では ~hoge/public_html/ の下の CGI は suexec で実行されるので、ここからさらに fuga にスイッチしようとすると失敗する。しかし、mod_php だとどこに置いても suexec は効かないから、~/hoge/public_html/ の下にある PHP スクリプトから ~fuga/public_html/ の下にあるファイルを fuga の権限で実行することもできる。バーチャルホストもまたしかり。
_ とはいえ、suexec で実行できるファイルってのは configure のときに --with-suexec-docroot、--with-suexec-userdir で指定した場所にあるものだけ。通常これらの場所には suexec で実行されることが前提の CGI しか置かれないはずなので、上で挙げたようなことをやっても、実は悪影響なんかない。CGI の中から system("suexec ....")なんてやるのは suexec の悪用であることには違いないが、そんなことをやっても問題を起こさないようにはなっている。はじめに「/usr/bin/whoami を /home/hoge/public_html/whoami にコピーしておく」なんて書いたけど、あくまで例のためであって、public_html の下にそんな CGI でない一般コマンドが存在している方がおかしい。
_ 前フリが長かったが、以下本題。
_ さて、http://www.example.com/~hoge/ を http://hoge.example.com/ という URL で見せたい。そのためにバーチャルホストで DocumentRoot /home/hoge/public_html と設定する。ここまではいい。しかし、この両方で suexec を可能にするために、configure で --with-suexec-docroot=/home なんて指定をする例が よく見られる。ところがこれは危険。
_ なぜかというと、この指定で作られた suexec コマンドを CGI/PHP スクリプトの中から直接呼びだすことで、/home の下、たとえば ~/bin などにあるスクリプトやバイナリをユーザをスイッチして実行できてしまうから。ローカルユーザが他人の権限を取得できてしまう。 suexec のセキュリティモデルの13番「ディレクトリが Apache のドキュメントツリー内にあるか?」のチェックがないがしろにされてしまう（~/bin は明らかにドキュメントツリーの外だ）。~/public_html の下にあるものは、他人が自分の権限で実行しても問題ない CGI しか置いてないはず。だけど、~/bin の下あるツール類がそういう起動のされかたを想定しているとは考えにくい。--with-suexec-docroot=/home で suexec を作ると、結果として suexec で実行できてはいけないファイルが suexec で動かせてしまう。
_ まとめ。
というわけで、suexec の制限をゆるめる方向で configure するのならば、自分が何をしようとしているのかよく理解してなきゃやっちゃダメ。suexec ってのは、「安全に」ユーザを切り替えて CGI を使うしくみではない。「ある程度の危険性とひきかえに」ユーザを切り替えるしくみである（sudo もそう）。便宜のためにやむなく使うものであって、RedHat などのように、ディストリビューションのデフォルトで有効にして配布していい類のものじゃないと思う。
- suexec が有効になっている場所（--with-suexec-docroot、--with-suexec-userdir で指定した場所）の下には他人が自分の権限で実行しても問題ないことが保証されているものしか置いちゃいけません。
- --with-suexec-docroot=/home はセキュリティホールになります。やめましょう。--with-suexec-docroot=/ なんてもってのほか。
- 1台のホストの中で suexec を使う CGI と使わない CGI を混在させないようにしましょう。
- ユーザに PHP を許可する場合、CGI の suexec 実行を許可しないか、あるいは mod_php ではなく、CGI として実行させましょう。
- suexec を使うのならば http://www.example.com/~hoge/ を http://hoge.example.com で見せたいなんてことを考えるのはやめましょう。
- SuExecUserGroup を使ってなくても、suexec のバイナリが存在しているだけで危険です。mv suexec suexec.bak とかやって名前を変えてもダメ。chmod u-s するか、いっそ削除すること。
_ 話はまったく関係ないんだが、suexec の和訳ドキュメントで とかげに注意とあるけど、これで何のことかわかる人いるのか？ 原文では Beware the Jabberwockとなっていて、こっちならばわかる人も多いだろうけど。これ、 鏡の国のアリスの有名な一節。有名な作品だからいろんな人が翻訳してるけど、Jabberwock をとかげと訳してる例はこの Apache ドキュメント以外にはたぶんないと思う。
_ Sendmail に比べたら遅れてるけど、Postfix にも dkfilterという DomainKeys（not DKIM） の実装はあるわけだ。んでも、wietse が本家 ML で Postfix 2.3 で DKIM（not DomainKeys）をサポートするよ、という発言を去年の夏だったか秋だったかにしてるので、じきに出るんだったらオフィシャルなものを待とうか、と思ったわけだ。
_ が、snapshot を見てもそんなのが実装されそうな気配は今もってまったく見えませぬ。だからといって dkfilter に手を出すのはなんか負けた気がする。
_ でもよく考えてみたら、Postfix のコンテンツフィルタってふつーに SMTP を喋ってるだけなので、Postfix 専用のものじゃなくてもいいんだよな。だったら Sendmail + dkim-milter を before-queue フィルタとして使っても可能なはず。……だったらはじめから Postfix なんか使わず Sendmail だけでいいじゃねーか。
_ そうはいってもものは試しなので、Postfix で Sendmail をフィルタにして DKIM をやってみた。両方の MTA をある程度知ってる人ならばどういじればいいのかはすぐにわかると思うのでいちいち設定方法は書かないが、まあかんたんだ。つーか、Linux の一部のディストリなんかだと、設定に入る前にふたつの MTA をひとつのホストで同時に起動できる状態にもっていく方がめんどくさそうだ（2台使ってもいいけど）。
_ やってみた結果: 一部問題はあるができました。バウンスメールのように envelope sender からドメインが拾えないものは HELO で名乗った FQDN を調べなきゃいかんのだけど、postfix から sendmail にリレーするときに HELO が変わっちゃうのでこれがおかしくなっちゃう。postfix は独自の拡張をやっててこれを保存して次段にわたすことも可能なんだけど、受ける方の sendmail がその拡張に対応してるわけがない。これはしかたないな。受けたメールの検証ではなく、こっちがサインして送る分にはたぶん問題ないとは思う。
_ ……なんてことをやって遊んでたのも束の間。きのう、本家 ML に こんなメールが流れた。
Postfix 2.3 will have support for domain keys. Instead of re-inventingというわけで、Postfix で独自に DomainKeys をサポートするのではなく、milter をサポートするから Sendmail 用のやつを借用して使ってね、ということになった模様。
software that already exists, I plan to add enough of the Milter
protocol so that people can use the plugins from sendmail.net.
That will happen in April._ なので、Postfix 2.3 では DKIM にかぎらず SenderID や各種アンチスパム、アンチウイルスフィルタも Sendmail 用のものがそのまま使えるようになるんだろう、きっと。とりあえず4月を待て、と。正式リリースは当分先になりそうだけど。
_ ただ、Sendmail は将来 X に移行するとアナウンスされてるけど、こっちでは pmilter という milter とは似て非ざる仕組みが使われる。milter と互換性なし。もっとも、smx は頓挫してやっぱりなかったことに、となりそうな気がしてならないんだが。
_ 風邪ひいたかなぁ？ きのうの夕方からあんまり調子よくなかったけど、今日はやたら喉が痛い。ほかには頭がちょっと重い程度で熱があるとかいうわけじゃないんだけど。
_ 冬の間はぴんぴんしてたくせに、春になったらこれだ。ちょっとおとなしくしておこう。
_ これとか これとか。ただ、 当の Nifty のプレスリリースの中に見当たらない。どういうこと？
_ ぷららが表明したばかりだから、追随する ISP がどんどん出てくるだろうことは、まあ 予想してたことなんだけど、なんだかなぁ。
_ いちおう念のため申しておくと、わしは馬鹿みたいなトラフィックを常時流し続けるユーザについても制限すべきでないと思ってるわけではない。ISP のバックボーンだって無限じゃないんだから、他のユーザの通信を圧迫するような使い方をするユーザにはちょっと遠慮してもらわなきゃ。そういう「量が多いから」という規制はむしろネットワークを守るために必要な措置だろう。そうではなく、帯域を圧迫してるわけでもないのに「そういうアプリを使ってるから」と通信内容によって規制することに反対なだけ。
_ ただよくわからんのは、 FTP や Windows Update さえも規制される(?)ということ。真偽は不明だが、Winny 制限じゃなくてほんとはトラフィック制限なのか？ それもトラフィックパターンによる制限？ まあ、トラフィック制限には反対しないわしだが、しかしこのコメントにあるような規制はポリシーとはまったく別の次元でアホだと思うぞ。
_ というか、Nifty って ダイナミック DNS サービスを提供してて、自宅サーバを公開しちゃうなんて使い方をしても問題ないはず。なのに、 自宅サーバも絞られる(?)らしい。これも真偽は不明だが、仮に真ならば、自分とこで提供してるサービスに沿った使い方もできないような規制をしてるということになる。いったい何を考えてんだ。関係ないけど、ISP ならば IP アドレスとユーザの対応は ISP 側でわかってるはずなんだから、DDNS サービスをやるのならば IP アドレスの更新はユーザにやらせるのではなく radius と連動させて自動化させるべきだと思うぞ。手抜きしやがって。
_ 今では定額常時接続がふつうになったけど、いっそまた昔みたいに従量課金に戻ることを考えてもいいのかもしれない。ただし時間課金ではなく転送量課金ね。携帯電話のパケット課金があるから、実際にそういう料金制度にしてもそんなに抵抗感なく受け入れられそうな気がする。