mod_process_security – Apache上でスレッド単位で権限分離を行うファイルのアクセス制御アーキテクチャ（後半編）

mod_process_security – Apache上でスレッド単位で権限分離を行うファイルのアクセス制御アーキテクチャ（前半編）の続き。

• ソース

前半編では、Apacheにおける従来のファイルのアクセス制御の問題をパフォーマンスやセキュリティの観点から説明した。簡単にまとめておくと、

• 従来はCGI実行方式やDSO実行方式毎にアクセス制御が存在していた煩雑
• CGIはそもそもアクセス制御有無に関わらず性能が低いしプロセスの生成も大規模に適していない
• FastCGIはプロセスを複数起動させておかなければならないので、大規模に適していない
• DSOのアクセス制御は性能を優先した場合はセキュリティが弱い
• DSOのアクセス制御はセキュリティを優先した場合は性能がCGIよりも低い
• DSOをマルチテナント環境で使う場合はユーザー毎のサーバプロセスや仮想マシン等での権限分離が必要でリソース効率が悪い
• 仮想ホスト環境で大規模を想定した効率のよいDSO実行方式を考慮したアクセス制御が欲しい

DSO使って高速にプログラム実行させて、かつ、仮想ホスト使ってサーバリソース節約して大規模で高速なシステム構築したい。（そのためにはセキュリティも担保しないといけない）

これらの問題を解決したのが、mod_process_securityなのである。LinuxのApache2系のpreforkに対応している。（2.4系は試していません^^;）

では、アーキテクチャを説明していく。（詳しくは論文を参照）

 

mod_process_securityのアーキテクチャ

mod_process_securityを組み込んで、CGIを実行した場合は以下のようなアーキテクチャをとる。

まず、プログラムにリクエストがあった場合は、一時的に子サーバプロセスが制御用スレッドを生成する。そしてそれと同時に、制御用スレッドに対して、LinuxのCapabilityの内、ユーザー権限の変更可能な特権を与えておく。そして、リクエストのあったプログラムのファイルの権限にスレッド自身の権限を変更して、同時に特権を破棄する。その後、スレッド経由でプログラムを実行する。CGIの場合は上記のような仕様に乗っ取って動作する。

一方、DSO実行方式の場合はどうか。今回最も意識した部分で、仮想ホスト環境等でのDSO採用を実現できる。それが以下の図である。

CGIの場合と同様に、制御用スレッドを生成しておく。そして、そのスレッドには、子サーバプロセスに組み込まれたインタプリタの情報がコピーされているので、制御用スレッドが直接プログラムを実行することができる。これによって、DSOであってもプログラムのファイルの権限でプログラムを実行できる。さらに、プログラム実行時にはスレッドに権限変更の特権を保持させていないので、従来のDSOのアクセス制御に関するセキュリティ問題の観点においてはセキュリティ的に問題は無いと考えている。

上記のようなアーキテクチャをとったため、DSOの従来のアクセス制御手法は安全にプログラムを実行するためには、子サーバプロセスの生成破棄が必要であったのに対して、mod_process_securityではスレッドの生成破棄にとどまるため、非常に性能劣化が改善されたと思われる。また、OSレイヤーで特殊な設定（例えば、システムコールのフックによってサーバプロセスのみに権限変更の特権を限定する）等も必要としないため、柔軟なシステム構築が可能だと考えている。

性能劣化の実験

では実際に、性能劣化面を実験してみた。

導入方法

導入方法も非常に簡単で以下のようになっている。基本的には拡張子を指定する仕組みをとった。また、動的にファイルの権限を取得するため、設定には要注意であるが、mod_vhost_aliasとの併用も可能になっている。

実験結果

では、実験結果である。

最初に述べた通り、従来のDSOのアクセス制御であるmod_ruid2を安全に扱おうために、子サーバプロセスの生成破棄を採用すると、ダントツで性能が悪くなっている。CGIが200前後レスポンスを返せているのに対して、5程度しか返せていない。アクセス集中においては、使い物にならない程の性能だと言える。

また、CGIとDSOが大きく性能に差があることも分かる。当然、仮想ホスト環境であっても、DSOを使いたくなるだろう。これまでは、それが実現できなかったが、mod_process_securityによってそれがようやく可能になる。mod_process_securityの性能劣化は、動的コンテンツを扱う上ではほとんどなく、DSOのアクセス制御を適応していない状態と同等のスループットがでている。

CGI実行方式部分を拡大すると以下のようになる。

CGIにおいても、suEXECより性能劣化がわずかに少ないことが分かった。誤差の範囲内で、ほぼ同等だと考えている。

では具体的なスループット低下の数値はこうなった。

最後に

このように、CGIやDSOの従来のアクセス制御よりも性能劣化が改善されており、また、CGIやDSO等の実行方式を統一的に扱うことができるアーキテクチャをとったところにも優位性があると考えている。

是非、ホスティング業界の方々は頭を悩ませていた所だと思うので、是非使ってみてはどうかと思う。そして、問題があればどんどんフィードバックして頂きたいなぁなんて思っています。

研究会の質疑応答では、やはりLinux以外のOSの対応を考えてみてはどうか、等の意見を頂いているのでBSDでどう実現できるかを考えていきたいとは思っている。また、スレッドのセマンティクスがどうなのかもこれから細かく見ていきたい。