Назад к обновлениям
New releaseJul 21, 2026

sandbox-runtime v0.0.66

Легковесный инструмент для песочницы, обеспечивающий ограничения файловой системы и сети на произвольные процессы на уровне ОС, без необходимости в контейнере.

Поделиться

Anthropic Sandbox Runtime (srt)

Легковесный инструмент песочницы для применения ограничений файловой системы и сети к произвольным процессам на уровне ОС, без необходимости в контейнере.

srt использует нативные примитивы песочницы ОС (sandbox-exec на macOS, bubblewrap на Linux) и прокси-фильтрацию сети. Его можно использовать для изоляции поведения агентов, локальных MCP-серверов, bash-команд и произвольных процессов.

Бета-превью для исследований

Sandbox Runtime — это исследовательское превью, разработанное для Claude Code с целью обеспечения более безопасных ИИ-агентов. Оно публикуется как раннее превью с открытым исходным кодом, чтобы помочь более широкой экосистеме создавать более безопасные агентные системы. Поскольку это раннее исследовательское превью, API и форматы конфигурации могут меняться. Мы приветствуем обратную связь и вклад, чтобы сделать ИИ-агентов безопаснее по умолчанию!

Установка```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": [] } }

Теперь MCP-серверу будет запрещена запись в запрещённый путь:```
> Write a file to ~/sensitive-folder
✗ Error: EPERM: operation not permitted, open '/Users/ollie/sensitive-folder/test.txt'

Как это работает

Песочница использует примитивы уровня ОС для применения ограничений, действующих на всё дерево процессов:

  • macOS: использует sandbox-exec с динамически генерируемыми профилями Seatbelt
  • Linux: использует bubblewrap для контейнеризации с изоляцией сетевого пространства имён
  • Windows: запускает изолированный процесс под выделенной локальной учётной записью srt-sandbox, с платформой фильтрации Windows для блокировки исходящего трафика по SID этой учётной записи и явными ACE для рабочего дерева в рамках каждой сессии

0d1c612947c798aef48e6ab4beb7e8544da9d41a-4096x2305

Модель двойной изоляции

Для эффективной работы песочницы необходимы как файловая, так и сетевая изоляция. Без файловой изоляции скомпрометированный процесс мог бы похитить SSH-ключи или другие конфиденциальные файлы. Без сетевой изоляции процесс мог бы выйти из песочницы и получить неограниченный доступ к сети.

Файловая изоляция применяет ограничения на чтение и запись:

  • Чтение (шаблон «сначала запрет, затем разрешение»): по умолчанию доступ на чтение разрешён везде. Вы можете запретить широкие области (например, /Users), а затем повторно разрешить конкретные пути внутри них (например, .). allowRead имеет приоритет над denyRead — в отличие от записи, где denyWrite имеет приоритет над allowWrite. Запись denyRead, которая является более конкретной, чем область allowRead, внутри которой она находится (например, denyRead: ["**/.env"] или ["./secrets"] с allowRead: ["."]), остаётся запрещённой.
  • Запись (шаблон «только разрешение»): по умолчанию доступ на запись запрещён везде. Вы должны явно разрешить пути (например, ., /tmp). Пустой список разрешений означает отсутствие доступа на запись.

Сетевая изоляция (шаблон «только разрешение»): по умолчанию весь сетевой доступ запрещён. Вы должны явно разрешить домены. Пустой список allowedDomains означает отсутствие сетевого доступа. Сетевой трафик маршрутизируется через прокси-серверы, работающие на хосте:

  • Linux: запросы маршрутизируются через файловую систему по Unix-доменному сокету. Сетевое пространство имён изолированного процесса удаляется полностью, поэтому весь сетевой трафик должен проходить через прокси на хосте (прослушивающие Unix-сокеты, которые монтируются в песочницу)

  • macOS: профиль Seatbelt разрешает связь только с конкретным портом localhost. Прокси прослушивают этот порт, создавая контролируемый канал для всего сетевого доступа

  • Windows: общесистемный набор фильтров WFP блокирует все исходящие соединения, исходящие от учётной записи srt-sandbox, кроме loopback-соединений в диапазон портов прокси. Прокси прослушивают внутри этого диапазона, создавая контролируемый канал для всего сетевого доступа

