Docker における seccomp / seccomp-bpf によるsyscallフィルタリング

[hiramekun]

[claude]

Claude finished @hiramekun's task in 2m 11s —— View job

---

概要

seccomp(SECure COMPuting mode)は Linux カーネルの機能で、プロセスが呼び出せる syscall(システムコール)を制限するものです。現在の主流実装は seccomp-bpf で、BPF(Berkeley Packet Filter と同じ VM)プログラムを使って「どの syscall を」「どの引数のときに」許可/拒否するかを柔軟に判定します。Docker はコンテナ起動時に runc を通じてこの seccomp-bpf フィルタをコンテナプロセスに適用し、コンテナ内から呼べる syscall をあらかじめ絞り込んでいます。

flowchart TD
    A["コンテナ内プロセスが syscall を発行"] --> B{"seccomp-bpf フィルタで判定"}
    B -->|"許可 (SCMP_ACT_ALLOW)"| C["カーネルが通常通り syscall を実行"]
    B -->|"拒否・errno を返す (SCMP_ACT_ERRNO)"| D["syscall は失敗し errno を返す(プロセスは継続)"]
    B -->|"拒否・強制終了 (SCMP_ACT_KILL)"| E["プロセスを SIGSYS で強制終了"]
    B -->|"監査のみ (SCMP_ACT_LOG)"| F["syscall は実行しつつ監査ログに記録"]

Loading

