アップデート一覧に戻る
New releaseJul 21, 2026

sandbox-runtime v0.0.66

軽量なサンドボックスツールで、コンテナを必要とせずに、OSレベルで任意のプロセスに対してファイルシステムとネットワークの制限を適用します。

共有

Anthropic Sandbox Runtime (srt)

任意のプロセスに対して、コンテナを必要とせずにOSレベルでファイルシステムとネットワークの制限を強制するための軽量サンドボックスツールです。

srt は、ネイティブのOSサンドボックスプリミティブ（macOSでは sandbox-exec、Linuxでは bubblewrap）とプロキシベースのネットワークフィルタリングを使用します。エージェント、ローカルMCPサーバー、bashコマンド、任意のプロセスの動作をサンドボックス化するために使用できます。

ベータ研究プレビュー

Sandbox Runtime は、より安全なAIエージェントを実現するために Claude Code 向けに開発された研究プレビューです。より広範なエコシステムがより安全なエージェントシステムを構築できるよう、早期のオープンソースプレビューとして公開されています。これは初期の研究プレビューであるため、APIや設定形式は変更される可能性があります。AIエージェントをデフォルトでより安全にするためのフィードバックと貢献を歓迎します！

インストール```bash

npm install -g @anthropic-ai/sandbox-runtime

## 基本的な使い方```bash
# Network restrictions
$ srt "curl anthropic.com"
Running: curl anthropic.com
<html>...</html>  # Request succeeds

$ srt "curl example.com"
Running: curl example.com
Connection blocked by network allowlist  # Request blocked

# Filesystem restrictions
$ srt "cat README.md"
Running: cat README.md
# Anthropic Sandb...  # Current directory access allowed

$ srt "cat ~/.ssh/id_rsa"
Running: cat ~/.ssh/id_rsa
cat: /Users/ollie/.ssh/id_rsa: Operation not permitted  # Specific file blocked

概要

このパッケージは、CLIツールとライブラリの両方として使用できるスタンドアロンのサンドボックス実装を提供します。一般的な開発者のユースケースに合わせたセキュア・バイ・デフォルトの設計思想を採用しており、プロセスは最小限のアクセス権で起動され、必要な穴だけを明示的に開ける方式です。

主な機能:

  • ネットワーク制限: HTTP/HTTPSおよびその他のプロトコルを介してアクセスできるホスト/ドメインを制御
  • ファイルシステム制限: 読み書きできるファイル/ディレクトリを制御
  • Unixソケット制限: ローカルIPCソケットへのアクセスを制御
  • 違反監視: macOSでは、システムのサンドボックス違反ログストアに接続してリアルタイムのアラートを受信

使用例: MCPサーバーのサンドボックス化

主なユースケースは、Model Context Protocol（MCP）サーバーをサンドボックス化してその機能を制限することです。たとえば、ファイルシステムMCPサーバーをサンドボックス化する場合:

サンドボックスなし (.mcp.json):```json { "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem"] } } }

**サンドボックスあり**（`.mcp.json`）：```json
{
  "mcpServers": {
    "filesystem": {
      "command": "srt",
      "args": ["npx", "-y", "@modelcontextprotocol/server-filesystem"]
    }
  }
}

次に、~/.srt-settings.json で制限を設定します:```json { "filesystem": { "denyRead": [], "allowWrite": ["."], "denyWrite": ["~/sensitive-folder"] }, "network": { "allowedDomains": [], "deniedDomains": [] } }

Now the MCP server will be blocked from writing to the denied path:```
> Write a file to ~/sensitive-folder
✗ Error: EPERM: operation not permitted, open '/Users/ollie/sensitive-folder/test.txt'

動作の仕組み

このサンドボックスは、プロセスツリー全体に適用される制限を強制するために、OSレベルのプリミティブを使用します。

  • macOS: 動的に生成されるSeatbeltプロファイルとともにsandbox-execを使用します
  • Linux: ネットワーク名前空間の分離を備えたコンテナ化にbubblewrapを使用します
  • Windows: サンドボックス化されたプロセスを専用のsrt-sandboxローカルユーザーアカウントで実行し、そのアカウントのSIDに基づくWindowsフィルタリングプラットフォームの送信ファイアウォールと、作業ツリーに対するセッションごとの明示的なACEを適用します

0d1c612947c798aef48e6ab4beb7e8544da9d41a-4096x2305

二重分離モデル

効果的なサンドボックス化には、ファイルシステムとネットワークの両方の分離が必要です。ファイル分離がないと、侵害されたプロセスがSSHキーやその他の機密ファイルを外部に持ち出す可能性があります。ネットワーク分離がないと、プロセスがサンドボックスから脱出して無制限のネットワークアクセスを取得する可能性があります。

ファイルシステム分離は、読み取りと書き込みの制限を強制します。

  • 読み取り（拒否→許可のパターン）: デフォルトでは、読み取りアクセスはすべての場所で許可されています。広い領域（例: /Users）を拒否し、その中の特定のパス（例: .）を再許可できます。allowReadはdenyReadよりも優先されます。これは書き込みとは逆で、denyWriteがallowWriteよりも優先されます。allowReadの領域内に含まれるdenyReadエントリがその領域よりも具体的な場合（例: allowRead: ["."]の状態でdenyRead: ["**/.env"]や["./secrets"]）、そのエントリは拒否されたままになります。
  • 書き込み（許可のみのパターン）: デフォルトでは、書き込みアクセスはすべての場所で拒否されています。パス（例: .、/tmp）を明示的に許可する必要があります。許可リストが空の場合、書き込みアクセスは一切ありません。

ネットワーク分離（許可のみのパターン）: デフォルトでは、すべてのネットワークアクセスが拒否されています。ドメインを明示的に許可する必要があります。allowedDomainsリストが空の場合、ネットワークアクセスは一切ありません。ネットワークトラフィックは、ホスト上で実行されているプロキシサーバーを経由してルーティングされます。

  • Linux: リクエストはUnixドメインソケットを介してファイルシステム経由でルーティングされます。サンドボックス化されたプロセスのネットワーク名前空間は完全に削除されるため、すべてのネットワークトラフィックはホスト上で実行されているプロキシ（サンドボックスにバインドマウントされたUnixソケットで待ち受け）を経由する必要があります

  • macOS: Seatbeltプロファイルは、特定のlocalhostポートへの通信のみを許可します。プロキシはこのポートで待ち受けし、すべてのネットワークアクセスのための制御されたチャネルを作成します

  • Windows: マシン全体に適用されるWFPフィルターセットが、srt-sandboxアカウントからのすべての送信接続をブロックします。ただし、プロキシポート範囲へのループバックは例外です。プロキシはその範囲内で待ち受けし、すべてのネットワークアクセスのための制御されたチャネルを作成します

