Home > Apacheについて | Linux | WEBについて | 研究について > mod_process_security – Apache上でスレッド単位で権限分離を行うファイルのアクセス制御アーキテクチャ(前半編)

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


「スレッド単位で権限分離を行うWebサーバ上のアクセス制御アーキテクチャ」として、3月15日16日に開催されたIA/IOT/SITE/ISMS合同研究会で発表してきた。概ね、好評だったように思う。ただ、やらないといけないことはいくつかあるので、そこはこれから大学で適宜やっていこうと思う。

まずは、この論文の概要としては、

    • 大規模Webサーバ上で大多数のユーザー(仮想ホスト)を一つのサーバで処理するようなマルチテナント環境において、ユーザー間のセキュリティを担保するためのアクセス制御を行う技術

である。(これまではsuEXECが使われていた)

これは、Webサービスが高度化していく時代において、低価格化がより望まれてきており、以前に増してマルチテナントで少ないサーバで多くのユーザー領域(仮想ホスト等)を共有して、かつ、セキュアな仕組みにしておきたいという背景がある。

実際のユースケースとしては、以下のような状況で使えるように思う。

    • モジュール版PHPやPerl等(DSO版)を安全かつ高速に仮想ホスト環境で実行可能
    • CGIやDSOのアクセス制御を統一的に扱うことが可能(suEXECとかいらない)
    • FastCGIももちろんアクセス制御された状態で動作可能

結局何ができるかというと、CGIやDSO及びFastCGI等の実行方式に関わらず、仮想ホスト環境においてsuEXECのような動的コンテンツをファイルのユーザー権限で実行することが可能であるということ。さらに、DSOを実行させた場合でも性能劣化が非常に少なくなっている。

