1.
スレッド単位で権限分離を行うWebサーバのアクセス制御アーキテクチャ - mod_process_security - 京都大学 学術情報メディアセンター 松本 亮介

2.
目次• 背景• Webサーバ上の動的コンテンツの扱い• 動的コンテンツに関する問題• 本研究の概要• 既存のアクセス制御アーキテクチャ• 提案するアクセス制御アーキテクチャ• 実験• まとめ• 今後の課題

3.
背景• クラウドやホスティング（レンタルサーバ）の低価格化 – クラウドコンピューティングの普及 ⇒ より低価格が望まれる – 運用管理やHWコストの削減が課題• マルチテナント環境のクラウドやホスティングが重要 – リソース効率の向上 ⇒ Webサーバを複数ユーザーで共有 – 動的コンテンツの扱い ⇒ セキュリティが重要• Unix系OSのファイルのアクセス制御でセキュリティを担保 – （例）CGI実行方式のアクセス制御であるsuEXEC – CGI実行方式は性能が低い ⇒ もっと高速に動作させたい 今後はマルチテナント環境で 高速かつ安全に動的コンテンツを処理したい

4.
Webサーバ上の動的コンテンツの扱いCGI実行方式は性能が低い – 高速に動作するDSO実行方式を使いたい – DSO実行方式とは？ CGI実行方式 DSO実行方式 ボトルネックServer Process Server Process CGI Process Program Program インタプリタを組み込んでおくマルチテナント環境でもDSO実行方式を使って高速に処理したい

5.
動的コンテンツに関する問題従来のアクセス制御手法は不完全 – 従来のDSO実行方式のためのアクセス制御の問題 • プロセスの中で疑似的に権限を分離するアーキテクチャ • 不完全な仕様（性能劣化が大きい・セキュリティが弱い等） – CGI実行方式のためのアクセス制御の特徴 • プロセス単位で権限を分離するアーキテクチャ • アクセス制御とは関係なくCGI実行方式そのものの性能が低い – 実行方式毎にアクセス制御が存在していて煩雑 • 設定も複雑で開発者の敷居が高いマルチテナント環境で動的コンテンツを扱うには・・・ – CGI実行方式を使わざるを得ない – DSOを使うためには個別にデーモンやOSを起動して分離 ⇒ オーバースペックでリソース効率が悪い

6.
本研究の概要パフォーマンスを考慮したアクセス制御に着目 – CGI・DSO実行方式に両対応したアーキテクチャを設計 – Webサービスの高度化に耐えうる基盤のセキュリティ機構mod_process_securityの提案 – プロセスの中でスレッド単位で権限分離を行うアーキテクチャ • DSO実行方式の性能をいかしたままアクセス制御可能 • 複数あるアクセス制御手法を統一的に扱うアーキテクチャ – Linux上で動作するApache HTTP Serverを対象⇒ マルチテナント環境で動的コンテンツが安全かつ高速に動作

7.
Webサーバ上のアクセス制御の概要• Apache HTTP Serverの利用を想定 – 仮想ホスト方式で複数のユーザーでサーバ共有する状況 – 複数のユーザー領域のセキュリティを担保 • 本研究でのアクセス制御はBasic認証やIP制限等では無い• 基本的なWebサーバのアクセス制御のアーキテクチャ – 仮想ホストへのリクエストはユーザー権限で実行 – 他の仮想ホストへのアクセスを防ぐ – suEXECやmod_suid2、mod_ruid2等 単一のサーバプロセス Webサービス A × Webサービス B 単一のOS × × 仮想ホスト A × 仮想ホスト B それぞれにユーザー権限 を設定しアクセス制御

8.
親サーバプロセス CGI実行方式 （owner : root） suEXECアーキテクチャ 子サーバプロセス （owner : apache） fork() execve() suexec-programボトルネック CGI用 プロセス （owner : root） setuid(), setgid() execve() CGI用 プロセス （owner : user1） index.php terminate process(owner: user1)

9.
親サーバプロセス DSO実行方式 （owner : root） mod_ruid2アーキテクチャ Set cap(Linux capability) 子サーバプロセス （owner : apache） ボトルネック Set capability setuid(), setgid() Unset cap × 子サーバプロセス execve() （owner : user1） Set capability index.php setuid(), setgid() terminate process (owner: user1) × Index.php経由で 権限変更が可能

