あらすじ
近年、supply-chain attackとかこわい。 特にCLIでnpmやらcodexやらclaude codeやらgeminiやら動かすのに裸んぼでは心もとないのではないか。
というわけでナウなLinuxサンドボックスを調べて比較してみる。
比較のやつ
firejail
老舗？のイメージ。 利用方法などはarch wikiがまとまっている。 わりと使いやすい、かつsuid+chroot+namespace+seccomp-bpfという必要なのがそろっている構成で、experimentalだがlandlockサポートも入っている。 じゃあfirejailでいいじゃん、という気もするのだが、そもそもfirejail使うでいいのか？というところが出発点でもある。
余談だがfirejailのコードはけっこう学びが多かった、このhackとかfirejailで知ったはず。
nsjail
officialなやつではないけどgoogleのやつ。 これもけっこう老舗感ある。 あまりfirejailと違わないような？出てきたときはnamespace対応だったり(ns-prefixはそこからきたんだったはず)があったかもしれないけど。 ebpfとかなんかがんばってる雰囲気。けどやっぱりあんまり違いはわからない。
systemd-nspawn
systemd-nspawnはデフォルトで存在しているのでそこは便利なのだが、決して使いやすいものではない。Nix(内部的にsystemd-nspawn使ってる)にするのがどうせならいいけど、これはこれで重い作業なんだよな。
そういえばfirejailは不十分なことがあってsystemd-nspawn(+systemd-run)にしてるってはなしあるけどよくわからんな。
まあでもプロセス隔離ならchroot+Linux namespace+seccomp-bpfでよくて、image buildやらpull/pushとかしたいとかでなければ要らん気もするな。
bubblewrap
flatpackで使われている(sandbox部分を切り出した？)setuidサンドボックス環境。 unshareのラッパーみたいなプリミティブなやつで、下で紹介するbubblejailのほうもあるんだけど、bubblewrap自体もbwrapコマンドでお手軽にサンドボックス環境を作ることはできる。 まあやっぱりfirejailと変わらない雰囲気。
これは直接本論とは関係ないのだが、OCamlのパッケージマネージャであるopamをLinuxで利用する場合にbubblewrapが必要となる(opamはsandbox環境でコマンドを実行することを強制しているのだ、賢い！)
bubblejail
bubblejailは上のbubblewrap(bwrap)の土台にしたもの。 READMEにfirejailとの違いがあって、
firejailの最大の問題点の1つは、誤ってサンドボックス化されていないアプリケーションを実行しても気付かない可能性があることです。 bubblejailは既存のホームディレクトリを透過的に上書きしようとする代わりに独立したホームディレクトリを作成します。 各インスタンスは独立したホームディレクトリを表します。通常、サンドボックス化されたアプリケーションはそれぞれ独自のホームディレクトリを持ちます。
とのこと。 あとまあbwrapは全部引数で渡す必要があるので設定ファイルで分離するとか。
crabjail
これもbubblewrap相当のcrablockというプログラムのラッパーになっている。 crablock自体bubblewrapのようにコマンドとして利用でき、crabjailはcrablockを呼び出す構造になっている。 特徴としてはcrablockも含めてRustで書かれている点とかか。
cage
内部実装にlandlockを使っている。 landlockはこんな話もあって、うーん不十分！ｗという気もする。
クロスプラットフォームなのが特徴といえばそうなのだが、とくに求めていないしな。 macOSの人はこれ使ったらいいと思いました。seatbeltよく知らないけど。
landrun
だいたいcageと同じと思われる。
結論
人類車輪の再発明好きすぎでは？ bubblejailがよさそうな雰囲気あるけどbubblewrapのラッパーを自作するのがいい気がしてきたのでやる(はいまた車輪の再発明を繰り返す)(高速な伏線回収)
