Linuxサンドボックスの隔離境界をどう捉えるか

Linuxで「sandbox」と呼ばれる仕組みは、同じ言葉でも隔離境界がかなり異なる。

大きく分けると、次の層として考えると整理しやすい。

1. プロセス自身の権限を削る — Landlock、seccompなど
2. Linux kernelのnamespace等で隔離する — 一般的なコンテナ
3. host kernelとの間に別のsystem call実装を挟む — gVisor
4. 別guest kernelを持つ — Kata Containers、FirecrackerなどのVM/microVM

重要なのは、「sandboxという名前」ではなく、信頼していないコードから見て、どのコードがsecurity boundaryになっているかを見ることだ。

通常のコンテナでは、namespaceやcgroupで見える範囲や資源を分離しても、sandbox内のプロセスはhost Linux kernelのsystem call実装を利用する。gVisorはこの間にuserspace kernelを置き、Kata ContainersやFirecrackerはguest kernelを置く。

一方、Landlockは別環境を作るのではなく、現在のプロセスとその子孫に対してアクセス権を不可逆に狭める方向の仕組みである。この違いは、起動コスト、互換性、運用負荷、想定する脅威モデルに直結する。

AIエージェントやCIのように、生成されたコードや依存パッケージのinstall scriptまで実行する環境では、少なくとも次の問いを分けて考える必要がある。

• host filesystemへのアクセスをどこまで許すか
• network egressをどこまで許すか
• host kernelを直接攻撃面に含めてよいか
• sandboxを何千・何万単位で起動する必要があるか
• suspend/resumeやsnapshotが必要か
• OCI imageとの互換性をどこまで重視するか

関連する実装として Landlockは非特権プロセス自身が権限を削るLSM、seccomp user notificationは「ポリシー判定器」ではない、SandlockはLandlockとseccompを組み合わせた軽量プロセスsandbox、gVisorはユーザー空間カーネルでhost kernel syscall面を減らす、Kata Containers 4.0はOCI UXのままVM境界を使う、Firecracker snapshotは状態を持つsandbox再開に向く がある。Kubernetes上でこれらを抽象化する動きについては Kubernetes Agent Sandboxはstateful singletonをSandbox CRDにする を参照。

設計上の論点は、AIエージェント用sandboxでcontainerとVMをどう選ぶか、AI実行環境ではenvironmentとterminal sessionを分けて考える、sandboxのcontrol planeはruntime種別から分離しておく に分けている。

#security #ai #moc

出典

• Landlock: unprivileged access control — Linux Kernel documentation
• What is gVisor?
• Kata Containers 4.0.0 release overview
• Firecracker snapshotting