mod_ruid2はgroupsを元の状態に戻せないのでpatch作成

mod_ruid2はDSO版のPHP等を効率良くある程度安全に使うにはかなり良いモジュールである。

「ある程度」と書いたのは、それなりに脆弱性があるためで、それは今後紹介するとして今回はそこに関しては言及しない。

簡単なmod_ruid2の動作だが、preforkされているサーバプロセスに対してリクエストがあった場合、サーバプロセスそのものをリクエスト対象のファイルの権限(uidやgid等)もしくは任意 の権限に変更し、そのごリクエスト処理を行なって、最後に変更されたサーバプロセスの権限を元の権限に戻す。このあたりの細かい話はLinux Capabilityの話になってくるので省略する。

ところが、今回色々試していると、サーバプロセスのユーザー、例えばapacheユーザー等がgroupsの設定を持っていた場合には、groupsの権限は戻せない実装になっていた。そのため、ある ディレクトリをgroupsで設定された別のgroup、例えばwww-admin等で権限設定されていた場合、元のapacheユーザーはwww-adminにアクセスできるが、mod_ruidの処理後そのgroups設定がなくなってしまい、アクセスできなくなる。

続きを読む

拡張子によってApacheモジュールの処理を適応するか判断するpatch(mod_ruid2版)

ブログはかなり久々。

会社での実装でいいものが生まれたりするのが、なかなかそれを社外に公開するわけにはいかず、あまり技術的な創作物をブログに書くことができなかった。今は、会社2割大学8割のような比率で研究しているので、最近作ったpatchでも紹介する。

実装対象は、DSO版PHPなどでもsuEXECのようなアクセス制御が行えるmod_ruid2に対してpatchを書いてみた。

mod_ruid2は実装上、モジュールとしてApacheに読み込んだ場合、すべての動的コンテンツ実行時にサーバプロセスをsetuid、setgidしてしまう。しかし、ある特定の環境下では、任意の拡張子(.phpや.py)においてのみモジュールの処理を実行させたい場合がある。Filesディレクティブ等を用いて、ファイルを指定するやり方もあるが、mod_ruid2等ではそういう設定記述は禁止されている。

そこで、mod_ruid2に2つの機能を実装した。

続きを読む

Apache hook関数

Apache HTTP Serverでとても重要なhook関数。

必ず忘れて、The Apache Modules Bookを読みなおしちゃうのでまとめておく。

 

 
分類 hook関数名 用途
設定初期化系 ap_hook_open_logs() ログのオープン
ap_hook_pre_config() pre_config実行時
ap_hook_post_config() initルーチンとかを呼ぶ時
ap_hook_optional_fn_retreive() オプションとして登録された関数の取得
プロセス初期化系 ap_hook_pre_mpm() scoreboad作成時
ap_hook_child_init() 子プロセス起動直後
コネクション処理系 ap_hook_create_connection() コネクション処理時、あまり使わない
ap_hook_pre_connection() コネクション処理の直前
ap_hook_process_connection() プロトコルの処理時
リクエスト処理系 ap_hook_create_request() リクエスト生成時に、モジュールがrequest_configを生成したい時
ap_hook_post_read_request() リクエストが読み込まれてすぐに、モジュールでリクエストを処理したい時
ap_hook_quick_handler() リクエストの処理が始まる前
ap_hook_translate_name() URIをファイル名に変換する時、モジュールで変換したい時
ap_hook_map_to_storage() モジュール自身のコンテキストに従ってper_dir_configを設定したい時
ap_hook_header_parser() モジュールでヘッダを参照したい時、post_read_request()で代用
ap_hook_access_checker() クライアントが認証受ける前に追加でアクセスチェックをしたい時
ap_hook_check_user_id() リクエストヘッダからユーザーIDやパスワードの確認時
ap_hook_auth_checker() リクエストされたリソースへのアクセスが認証されているか確認時
ap_hook_type_checker() コンテントタイプ等を設定したりする時
ap_hook_fixups() レスポンス内容の生成を変更する最後の機会
ap_hook_handler() レスポンス内容の生成時
ap_hook_log_transaction() レスポンス返した後のロギング時
エラー処理系 ap_hook_insert_error_filter() エラーの応答時にフィルターを挿入する時
ap_hook_error_log() エラーログ生成時
その他 ap_hook_default_port() リクエストで利用したデフォルトのポートを返す時
ap_hook_http_scheme() リクエストからHTTPメソッドを回収する時、用途はHTTPメソッドの容易な拡張
ap_hook_fatal_exception() 例外処理時
ap_hook_get_mgmt_items() 操作状況をモジュール提供
ap_hook_suexec_identity() suexecのID取得

 

うーむ、多い。

これで今後の作業は楽になるだろう。

Linux Capabilityに関するまとめと更なる疑問

Capabilityのビットの種類


プロセスに関するLinux Capabilityには4種類のビットがあり、それぞれ役割が異なる。

[note]

P: Permitted

E: Effective

I: Inherited

B: Bounding

[/note]

この中で、プロセスがCapabilityを必要とする操作をOSに対して要求した際、評価されるのはEビットである。しかし、Eビットを決定する過程で他のビットも利用される。

続きを読む

Linux Capabilityに関する疑問

Capabilityをセットする際、セットしたいCapability *以外* のCapabilityを落としすことでCapability機能を実現している。その *落とした* Capabilityを再度同じプロセスにセットし直せない様な仕様になっているのは、どういうリスクを想定しているのだろうか。

もう少し踏み込んでみよう。

例えば、あるプロセスにあるCapabilityのみをセットした状態にし、それ以外のCapabilityは落とした状態とする。
そこで、

「プロセスにセットしてあるCapabilityを一旦落とした後、再度、直前までセットしていたCapability *のみ* をセットし直すことは可能だ」

という仕様を許可することは、リスク的にどういったものが考えられるのだろうか?