ホスティングサービスにおいて，仮想ホスト単位で権限を分離するためには，Web サーバ上のアクセス制御である suEXEC 等を利用する．しかし，既存の Web サーバにおけるアクセス制御方式は，プロセスの生成，破棄が必要となり，パフォーマンスが低く，Web API のような動的コンテンツに適していない．また，インタプリタやプログラム実行方式別に複数用意されており，システム開発者が扱いにくい．そこで，本稿では，コンテンツ処理時にサーバプロセス上で新規スレッドを生成し，スレッドで権限分離を行った上で，スレッド経由でコンテンツの処理を行うアクセス制御手法 “mod_process_security” を提案する．この手法は，高速に動作し，かつ，煩雑になっている Web サーバ上のアクセス制御手法を統一することで，システム開発者が扱いやすくなる．実装は，広く使われている Linux と Apache HTTP Server に対して Apache モジュールとして組み込む形式をとった．

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.00GHz
Memory 4GB
NIC Realtek RTL8111/8168B 1Gbps
OS 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.conf
LoadModule process_security_module modules/mod_process_security.so
PSExtensions .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
180
Responses/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サービスの高度化に耐えうる基盤設計
• セキュリティとパフォーマンス向上の一つの答え
• 仮想ホスト単位でのリソース割当機能設計
• リソース割当の適応的決定の設計