Linux Capabilityの全て

Linux Capabilityの全てはこの式を噛み締めること。

意外と味がでてくる。

PはスレッドのCapability。

FはファイルのCapability。

ダッシュがついたら新しいCapability。

[important]

P'(permitted)   = (P(inheritable) & F(inheritable)) | (F(permitted) & cap_bset)

P'(effective)     = F(effective) ? P'(permitted) : 0

P'(inheritable) = P(inheritable)

[/important]

Permittedやらは前言ったとおりで、cap_bsetはbounding set。

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 *のみ* をセットし直すことは可能だ」

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

これからやりたい事

  • Apacheの動的リソース管理 -> いずれはKernelのレイヤーで
    • リソースを時系列データとして扱い変化点を検出
    • 外れ値は検知しない
    • 各リソースの時系列データの相関を時系列データとして見る
    • SDARの基本モデルであるARモデルをARMAモデルなどの多次元対応
    • 意味のあるリソース情報の選択
  • Kernelから見たApacheの新しいセキュリティモデル
    • ApacheのsuEXECから脱却
    • Capabilityの基本設計を言及
    • WrapperではなくプロセスやファイルからのApacheのセキュリティモデルを提案
    • Kernelに近いセキュリティのアプローチからApacheのセキュリティモデルを設計
    • SE-PostgreSQLのようなSE-Apaceh的モデルの提案