HTTP/HTTPS（HTTPプロキシ経由）とその他のTCPトラフィック（SOCKS5プロキシ経由）の両方がこれらのプロキシによって仲介され、ドメインの許可リストと拒否リストが適用されます。

Claude Codeのサンドボックス化の詳細については、以下を参照してください。

アーキテクチャ```

src/ ├── index.ts # Library exports ├── cli.ts # CLI entrypoint (srt command) ├── utils/ # Shared utilities │ ├── debug.ts # Debug logging │ ├── settings.ts # Settings reader (permissions + sandbox config) │ ├── platform.ts # Platform detection │ └── exec.ts # Command execution utilities └── sandbox/ # Sandbox implementation ├── sandbox-manager.ts # Main sandbox manager ├── sandbox-schemas.ts # Zod schemas for validation ├── sandbox-violation-store.ts # Violation tracking ├── sandbox-utils.ts # Shared sandbox utilities ├── http-proxy.ts # HTTP/HTTPS proxy for network filtering ├── socks-proxy.ts # SOCKS5 proxy for network filtering ├── linux-sandbox-utils.ts # Linux bubblewrap sandboxing ├── macos-sandbox-utils.ts # macOS sandbox-exec sandboxing └── windows-sandbox-utils.ts # Windows srt-win sandboxing

## 使用方法

### CLIツールとして

`srt` コマンド（Anthropic Sandbox Runtime）は、任意のコマンドをセキュリティ境界でラップします：```bash
# Run a command in the sandbox
srt echo "hello world"

# With debug logging
srt --debug curl https://example.com

# Specify custom settings file
srt --settings /path/to/srt-settings.json npm install

ライブラリとして```typescript

import { SandboxManager, type SandboxRuntimeConfig, } from '@anthropic-ai/sandbox-runtime' import { spawn } from 'child_process'

// Define your sandbox configuration const config: SandboxRuntimeConfig = { network: { allowedDomains: ['example.com', 'api.github.com'], deniedDomains: [], }, filesystem: { denyRead: ['~/.ssh'], allowWrite: ['.', '/tmp'], denyWrite: ['.env'], }, }

// Initialize the sandbox (starts proxy servers, etc.) await SandboxManager.initialize(config)

// Wrap a command with sandbox restrictions const sandboxedCommand = await SandboxManager.wrapWithSandbox( 'curl https://example.com', )

// Execute the sandboxed command const child = spawn(sandboxedCommand, { shell: true, stdio: 'inherit' })

// Handle exit and cleanup after child process completes child.on('exit', async code => { console.log(Command exited with code ${code}) // Cleanup when done (optional, happens automatically on process exit) await SandboxManager.reset() })

**違反の帰属（`commandId` / `commandText`）。** ラップされたコマンドの実行中に観測された違反（seatbelt のログ行、seccomp イベント、プロキシの拒否）は、帰属キーの下に保存され、`annotateStderrWithSandboxFailures(key, stderr)` / `getViolationsForCommand(key)` が同じキーでそれらを検索します。デフォルトでは、キーはラップされた文字列そのものです。代わりに、不透明な呼び出しごとの `commandId`（例：ツール使用 ID）を渡して、それでキー付けすることを推奨します。キーは最初の 100 文字で比較されるため、プレフィックスを共有する長いコマンドは、そうしないと相互に帰属してしまい、同じテキストの再実行は以前の実行のイベントを引き継ぐことになります。実行する文字列が、呼び出しが*表す*コマンドではない場合（例：組み立てた `source <snapshot> && eval '<cmd>'` をラップする場合）、`commandText: '<cmd>'` も渡してください。これは、`ignoreViolations` のコマンドパターンが照合する対象であり、各違反が自身の `command` として報告する内容でもあります。```typescript
const wrapped = await SandboxManager.wrapWithSandbox(
  assembledCommand, // what actually runs
  undefined,
  undefined,
  undefined,
  { commandId: invocationId, commandText: rawCommand },
)
// ... run it ...
const annotated = SandboxManager.annotateStderrWithSandboxFailures(invocationId, stderr)

利用可能なエクスポート```typescript

// Main sandbox manager export { SandboxManager } from '@anthropic-ai/sandbox-runtime'

// Violation tracking export { SandboxViolationStore } from '@anthropic-ai/sandbox-runtime'

// TypeScript types export type { SandboxRuntimeConfig, NetworkConfig, FilesystemConfig, IgnoreViolationsConfig, SandboxAskCallback, FsReadRestrictionConfig, FsWriteRestrictionConfig, NetworkRestrictionConfig, } from '@anthropic-ai/sandbox-runtime'

## 設定

### 設定ファイルの場所

デフォルトでは、サンドボックスランタイムは `~/.srt-settings.json` で設定を探します。`--settings` フラグを使用してカスタムパスを指定できます:```bash
srt --settings /path/to/srt-settings.json <command>