10.
提案するアクセス制御アーキテクチャ - mod_process_security -• スレッドを利用してボトルネックを低減 – 制御用スレッド単位で権限分離するアーキテクチャ • 動的コンテンツのリクエスト時にスレッド生成 • プロセスの生成・破棄は不要 • スレッドの生成・破棄により処理効率が上昇 – 実行方式で区別しない統一的アーキテクチャ • CGIやDSOに個別のソフトウェアを組み込む必要無し – Apacheモジュールで簡単に組み込み・設定可能 • 開発者が扱いやすい仕様

11.
親サーバプロセス CGI実行方式 （owner : root） mod_process_security 子サーバプロセス （owner : apache） Create thread, set cap 制御用スレッド （owner : apache） setuid・setgid, unset cap CGIの仕様 制御用スレッド （owner : user1） execve() CGI用プロセス （owner : user1） index.php terminate process destroy thread(owner: user1)

12.
親サーバプロセス DSO実行方式 （owner : root） mod_process_security 子サーバプロセス （owner : apache） Create thread, set cap 制御用スレッド （owner : apache） DSOの仕様 setuid・setgid, unset cap execve() 制御用スレッド （owner : user1） index.php (owner: user1) destroy thread

13.
実験• 1秒間に処理可能なレスポンス数を計測（response/sec） • クライアントからWebサーバに対して1秒間に複数リクエストを生成 • リクエスト数を変動させて、スループットが低下するか評価 • アクセス制御の適応有無でスループットに差がでるか評価 • phpinfo()を表示するプログラム（54KB）ベンチマークソフト（httperf 0.9.0） クライアントCPU Intel Core2Duo E8400 3.00GHzMemory 4GBNIC Realtek RTL8111/8168B 1GbpsOS CentOS 5.6 Webサーバ CPU Intel Xeon X5355 2.66GHz Memory 8GB NIC Broadcom BCM5708 1Gbps OS CentOS 5.6 Middle Ware Apache 2.2

14.
導入方法$ sudo cp mod_process_security.so /etc/httpd/modules/.$ cat /etc/httpd/conf.d/ps.confLoadModule process_security_module modules/mod_process_security.soPSExtensions .php .cgi .py .pl .rb# 静的コンテンツも動的コンテンツも適応したい場合は以下# PSExAll On$ sudo /etc/init.d/httpd restart

15.
スループット比較 3000 DSO(mod_process_security)は DSO（アクセス制御無し）と比較 2500 してスループット劣化は微小 DSO実行方式Responses/sec 2000 CGIのアクセス制御のス 1500 ループット劣化は微小 1000 CGI実行方式 DSO(mod_ruid2）は全てのRequestに対し 500 （次スライドで拡大） て、5前後のResponse/secでありスルー プット劣化が大きい 0 Requests/sec DSO(mod_process_security) DSO(アクセス制御無し） DSO（mod_ruid2) CGI(アクセス制御無し） CGI（suEXEC) CGI（mod_process_security)

16.
CGIに関するスループット比較 200 180Responses/sec 160 140 アクセス制御無し、 mod_process_secuiry、 120 suEXECの順に性能が高い。 100 100 200 300 400 500 600 700 800 900 1000 Requests/sec CGI(アクセス制御無し) CGI(suexec) CGI(mod_process_security)

17.
考察• mod_process_security採用によるスループット劣化は少ない – アクセス制御を組み込まない場合と比較 • CGI実行方式の場合はsuEXECよりもスループット劣化が少ない • DSO実行方式の場合はmod_ruid2よりもスループット劣化が少ない アクセス制御無しと 実行方式 アクセス制御手法 比較したスループット 低下率（平均） suEXEC 2.13% CGI mod_process_security 1.48% mod_ruid2やmod_suid2 99.9% DSO mod_process_security 0.19%

18.
まとめ• DSOの性能を生かした柔軟なアクセス制御手法 – OSレイヤーでの変更を必要としないアーキテクチャ – 柔軟なシステム設計に対応• マルチテナント環境で高いパフォーマンスとセキュリティ – 仮想マシンや個別のデーモンでの分離が不要 – リソース効率が良い ⇒ 低価格化に繋がる – DSOの性能とセキュリティを担保• 複数あったアクセス制御手法を統一 – CGIやDSO等区別しない – 導入方法もApacheモジュールで動作するため簡単 – 開発者が扱いやすい ⇒ マルチテナント環境やホスティングの低価格化を考慮した Webサービスの高度化に耐えうるセキュリティアーキテクチャ

19.
今後の課題• 今後の課題 – アクセス制御の導入を促していく • https://modules.apache.org/ で公開済み – Apacheの開発MLで標準機能とするかの議論 – Webサービスの高度化に耐えうる基盤設計 • セキュリティとパフォーマンス向上の一つの答え • 仮想ホスト単位でのリソース割当機能設計 • リソース割当の適応的決定の設計