Как 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` для конкретного вызова (например, идентификатор использования инструмента), чтобы использовать его в качестве ключа — рекомендуется: ключи сравниваются по первым 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-пуши на GitHub заблокированы; используйте удалённый репозиторий https://"}`). Записи без причины сообщают общую причину. Для SSH-назначений (порт 22) причина также доставляется внутри канала: SSH-клиент, туннелируемый через SOCKS ProxyCommand без аутентификации (например, BSD `nc -X 5`), получает разрыв 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 принципиально ломает:
  - **mTLS вышестоящие серверы** — только клиент внутри песочницы владеет клиентским сертификатом, поэтому прокси не может переустановить соединение от его имени.
  - **Клиенты с закреплением сертификатов** — клиенты, которые сами проверяют личность вышестоящего сервера (собственные 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-сокетов (поведение зависит от платформы):

НастройкаmacOSLinux
allowUnixSockets: string[]Список разрешённых путей сокетовИгнорируется (seccomp не может фильтровать по пути)
allowAllUnixSockets: booleanРазрешить все сокетыОтключить блокировку seccomp

Unix-сокеты заблокированы по умолчанию на обеих платформах.

  • macOS: Используйте allowUnixSockets, чтобы разрешить конкретные пути (например, ["/var/run/docker.sock"]), или allowAllUnixSockets: true, чтобы разрешить все.
  • Linux: Блокировка использует фильтры seccomp (только x64/arm64). Если seccomp недоступен, сокеты не ограничиваются, и выводится предупреждение. Используйте allowAllUnixSockets: true, чтобы явно отключить блокировку.

Конфигурация файловой системы

Использует два разных шаблона:

Ограничения на чтение (шаблон «сначала запрет, затем разрешение») — по умолчанию разрешено всё чтение:

  • filesystem.denyRead — Массив путей, для которых запрещён доступ на чтение. Пустой массив = полный доступ на чтение.
  • filesystem.allowRead — Массив путей, для которых повторно разрешён доступ на чтение внутри запрещённых областей (имеет приоритет над denyRead). Примечание: это противоположность записи, где denyWrite имеет приоритет над allowWrite.

Ограничения на запись (шаблон «только разрешение») — по умолчанию запрещена вся запись:

  • filesystem.allowWrite — Массив путей, для которых разрешён доступ на запись. Пустой массив = нет доступа на запись.
  • filesystem.denyWrite — Массив путей, для которых запрещён доступ на запись внутри разрешённых путей (имеет приоритет над allowWrite)

Синтаксис путей (macOS):

На macOS пути поддерживают glob-шаблоны в стиле git, аналогично синтаксису .gitignore:

  • * — Соответствует любым символам, кроме / (например, *.ts соответствует foo.ts, но не foo/bar.ts)
  • ** — Соответствует любым символам, включая / (например, src/**/*.ts соответствует всем файлам .ts в src/)
  • ? — Соответствует любому одному символу, кроме / (например, file?.txt соответствует file1.txt)
  • [abc] — Соответствует любому символу из набора (например, file[0-9].txt соответствует file3.txt)

Примеры:

  • "allowWrite": ["src/"] — Разрешить запись во всю директорию src/
  • "allowWrite": ["src/**/*.ts"] — Разрешить запись во все файлы .ts в src/ и поддиректориях
  • "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 — Разрешить доступ к com.apple.trustd.agent в песочнице macOS (логическое значение, по умолчанию: false). Это необходимо программам на Go (gh, gcloud, terraform, kubectl и т. д.) для проверки TLS-сертификатов при использовании httpProxyPort с MITM-прокси и пользовательским CA. Предупреждение безопасности: включение этой опции открывает потенциальный вектор утечки данных через службу trustd.
  • allowAppleEvents — Разрешить отправку Apple Events и запросов на открытие Launch Services из песочницы macOS (логическое значение, по умолчанию: false). Без этого команды вроде open, osascript и всё, что открывает URL-адреса или скриптует другие приложения через AppleScript, завершаются с ошибкой 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": [] } }

Это запрещает чтение всего, что находится в `/Users` (или `/home` в Linux), а затем снова разрешает доступ к текущей рабочей директории. Системные пути (`/usr`, `/lib` и т. д.) остаются доступными для чтения.

### Частые проблемы и советы

**Запуск Jest:** Используйте флаг `--no-watchman`, чтобы избежать нарушений песочницы:```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), но лишает результирующее пространство имён capabilities. Как bubblewrap, так и уровень изоляции seccomp нуждаются в пространствах имён пользователей с capabilities. Отключите это ограничение с помощью:```bash sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

или добавьте профиль AppArmor, предоставляющий `userns` соответствующим бинарным файлам.

**Необязательные зависимости Linux (для резервного механизма seccomp):**

Пакет включает предварительно сгенерированные BPF-фильтры seccomp для архитектур x86-64 и arm. Эти зависимости нужны только в том случае, если вы используете другую архитектуру, для которой предварительно сгенерированные фильтры недоступны:

- `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 — исходящего барьера Windows Filtering Platform (WFP), привязанного к SID учётной записи песочницы, и явных ACE для каждой сессии, которые предоставляют или запрещают этому SID доступ к настроенным путям файловой системы.

### Настройка

Выполняется один раз на каждой машине (самоповышение прав; одно приглашение UAC):```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` — диапазон портов `[low, high]` (включительно), к которым привязываются JS-прокси внутри. **Должен совпадать** с диапазоном, переданным в `windows-install --proxy-port-range` (по умолчанию `[60080, 60089]`) — разрешение WFP loopback PERMIT покрывает только этот диапазон.
- `windows.sublayerGuid` — GUID подслоя WFP, под которым были установлены фильтры. Опустите, чтобы использовать значение по умолчанию на этапе компиляции; задавайте только если корпоративные инструменты установили фильтры под пользовательским подслоем.
- `windows.srtWin.path` — путь к бинарному файлу `srt-win`. Опустите, чтобы использовать встроенный `vendor/srt-win/<arch>/srt-win.exe`. Задавайте при встраивании CLI `srt-win` в мультивызывной бинарник; при запуске тогда передаётся `--srt-win` как `argv[1]`, чтобы диспетчер встраивающего приложения мог направить вызов в `srt_win::run_from_args`.

### Известные ограничения

- **Отзыв сертификатов через schannel.** Запрос CRL/OCSP через CryptoAPI выполняется через 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, обслуживаемая через loopback-прокси, чтобы устранить этот обходной путь.
- **Установки инструментов для конкретного пользователя недоступны.** Процесс в песочнице работает как `srt-sandbox`, а не как вы, поэтому инструменты, установленные в вашем профиле (Node под управлением nvm/fnm, пакеты `winget`/Scoop для пользователя, `pip install --user`, `%LOCALAPPDATA%\Programs\…`), разрешаются через унаследованный `PATH`, но не могут быть открыты учётной записью песочницы. Предпочитайте установки на уровне машины (`Program Files`, `choco`/`winget --scope machine`) или добавляйте конкретные пути профиля в `filesystem.allowRead`.
- **Переопределения `filesystem.allowRead` / `filesystem.allowWrite` для каждого запуска не поддерживаются.** Разрешения `allowRead`/`allowWrite` на уровне сессии (в конфиге, переданном в `initialize()`) работают, как описано выше; передача их для каждой команды в `customConfig` у `wrapWithSandbox` вызывает исключение — разрешения применяются на уровне сессии через `srt-win acl grant` в `initialize()`, а `srt-win exec` предоставляет только запреты для каждого запуска.
- **`proxyAuthToken` виден в командной строке запускающего процесса.** Прокси-окружение (включая `HTTP_PROXY=http://srt:<token>@127.0.0.1:…`) передаётся двухэтапному запускающему процессу как аргументы `--env` в argv `srt-win exec`, поэтому токен доступен для чтения любому локальному субъекту, который может открыть процесс запускающего приложения с правами `PROCESS_QUERY_LIMITED_INFORMATION`. Токен существует, чтобы процесс в песочнице мог аутентифицироваться на loopback-прокси, поэтому он не является секретом от самой песочницы; на однопользовательской машине разработчика это обычно приемлемо, но на общем хосте считайте, что список разрешённых прокси доступен другим субъектам той же сессии.
- **Разрешение DNS через системный резолвер не ограничено.** `getaddrinfo()` обслуживается службой `Dnscache`, работающей как `NETWORK SERVICE`, поэтому разрешение имён выполняется успешно, даже если последующий `connect()` из процесса в песочнице блокируется. Инструменты, которые сами работают с UDP/53 (`nslookup`, `dig`), ограничены. Это повторяет поведение macOS.

### Удаление```powershell
npx @anthropic-ai/sandbox-runtime windows-uninstall

Удаляет набор фильтров WFP, учетную запись srt-sandbox и ее профиль, группу sandbox-runtime-users, а также удаляет ключ HKLM\SOFTWARE\sandbox-runtime (учетные данные, маркер, запись CA) — одно приглашение UAC. %ProgramData%\sandbox-runtime (материалы ключа CA) остается на месте; удалите его (и %LOCALAPPDATA%\sandbox-runtime для каждого пользователя) вручную для полной очистки.

Разработка```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` компилируются из C-исходников в `vendor/seccomp-src/` с помощью `npm run build:seccomp` (только Linux; требуются `gcc` и `libseccomp-dev`). CI запускает его перед тестами на каждой Linux-архитектуре, а release-пайплайн собирает обе архитектуры и включает их в опубликованный пакет.

## Детали реализации

### Архитектура сетевой изоляции

Песочница запускает 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`, кроме loopback-подключений к настроенному диапазону портов прокси. Прокси привязываются к этому диапазону. Переменные окружения (`HTTP_PROXY`, `HTTPS_PROXY`, `ALL_PROXY`, …) направляют инструменты на прокси, но границей является WFP-фильтр — процесс, который игнорирует или сбрасывает их, всё равно остаётся изолированным.

### Изоляция файловой системы

Ограничения файловой системы применяются на уровне ОС:

- **macOS**: Используется `sandbox-exec` с динамически генерируемыми профилями Seatbelt, которые задают разрешённые пути для чтения/записи
- **Linux**: Используется `bubblewrap` с bind-mount, помечающим каталоги как read-only или read-write в зависимости от конфигурации
- **Windows**: На настроенные пути записываются аддитивные явные ACE `(OI)(CI)` для SID `srt-sandbox` (ALLOW для `allowRead`/`allowWrite`, DENY для `denyRead`/`denyWrite`), затем они удаляются при `reset()`

**Разрешения файловой системы по умолчанию:**

- **Чтение** (deny-then-allow): Разрешено везде по умолчанию. Вы можете запретить широкие области, а затем повторно разрешить конкретные пути внутри них. `allowRead` имеет приоритет над `denyRead`.

  - Пример: `denyRead: ["~/.ssh"]` для блокировки доступа к SSH-ключам
  - Пример: `denyRead: ["/Users"], allowRead: ["."]` для блокировки всего `/Users`, кроме рабочей области
  - Пустой `denyRead: []` = полный доступ на чтение (ничего не запрещено)

- **Запись** (allow-only): Запрещена везде по умолчанию. Вы должны явно разрешить пути.
  - Пример: `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 обязательные пути запрета блокируют только файлы, которые уже существуют. Несуществующие файлы, соответствующие этим шаблонам, не могут быть заблокированы подходом bind-mount в bubblewrap. В macOS используются glob-шаблоны, которые блокируют как существующие, так и новые файлы.

Глубина поиска в Linux: В Linux песочница использует ripgrep для сканирования опасных файлов в подкаталогах внутри разрешённых путей записи. По умолчанию для производительности поиск выполняется на глубину до 3 уровней. Вы можете настроить это с помощью mandatoryDenySearchDepth:```json { "mandatoryDenySearchDepth": 5, "filesystem": { "allowWrite": ["."] } }

- По умолчанию: `3` (поиск на глубину до 3 уровней)
- Диапазон: от `1` до `10`
- Более высокие значения обеспечивают большую защиту, но снижают производительность
- Файлы в текущей рабочей директории (глубина 0) защищены всегда, независимо от этого параметра

### Ограничения Unix-сокетов (Linux)

В Linux песочница использует **seccomp BPF (Berkeley Packet Filter)** для блокировки создания Unix domain-сокетов на уровне системных вызовов. Это обеспечивает дополнительный уровень безопасности, предотвращая создание процессами новых Unix domain-сокетов для локального IPC (если это явно не разрешено).

**Как это работает:**

1. **Встроенный BPF-фильтр**: Пакет поставляется со статическим бинарником `apply-seccomp` для x64 и arm64 со встроенным seccomp BPF-фильтром. Фильтр зависит от архитектуры, но не зависит от libc, поэтому бинарник работает как с glibc, так и с musl.

2. **Определение во время выполнения**: Песочница автоматически определяет архитектуру вашей системы и использует соответствующий бинарник `apply-seccomp`.

3. **Фильтрация системных вызовов**: BPF-фильтр перехватывает системный вызов `socket()` и блокирует создание сокетов `AF_UNIX`, возвращая `EPERM`. Это предотвращает создание новых Unix domain-сокетов кодом внутри песочницы.

4. **Двухэтапное применение с помощью бинарника apply-seccomp**:
   - Внешний bwrap создаёт песочницу с ограничениями файловой системы, сети и PID namespace
   - Процессы сетевого моста (socat) запускаются внутри песочницы (им нужны Unix-сокеты)
   - apply-seccomp создаёт вложенный namespace user+PID+mount и перемонтирует `/proc`
   - Внутри вложенного namespace apply-seccomp выступает в роли PID 1 (init/reaper, не поддающийся дампу)
   - apply-seccomp выполняет fork, применяет seccomp-фильтр через `prctl()` и запускает команду пользователя через exec
   - Команда пользователя выполняется со всеми ограничениями песочницы плюс блокировкой создания Unix-сокетов

**Изоляция PID namespace**: Вложенный PID namespace гарантирует, что команда пользователя не может видеть или адресовать процессы, работающие без seccomp-фильтра (init от bwrap, обёртка shell или помощники socat). Это сохраняет границу seccomp независимо от `kernel.yama.ptrace_scope`, поскольку нефильтрованные помощники недоступны через `ptrace` или `/proc/N/mem`. Внутренний PID 1 устанавливает `PR_SET_DUMPABLE=0`, поэтому он также не доступен для ptrace. Если создание вложенного namespace не удаётся, apply-seccomp прерывает работу, а не запускается без изоляции.

**Ограничения безопасности**: Фильтр блокирует `socket(AF_UNIX, ...)` и системные вызовы `io_uring_setup`/`io_uring_enter`/`io_uring_register` (последние три — потому что `IORING_OP_SOCKET` в Linux 5.19+ в противном случае обошёл бы правило `socket()`). Он не предотвращает операции с файловыми дескрипторами Unix-сокетов, унаследованными от родительских процессов или переданными через `SCM_RIGHTS`. Для большинства сценариев песочницы блокировки создания сокетов достаточно для предотвращения несанкционированного IPC.

**Ноль зависимостей во время выполнения**: Предварительно собранные статические бинарники apply-seccomp и предварительно сгенерированные BPF-фильтры включены для архитектур x64 и arm64. Никаких инструментов компиляции или внешних зависимостей во время выполнения не требуется.

**Поддержка архитектур**: x64 и arm64 полностью поддерживаются с предварительно собранными бинарниками. Другие архитектуры в настоящее время не поддерживаются. Чтобы использовать песочницу без блокировки Unix-сокетов на неподдерживаемых архитектурах, установите `allowAllUnixSockets: true` в вашей конфигурации.

### Обнаружение и мониторинг нарушений

Когда процесс в песочнице пытается получить доступ к ограниченному ресурсу:

1. **Блокирует операцию** на уровне ОС (возвращает ошибку `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

### Advanced: Bring Your Own Proxy

Для более сложной фильтрации сети вы можете настроить песочницу на использование собственного прокси вместо встроенных. Это позволяет:

- **Инспекцию трафика**: Используйте такие инструменты, как [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`, которые могут допускать эксфильтрацию данных. Кроме того, в некоторых случаях возможен обход сетевой фильтрации через [domain fronting](https://en.wikipedia.org/wiki/Domain_fronting).
  • Повышение привилегий через Unix-сокеты: Параметр allowUnixSockets может непреднамеренно предоставить доступ к мощным системным службам, что может привести к обходу песочницы. Например, если он используется для разрешения доступа к /var/run/docker.sock, это фактически предоставит доступ к хост-системе через эксплуатацию docker-сокета. Пользователям рекомендуется тщательно обдумывать, какие Unix-сокеты они разрешают через песочницу.
  • Повышение прав через разрешения файловой системы: Чрезмерно широкие права на запись в файловой системе могут позволить атаки с повышением привилегий. Разрешение записи в каталоги, содержащие исполняемые файлы в $PATH, системные каталоги конфигурации или файлы конфигурации пользовательской оболочки (.bashrc, .zshrc), может привести к выполнению кода в различных контекстах безопасности, когда другие пользователи или системные процессы обращаются к этим файлам.
  • Надёжность песочницы Linux: Реализация для Linux обеспечивает сильную изоляцию файловой системы и сети, но включает режим enableWeakerNestedSandbox, который позволяет ей работать внутри Docker-сред без привилегированных пространств имён. Этот параметр значительно ослабляет безопасность и должен использоваться только в тех случаях, когда дополнительная изоляция обеспечивается иными средствами.
  • Более слабая сетевая изоляция (macOS): Параметр enableWeakerNetworkIsolation повторно включает доступ к com.apple.trustd.agent, который необходим Go-программам для проверки TLS-сертификатов через macOS Security framework. Это открывает потенциальный вектор эксфильтрации данных через службу trustd, и его следует включать только тогда, когда требуется проверка TLS в Go (например, при использовании httpProxyPort с MITM-прокси и пользовательским CA).
  • Apple Events (macOS): Параметр allowAppleEvents повторно включает отправку Apple Events и запросов открытия Launch Services ((allow appleevent-send), (allow lsopen) и mach-lookups для com.apple.coreservices.appleevents, com.apple.CoreServices.coreservicesd и com.apple.coreservices.quarantine-resolver), которые требуются для open, osascript и вспомогательных программ открытия URL. При их разрешении команда в песочнице может запускать произвольные приложения без запроса пользователя, а запущенные приложения работают полностью вне песочницы — так что этот параметр устраняет изоляцию выполнения кода, а не просто ослабляет её. Управление уже запущенными приложениями через Apple Events дополнительно ограничивается согласием на автоматизацию TCC в macOS, но запуск через open — нет. Включайте это только тогда, когда командам внутри песочницы действительно нужно открывать URL-адреса или приложения.

Известные ограничения и планы на будущее

Обход прокси в Linux: В настоящее время для направления трафика через прокси используются переменные окружения (HTTP_PROXY, HTTPS_PROXY, ALL_PROXY). Это работает для большинства приложений, но может игнорироваться программами, которые не учитывают эти переменные, что приводит к невозможности подключения к интернету.

Будущие улучшения:

  • Поддержка Proxychains: Добавить поддержку proxychains с LD_PRELOAD в Linux для перехвата сетевых вызовов на более низком уровне, что сделает обход более сложным

  • Мониторинг нарушений в Linux: Реализовать автоматическое обнаружение нарушений на основе strace для Linux, интегрированное с хранилищем нарушений. В настоящее время пользователи Linux должны вручную запускать strace, чтобы увидеть нарушения, в отличие от macOS, где автоматический мониторинг нарушений осуществляется через системное хранилище журналов

Читать далее

Категории

Оборонительные ИнструментыБезопасность контейнеровДинамический анализ (песочница)Аудит конфигурацииВиртуализация для безопасностиСетевая безопасностьРеагирование на Инциденты