要約

  • 特権付きmasterの構成では、大半のサービスが初期化時に必要なファイルを開いた後、リクエスト処理前にrootを放棄する。四つの配送サービスは、限定された処理のために保存されたrootの実効IDを残す。
  • 非特権masterは監督プロセスの権限を下げる一方、内部の分離を弱め、サービス侵害時に秘密鍵やログへ届きやすくする。製品文書が認める本番構成も限られる。

メールサーバーが「rootで動いているか」と尋ねても、危険の場所は見えてこない。Postfixの構造からは、どのプロセスが、要求処理のどの段階で、どのファイルや他の利用者の資源に対して権限を必要とするのか、という問いのほうが有効だと分かる。

SMTPまたはQMQPで受けたメッセージは、まずネットワーク側のPostfixサービスに届く。サービスは入力を確認し、エンベロープと本文をcleanup(8)へ渡す。cleanupはキュー投入前の最終処理を行い、メッセージをincomingキューに書き込んでqmgr(8)に到着を知らせる。キュー管理プロセスが次の配送エージェントを選ぶ。activeキューには上限があるため、大量の滞留があっても、管理プロセスが全メッセージを一度に開く必要はない。常駐するmaster(8)は各サービスを監視し、必要になった時点で起動し、設定されたプロセス数の上限を守る。

監督プロセスと、リクエストを処理するサービスは別の役割を担う。Postfixの特権付きmaster構成では、サービスがroot権限で起動してTLS秘密鍵やデータベースのパスワードなどを読み、その後、リクエストを処理する前にrootを取り消し不能な形で放棄できる。現在のセキュリティ文書によれば、その後にサービスが侵害されても、これらのファイル、データベース、ログは開けない。rootは初期化や権限の振り分けに関わるのであって、ネットワークに面した全プロセスに生涯与えられるとは限らない。

この方式には例外がある。大半のサービスはrootを完全に手放すが、local(8)、pipe(8)、spawn(8)、virtual(8)は保存されたrootの実効IDを保持する。対象ユーザーとして処理したり、メールボックスや外部コマンドなどPostfix以外の資源を扱ったりするためだ。Postfixは、rootによる内部サービス間の権限分離と、外部ファイルやプログラムに触れる際の権限制御を区別している。「rootプロセス」という一語では、この二つの境界を説明できない。

Wietse Venemaは2010年のLISA講演で、Postfixを分割型の最小権限アーキテクチャと説明した。メールの受信と配送を低権限のchrootプロセスで分けるファイアウォール設計を、影響を受けた例の一つに挙げている。また、通信基盤を整えた後なら、小さなプログラムに分けることが保守に役立つと述べた。これは当時の設計者自身による説明であり、現在のデーモン数や安全性の測定結果ではない。現在の公式資料は、受信、整形、キュー管理、配送が別サービスとして動くことを示している。

今回の変更は、masterからrootを取り除けばシステム全体が自動的に安全になるという主張ではない。Postfixの文書によると、Venemaは2025年、未公開の統合テスト用に非特権master(8)を実装した。2026年に顧客から問い合わせを受け、限られた本番用途に使えるよう改良して文書を追加した。このモードではmasterはrootではなく固定のpostfixユーザーで動く。サービスは初期化中もリクエスト処理中も同じPostfix権限を使う。Postfixは、その結果、内部の権限分離や、外部ファイル、メールボックス、外部コマンドに対する従来の制約を維持できないと説明する。

違いはファイル権限に現れる。秘密鍵ファイルはpostfixユーザーから読める必要があり、サービスが侵害されれば鍵を読まれる可能性がある。任意のPostfixログはpostfix所有でなければならず、侵害されたサービスが閲覧、改変、削除できる。設定ファイルをpostfix所有にしてはならない。複数インスタンスを使う場合も、すべてを特権付きmasterにするか、すべてを非特権masterにする必要がある。混在はできない。

本番で使える範囲は狭い。Postfixは、全メッセージをSMTPまたはLMTPで転送する構成について、非特権masterを本番利用可能としている。一方、ローカルサービスがPostfix以外のプログラムを実行する構成や、メールボックスファイルへ配送する構成では、本番利用を禁止する。文書にあるリスクの一つは、利用者の.forwardに書かれたコマンドが、宛先ユーザーではなくpostfix権限で実行され、その利用者がメールシステムを操作できてしまうことだ。警告は構成を特定しているが、曖昧ではない。

設計上の教訓は「rootは安全」でも「rootは危険」でもない。権限を変えると、リスクの位置も移る。非特権masterは限定された中継構成に合うかもしれないが、各サービスが秘密鍵とログにアクセスできるようになる。特権付き構成なら、初期化後の権限放棄によってそれらを隔てられる。masterの実行ユーザーを変える前に、配送経路を洗い出し、各サービスが触れられるファイルとコマンドに選択したモードが合うか確認すべきだ。公開文書は選択の条件を示すが、どちらが広く使われているか、実環境でどんな安全性の結果が生じたかは示していない。

出典