smolvmのUnixソケット転送：隔離VMへ渡す権限を設計する

分析・見解

Docker APIとSSH agentは、どちらもUnixソケットを通じて高い能力を提供します。しかし能力の内容は同じではありません。Docker APIは、接続先のDockerデーモンが許す範囲でイメージ、コンテナ、ボリューム、ネットワークなどを操作する入口になり得ます。ホストの通常のDockerソケットへ無制限に接続させる場合、VMのゲスト内でrootであるかどうかとは別に、ホスト側のコンテナ運用へ影響できる可能性を評価しなければなりません。隔離VMを使っていても、転送先ソケットの認可モデルが広ければ、実効権限は広がります。

一方、SSH agent転送の主な利点は、秘密鍵ファイルをイメージ、ボリューム、環境変数へ置かずに済むことです。鍵の複製を避けられるため、VM破棄後に鍵の残骸を回収する運用から距離を置けます。ただし、agentは署名の代理を行います。信頼していないコードを実行するVMへ転送すれば、そのコードが利用可能な鍵で署名を要求できる期間を与えることになります。READMEが「信頼するワークロードだけへ転送する」と明記する理由はここにあります。

v1.6.13の任意ソケット転送は、固定のDockerとSSH agentという二つの用途を、指定したソケット集合へ一般化するものです。関連する変更の説明では、ホストからゲストのUnixソケットへ到達する方向と、ゲストからホストのサービスへ到達する方向の双方を扱い、各公開ソケットに動的なvsockポートを割り当てるとされています。したがって設計レビューでは「VMにどのソケットをマウントするか」だけでなく、方向、接続主体、対象サービス、失効時点を一組で記録する必要があります。

DockerをTCPで公開すれば既存ツールとの接続は作りやすく見えますが、認証なしのTCP公開を避け、TLS設定やポート管理を追加で扱う必要があります。リリースに含まれたDocker文書の変更は、Unixソケットを推奨し、TCP代替のTLSと動的ポートの注意点を示しています。ローカルなUnixソケットだから自動的に安全なのではなく、ファイル所有者、グループ、プロセス境界が認可の一部になるという理解が重要です。

ここで有効なのが、smolvmの既定値であるネットワーク無効と、許可ホストの明示です。Docker APIを必要とするビルド用VM、限定したGit操作だけを行うVM、外部接続を許さないテストVMを同じ構成にせず、能力ごとにVMを分けます。ソケット転送、ネットワーク、ボリューム、ポート公開は足し算で権限を増やします。いずれか一つだけを安全に見えても、組み合わせで何が可能になるかを確認することが、マイクロVMを利用する際の実務的な境界設計です。