では、具体的にどういう処理をしているのかを簡単に説明する。(詳しくは論文で

 

実行方式について

 

まずは、CGI実行方式とDSO実行方式は以下の図のような差がある。

CGIは実行時に、シェバン行からインタプリタのバイナリを探して、fork()してexecve()するため、実行毎に新規でプロセスの生成及び実行後のプロセス破棄が生じるため、性能が低い。一方で、DSOはインタプリタをサーバプロセスに組み込んでおく事で、サーバプロセスが直接プログラムを実行できる仕組みをとっている。

 

従来のCGIのアクセス制御について

 

では、CGIにアクセス制御、例えばsuEXECを導入した場合は、どのようにプログラムをファイルのユーザー権限で動作させているのか。それが以下の図となる。

このように、CGIを実行する際にsuEXECのラッパープログラムを介して実行することで、一旦setuid-rootなラッパープログラムによってroot権限のプロセスになり、そしてプロセス自分自身をファイルのユーザー権限(この場合はuser1)に変更してプログラムを実行する。これによって、ユーザー権限で実行され、仮想ホストのマルチテナント環境でも、仮想ホスト間でのアクセスを制御しセキュリティを担保している。

しかし、CGIは遅い。マルチテナント環境であってもDSOで実行したい。現状、DSOのアクセス制御としてはmod_ruid2があり、それを適応するとどうなるか。

 

従来のDSOのアクセス制御とその問題について

 

まず、サーバプロセスにLinuxCapabilityを与えておく。これは、rootの権限を細分化したもので、今回の場合は一般ユーザーであっても権限変更可能な特権を子サーバプロセスに与える。これによって、リクエストのあったプログラムの権限に子サーバプロセス自体の権限を変更し、プログラムを実行する。さらに、子サーバプロセスの生成・破棄は非常に処理に時間がかかるので、プロセスを再利用するために、再度元のapacheユーザー権限にプロセスの権限を変更して、次のリクエストを待ち受ける。これが、mod_ruid2のアーキテクチャである。

しかし、これは一つ大きな脆弱性を抱えている。子サーバプロセスに権限変更の特権を保持させていることは、index.php経由で権限変更が可能なことを意味する。これでは、プログラム経由で自由に権限変更をして、悪い事が沢山できてしまう。

そこでこれを防ぐために、以下のような実装変更を行う。

子サーバプロセスの権限をプログラムの権限に変更した段階で、きちんと権限変更の特権であるCapabilityを破棄しておく。これによって、プログラム経由で権限変更できなくなる。しかし、同時に元の子サーバプロセスの権限であるapacheに変更できなくなるので、子サーバプロセスを破棄しなければならない。このように、結局子サーバプロセスの生成・破棄が生じて、大幅に処理が低下する。せっかく、処理を早くするためにDSO実行方式を使っているのに、アクセス制御を組み込むことで、性能が大幅に劣化してしまっては意味がない。実験してみると、CGIよりも性能が低い程度にまで落ち込む

では、どうするか。

これらを解決するためにmod_process_securityが生まれたのである。

意外と多くなってしまったので、次回に続く・・・

書きました: mod_process_security – Apache上でスレッド単位で権限分離を行うファイルのアクセス制御アーキテクチャ(後半編)

コメント:0

コメントフォーム
Remember personal info

CAPTCHA


トラックバック:8

このエントリーのトラックバックURL
http://blog.matsumoto-r.jp/wp-trackback.php?p=1972
Listed below are links to weblogs that reference
mod_process_security – Apache上でスレッド単位で権限分離を行うファイルのアクセス制御アーキテクチャ(前半編) from 人間とウェブの未来
pingback from 人間とウェブの未来 » mod_process_security – Apache上でスレッド単位で権限分離を行うファイルのアクセス制御アーキテクチャ(後半編) 12-03-19 (月) 14:20

[…] mod_process_security – Apache上でスレッド単位で権限分離を行うファイルのアク…の続き。 […]

pingback from 人間とウェブの未来 » mod_process_security – Apache上でスレッド単位で権限分離を行うファイルのアクセス制御アーキテクチャ(前半編) | WordBuff.in 12-03-23 (金) 12:19

[…] […]

pingback from 人間とウェブの未来 - Apache 2.4.1のmod_luaでApacheに介入する(mod_rewriteの終焉?) 12-03-26 (月) 20:42

[…] たったの2行。コールバック関数に登録するのに、ApacheモジュールにC言語で書くとそれだけでも面倒な作業になるのだが、こっちはシンプルで非常に直感的だ。ちなみに、Apacheモジュールだとこんな風に書く。(mod_process_securityを参考に) static const command_rec process_security_cmds[] = {   AP_INIT_FLAG("PSExAll", set_all_ext, NULL, ACCESS_CONF | RSRC_CONF, "Set Enable All Extensions On / Off. (default Off)"), AP_INIT_TAKE1("PSMode", set_mode, NULL, RSRC_CONF | ACCESS_CONF, "stat only. you can custmize this code."), AP_INIT_TAKE2("PSMinUidGid", set_minuidgid, NULL, RSRC_CONF, "Minimal uid and gid."), AP_INIT_TAKE2("PSDefaultUidGid", set_defuidgid, NULL, RSRC_CONF, "Default uid and gid."), AP_INIT_ITERATE("PSExtensions", set_extensions, NULL, ACCESS_CONF | RSRC_CONF, "Set Enable Extensions."), {NULL} };   static void register_hooks(apr_pool_t *p) { ap_hook_post_config(process_security_init, NULL, NULL, APR_HOOK_MIDDLE); ap_hook_handler(process_security_handler, NULL, NULL, APR_HOOK_REALLY_FIRST); }   module AP_MODULE_DECLARE_DATA process_security_module = { STANDARD20_MODULE_STUFF, create_dir_config, /* dir config creater */ NULL, /* dir merger */ create_config, /* server config */ NULL, /* merge server config */ process_security_cmds, /* command apr_table_t */ register_hooks /* register hooks */ }; […]

pingback from 人間とウェブの未来 - IA/IOT/SITE/ISME 合同研究会の発表資料(mod_process_security) 12-04-01 (日) 16:42

[…] mod_process_security – Apache上でスレッド単位で権限分離を行うファイルのアク… […]

pingback from 人間とウェブの未来 - mod_request_dumperでApacheのrequest_recをMongoDBに入れてみた 12-05-23 (水) 9:02

[…] これは一見悪い結果のように見えるのですが、非常に軽い静的ファイルで1/4くらいであれば、経験上、その他の動的コンテンツやそれなりの大きさの静的コンテンツではそこまでボトルネックにならない値だと考えています。性能劣化としては、1リクエスト毎にスレッドの生成破棄を行う程度の劣化率だと思われます。詳しくは、mod_process_securityの検証結果を見て頂けると良いかと思います。 […]

pingback from 人間とウェブの未来 - mod_mrubyでApacheのリバースプロキシを実装してみた 12-06-16 (土) 22:12

[…] あ、そうそう、mod_vhost_aliasとsuEXECと併用できないとか、mod_perlやmod_phpはApache権限で動くからセキュリティ的に弱い、といった問題はmod_process_securityで解決していますので、動的コンテンツをコンテンツのuid、gidで動的に実行するモジュールはmod_process_securityのアーキテクチャの記事をご覧ください。 […]

pingback from 人間とウェブの未来 - 国際会議SAINT2012でApacheの新しいアクセス制御の発表をしました 12-07-20 (金) 16:01

[…] mod_process_security(前半編) […]

pingback from 人間とウェブの未来 - 僕が考える最強の超高集積型Webホスティングシステム! 12-09-27 (木) 2:34

[…] そこで、この問題を解決するために、mod_process_securityを開発しました。これを使えば、DSOであっても実行時に制御用スレッドを挟む事で、スクリプトを顧客の権限で実行する事ができ、他の顧客領域にアクセスできなくなります。また、性能もDSOとほぼ同程度の速度(CGIの数倍以上)でスクリプトを実行する事ができます。詳しいアーキテクチャについては、「mod_process_security – Apache上でスレッド単位で権限分離を行うファイルのアクセス制御アーキテクチャ」を見てください。 […]

Home > Apacheについて | Linux | WEBについて | 研究について > mod_process_security – Apache上でスレッド単位で権限分離を行うファイルのアクセス制御アーキテクチャ(前半編)

検索
フィード
メタ情報

Return to page top