デザイン -------- セキュリティがこのプロジェクトの重要な目標で、２番目に信頼性がきます。私は、 速度と拡張性と移植性も持ち続けるようにしています。 ことは、最低限必要な特権をもった複数のプロセスに別けられます。プロセス間のや りとりは、ほとんど信頼されません。小さなパフォーマンスの衝突があることを意味 しているとしても、root 権限で実行されているプロセスは、できる限り単純に振舞い 続けます。 imap-master ----------- root 権限で実行されます。いくつかは、それ自身によって、いくつかは他のプロセ スの要求によって、新しいプロセスは実行します。要求のあったプロセスは決して root 権限として起動されず、許可される UID の範囲も制限することができます。 全てを１つの UID で動作させる設定にすることも可能です。 root アクセスを持た ないどこかで imap を使用したいというときにのみ、とても便利です。 imap-login ---------- 特権を持たないユーザ(imapd)で実行されます。新しいクライアントの接続を受ける のと、クライアントが認証されるまでのコマンドの構文解析を扱います。それは、複 数の接続、もしくは接続あたり１プロセスで扱うどちらかであることができます。接 続あたり１プロセスにすることは、場合によってはより安全になり、常に権限奪取す ることを見つけますが、効率的ではありません。 SSL と TLS の接続も、全てログインプロセスによって、扱われます。imap プロセス への接続の fd を経由する代わりに、ログインは新しい匿名の UNIX ソケットを作成 し、 imap プロセスとクライアント間のやり取りを解釈するために使います。もし、 接続あたり１つのログインプロセスを使っているならば、実行中の SSL IMAP 接続の ために、実際は常に２つのプロセスがあることを意味します。 SSL プロトコルはとても複雑ですし、私はまだベータ版の gnutls を使用しているの で、それは完全に安全であるのか信頼はされないでしょう。 接続あたり１つのログインプロセスを使うことは、login が、いかなる特権もない chroot された環境で動作しているように、使う分にはとても安全であるでしょう。 攻撃者がプライベート SSL キーを入手しない限りは... １つのログインプロセスが複数の接続を扱うようにするならば、セキュリティ上の欠 陥は攻撃者が全ての他のユーザの接続を知ることになり、おそらく、それを乗っ取る か、もし平文での認証を使っている場合は、そのパスワードを盗むでしょう。 imap-auth --------- ユーザを認証することができる最低限の特権で実行します。PAM や shadow パスワー ドの場合は、それは root です。ユーザを認証するために、 imap-login と imap-master がやりとりをします。 * imap-login - LOGIN もしくは AUTHENTICATE コマンドを受信します - imap-auth プロセスで認証を初め、 AUTHENTICATE では完了するまでクライア ントと imap-auth がデータを渡し続けます。 - もし成功したら、imap-master に送信した cookie を受信します。 * imap-master - cookie のために imap-auth からデータを要求します。データには UID と GID とメールの形式と、(メールディレクトリのような)メールの特別 なデータが含まれています。指定があれば chroot ディレクトリも受信 します。 - UID が有効な範囲にあるのかと、与えられたディレクトリで、 chtoor できる許可があるかチェックします。 - 全てに問題がなければ、 imap プロセスに接続を渡します。 - 全てに問題がなかったかどうかに関係なく、imap-login に返答します。 - もし成功したら、接続の処理を止めて、 imap のプロセスが残りの世話を行 います。 * imap-auth a) 与えられたプロトコルでの認証要求を受信します。 - プロトコル特有の方法で要求を初期化します。 - もし失敗したら、クライアントに、失敗の応答を送信します。 - 成功したら、クライアントに cookie を送信します。 b) cookie を与えるために、認証要求の継続を受信します。 - cookie が有効か確かめ、もし有効でなければ返答します。 - プロトコル特有のデータを扱います。 - 認証が終了したかどうかに関係なく、クライアントに情報を返答します。 - cookie の有効時間をリセットします。 c) cookie に関係するデータを受信するために、要求を受信します。 - cookie が有効か確かめ、もし有効でなければ返答します。 - データに返答します。 cookie は特定の imap-login プロセスに関係がありますので、１つのプロセスは、 それと見せかけて他の誰かの認証要求を盗むことはできません。 imap ---- 特権なしで実行され、任意で chroot できます(安全であれば)。これは imapd の大 きな部分を占め、ほとんどの潜在的なセキュリティの欠陥がある部分です。 maildir と mbox 形式は、データ検索の高速化のために、いくつかの index ファイ ルを使っており、それが本当に必要でない限り、実際のメールファイルを開かれませ ん。この index ファイルは共有メモリマップを使ってアクセスされ、 fcntl() を使っ てロックされます。 ファイルが信頼されていない場合、メモリマップを使うことはセキュリティ上の問題 を生み出します。使用中のファイルを変更することによって、いくつかの関数でバッ ファオーバーフローを作り出すことは可能です。現在これは、ファイルの書き込みア クセス権限を制限することで問題にはならず、なので、攻撃者は imap プロセスを乗っ 取ることで、何らかの特別な権限を得ることができません。 メモリマップの問題以外に、 index ファイルは有効なデータを含んでいると信頼され ません。その全ては、使う前に確認が行われます。 共有メールボックスをサポートすることは、小さな問題となります。信頼されていな い index ファイルの使用をサポートをすることはできないので、それぞれのユーザ に別々の信頼された index を作成するべきでしょう。もし、ユーザが index ファイ ルのダイレクトアクセスをしないならば、それは任意に共有させることができます。 indexer ------- 使える余分な時間があると思われるときに、 indexer はメインのプロセスから起動 されるでしょう。それはユーザのメールボックスを作り、必要が感じられたときに、 インデックスの圧縮か再構築をします。実際のインデックス作業は imap プロセスが 行うように、 root の権限を使わないで行われます。 しかし、いずれにしてもこれはまだ計画段階です。 indexer はまだありません。