Postfix の概要 - セキュリティ

イントロダクション

仕様上、メールソフトウェアは潜在的に信頼できないソースからの情報を処理します。そのため、メールソフトウェアはユーザ権限で走る場合やネットワークに直接話しかけない場合であっても、最大の注意を持って書かれなければなりません。

Postfix は複雑なシステムです。初期のリリースは(コメントを削ると) 約30,000行のコードでした。これほど複雑なシステムでは、システムのセキュリティは単一のメカニズムには依存すべきではありません。もしそうであれば、たった一つのエラーでもメールシステム全体を危うくしてしまいます。そのため、ソフトウェアやその他のエラーからの損害を制御するために、Postfix は複数の防御レイヤーを使います。

最小の権限

ほとんどの Postfix デーモンプログラムは固定された低い権限で、 chroot された環境で走らせることができます。これは特にネットワークに去らされたプログラムに当てはまります: SMTP サーバと SMTP クライアント。低い権限と組み合わせている時であっても、システムが危うくならないという保証はしませんが、chroot(2) はかなりのハードルを加えることになります。そして我々は全てが少しずつ役に立っていることを知っています。

絶縁

Postfix はお互いの活動を隔離するために別々のプロセスを使います。特に、ネットワークからセキュリティに注意が必要な local 配送プログラムへの直接の道筋は存在しません。侵入者はまず、複数のプログラムを破らなければいけません。Postfix システムのある部分はマルチスレッド化されています。しかし、外界と接する全てのプログラムはシングルスレッドです。別々のプロセスにすることで共有アドレス空間内でのマルチスレッドよりもよく隔離できます。

制御下の環境

どの Postfix メール配送プログラムもユーザプロセスの制御下で走ることはありません。代わりに、ほとんどの Postfix プログラムは制御下の環境で走る常駐 master デーモンの制御下で、ユーザプロセスとの親子関係なしに走ります。このアプローチはシグナルやオ－プンされたファイル、環境変数、 UNIX システムが悪意をもつ可能性のある親から子へと渡される他のプロセス属性を含んだ攻撃手段を排除します。

Set-uid

Postfix プログラムはどれも set-uid しません。この概念の導入は UNIX の歴史において犯された最大の間違いです。Set-uid (とその弱い従兄弟の set-gid) はその価値以上にトラブルを引き起こします。UNIX システムに新しい機能が加わるたびに、 set-uid はセキュリティ問題を引き起こします: シェアードライブラリ、/proc ファイルシステム、複数言語のサポート、ほんの少し例をあげてみました。 Set-uid は例えばプロセス毎のファイルシステム名前空間のようないくつかの機能を導入することを不可能にし、それにより plan9 のような UNIX の後継者が魅力的になっています。

はじめは、ローカルプロセスが set-uid や set-gid コマンド、メールデーモンプロセスの助けを借りずにメールを送信できるようにするため、 maildrop キューディレクトリは world-writable でした。 maildrop ディレクトリはネットワークを通して入って来るメールには使われず、そのキューファイルは他のユーザには読めませんでした。

書き込み可能なディレクトリは悩む機会を開きます: ローカルユーザは誰か他の人の maildrop ファイルにハードリンクを作ることができるため、メールが出て行かなかったり、複数回配送されます; ローカルユーザは不要なファイルで maildrop ディレクトリを埋めつくし、メールシステムをクラッシュさせようとすることができます; そしてローカルユーザは誰か他の人のファイルを maildrop ディレクトリにハードリンクしてメールとして送らせようとすることができます。しかし、Postfix キューファイルは特別な形式になっています; 10^12 個の非 Postfix ファイルの内、有効な Postfix キューファイルとして認識されるのは 1個以下です。

#潜在的な誤動作の可能性のため、Postfix は world-writable な maildrop ディレクトリをやめ、メール投函用の小さな set-gid postdrop ヘルパープログラムを使います。　

信頼

概要の別の場所でも述べたように、Postfix プログラムはキューファイルや Postfix 内部 IPC メッセージの中身を信頼しません。キューファイルはファイルやコマンドのように注意を要する配送先への配送について、ディスク上に記録を持ちません。代わりに、ローカル配送エージェントのようなプログラムは直接入手した情報を元にセキュリティに注意を要する判断を試みます。

もちろん、Postfix プログラムはネットワークから受け取ったデータも信頼しません。特に、Postfix は送信者が与えたデータを環境変数を通じてエクスポートする前にフィルタします。Web サイトのセキュリティ災害から人々が学んだ教訓があるとすれば、これは次のことです: ネットワークからのどんなデータも shell に近付けてはいけない。フィルタリングは我々ができる最大限のことです。

大量の入力

バッファオーバーラン問題を防ぐために、文字列やバッファ用のメモリは動的に割り当てられます。
メッセージ入力中の長い行は適切なサイズの塊の並びに分割され、配送の際に再構築されます。
古いプラットホームでのバッファオーバーランを防ぐため、診断は syslog(3) インターフェースに渡される前に(ある単一の場所で!) 切り詰められます。しかし、システムコールやライブラリルーチンにデータが渡される前に全般的に切り詰めようとはしていません。プラットホームによっては、下にあるソフトウェアの脆弱性のためにソフトウェアがバッファオーバーラン問題を現すかもしれません。
不当に長いコマンドライン引数から守るために、特に何もしようとしません。UNIX カーネルが自身に制限を課しており、暴走プログラムや悪意あるユーザに対処するにはこれで十分でしょう。

その他の防御

メールシステムが高負荷で動けなくなることを防ぐため、あらゆるオブジェクト型のメモリ内インスタンス数は制限されています。
問題がある場合、ソフトウェアはクライアントにエラー応答を送ったり致命的なエラーで終了したり、失敗したプログラムを再起動しようとする前に一時停止します。これは問題を悪化させるだけの暴走状態を防ぐためです。