完全な設定例```json

{ "network": { "allowedDomains": [ "github.com", ".github.com", "lfs.github.com", "api.github.com", "npmjs.org", ".npmjs.org" ], "deniedDomains": ["malicious.com"], "allowUnixSockets": ["/var/run/docker.sock"], "allowLocalBinding": false }, "filesystem": { "denyRead": ["~/.ssh"], "allowRead": [], "allowWrite": [".", "src/", "test/", "/tmp"], "denyWrite": [".env", "config/production.json"] }, "ignoreViolations": { "*": ["/usr/bin", "/System"], "git push": ["/usr/bin/nc"], "npm": ["/private/tmp"] }, "enableWeakerNestedSandbox": false, "enableWeakerNetworkIsolation": false, "allowAppleEvents": false }

### 設定オプション

#### ネットワーク設定

**許可のみパターン**を使用します。デフォルトではすべてのネットワークアクセスが拒否されます。

- `network.allowedDomains` - 許可されるドメインの配列（`*.example.com` のようなワイルドカードをサポート）。空の配列 = ネットワークアクセスなし。オプションの `:port` サフィックス（`api.example.com:443`、`*.example.com:8443`）により、エントリがその宛先ポートに制限されます。ポート指定のないエントリは任意のポートに一致します。
  - IPv6 リテラルは RFC 3986 スタイルで角括弧で囲む必要があります：`[::1]`、`[2001:db8::1]:443`。角括弧なしのマルチコロンエントリは曖昧として拒否されます（`2001:db8::1:443` 自体は有効なアドレスです）。
- `network.deniedDomains` - 拒否されるドメインの配列（最初にチェックされ、allowedDomains より優先されます）。同じ `:port` サフィックスを使用し、裸の `*`（または `*:22`）は全拒否として受け入れられます。
- `network.deniedDomainReasons` - オプションのマップ。`deniedDomains` エントリ（完全一致で照合）から、そのエントリが接続を拒否したときに `<sandbox_violations>` 行に表示されるモデル向けの理由を対応付けます。何がブロックされたか、および承認された代替手段を示します（例：`{"github.com:22": "SSH pushes to GitHub are blocked; use an https:// remote"}`）。理由のないエントリには一般的な理由が報告されます。SSH 宛先（ポート 22）の場合、理由はインバンドでも配信されます。認証なし SOCKS ProxyCommand（例：BSD `nc -X 5`）を介してトンネリングされた SSH クライアントは、鍵交換前の SSH 切断を受信し、その説明が理由となります。OpenSSH はこれをそのまま表示するため、理由は約 400 ASCII 文字未満に保ち、命令形を先頭に置いてください（OpenSSH は非 ASCII を切り詰めてエスケープするため）。
- `network.allowLocalBinding` - ローカルポートへのバインドを許可します（ブール値、デフォルト: false）

**TLS 終端**（`network.tlsTerminate`、実験的）：設定すると、HTTPS CONNECT がプロセス内で終端され、SRT が復号化されたリクエストを確認（および `network.filterRequest` でフィルタリング）できるようになります。サンドボックス化されたプロセスは、MITM CA（`caCertPath`/`caKeyPath`、省略時は一時的な CA）とホストの通常のルート証明書を含むトラストバンドルを指すように設定されるため、プロキシ発行の証明書と実際のアップストリーム証明書の両方が検証されます。

- `network.tlsTerminate.excludeDomains` - **終端されない**ドメインパターン（`allowedDomains` と同じ構文）。一致する CONNECT は代わりに透過的にトンネリングされます。これらは引き続きドメイン許可リストの対象ですが、サンドボックス内のクライアントは実際のアップストリームとの独自の TLS ハンドシェイクを完了し、`filterRequest` / 資格情報の注入はその HTTPS トラフィックには適用されません。TLS 終端が根本的に破綻する次の 2 つのケースにこれを使用します。
  - **mTLS アップストリーム** - クライアント証明書を保持しているのはサンドボックス内のクライアントのみであるため、プロキシはその代わりに接続を再確立できません。
  - **証明書ピンニングを行うクライアント** - アップストリームの ID を自身で検証する（カスタム CA、SAN ピンニング）クライアントで、MITM 証明書を拒否します。
- `network.tlsTerminate.extraCaCertPaths` - そのトラストバンドルに追加される PEM CA 証明書ファイルへのパス。MITM CA とホストの通常のルート証明書の後に追加されます。除外（非終端）ホストはサンドボックス内のクライアントによって検証され、SRT が設定するトラスト環境変数（`SSL_CERT_FILE`、`GIT_SSL_CAINFO` など）は各ツールの独自のトラスト設定を_置き換える_ため、サイトローカルのルート証明書（例：内部 mTLS CA）はバンドル内に存在する必要があります。そうでない場合、それらのホストは決して検証できません。各ファイルの `CERTIFICATE` ブロックのみがバンドルにコピーされます（その他、例えば結合 PEM 内の秘密鍵などは、サンドボックスに公開されることは決してありません）。存在しない、読み取れない、または PEM `CERTIFICATE` ブロックを含まないファイルはスキップされるため、一部のホストにのみ存在するパスをリストしても安全です。```json
{
  "network": {
    "allowedDomains": ["*.example.com", "internal-mtls.example.net"],
    "deniedDomains": [],
    "tlsTerminate": {
      "excludeDomains": ["internal-mtls.example.net"],
      "extraCaCertPaths": ["/etc/internal-mtls-roots.pem"]
    }
  }
}

Unix Socket 設定（プラットフォーム固有の動作）:

設定macOSLinux
allowUnixSockets: string[]ソケットパスの許可リスト無視（seccomp はパスでフィルタリングできない）
allowAllUnixSockets: booleanすべてのソケットを許可seccomp ブロックを無効化

Unix ソケットは、両プラットフォームでデフォルトでブロックされます。

  • macOS: allowUnixSockets を使用して特定のパス（例: ["/var/run/docker.sock"]）を許可するか、allowAllUnixSockets: true を使用してすべてを許可します。
  • Linux: ブロックには seccomp フィルタ（x64/arm64 のみ）を使用します。seccomp が利用できない場合、ソケットは制限なしとなり、警告が表示されます。allowAllUnixSockets: true を使用してブロックを明示的に無効化します。

ファイルシステム設定

2 つの異なるパターンを使用します:

読み取り制限（拒否→許可パターン）- デフォルトですべての読み取りが許可されます:

  • filesystem.denyRead - 読み取りアクセスを拒否するパスの配列。空の配列 = 完全な読み取りアクセス。
  • filesystem.allowRead - 拒否された領域内で読み取りアクセスを再許可するパスの配列（denyRead より優先）。注: これは書き込みの逆で、書き込みでは denyWrite が allowWrite より優先されます。

書き込み制限（許可のみパターン）- デフォルトですべての書き込みが拒否されます:

  • filesystem.allowWrite - 書き込みアクセスを許可するパスの配列。空の配列 = 書き込みアクセスなし。
  • filesystem.denyWrite - 許可されたパス内で書き込みアクセスを拒否するパスの配列（allowWrite より優先）

パス構文（macOS）:

macOS では、パスは .gitignore 構文と同様の git スタイルの glob パターンをサポートします:

  • * - / 以外の任意の文字に一致（例: *.ts は foo.ts に一致するが foo/bar.ts には一致しない）
  • ** - / を含む任意の文字に一致（例: src/**/*.ts は src/ 内のすべての .ts ファイルに一致）
  • ? - / 以外の任意の 1 文字に一致（例: file?.txt は file1.txt に一致）
  • [abc] - セット内の任意の文字に一致（例: file[0-9].txt は file3.txt に一致）

例:

  • "allowWrite": ["src/"] - src/ ディレクトリ全体への書き込みを許可
  • "allowWrite": ["src/**/*.ts"] - src/ およびサブディレクトリ内のすべての .ts ファイルへの書き込みを許可
  • "denyRead": ["~/.ssh"] - SSH ディレクトリへの読み取りを拒否
  • "denyRead": ["/Users"], "allowRead": ["."] - /Users 全体への読み取りを拒否するが、現在のディレクトリは再許可
  • "denyWrite": [".env"] - .env ファイルへの書き込みを拒否（現在のディレクトリが許可されていても）

パス構文（Linux）:

Linux は現在 glob マッチングをサポートしていません。 リテラルパスのみを使用してください:

  • "allowWrite": ["src/"] - src/ ディレクトリへの書き込みを許可
  • "denyRead": ["/home/user/.ssh"] - SSH ディレクトリへの読み取りを拒否
  • "denyRead": ["/home"], "allowRead": ["."] - /home 全体への読み取りを拒否するが、現在のディレクトリは再許可

すべてのプラットフォーム:

  • パスは絶対パス（例: /home/user/.ssh）または現在の作業ディレクトリからの相対パス（例: ./src）にできます
  • ~ はユーザーのホームディレクトリに展開されます

その他の設定

  • ignoreViolations - 違反を無視するパスの配列にコマンドパターンをマッピングするオブジェクト
  • enableWeakerNestedSandbox - Docker 環境向けの弱いサンドボックスモードを有効化（ブール値、デフォルト: false）
  • enableWeakerNetworkIsolation - macOS サンドボックス内の com.apple.trustd.agent へのアクセスを許可（ブール値、デフォルト: false）。これは Go プログラム（gh、gcloud、terraform、kubectl など）が、httpProxyPort を MITM プロキシとカスタム CA とともに使用する際に TLS 証明書を検証するために必要です。セキュリティ警告: これを有効にすると、trustd サービスを通じた潜在的なデータ流出経路が開かれます。
  • allowAppleEvents - macOS サンドボックスから Apple Events と Launch Services のオープンリクエストの送信を許可（ブール値、デフォルト: false）。これがないと、open、osascript、および AppleScript を介して URL や他のアプリのスクリプトを開くものはすべて、AppleScript エラー -600（「アプリケーションが実行されていません」）または LaunchServices エラー（-10822、-54）で失敗します。セキュリティ警告: これを有効にすると、サンドボックスはコード実行の分離を提供しなくなります。サンドボックス化されたコマンドは、ユーザーのプロンプトなしで open を介して他のアプリケーションを起動でき、起動されたものはすべてサンドボックスのファイルシステムおよびネットワーク制限の外で実行されます。すでに実行中のアプリの Apple Events によるスクリプト化は、ユーザーのアプリごとの TCC 自動化同意によってさらに制限されます。埋め込み側は、このオプションを信頼できるユーザーレベルの設定からのみ取得する必要があります。チェックアウトされたリポジトリ内のプロジェクトローカルファイルからは決して取得しないでください。攻撃者が作成したプロジェクトが自身のサンドボックス権限を昇格させる可能性があります。

一般的な設定レシピ

GitHub アクセスを許可（必要なすべてのエンドポイント）:```json { "network": { "allowedDomains": [ "github.com", "*.github.com", "lfs.github.com", "api.github.com" ], "deniedDomains": [] }, "filesystem": { "denyRead": [], "allowWrite": ["."], "denyWrite": [] } }

**特定のディレクトリに制限する:**```json
{
  "network": {
    "allowedDomains": [],
    "deniedDomains": []
  },
  "filesystem": {
    "denyRead": ["~/.ssh"],
    "allowWrite": [".", "src/", "test/"],
    "denyWrite": [".env", "secrets/"]
  }
}

ワークスペースのみのファイルシステムアクセス（ワークスペース外の読み取りを拒否）：```json { "network": { "allowedDomains": [], "deniedDomains": [] }, "filesystem": { "denyRead": ["/Users"], "allowRead": ["."], "allowWrite": ["."], "denyWrite": [] } }

This denies reading anything under `/Users` (or `/home` on Linux), then re-allows the current working directory. System paths (`/usr`, `/lib`, etc.) remain readable.

### Common Issues and Tips

**Running Jest:** Use `--no-watchman` flag to avoid sandbox violations:```bash
srt "jest --no-watchman"

Watchmanはサンドボックス境界の外にあるファイルにアクセスするため、権限エラーが発生します。これを無効にすると、Jestは組み込みのファイルウォッチャーで実行できるようになります。

プラットフォームサポート

  • macOS: カスタムプロファイルでsandbox-execを使用（追加の依存関係なし）
  • Linux: コンテナ化にbubblewrap（bwrap）を使用
  • Windows: アルファ版 — バンドルされたsrt-win.exeヘルパーを使用（追加の依存関係なし）。セットアップ、セキュリティモデル、既知の制限については、Windows（アルファ版）を参照してください

プラットフォーム固有の依存関係

Linuxで必要なもの:

  • bubblewrap - コンテナランタイム
    • Ubuntu/Debian: apt-get install bubblewrap
    • Fedora: dnf install bubblewrap
    • Arch: pacman -S bubblewrap
  • socat - プロキシブリッジ用のソケットリレー
    • Ubuntu/Debian: apt-get install socat
    • Fedora: dnf install socat
    • Arch: pacman -S socat
  • ripgrep - 拒否パス検出用の高速検索ツール
    • Ubuntu/Debian: apt-get install ripgrep
    • Fedora: dnf install ripgrep
    • Arch: pacman -S ripgrep

Ubuntu 24.04+の注意: これらのリリースではkernel.apparmor_restrict_unprivileged_usernsがデフォルトで有効になっており、unshare(CLONE_NEWUSER)は許可されますが、結果の名前空間からケーパビリティが削除されます。bubblewrapとseccomp分離レイヤーの両方が、ケーパビリティを持つユーザー名前空間を必要とします。次のコマンドで制限を無効にしてください:```bash sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

または、関連するバイナリに`userns`を許可するAppArmorプロファイルを追加します。

**オプションのLinux依存関係（seccompフォールバック用）：**

このパッケージには、x86-64およびarmアーキテクチャ用の事前生成されたseccomp BPFフィルタが含まれています。これらの依存関係は、事前生成されたフィルタが利用できない別のアーキテクチャを使用している場合にのみ必要です：

- `gcc`または`clang` - Cコンパイラ
- `libseccomp-dev` - Seccompライブラリ開発ファイル
  - Ubuntu/Debian: `apt-get install gcc libseccomp-dev`
  - Fedora: `dnf install gcc libseccomp-devel`
  - Arch: `pacman -S gcc libseccomp`

**macOSに必要なもの：**

- `ripgrep` - 拒否パス検出用の高速検索ツール
  - Homebrewでインストール: `brew install ripgrep`
  - または以下からダウンロード: https://github.com/BurntSushi/ripgrep/releases

**Windowsに必要なもの：**

- 追加の依存関係は不要です。`srt-win.exe`ヘルパー（x64およびarm64）はnpmパッケージに同梱されています。一度だけ昇格権限が必要な`windows-install`ステップが必要です — 以下を参照してください。

## Windows（アルファ版）

Windowsサポートは**アルファ版**です。サンドボックス化されたプロセスは、専用の`srt-sandbox`ローカルユーザーアカウントで実行され、ネイティブのWindowsセキュリティプリミティブによって呼び出し元ユーザーから分離されます — サンドボックスアカウントのSIDをキーとするWindowsフィルタリングプラットフォーム（WFP）の送信ファイアウォール、および設定されたファイルシステムパスへのそのSIDのアクセスを許可または拒否するセッションごとの明示的なACEです。

### セットアップ

マシンごとに1回実行します（自己昇格します。UACプロンプトが1回表示されます）：```powershell
npx @anthropic-ai/sandbox-runtime windows-install