コンテナ起動時の適用タイミングは、[[#66|namespace/cgroup のセットアップ]]の後、コンテナのエントリポイントを execve する直前です。

sequenceDiagram
    participant Runc as runc(OCIランタイム)
    participant Kernel as Linux カーネル
    participant Proc as コンテナプロセス

    Runc->>Kernel: namespace 作成・cgroup 設定(#66 参照)
    Runc->>Kernel: prctl(PR_SET_NO_NEW_PRIVS, 1)
    Runc->>Kernel: seccomp(SECCOMP_SET_MODE_FILTER, BPFプログラム)
    Note over Kernel: default.json などのプロファイルから\n生成したBPFフィルタをロード
    Runc->>Proc: execve() でエントリポイントを実行
    Proc->>Kernel: 以後の全 syscall がフィルタを通過

Loading

何が嬉しいのか

namespace や cgroup は「何が見えるか」「どれだけリソースを使えるか」を制御しますが、カーネルの攻撃対象面(attack surface)そのものは制限しません。Linux カーネルには 300 以上の syscall があり、その中にはコンテナ内の一般的なアプリケーションがまず使わないもの(mount、reboot、kexec_load、perf_event_open、ptrace の一部用法 など)や、カーネルの脆弱性が繰り返し見つかっている領域(ptrace、旧来の名前空間操作系など)が含まれます。

seccomp を使わない場合、コンテナ内で任意コード実行を許してしまうと、攻撃者はそれらの危険な syscall を自由に呼び出せてしまい、カーネル脆弱性を突いたコンテナエスケープや権限昇格のリスクが高まります。seccomp-bpf でホワイトリスト化しておくことで、

• コンテナエスケープの難易度を上げる:未知のカーネル脆弱性が syscall 経由で存在していても、そもそも呼び出せなければ悪用できない
• 多層防御(defense in depth):namespace(可視性の分離)・cgroup(リソース制限)・capabilities(権限の分離)・seccomp(syscall の制限)を組み合わせることで、1 つの機構が突破されても被害を限定できる
• 最小権限の原則を syscall レベルまで徹底できる:例えば Webサーバコンテナに mount や reboot の権限は通常不要なので、これらを塞いでおいても機能に影響しない

といったメリットがあります。実例としては、CVE-2016-5195(通称 Dirty COW)のような一部のカーネル脆弱性は、Docker のデフォルト seccomp プロファイルによって悪用経路が緩和されることが知られています。

詳細

Docker のデフォルトプロファイル

docker run はデフォルトで default.json という組み込みプロファイルを適用します。これは約 300〜350 ある syscall のうち、危険/不要とされる約 40〜50 個(カーネルバージョンにより変動)を拒否し、残りを許可するホワイトリスト方式です。ブロックされる代表例:

• mount / umount2 — ファイルシステムのマウント操作
• reboot — システムの再起動
• kexec_load / kexec_file_load — 実行中カーネルの入れ替え
• perf_event_open — パフォーマンスカウンタへのアクセス(サイドチャネル攻撃対策も兼ねる)
• ptrace(条件付き)— 他プロセスのトレース・メモリ操作
• add_key / keyctl — カーネルキーリング操作

プロファイルのカスタマイズ

# seccomp を無効化する(非推奨・デバッグ用途のみ)
docker run --security-opt seccomp=unconfined myimage

# 独自のプロファイル(JSON)を指定する
docker run --security-opt seccomp=./my-profile.json myimage

プロファイルの JSON では、defaultAction(該当しない syscall への既定動作)と syscalls の配列(個別の syscall ごとのアクション)を定義します。

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": ["read", "write", "open", "close", "execve"],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

さらに args フィールドで syscall の引数値まで条件に含められるため、「clone は呼べるが特定のフラグ(CLONE_NEWUSER など)のときだけ拒否する」といった細かい制御も可能です。

内部実装(seccomp-bpf の仕組み)

1. アプリケーションは seccomp(2) syscall(または互換の prctl(PR_SET_SECCOMP, ...))で BPF プログラムをカーネルに登録する
2. カーネルはそれ以降、そのプロセス(および fork/clone した子プロセス)が syscall を発行するたびに、syscall 番号・引数を BPF VM に渡してフィルタを評価する
3. フィルタの返り値(SCMP_ACT_ALLOW / ERRNO / KILL / TRAP / LOG / NOTIFY など)に応じてカーネルが動作を決める
4. runc は Docker/containerd から渡された OCI spec (config.json) 内の linux.seccomp セクションを libseccomp 経由で BPF プログラムにコンパイルし、コンテナプロセスの execve 直前にロードする

SCMP_ACT_NOTIFY は比較的新しいアクションで、カーネルではなくユーザー空間(監視プロセス)に syscall の可否判断を委譲できます。gVisor のようなサンドボックスや、特権なしで一部の特権 syscall を模倣したいツールで使われます。

注意点

• アーキテクチャ差異:同じ論理 syscall でもアーキテクチャによって番号が異なるため、プロファイルには architectures の指定が必要
• Kubernetes との関係:Kubernetes は長らく seccomp を PodSecurityContext や annotation 経由で明示的に有効化する必要がありましたが、v1.27 以降は RuntimeDefault(コンテナランタイムのデフォルトプロファイル)を使う設定が一般化しています。デフォルトでは Unconfined(制限なし)になっているクラスタもあるため、明示的な設定が推奨されます
• unconfined の乱用は避ける:デバッグのために --security-opt seccomp=unconfined を使うことはあっても、本番運用でこれを常用すると seccomp の防御層がまるごと失われる
• capabilities との違い:capabilities は「root 権限を細分化した権限単位」の制御、seccomp は「そもそもどの syscall を呼べるか」という更に低レベルの制御です。両者は独立した機構で、Docker は両方をデフォルトで有効にしています

参考リンク

• Docker docs: Seccomp security profiles for Docker
• moby/moby: default.json (デフォルトプロファイル)
• seccomp(2) — Linux manual page
• libseccomp
• Kernel docs: SECure COMPuting with filters
• Kubernetes docs: Restrict a Container's Syscalls with seccomp

関連ノート

• cgroup と namespace はどのように Docker のコンテナ化技術を支えているか #66 cgroup と namespace はどのように Docker のコンテナ化技術を支えているか — cgroup と namespace はどのように Docker のコンテナ化技術を支えているか #66 : namespace(可視性)と cgroup(リソース制限)の観点で Docker のコンテナ化を解説したノート。本ノートはそれらと並ぶもう一つの隔離機構である seccomp(syscall 制限)にフォーカス

---

• issue の内容を確認
• 重複・関連ノートの確認(cgroup と namespace はどのように Docker のコンテナ化技術を支えているか #66 が関連ノート、相互リンク済み)
• 回答の作成
• タイトル編集(「Docker における seccomp / seccomp-bpf によるsyscallフィルタリング」に変更)
• ラベル付与(infra, cs-fundamentals, type:concept)

[claude]

関連ノート: #68

[hiramekun]

@claude BPF/BPF VM って何？

[claude]

Claude finished @hiramekun's task in 42s —— View job

---

• コメント内容を確認(「BPF/BPF VM って何？」という質問)
• 回答を作成

---

BPF は Berkeley Packet Filter の略で、元々は 1992 年に BSD 系 OS 向けに考案された、カーネル内でパケットを高速にフィルタリングするための仕組みです(tcpdump/libpcap の中核技術)。全パケットをユーザー空間にコピーしてから判定すると遅いので、「小さな専用の仮想マシン(VM)をカーネル内に置き、そこでユーザーが与えたフィルタプログラムを直接実行する」という発想で生まれました。seccomp-bpf はこの VM の仕組みを syscall フィルタリングに転用したものです。

BPF VM の中身

BPF VM は、次のような非常にシンプルなレジスタマシンです(seccomp が使うのは "classic BPF" と呼ばれる旧世代の仕様)。

• レジスタ: アキュムレータ(A)とインデックスレジスタ(X)の 2 つだけ
• 入力データ: パケットならパケットのバイト列、seccomp なら struct seccomp_data(syscall 番号・引数・実行アーキテクチャなど)
• 命令セット: load(入力からAレジスタに値をロード)、jeq/jgt などの比較・条件分岐、ret(結果を返して終了)といった一握りの命令のみ
• プログラムの形: 命令の配列(struct sock_filter の配列)。各命令は「コード・ジャンプ先(true/false)・即値」の固定長フォーマット

例えば seccomp で write(2) だけを許可する cBPF プログラムはおおよそこういう形になります(擬似コード)。

BPF_STMT(BPF_LD | BPF_W | BPF_ABS, offsetof(struct seccomp_data, nr)), // syscall番号をロード
BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_write, 0, 1),                 // write なら次へ、違えば1命令スキップ
BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW),                          // 許可を返す
BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_KILL),                           // それ以外は強制終了

runc/libseccomp は、Docker の default.json のような人間可読な JSON プロファイルを、内部でこの cBPF 命令列にコンパイルしてからカーネルにロードします。前のコメントで触れた seccomp(SECCOMP_SET_MODE_FILTER, ...) は、まさにこのコンパイル済み BPF プログラムをカーネルに渡す syscall です。

なぜ「VM」という設計にしたのか

• 安全性: カーネルにロードする前に verifier(検証器) がプログラムを静的検証します。ジャンプは常に前方のみ(ループ禁止)・命令数の上限・不正なメモリアクセスの禁止などをチェックするため、ユーザー由来のプログラムでもカーネルをクラッシュさせたり無限ループさせたりできません
• 性能: カーネル内で直接実行される(場合によっては JIT コンパイルもされる)ため、syscall のたびにユーザー空間へコンテキストスイッチして判定する方式より大幅に高速です
• 柔軟性: 命令の組み合わせで「syscall 番号が X かつ第1引数が Y なら許可」のような任意の条件分岐が表現できます。これが seccomp プロファイルの args フィールドで細かい条件指定ができる理由です

補足: classic BPF と eBPF の違い

現代よく聞く "eBPF"(extended BPF)は、この BPF VM を大幅に拡張したもの(レジスタ数増加・マップ機能・より多くの命令・ネットワーク/トレーシング/セキュリティ用途)で、Cilium や XDP、様々な observability ツールで使われています。ただし seccomp が使っているのは classic BPF(cBPF) であり、eBPF ではありません(2 つは別の仕様・別の VM 実装です)。

参考:

• Linux kernel docs: BPF (Berkeley Packet Filter)
• Linux kernel docs: seccomp filter
• libseccomp

[claude]

関連ノート: #69

[claude]

関連ノート: #70