sandbox_execがより汎用的なものに進化する過程を文書化してきた。この投稿はSandlock v1.4.0について——単なる巧みなラッパーではなく、適切なマルチレイヤーセキュリティシステムになったポイント。

リポジトリ： github.com/bkmashiro/Sandlock

リファクタリング：822行 → 8モジュール

更新 2026-03-09： sandbox_execはその後Sandlockに進化した——厳格モード、言語レベルサンドボックス（Python/JS）、ソーススキャナー、LD_PRELOADフックを持つモジュラーなフルスタックサンドボックス。Sandlock v1.4：単一ファイルからフルスタックサンドボックスへとGitHubリポジトリを参照。

前の2つの投稿は脅威モデルとseccompサンドボックスについてだった。この投稿はさらに進む：セキュリティプロパティがOSレベルフィルターではなくコンパイルターゲットから来るWebAssembly実行環境について。

なぜWASMセキュリティが違うのか

seccompでは62項目のブロックリストを書いた。新しい危険なシステムコールが現れたら（io_uring、お前を見ているぞ）、リストに追加する。セキュリティモデルは「悪いものをブロックする」だ。

先週sandbox_execを出荷した——AWS Lambdaで学生コードを分離するためにseccomp-bpfを使用する224行のCプログラム。その時の正直な答えは：「WASMの方がクリーンだが、Pythonエコシステムがまだそこにない。」

今週は「Pythonエコシステムがまだそこにない」がミリ秒で何を意味するか正確に測定した。答えは予想以上にニュアンスがある。

セットアップ

• ランタイム：Wasmtime v42.0.1
• プラットフォーム：macOS arm64
• 方法論：シナリオごとに50回、5ウォームアップ回、平均
• 比較：Python 3.xをラップするsandbox_exec

認証は解決済みに感じられることの1つだ——そうでないコードベースを引き継ぐまでは。Leverage OJの書き換えを始めたとき、認証システムはトレンチコートを着た3つの別々の問題だった：PM2で壊れるセッションセットアップ、独自の並行認証宇宙に分岐したContestUserコンセプト、そして1つの設定漏洩で完全な認証情報ダンプになるパスワードハッシュスキーム。

これらは最初は明らかではなかった。システムは動作していた——ユーザーはログインでき、セッションは永続化し、コンテストは実行された。しかし「動作する」と「正しい」は別物であり、よく見れば見るほど、もはや有効でない仮定を蓄積したシステムが見えてきた。

本番アプリケーションに50以上の新しいエンドポイントを追加すると、新しいアプリケーションだけでなく——新しい攻撃対象領域も持つことになる。Leverage OJバックエンド書き換えはシステムのほぼすべてのルートに触れ、新しいロール階層を導入し、認証レイヤー全体を置き換えた。それはまさにパーミッションバグを生み出す種類の変更だ：旧システムで機能していたアクセス制御がポートされなかった、または間違ってポートされた種類のバグ。

稼働前に体系的なセキュリティ監査を行った。この投稿は方法論と発見したものについてだ——間違ったユーザーが提出されたコードの再評価をトリガーできる回帰と、何年もアクセス制御なしで本番に放置されていたFIXMEコメントを含めて。