This provisions the srt-sandbox local user account (with a random password stored DPAPI-encrypted in HKLM\SOFTWARE\sandbox-runtime — machine-wide, so fleet installs running as SYSTEM work and one user's rotation updates the copy the others read), the sandbox-runtime-users local group, and installs a machine-wide WFP filter set keyed on the srt-sandbox SID. It is idempotent — re-running it rotates the sandbox account's password and reconciles the filter set.

No logout is required. The WFP filters key on the dedicated sandbox account's SID, so your own network, services, and every other principal on the machine are unaffected.

After install, SandboxManager.initialize() and the srt CLI work as on other platforms. initialize() verifies the sandbox account and WFP fence are live, and fails with an actionable error if not.

Programmatic install/uninstall are exported as installWindowsSandbox() / uninstallWindowsSandbox().

Security model

The sandboxed command runs as the srt-sandbox account, not as the calling user. The bundled srt-win.exe helper does a two-hop launch: the broker calls CreateProcessWithLogonW to start a runner as srt-sandbox, and the runner spawns the target under a restricted token inside a job object. The child inherits the sandbox account's isolated profile (%USERPROFILE%, %TEMP%, HKCU) and a fresh environment overlaid with only the broker's PATH and the generated proxy variables.

Running under a distinct user SID structurally closes the surrogate-spawn class of escape (Task Scheduler, PROC_THREAD_ATTRIBUTE_PARENT_PROCESS onto a broker-owned process, BITS, out-of-process COM with RunAs="Interactive User"): any process the child manages to spawn out-of-band still carries the srt-sandbox SID, so it remains subject to the WFP egress fence and has no rights on the calling user's files.

Network isolation is a two-filter WFP set at FWPM_LAYER_ALE_AUTH_CONNECT_V4/V6: a PERMIT for loopback destinations inside the configured proxy port range (default 60080–60089), and a BLOCK for any connect whose token carries the srt-sandbox SID. The sandboxed process reaches the internet only via the JS HTTP/SOCKS5 proxies listening in that range; a process that strips its proxy environment and connects directly is blocked at the kernel.

Filesystem isolation is enforced by NTFS discretionary ACLs. The srt-sandbox account has no inherent rights on the calling user's files, so at initialize() the sandbox writes additive, inheriting explicit ACEs for the srt-sandbox SID only — it never rewrites or replaces a path's existing security descriptor:

  • filesystem.allowWrite → an inheriting MODIFY ALLOW ACE (READ|WRITE|EXECUTE|DELETE, with FILE_DELETE_CHILD withheld). The sandboxed process can create, modify, and delete files inside the working tree; withholding FILE_DELETE_CHILD from the grant is defense-in-depth for the deny stamps below, not a guard on the tree root.
  • filesystem.allowRead → an inheriting READ|EXECUTE ALLOW ACE
  • filesystem.denyRead / filesystem.denyWrite → an inheriting DENY ACE on the target, plus an inheriting FILE_DELETE_CHILD DENY on its parent — together with the withheld FILE_DELETE_CHILD on the working-tree grant, this stops the sandboxed process from renaming or deleting a denied path via its parent directory

reset() removes every ACE this session added (refcounted across this user's concurrent hosts via the per-user session DB; a crash-recovery pass on the next initialize() cleans up after an unclean exit). Directory targets are supported (the ACEs inherit to the whole subtree). Glob patterns are expanded to concrete paths at initialize() time — a matching path that appears later is not covered.

TLS termination on Windows

network.tlsTerminate requires the MITM CA to be present in the sandbox user's CurrentUser\Root certificate store (schannel — the TLS backend used by System32\curl.exe, PowerShell Invoke-WebRequest, .NET, and default-backend git — trusts only the OS store, not environment variables). This is an install-time step, separate from windows-install:```typescript import { windowsTrustCa } from '@anthropic-ai/sandbox-runtime' windowsTrustCa('/path/to/mitm-ca.crt') // or: srt-win user trust-ca 

`initialize()` は、セッションの CA サムプリントをインストール済みのものと比較し、不一致の場合は実行可能なメッセージを表示して失敗するため、古いインストール時の CA がサンドボックス内の TLS を静かに壊すことはありません。

OpenSSL ベースのクライアント（msys2 `curl`、`git -c http.sslBackend=openssl`、Node、Python、cargo）は、環境変数によるトラストレイヤーでカバーされます。macOS/Linux で使用されるのと同じトラストバンドルが、`NODE_EXTRA_CA_CERTS`、`SSL_CERT_FILE`、`CURL_CA_BUNDLE`、`GIT_SSL_CAINFO`、`CARGO_HTTP_CAINFO` などを介してサンドボックスに渡され、バンドルパスはセッションの `allowRead` 許可に追加されるため、サンドボックスアカウントがそれを開くことができます。

### Windows 固有の設定

クロスプラットフォームの `filesystem` および `network` ブロックは、上記のとおり適用されます。Windows のみの設定は `windows` の下にあります:

- `windows.proxyPortRange` — JS プロキシが内部でバインドする包括的なポート範囲 `[low, high]`。`windows-install --proxy-port-range`（デフォルト `[60080, 60089]`）に渡された範囲と**一致する必要があります** — WFP ループバック PERMIT はその範囲のみをカバーします。
- `windows.sublayerGuid` — フィルタがインストールされた WFP サブレイヤー GUID。省略するとコンパイル時のデフォルトが使用されます。エンタープライズツールがカスタムサブレイヤーの下にフィルタをインストールした場合のみ設定します。
- `windows.srtWin.path` — `srt-win` バイナリへのパス。省略すると、同梱の `vendor/srt-win/<arch>/srt-win.exe` が解決されます。`srt-win` の CLI をマルチコールバイナリに埋め込む場合に設定します。その場合、spawn は `--srt-win` を `argv[1]` として渡すため、エンベッダーのディスパッチャーが `srt_win::run_from_args` にルーティングできます。

### 既知の制限事項

- **schannel での証明書失効。** CryptoAPI の CRL/OCSP フェッチは、呼び出し元のトークンで WinHTTP を介して実行され、プロキシ環境を無視するため、WFP の egress フェンスによってブロックされます。失効チェックがデフォルトで有効な schannel を使用するツールは、ツールごとに失効を無効にしない限り、`CRYPT_E_REVOCATION_OFFLINE`（`0x80092013`）で失敗します: `curl --ssl-no-revoke`、`git -c http.schannelCheckRevoke=false`、`CARGO_HTTP_CHECK_REVOKE=false`。`Invoke-WebRequest`、.NET `HttpClient`、および `gh` はデフォルトで失効をチェックしないため、影響を受けません。ループバックプロキシから提供される CRL 配布ポイントが、この回避策を不要にするために計画されています。
- **ユーザー単位のツールインストールには到達できません。** サンドボックス化されたプロセスはあなたではなく `srt-sandbox` として実行されるため、プロファイルの下にインストールされたツール（nvm/fnm 管理の Node、ユーザー単位の `winget`/Scoop パッケージ、`pip install --user`、`%LOCALAPPDATA%\Programs\…`）は継承された `PATH` 上では解決されますが、サンドボックスアカウントでは開くことができません。マシン全体へのインストール（`Program Files`、`choco`/`winget --scope machine`）を優先するか、特定のプロファイルパスを `filesystem.allowRead` に追加してください。
- **実行ごとの `filesystem.allowRead` / `filesystem.allowWrite` オーバーライドはサポートされていません。** セッションレベルの `allowRead`/`allowWrite`（`initialize()` に渡される設定内）は上記のとおり機能します。`wrapWithSandbox` の `customConfig` でコマンドごとに渡すと例外がスローされます — 許可は `initialize()` で `srt-win acl grant` を介してセッション全体に適用され、`srt-win exec` は実行ごとの拒否のみを公開します。
- **`proxyAuthToken` はランナーのコマンドラインで参照可能です。** プロキシ環境（`HTTP_PROXY=http://srt:<token>@127.0.0.1:…` を含む）は、`srt-win exec` の argv 上の `--env` 引数として 2 ホップランナーに渡されるため、`PROCESS_QUERY_LIMITED_INFORMATION` でランナープロセスを開くことができるローカルのプリンシパルなら誰でもトークンを読み取れます。トークンはサンドボックス化されたプロセスがループバックプロキシに認証できるように存在するため、サンドボックス自体にとっては秘密ではありません。シングルユーザーの開発マシンでは通常許容されますが、共有ホストではプロキシの許可リストを同じセッションの他のプリンシパルが到達可能なものとして扱ってください。
- **システムリゾルバーによる DNS 解決はフェンスされません。** `getaddrinfo()` は `NETWORK SERVICE` として実行される `Dnscache` サービスによって処理されるため、サンドボックス化されたプロセスからの後続の `connect()` がブロックされていても名前解決は成功します。独自の UDP/53 を行うツール（`nslookup`、`dig`）はフェンスされます。これは macOS の動作を反映しています。

### アンインストール```powershell
npx @anthropic-ai/sandbox-runtime windows-uninstall

Removes the WFP filter set, the srt-sandbox account and its profile, the sandbox-runtime-users group, and removes the HKLM\SOFTWARE\sandbox-runtime key (credential, marker, CA record) — one UAC prompt. %ProgramData%\sandbox-runtime (the CA key material) is left in place; delete it (and %LOCALAPPDATA%\sandbox-runtime per user) manually for a full sweep.

開発```bash

Install dependencies

npm install

Build the project

npm run build

Run tests

npm test

Type checking

npm run typecheck

Lint code

npm run lint

Format code

npm run format

### Seccomp バイナリのビルド

BPF フィルタと `apply-seccomp` ローダーは、`vendor/seccomp-src/` 内の C ソースから `npm run build:seccomp` を介してコンパイルされます（Linux のみ。`gcc` と `libseccomp-dev` が必要）。CI は各 Linux アーキテクチャでテストの前にこれを実行し、リリースワークフローは両方のアーキテクチャをビルドして公開パッケージにバンドルします。

## 実装の詳細

### ネットワーク分離アーキテクチャ

サンドボックスは、ホストマシン上で HTTP および SOCKS5 プロキシサーバーを実行し、権限ルールに基づいてすべてのネットワークリクエストをフィルタリングします。

1. **HTTP/HTTPS トラフィック**: HTTP プロキシサーバーがリクエストを傍受し、許可/拒否されたドメインに対して検証します
2. **その他のネットワークトラフィック**: SOCKS5 プロキシが他のすべての TCP 接続（SSH、データベース接続など）を処理します
3. **権限の適用**: プロキシは設定の `permissions` ルールを適用します

**プラットフォーム固有のプロキシ通信:**

- **Linux**: リクエストは Unix ドメインソケット経由でファイルシステムを介してルーティングされます（ブリッジには `socat` を使用）。ネットワーク名前空間は bubblewrap コンテナから削除され、すべてのネットワークトラフィックがプロキシを経由する必要があります。

- **macOS**: Seatbelt プロファイルは、プロキシが待ち受ける特定の localhost ポートへの通信のみを許可します。その他のすべてのネットワークアクセスはブロックされます。

- **Windows**: WFP `ALE_AUTH_CONNECT` フィルタは、設定されたプロキシポート範囲へのループバックを除き、`srt-sandbox` アカウントからのすべての送信接続をブロックします。プロキシはその範囲内にバインドされます。環境変数（`HTTP_PROXY`、`HTTPS_PROXY`、`ALL_PROXY` など）はツールをプロキシに向けますが、WFP フィルタが境界となります。これらを無視または設定解除するプロセスも依然として隔離されます。

### ファイルシステムの分離

ファイルシステムの制限は OS レベルで適用されます。

- **macOS**: 許可された読み取り/書き込みパスを指定する動的に生成された Seatbelt プロファイルで `sandbox-exec` を使用します
- **Linux**: バインドマウントで `bubblewrap` を使用し、設定に基づいてディレクトリを読み取り専用または読み取り/書き込みとしてマークします
- **Windows**: 設定されたパスに `srt-sandbox` SID の追加的な `(OI)(CI)` 明示的 ACE を書き込み（`allowRead`/`allowWrite` では ALLOW、`denyRead`/`denyWrite` では DENY）、その後 `reset()` で削除します

**デフォルトのファイルシステム権限:**

- **読み取り**（拒否後許可）: デフォルトでどこでも許可されます。広い領域を拒否してから、その中の特定のパスを再許可できます。`allowRead` は `denyRead` より優先されます。

  - 例: `denyRead: ["~/.ssh"]` で SSH キーへのアクセスをブロック
  - 例: `denyRead: ["/Users"], allowRead: ["."]` でワークスペースを除く `/Users` 全体をブロック
  - 空の `denyRead: []` = 完全な読み取りアクセス（拒否なし）

- **書き込み**（許可のみ）: デフォルトでどこでも拒否されます。パスを明示的に許可する必要があります。
  - 例: `allowWrite: [".", "/tmp"]` で現在のディレクトリと /tmp への書き込みを許可
  - 空の `allowWrite: []` = 書き込みアクセスなし（許可なし）
  - `denyWrite` は許可されたパス内に例外を作成します（拒否が優先）

**優先順位は読み取りと書き込みで意図的に逆になっています:** `allowRead` は `denyRead` を上書きし、`denyWrite` は `allowWrite` を上書きします。これにより、拒否された領域内に読み取り可能な領域を切り出し、書き込み可能な領域内に保護領域を切り出すことができます。

### 必須拒否パス（自動保護ファイル）

特定の機密ファイルとディレクトリは、許可された書き込みパス内にある場合でも、**書き込みが常にブロックされます**。これは、サンドボックスエスケープと設定改ざんに対する多層防御を提供します。

**常にブロックされるファイル:**

- シェル設定ファイル: `.bashrc`、`.bash_profile`、`.zshrc`、`.zprofile`、`.profile`
- Git 設定ファイル: `.gitconfig`、`.gitmodules`
- その他の機密ファイル: `.ripgreprc`、`.mcp.json`

**常にブロックされるディレクトリ:**

- IDE ディレクトリ: `.vscode/`、`.idea/`
- Claude 設定ディレクトリ: `.claude/commands/`、`.claude/agents/`
- Git フックと設定: `.git/hooks/`、`.git/config`

これらのパスは自動的にブロックされます。`denyWrite` に追加する必要はありません。たとえば、`allowWrite: ["."]` でも、`.bashrc` や `.git/hooks/pre-commit` への書き込みは失敗します。```bash
$ srt 'echo "malicious" >> .bashrc'
/bin/bash: .bashrc: Operation not permitted

$ srt 'echo "bad" > .git/hooks/pre-commit'
/bin/bash: .git/hooks/pre-commit: Operation not permitted

注（Linux）： Linux では、必須拒否パスは既に存在するファイルのみをブロックします。これらのパターンに一致する存在しないファイルは、bubblewrap のバインドマウント方式ではブロックできません。macOS はグロブパターンを使用し、既存ファイルと新規ファイルの両方をブロックします。

Linux の検索深度： Linux では、サンドボックスは ripgrep を使用して、許可された書き込みパス内のサブディレクトリにある危険なファイルをスキャンします。デフォルトでは、パフォーマンスのため最大 3 階層の深さまで検索します。これは mandatoryDenySearchDepth で設定できます：```json { "mandatoryDenySearchDepth": 5, "filesystem": { "allowWrite": ["."] } }

- デフォルト: `3`（最大3階層まで検索）
- 範囲: `1` から `10`
- 値を大きくすると保護は強化されますが、パフォーマンスは低下します
- CWD（深さ0）内のファイルは、この設定に関係なく常に保護されます

### Unixソケット制限（Linux）

Linuxでは、サンドボックスは **seccomp BPF（Berkeley Packet Filter）** を使用して、システムコールレベルでUnixドメインソケットの作成をブロックします。これにより、プロセスがローカルIPC用に新しいUnixドメインソケットを作成するのを防ぐ、追加のセキュリティ層が提供されます（明示的に許可されている場合を除く）。

**仕組み:**

1. **組み込みのBPFフィルタ**: このパッケージには、seccomp BPFフィルタがコンパイル済みの静的 `apply-seccomp` バイナリがx64およびarm64向けに同梱されています。このフィルタはアーキテクチャ固有ですがlibc非依存のため、バイナリはglibcとmuslの両方で動作します。

2. **実行時の検出**: サンドボックスはシステムのアーキテクチャを自動的に検出し、一致する `apply-seccomp` バイナリを使用します。

3. **システムコールフィルタリング**: BPFフィルタは `socket()` システムコールをインターセプトし、`EPERM` を返すことで `AF_UNIX` ソケットの作成をブロックします。これにより、サンドボックス化されたコードが新しいUnixドメインソケットを作成するのを防ぎます。

4. **apply-seccompバイナリを使用した2段階の適用**:
   - 外側のbwrapが、ファイルシステム、ネットワーク、PID名前空間の制限を備えたサンドボックスを作成します
   - ネットワークブリッジプロセス（socat）がサンドボックス内で起動します（Unixソケットが必要）
   - apply-seccompがネストされたユーザー+PID+mount名前空間を作成し、`/proc` を再マウントします
   - ネストされた名前空間内で、apply-seccompがPID 1（非ダンプ可能なinit/リーパー）として動作します
   - apply-seccompがフォークし、`prctl()` を介してseccompフィルタを適用し、ユーザーコマンドをexecします
   - ユーザーコマンドは、すべてのサンドボックス制限に加えてUnixソケット作成のブロックが適用された状態で実行されます

**PID名前空間の分離**: ネストされたPID名前空間により、ユーザーコマンドはseccompフィルタなしで実行されるプロセス（bwrapのinit、シェルラッパー、socatヘルパー）を認識したり、アドレス指定したりできなくなります。これにより、フィルタリングされていないヘルパーが `ptrace` や `/proc/N/mem` を介して到達できないため、`kernel.yama.ptrace_scope` に関係なくseccomp境界が維持されます。内部のPID 1は `PR_SET_DUMPABLE=0` を設定するため、これもptrace可能ではありません。ネストされた名前空間の作成に失敗した場合、apply-seccompは分離なしで実行するのではなく、中止します。

**セキュリティ上の制限**: このフィルタは `socket(AF_UNIX, ...)` と `io_uring_setup`/`io_uring_enter`/`io_uring_register` システムコールをブロックします（後者の3つは、Linux 5.19以降の `IORING_OP_SOCKET` が `socket()` ルールをバイパスする可能性があるため）。親プロセスから継承された、または `SCM_RIGHTS` を介して渡されたUnixソケットファイル記述子に対する操作は防止しません。ほとんどのサンドボックス化シナリオでは、ソケット作成のブロックで不正なIPCを防ぐのに十分です。

**ランタイム依存関係ゼロ**: プリビルドの静的apply-seccompバイナリと事前生成されたBPFフィルタが、x64およびarm64アーキテクチャ向けに含まれています。実行時にコンパイルツールや外部依存関係は必要ありません。

**アーキテクチャサポート**: x64およびarm64は、プリビルドバイナリで完全にサポートされています。その他のアーキテクチャは現在サポートされていません。サポートされていないアーキテクチャでUnixソケットブロックなしのサンドボックス化を使用するには、設定で `allowAllUnixSockets: true` を設定してください。

### 違反の検出と監視

サンドボックス化されたプロセスが制限されたリソースにアクセスしようとすると:

1. **操作をブロック**します（OSレベルで `EPERM` エラーを返します）
2. **違反をログに記録**します（プラットフォーム固有のメカニズム）
3. **ユーザーに通知**します（Claude Codeでは、権限プロンプトがトリガーされます）

**macOS**: サンドボックスランタイムは、macOSのシステムサンドボックス違反ログストアを利用します。これにより、何が試行され、なぜブロックされたかについての詳細情報を含むリアルタイム通知が提供されます。これはClaude Codeが違反検出に使用するのと同じメカニズムです。```bash
# View sandbox violations in real-time
log stream --predicate 'process == "sandbox-exec"' --style syslog

Linux: Bubblewrapには組み込みの違反レポート機能はありません。straceを使用してシステムコールをトレースし、ブロックされた操作を特定します:```bash

Trace all denied operations

strace -f srt 2>&1 | grep EPERM

Trace specific file operations

strace -f -e trace=open,openat,stat,access srt 2>&1 | grep EPERM

Trace network operations

strace -f -e trace=network srt 2>&1 | grep EPERM

### 上級編: 独自プロキシの利用

より高度なネットワークフィルタリングを行うには、組み込みのプロキシの代わりに独自のプロキシを使用するようにサンドボックスを設定できます。これにより、以下が可能になります:

- **トラフィック検査**: [mitmproxy](https://mitmproxy.org/) などのツールを使用してトラフィックを検査・変更する
- **カスタムフィルタリングロジック**: 単純なドメイン許可リストを超えた複雑なルールを実装する
- **監査ログ**: コンプライアンスやデバッグのためにすべてのネットワークリクエストを記録する

**mitmproxy を使用した例:**```bash
# Start mitmproxy with custom filtering script
mitmproxy -s custom_filter.py --listen-port 8888

注: カスタムプロキシ設定は、新しい設定形式ではまだサポートされていません。この機能は将来のリリースで追加される予定です。

重要なセキュリティ上の考慮事項: ドメイン許可リストを使用している場合でも、データ流出の経路が存在する可能性があります。たとえば、github.com を許可すると、プロセスが任意のリポジトリにプッシュできるようになります。カスタムMITMプロキシと適切な証明書設定を使用すれば、特定のAPI呼び出しを検査およびフィルタリングしてこれを防ぐことができます。

セキュリティ上の制限事項

  • ネットワークサンドボックスの制限: ネットワークフィルタリングシステムは、プロセスが接続を許可されるドメインを制限することで動作します。プロキシを通過するトラフィックをそれ以外に検査することはなく、ユーザーはポリシーで信頼できるドメインのみを許可する責任があります。
ユーザーは、`github.com` のような広範なドメインを許可することでデータ流出の可能性が生じるリスクを認識する必要があります。また、場合によっては[ドメインフロンティング](https://en.wikipedia.org/wiki/Domain_fronting)によってネットワークフィルタリングを回避できる可能性があります。
  • Unixソケットを介した権限昇格: allowUnixSockets 設定は、意図せず強力なシステムサービスへのアクセスを許可し、サンドボックスのバイパスにつながる可能性があります。たとえば、/var/run/docker.sock へのアクセスを許可するために使用された場合、Dockerソケットを悪用してホストシステムへのアクセスを事実上許可することになります。ユーザーは、サンドボックスを介して許可するUnixソケットを慎重に検討することをお勧めします。
  • ファイルシステム権限の昇格: 過度に広範なファイルシステム書き込み権限は、権限昇格攻撃を可能にする可能性があります。$PATH 内の実行可能ファイルを含むディレクトリ、システム設定ディレクトリ、またはユーザーのシェル設定ファイル（.bashrc、.zshrc）への書き込みを許可すると、他のユーザーやシステムプロセスがこれらのファイルにアクセスした際に、異なるセキュリティコンテキストでのコード実行につながる可能性があります。
  • Linuxサンドボックスの強度: Linux実装は強力なファイルシステムおよびネットワーク分離を提供しますが、特権名前空間なしでDocker環境内で動作できるようにする enableWeakerNestedSandbox モードが含まれています。このオプションはセキュリティを大幅に弱めるため、他の方法で追加の分離が強制される場合にのみ使用する必要があります。
  • 弱いネットワーク分離（macOS）: enableWeakerNetworkIsolation オプションは、GoプログラムがmacOSセキュリティフレームワークを介してTLS証明書を検証するために必要な com.apple.trustd.agent へのアクセスを再び有効にします。これにより、trustdサービスを介した潜在的なデータ流出経路が開かれるため、GoのTLS検証が必要な場合（例: MITMプロキシとカスタムCAで httpProxyPort を使用する場合）にのみ有効にする必要があります。
  • Apple Events（macOS）: allowAppleEvents オプションは、Apple Eventsの送信とLaunch Servicesのオープンリクエスト（(allow appleevent-send)、(allow lsopen)、および com.apple.coreservices.appleevents、com.apple.CoreServices.coreservicesd、com.apple.coreservices.quarantine-resolver のmach-lookup）を再び有効にします。これらは open、osascript、およびURLを開くヘルパーが必要とするものです。これらを許可すると、サンドボックス化されたコマンドがユーザープロンプトなしで任意のアプリケーションを起動でき、起動されたアプリケーションはサンドボックスの外で完全に実行されるため、このオプションはコード実行の分離を弱めるだけでなく、完全に削除します。Apple Eventsを介した既に実行中のアプリケーションのスクリプト化は、macOSのTCC自動化同意によってさらに制限されますが、open を介した起動は制限されません。これは、サンドボックス内のコマンドが実際にURLやアプリケーションを開く必要がある場合にのみ有効にしてください。

既知の制限事項と今後の作業

Linuxプロキシバイパス: 現在、環境変数（HTTP_PROXY、HTTPS_PROXY、ALL_PROXY）を使用してトラフィックをプロキシ経由で転送しています。これはほとんどのアプリケーションで機能しますが、これらの変数を尊重しないプログラムでは無視される可能性があり、インターネットに接続できなくなる可能性があります。

今後の改善点:

  • Proxychainsサポート: Linuxで LD_PRELOAD を使用した proxychains のサポートを追加し、ネットワーク呼び出しをより低いレベルでインターセプトして、バイパスをより困難にします

  • Linux違反監視: 違反ストアと統合された、Linux向けの自動 strace ベースの違反検出を実装します。現在、Linuxユーザーは違反を確認するために手動で strace を実行する必要があります。macOSにはシステムログストアを介した自動違反監視があるのとは対照的です。

もっと読む

カテゴリ

防御ツールコンテナセキュリティ動的分析 (サンドボックス)構成監査セキュリティ仮想化ネットワークセキュリティインシデントレスポンス