seccompによるシステムコールフィルタリング

なぜシステムコールを絞るのか

プロセスがカーネルに対してできることは、究極的にはすべて システムコール を通じて行われます。ファイルを開くのも、ネットワークに繋ぐのも、新しいプロセスを生むのも、入口はシステムコール1本です。逆に言えば、ここを絞れば、たとえコードが乗っ取られてもできることの上限をカーネル側で機械的に制限できます。

一般的な Linux には 350 を超えるシステムコールがありますが、ある特定のワークロードが実際に使うのはごく一部です。使わない ptrace や mount、keyctl、未使用の古い呼び出しを残しておくのは、攻撃者に余分な道具を渡すようなものです。seccomp（secure computing mode） は、この攻撃面（attack surface）をプロセス単位で削るための仕組みです。

2つのモード：strict と filter

seccomp には2つのモードがあります。

• SECCOMP_MODE_STRICT：最古のモード。許されるのは read / write / _exit / sigreturn の4つだけで、それ以外を呼ぶと即座にプロセスが殺されます。極端に厳しく、用途は限られます。
• SECCOMP_MODE_FILTER（seccomp-bpf）：BPF プログラムを与え、システムコールごとに何を許し何を拒むかを自分で定義できます。現在「seccomp」と言えばほぼこちらを指します。

filter モードは prctl(PR_SET_SECCOMP, ...) または専用の seccomp() システムコールで有効化します。後者はスレッドグループ全体への同期適用（TSYNC）などの拡張フラグを持ち、現在はこちらが推奨されます。

seccomp-bpf：何を入力に判定するのか

filter モードの BPF プログラムは、eBPF ではなく古典 BPF（cBPF）です。検証器付きの汎用 eBPF とは別系統で、ループのない単純な命令列だけを許す古い形式が使われます。システムコールが発行されるたび、カーネルはその文脈を seccomp_data という固定構造体にまとめ、これを入力としてフィルタを実行します。フィルタが見られるのは次の4つです。

struct seccomp_data {
    int   nr;                   /* システムコール番号 */
    __u32 arch;                 /* アーキテクチャ識別子(AUDIT_ARCH_*) */
    __u64 instruction_pointer;  /* 呼び出し時のIP */
    __u64 args[6];              /* 引数レジスタの値(最大6個) */
};

ここから重要な原則が2つ導けます。

第一に、arch の検査は必須です。システムコール番号は ABI ごとに異なり、同じ番号 0 が x86-64 では read、別の ABI では全く違う呼び出しを指します。arch を確認せずに番号だけで判定すると、攻撃者が別の呼び出し規約（例：32ビット互換 ABI）に切り替えてフィルタをすり抜けられます。詳しくは システムコールABIの内部 も参照してください。

第二に、フィルタが見られるのはレジスタに入った引数の生の値だけで、ポインタの指す先は読めません。open に渡されたパス文字列の中身でフィルタはできないのです。理由は TOCTOU（time-of-check to time-of-use）：BPF が値を読んでから実際にカーネルが使うまでの間に、別スレッドがメモリを書き換えれば検査が無意味になります。引数フィルタはスカラ値（フラグやファイルディスクリプタ番号など）に限る、というのが鉄則です。

アクション：拒否・許可・委譲

フィルタの戻り値が、そのシステムコールの運命を決めます。値は「上位16ビットがアクション、下位16ビットがデータ」という形式で、主なアクションは次のとおりです。

複数のフィルタが積まれている場合、各フィルタを順に実行し、最も「強い」アクション（優先順位が最高のもの）が採用されます。優先順位は KILL_PROCESS ＞ KILL_THREAD ＞ TRAP ＞ ERRNO ＞ USER_NOTIF ＞ TRACE ＞ LOG ＞ ALLOW の順で、上の表の並びがそのまま強さの順です。つまりどれか1つでも KILL を返せば殺され、ERRNO と ALLOW なら ERRNO が勝ちます。あるフィルタが一度課した制限を、後から積んだフィルタが覆せない仕組みです。

なお実装上は「戻り値（の下位ビットを除いたアクション部分）が数値的に小さいほど強い」という規則でほぼ説明できますが、唯一 KILL_PROCESS だけは値が 0x80000000 と最大でありながら最優先になるよう特別扱いされています。値の大小ではなく、上記の優先順位表で覚えるのが安全です。

ERRNO は実務で最も多用されます。拒否したいシステムコールを単に EPERM で失敗させれば、アプリは「権限がない」と認識して穏当に縮退でき、プロセスを殺すよりも互換性が高いからです。TRAP は同期 シグナル SIGSYS を送るので、ハンドラ内でログを取ったりエミュレーションしたりできます。

コンテナサンドボックスでの利用

seccomp が最も広く使われているのが コンテナ です。コンテナはホストのカーネルを共有するため、カーネルの脆弱性を突かれると隔離を越えられます。そこで、コンテナ内のプロセスが呼べるシステムコールを絞り、危険な呼び出し（mount、ptrace、kexec_load、各種 BPF/モジュール操作など）を初めから塞いでおきます。

主要なコンテナランタイムはデフォルトの seccomp プロファイルを持ち、典型的には JSON で「基本は拒否、リストにある安全なものだけ許可」というホワイトリスト方式を取ります。許可リストに載らない呼び出しは ERRNO で失敗させるのが既定です。これにより、おおよそ 40〜60 種の危険なシステムコールが標準で封じられます。

USER_NOTIF：判定を別プロセスへ委譲する

SECCOMP_RET_USER_NOTIF は新しく強力なアクションです。フィルタ自身は最終判断をせず、判定を信頼できる監視プロセス（スーパーバイザ）へ委譲します。流れはこうです。

1. 対象プロセスが対象のシステムコールを呼ぶと、カーネルはそれをブロックしたまま通知を生成する。
2. 監視プロセスはフィルタ設定時に得た通知用ファイルディスクリプタを ioctl(SECCOMP_IOCTL_NOTIF_RECV) で読み、誰がどの引数で何を呼んだかを受け取る。
3. 監視プロセスはポリシーに従い、SECCOMP_IOCTL_NOTIF_SEND で「この errno で失敗させる」「この戻り値で成功させる」などの応答を返す。
4. カーネルは応答に従って対象プロセスの呼び出しを完了させる。

これがなぜ画期的かというと、フィルタ単体では不可能だった引数のポインタ先を見た判定が、監視プロセス経由なら（後述の注意つきで）可能になるからです。たとえば「/safe/ 配下のパスへの open だけ許す」といった、文字列に依存するポリシーを外部で実装できます。

さらに SECCOMP_IOCTL_NOTIF_ADDFD を使えば、監視プロセスが自分で開いたファイルディスクリプタを対象プロセスのテーブルへ注入できます。対象が呼んだ open を監視側が肩代わりして実際に開き、その fd を返す——つまりシステムコールのエミュレーションまで委譲できるわけです。サンドボックス内のプロセスに直接権限を与えず、信頼できる仲介者が代行する構図です。

まとめ