Volver a actualizaciones
Nuevo releaseAug 8, 2026

sandbox-runtime v0.0.71

Una herramienta de sandboxing ligera para aplicar restricciones de sistema de archivos y red en procesos arbitrarios a nivel del sistema operativo, sin necesidad de un contenedor.

Compartir

Anthropic Sandbox Runtime (srt)

Una herramienta de sandboxing ligera para imponer restricciones de sistema de archivos y red en procesos arbitrarios a nivel del sistema operativo, sin requerir un contenedor.

srt utiliza primitivas nativas de sandboxing del sistema operativo (sandbox-exec en macOS, bubblewrap en Linux) y filtrado de red basado en proxy. Puede usarse para sandboxear el comportamiento de agentes, servidores MCP locales, comandos bash y procesos arbitrarios.

Vista previa de investigación Beta

El Sandbox Runtime es una vista previa de investigación desarrollada para Claude Code para permitir agentes de IA más seguros. Se pone a disposición como una vista previa temprana de código abierto para ayudar al ecosistema en general a construir sistemas agénticos más seguros. Al tratarse de una vista previa de investigación temprana, las API y los formatos de configuración pueden evolucionar. Agradecemos comentarios y contribuciones para hacer que los agentes de IA sean más seguros por defecto.

Instalación```bash

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

## Uso básico```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

Descripción general

Este paquete proporciona una implementación de sandbox independiente que puede utilizarse tanto como herramienta CLI como biblioteca. Está diseñado con una filosofía seguro por defecto adaptada a los casos de uso comunes de los desarrolladores: los procesos se inician con acceso mínimo, y tú abres explícitamente solo los huecos que necesitas.

Capacidades clave:

  • Restricciones de red: Controla qué hosts/dominios pueden accederse mediante HTTP/HTTPS y otros protocolos
  • Restricciones del sistema de archivos: Controla qué archivos/directorios pueden leerse/escribirse
  • Restricciones de sockets Unix: Controla el acceso a sockets IPC locales
  • Monitoreo de violaciones: En macOS, accede al almacén de registros de violaciones de sandbox del sistema para alertas en tiempo real

Ejemplo de caso de uso: Sandboxing de servidores MCP

Un caso de uso clave es aplicar sandbox a los servidores del Model Context Protocol (MCP) para restringir sus capacidades. Por ejemplo, para poner en sandbox el servidor MCP de sistema de archivos:

Sin sandboxing (.mcp.json):```json { "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem"] } } }

**Con sandboxing** (`.mcp.json`):```json
{
  "mcpServers": {
    "filesystem": {
      "command": "srt",
      "args": ["npx", "-y", "@modelcontextprotocol/server-filesystem"]
    }
  }
}

A continuación, configure las restricciones en ~/.srt-settings.json:```json { "filesystem": { "denyRead": [], "allowWrite": ["."], "denyWrite": ["~/sensitive-folder"] }, "network": { "allowedDomains": [], "deniedDomains": [] } }

Ahora el servidor MCP estará bloqueado para escribir en la ruta denegada:```
> Write a file to ~/sensitive-folder
✗ Error: EPERM: operation not permitted, open '/Users/ollie/sensitive-folder/test.txt'

Cómo funciona

El sandbox utiliza primitivas a nivel de sistema operativo para imponer restricciones que se aplican a todo el árbol de procesos:

  • macOS: Utiliza sandbox-exec con perfiles Seatbelt generados dinámicamente
  • Linux: Utiliza bubblewrap para la contenedorización con aislamiento de espacio de nombres de red
  • Windows: Ejecuta el proceso en el sandbox bajo una cuenta de usuario local dedicada srt-sandbox, con una Plataforma de filtrado de Windows barrera de salida basada en el SID de esa cuenta y ACEs explícitas por sesión en el árbol de trabajo

0d1c612947c798aef48e6ab4beb7e8544da9d41a-4096x2305

Modelo de aislamiento dual

Tanto el aislamiento del sistema de archivos como el de red son necesarios para un sandboxing eficaz. Sin el aislamiento de archivos, un proceso comprometido podría exfiltrar claves SSH u otros archivos sensibles. Sin el aislamiento de red, un proceso podría escapar del sandbox y obtener acceso a la red sin restricciones.

Aislamiento del sistema de archivos impone restricciones de lectura y escritura:

  • Lectura (patrón de denegar-luego-permitir): Por defecto, el acceso de lectura está permitido en todas partes. Puedes denegar regiones amplias (p. ej., /Users) y luego volver a permitir rutas específicas dentro de ellas (p. ej., .). allowRead tiene prioridad sobre denyRead — lo contrario de la escritura, donde denyWrite tiene prioridad sobre allowWrite.
  • Escritura (patrón de solo permiso): Por defecto, el acceso de escritura está denegado en todas partes. Debes permitir explícitamente rutas (p. ej., ., /tmp). Una lista de permisos vacía significa que no hay acceso de escritura.

Aislamiento de red (patrón de solo permiso): Por defecto, todo el acceso a la red está denegado. Debes permitir explícitamente dominios. Una lista allowedDomains vacía significa que no hay acceso a la red. El tráfico de red se enruta a través de servidores proxy que se ejecutan en el host:

  • Linux: Las solicitudes se enrutan a través del sistema de archivos mediante un socket de dominio Unix. El espacio de nombres de red del proceso en el sandbox se elimina por completo, por lo que todo el tráfico de red debe pasar por los proxies que se ejecutan en el host (escuchando en sockets Unix que se montan mediante bind dentro del sandbox)

  • macOS: El perfil de Seatbelt solo permite la comunicación con un puerto específico de localhost. Los proxies escuchan en ese puerto, creando un canal controlado para todo el acceso a la red

  • Windows: Un conjunto de filtros WFP en toda la máquina bloquea todas las conexiones salientes originadas desde la cuenta srt-sandbox, excepto loopback hacia el rango de puertos del proxy. Los proxies escuchan dentro de ese rango, creando un canal controlado para todo el acceso a la red

Tanto el tráfico HTTP/HTTPS (mediante proxy HTTP) como el resto del tráfico TCP (mediante proxy SOCKS5) son mediados por estos proxies, que aplican tus listas de permitidos y denegados de dominios.

Para obtener más detalles sobre el sandboxing en Claude Code, consulta:

Arquitectura```

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

## Usage

### As a CLI tool

The `srt` command (Anthropic Sandbox Runtime) wraps any command with security boundaries:

El comando `srt` (Anthropic Sandbox Runtime) envuelve cualquier comando con límites de seguridad:```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

Como biblioteca```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() })

**Atribución de violaciones (`commandId` / `commandText`).** Las violaciones observadas mientras se ejecuta un comando envuelto (líneas de registro de seatbelt, eventos de seccomp, denegaciones de proxy) se almacenan bajo una clave de atribución, y `annotateStderrWithSandboxFailures(key, stderr)` / `getViolationsForCommand(key)` las buscan mediante esa misma clave. Por defecto, la clave es la propia cadena envuelta. Pasa un `commandId` opaco por invocación (p. ej. un id de tool-use) para usar esa clave en su lugar — recomendado: las claves se comparan por sus primeros 100 caracteres, por lo que comandos largos que compartan un prefijo se atribuirían de forma cruzada, y una re-ejecución del mismo texto heredaría los eventos de la ejecución anterior. Si la cadena que *ejecutas* no es el comando que la invocación *representa* (p. ej. envuelves un `source <snapshot> && eval '<cmd>'` ensamblado), pasa también `commandText: '<cmd>'`: es lo que los patrones de comando de `ignoreViolations` comparan y lo que cada violación reporta como su `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)

Exportaciones disponibles```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'

## Configuración

### Ubicación del archivo de configuración

Por defecto, el runtime del sandbox busca la configuración en `~/.srt-settings.json`. Puedes especificar una ruta personalizada mediante la opción `--settings`:```bash
srt --settings /path/to/srt-settings.json <command>

Ejemplo completo de configuración```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 }

### Opciones de configuración

#### Configuración de red

Utiliza un **patrón de solo permitidos**: todo el acceso a la red está denegado por defecto.

- `network.allowedDomains` - Matriz de dominios permitidos (admite comodines como `*.example.com`). Matriz vacía = sin acceso a la red. Un sufijo opcional `:port` (`api.example.com:443`, `*.example.com:8443`) restringe una entrada a ese puerto de destino; las entradas sin puerto coinciden con cualquier puerto.
  - Los literales IPv6 deben estar entre corchetes, estilo RFC 3986: `[::1]`, `[2001:db8::1]:443`. Una entrada sin corchetes con múltiples dos puntos se rechaza por ambigua (`2001:db8::1:443` es en sí misma una dirección válida).
- `network.deniedDomains` - Matriz de dominios denegados (se comprueba primero, tiene prioridad sobre allowedDomains). Mismo sufijo `:port`, y se acepta un `*` desnudo (o `*:22`) para denegar todo.
- `network.deniedDomainReasons` - Mapa opcional de una entrada de `deniedDomains` (coincidente por cadena exacta) a una razón visible para el modelo que aparece en la línea `<sandbox_violations>` cuando esa entrada deniega una conexión — indica qué está bloqueado y la alternativa sancionada (p. ej. `{"github.com:22": "SSH pushes to GitHub are blocked; use an https:// remote"}`). Las entradas sin razón informan una genérica. Para destinos SSH (puerto 22), la razón también se entrega dentro de la banda: un cliente SSH tunelizado a través de un ProxyCommand SOCKS sin autenticación (p. ej. BSD `nc -X 5`) recibe una desconexión SSH previa al intercambio de claves cuya descripción es la razón, que OpenSSH imprime textualmente: mantén dichas razones por debajo de ~400 caracteres ASCII, con imperativo primero, ya que OpenSSH trunca y escapa los no ASCII.
- `network.allowLocalBinding` - Permitir la vinculación a puertos locales (booleano, valor por defecto: false)

**Terminación TLS** (`network.tlsTerminate`, experimental): cuando se establece, los CONNECT HTTPS se terminan en el proceso para que SRT pueda ver (y filtrar, mediante `network.filterRequest`) las solicitudes descifradas. El proceso en la sandbox se apunta a un conjunto de certificados de confianza que contiene la CA MITM (`caCertPath`/`caKeyPath`, o una CA efímera si se omite) además de las raíces habituales del host, de modo que tanto los certificados emitidos por el proxy como los certificados upstream reales se verifican.

- `network.tlsTerminate.excludeDomains` - Patrones de dominio (misma sintaxis que `allowedDomains`) que **no** se terminan. Los CONNECT que coinciden se tunelizan de forma opaca: siguen sujetos a la lista de permitidos de dominios, pero el cliente dentro de la sandbox completa su propio handshake TLS con el upstream real, y `filterRequest` / la inyección de credenciales no se aplican a su tráfico HTTPS. Úsalo para los dos casos en los que la terminación TLS falla fundamentalmente:
  - **Upstreams mTLS** - solo el cliente dentro de la sandbox posee el certificado de cliente, por lo que el proxy no puede re-originar la conexión en su nombre.
  - **Clientes con fijación de certificados** - clientes que verifican la identidad del upstream por sí mismos (CAs personalizadas, fijación de SAN) y rechazan el certificado MITM.
- `network.tlsTerminate.extraCaCertPaths` - Rutas a archivos de certificados CA en formato PEM que se añaden a ese conjunto de confianza, después de la CA MITM y de las raíces habituales del host. Los hosts excluidos (no terminados) son verificados por el cliente dentro de la sandbox, y las variables de entorno de confianza que SRT establece (`SSL_CERT_FILE`, `GIT_SSL_CAINFO`, ...) _reemplazan_ la configuración de confianza propia de cada herramienta, por lo que una raíz local del sitio (p. ej. una CA mTLS interna) debe estar en el conjunto o esos hosts nunca podrán verificarse. Solo los bloques `CERTIFICATE` de cada archivo se copian en el conjunto (cualquier otra cosa, p. ej. una clave privada en un PEM combinado, nunca se expone a la sandbox); los archivos que faltan, no se pueden leer o no contienen ningún bloque PEM `CERTIFICATE` se omiten, por lo que es seguro listar rutas que existen solo en algunos hosts.```json
{
  "network": {
    "allowedDomains": ["*.example.com", "internal-mtls.example.net"],
    "deniedDomains": [],
    "tlsTerminate": {
      "excludeDomains": ["internal-mtls.example.net"],
      "extraCaCertPaths": ["/etc/internal-mtls-roots.pem"]
    }
  }
}

Configuración de sockets Unix (comportamiento específico de plataforma):

ConfiguraciónmacOSLinux
allowUnixSockets: string[]Lista de rutas de socket permitidasIgnorado (seccomp no puede filtrar por ruta)
allowAllUnixSockets: booleanPermitir todos los socketsDeshabilitar el bloqueo de seccomp

Los sockets Unix están bloqueados por defecto en ambas plataformas.

  • macOS: Usa allowUnixSockets para permitir rutas específicas (p. ej., ["/var/run/docker.sock"]), o allowAllUnixSockets: true para permitir todas.
  • Linux: El bloqueo usa filtros seccomp (solo x64/arm64). Si seccomp no está disponible, los sockets no tienen restricciones y se muestra una advertencia. Usa allowAllUnixSockets: true para deshabilitar explícitamente el bloqueo.

Configuración del sistema de archivos

Usa dos patrones diferentes:

Restricciones de lectura (patrón de denegar-luego-permitir): todas las lecturas permitidas por defecto:

  • filesystem.denyRead - Arreglo de rutas para denegar el acceso de lectura. Arreglo vacío = acceso de lectura completo.
  • filesystem.allowRead - Arreglo de rutas para volver a permitir el acceso de lectura dentro de regiones denegadas (tiene prioridad sobre denyRead). Nota: esto es lo opuesto a escritura, donde denyWrite tiene prioridad sobre allowWrite.

Restricciones de escritura (patrón de solo permitir): todas las escrituras denegadas por defecto:

  • filesystem.allowWrite - Arreglo de rutas para permitir el acceso de escritura. Arreglo vacío = sin acceso de escritura.
  • filesystem.denyWrite - Arreglo de rutas para denegar el acceso de escritura dentro de las rutas permitidas (tiene prioridad sobre allowWrite)

Sintaxis de rutas (macOS):

Las rutas admiten patrones glob estilo git en macOS, similares a la sintaxis de .gitignore:

  • * - Coincide con cualquier carácter excepto / (p. ej., *.ts coincide con foo.ts pero no con foo/bar.ts)
  • ** - Coincide con cualquier carácter, incluido / (p. ej., src/**/*.ts coincide con todos los archivos .ts en src/)
  • ? - Coincide con cualquier carácter único excepto / (p. ej., file?.txt coincide con file1.txt)
  • [abc] - Coincide con cualquier carácter del conjunto (p. ej., file[0-9].txt coincide con file3.txt)

Ejemplos:

  • "allowWrite": ["src/"] - Permitir escritura en todo el directorio src/
  • "allowWrite": ["src/**/*.ts"] - Permitir escritura en todos los archivos .ts en src/ y subdirectorios
  • "denyRead": ["~/.ssh"] - Denegar lectura del directorio SSH
  • "denyRead": ["/Users"], "allowRead": ["."] - Denegar lectura de todo /Users, pero volver a permitir el directorio actual
  • "denyWrite": [".env"] - Denegar escritura del archivo .env (incluso si el directorio actual está permitido)

Sintaxis de rutas (Linux):

Actualmente Linux no admite coincidencia de glob. Usa solo rutas literales:

  • "allowWrite": ["src/"] - Permitir escritura al directorio src/
  • "denyRead": ["/home/user/.ssh"] - Denegar lectura del directorio SSH
  • "denyRead": ["/home"], "allowRead": ["."] - Denegar lectura de todo /home, pero volver a permitir el directorio actual

Todas las plataformas:

  • Las rutas pueden ser absolutas (p. ej., /home/user/.ssh) o relativas al directorio de trabajo actual (p. ej., ./src)
  • ~ se expande al directorio personal del usuario

Otra configuración

  • ignoreViolations - Objeto que asigna patrones de comandos a arreglos de rutas en las que se deben ignorar las violaciones
  • enableWeakerNestedSandbox - Habilita el modo de sandbox más débil para entornos Docker (booleano, por defecto: false)
  • enableWeakerNetworkIsolation - Permite el acceso a com.apple.trustd.agent en la sandbox de macOS (booleano, por defecto: false). Esto es necesario para que los programas Go (gh, gcloud, terraform, kubectl, etc.) verifiquen certificados TLS cuando se usa httpProxyPort con un proxy MITM y una CA personalizada. Advertencia de seguridad: habilitar esto abre un posible vector de exfiltración de datos a través del servicio trustd.
  • allowAppleEvents - Permite enviar Apple Events y solicitudes de apertura de Launch Services desde la sandbox de macOS (booleano, por defecto: false). Sin esto, comandos como open, osascript y cualquier cosa que abra URLs o scripts de otras aplicaciones mediante AppleScript fallan con el error de AppleScript -600 ("Application isn't running") o errores de LaunchServices (-10822, -54). Advertencia de seguridad: habilitar esto significa que la sandbox ya no proporciona aislamiento de ejecución de código. Un comando en la sandbox puede lanzar otras aplicaciones mediante open sin aviso al usuario, y cualquier cosa que lance se ejecuta fuera de las restricciones de sistema de archivos y red de la sandbox; además, el scripting de aplicaciones ya en ejecución mediante Apple Events está controlado por el consentimiento de automatización TCC por aplicación del usuario. Los integradores solo deben tomar esta opción de una configuración de confianza a nivel de usuario — nunca de archivos locales del proyecto en un repositorio clonado, lo que permitiría que un proyecto creado por un atacante eleve sus propios permisos de sandbox.

Recetas de configuración comunes

Permitir acceso a GitHub (todos los endpoints necesarios):```json { "network": { "allowedDomains": [ "github.com", "*.github.com", "lfs.github.com", "api.github.com" ], "deniedDomains": [] }, "filesystem": { "denyRead": [], "allowWrite": ["."], "denyWrite": [] } }

**Restringir a directorios específicos:**```json
{
  "network": {
    "allowedDomains": [],
    "deniedDomains": []
  },
  "filesystem": {
    "denyRead": ["~/.ssh"],
    "allowWrite": [".", "src/", "test/"],
    "denyWrite": [".env", "secrets/"]
  }
}

Acceso al sistema de archivos solo del espacio de trabajo (denegar lecturas fuera del espacio de trabajo):```json { "network": { "allowedDomains": [], "deniedDomains": [] }, "filesystem": { "denyRead": ["/Users"], "allowRead": ["."], "allowWrite": ["."], "denyWrite": [] } }

Esto deniega la lectura de cualquier cosa bajo `/Users` (o `/home` en Linux), y luego vuelve a permitir el directorio de trabajo actual. Las rutas del sistema (`/usr`, `/lib`, etc.) permanecen legibles.

### Problemas comunes y consejos

**Ejecutar Jest:** Usa la opción `--no-watchman` para evitar violaciones del sandbox:```bash
srt "jest --no-watchman"

Watchman accede a archivos fuera de los límites del sandbox, lo que provocará errores de permisos. Deshabilitarlo permite que Jest se ejecute con el observador de archivos integrado en su lugar.

Soporte de plataformas

  • macOS: Utiliza sandbox-exec con perfiles personalizados (sin dependencias adicionales)
  • Linux: Utiliza bubblewrap (bwrap) para la contenerización
  • Windows: Alpha — utiliza un asistente incluido srt-win.exe (sin dependencias adicionales). Consulta Windows (alpha) a continuación para la configuración, el modelo de seguridad y las limitaciones conocidas

Dependencias específicas por plataforma

Linux requiere:

  • bubblewrap - Entorno de ejecución de contenedores
    • Ubuntu/Debian: apt-get install bubblewrap
    • Fedora: dnf install bubblewrap
    • Arch: pacman -S bubblewrap
  • socat - Relé de sockets para el puente de proxy
    • Ubuntu/Debian: apt-get install socat
    • Fedora: dnf install socat
    • Arch: pacman -S socat
  • ripgrep - Herramienta de búsqueda rápida para la detección de rutas denegadas
    • Ubuntu/Debian: apt-get install ripgrep
    • Fedora: dnf install ripgrep
    • Arch: pacman -S ripgrep

Nota para Ubuntu 24.04+: Estas versiones habilitan kernel.apparmor_restrict_unprivileged_userns de forma predeterminada, lo que permite unshare(CLONE_NEWUSER) pero elimina las capacidades del espacio de nombres resultante. Tanto bubblewrap como la capa de aislamiento seccomp necesitan espacios de nombres de usuario con capacidades. Deshabilite la restricción con:```bash sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

o añade un perfil de AppArmor que conceda `userns` a los binarios relevantes.

**Dependencias opcionales de Linux (para el respaldo de seccomp):**

El paquete incluye filtros BPF de seccomp pregenerados para arquitecturas x86-64 y arm. Estas dependencias solo se necesitan si te encuentras en una arquitectura diferente donde no están disponibles los filtros pregenerados:

- `gcc` o `clang` - compilador de C
- `libseccomp-dev` - archivos de desarrollo de la biblioteca Seccomp
  - Ubuntu/Debian: `apt-get install gcc libseccomp-dev`
  - Fedora: `dnf install gcc libseccomp-devel`
  - Arch: `pacman -S gcc libseccomp`

**macOS requiere:**

- `ripgrep` - herramienta de búsqueda rápida para la detección de rutas denegadas
  - Instalar vía Homebrew: `brew install ripgrep`
  - O descargar desde: https://github.com/BurntSushi/ripgrep/releases

**Windows requiere:**

- No hay dependencias adicionales. El asistente `srt-win.exe` (x64 y arm64) está incluido con el paquete npm. Se requiere un paso único de `windows-install` con privilegios elevados — ver más abajo.

## Windows (alfa)

El soporte para Windows es **alfa**. El proceso en sandbox se ejecuta bajo una cuenta de usuario local dedicada `srt-sandbox`, aislado del usuario que lo invoca mediante primitivas de seguridad nativas de Windows — una barrera de salida de la Plataforma de filtrado de Windows (WFP) basada en el SID de la cuenta de sandbox, y ACE explícitos por sesión que conceden o deniegan a ese SID el acceso a las rutas del sistema de archivos configuradas.

### Configuración

Ejecutar una vez por máquina (se autoeleva; un aviso de UAC):```powershell
npx @anthropic-ai/sandbox-runtime windows-install

This provisions the srt-sandbox local user account (with a random password stored DPAPI-encrypted under %LOCALAPPDATA%\sandbox-runtime\state.db), 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 concurrent hosts via state.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()` compara el thumbprint de la CA de la sesión con el instalado y falla con un mensaje procesable si no coinciden, de modo que una CA obsoleta del momento de la instalación no pueda romper silenciosamente TLS dentro del sandbox.

Los clientes basados en OpenSSL (`curl` de msys2, `git -c http.sslBackend=openssl`, Node, Python, cargo) están cubiertos por la capa de confianza basada en variables de entorno: el mismo paquete de confianza utilizado en macOS/Linux se pasa al sandbox mediante `NODE_EXTRA_CA_CERTS`, `SSL_CERT_FILE`, `CURL_CA_BUNDLE`, `GIT_SSL_CAINFO`, `CARGO_HTTP_CAINFO`, etc., y la ruta del paquete se añade a la concesión `allowRead` de la sesión para que la cuenta del sandbox pueda abrirlo.

### Configuración específica de Windows

Los bloques multiplataforma `filesystem` y `network` se aplican como se describió anteriormente. Los ajustes exclusivos de Windows se encuentran bajo `windows`:

- `windows.proxyPortRange` — rango de puertos inclusivo `[low, high]` al que se vinculan los proxies JS. **Debe coincidir** con el rango pasado a `windows-install --proxy-port-range` (por defecto `[60080, 60089]`) — el PERMIT de loopback de WFP solo cubre ese rango.
- `windows.sublayerGuid` — GUID de la subcapa WFP bajo la cual se instalaron los filtros. Omítelo para usar el valor predeterminado de compilación; establécselo solo cuando las herramientas empresariales instalaron los filtros bajo una subcapa personalizada.
- `windows.srtWin.path` — ruta al binario `srt-win`. Omítelo para resolver el empaquetado `vendor/srt-win/<arch>/srt-win.exe`. Configúralo al incrustar la CLI de `srt-win` en un binario multicall; los spawns entonces pasan `--srt-win` como `argv[1]` para que el despachador del integrador pueda enrutar a `srt_win::run_from_args`.

### Limitaciones conocidas

- **Revocación de certificados en schannel.** La consulta CRL/OCSP de CryptoAPI sale por WinHTTP con el token del llamador, ignorando el entorno de proxy, por lo que es bloqueada por la valla de salida de WFP. Las herramientas que usan schannel con verificación de revocación activada por defecto fallan con `CRYPT_E_REVOCATION_OFFLINE` (`0x80092013`) a menos que la revocación esté desactivada por herramienta: `curl --ssl-no-revoke`, `git -c http.schannelCheckRevoke=false`, `CARGO_HTTP_CHECK_REVOKE=false`. `Invoke-WebRequest`, .NET `HttpClient` y `gh` no comprueban la revocación por defecto y no se ven afectados. Está previsto un punto de distribución de CRL servido desde el proxy de loopback para eliminar esta solución.
- **Las instalaciones de herramientas por usuario no son accesibles.** El proceso sandbox se ejecuta como `srt-sandbox`, no como tú, por lo que las herramientas instaladas en tu perfil (Node gestionado por nvm/fnm, paquetes `winget`/Scoop por usuario, `pip install --user`, `%LOCALAPPDATA%\Programs\…`) se resuelven en el `PATH` heredado pero no pueden ser abiertas por la cuenta del sandbox. Prefiere instalaciones de todo el sistema (`Program Files`, `choco`/`winget --scope machine`), o añade las rutas específicas del perfil a `filesystem.allowRead`.
- **No se admiten anulaciones por ejecución de `filesystem.allowRead` / `filesystem.allowWrite`.** Los `allowRead`/`allowWrite` a nivel de sesión (en la configuración pasada a `initialize()`) funcionan como se describió anteriormente; pasarlos por comando en `customConfig` de `wrapWithSandbox` lanza una excepción: las concesiones se aplican a toda la sesión mediante `srt-win acl grant` en `initialize()`, y `srt-win exec` solo expone denegaciones por ejecución.
- **`proxyAuthToken` es visible en la línea de comandos del runner.** El entorno del proxy (incluido `HTTP_PROXY=http://srt:<token>@127.0.0.1:…`) se pasa al runner de dos saltos como argumentos `--env` en el argv de `srt-win exec`, por lo que el token es legible por cualquier principal local que pueda abrir el proceso del runner con `PROCESS_QUERY_LIMITED_INFORMATION`. El token existe para que el proceso sandbox pueda autenticarse ante el proxy de loopback, por lo que no es un secreto para el propio sandbox; en una máquina de desarrollo de un solo usuario esto suele ser aceptable, pero en un host compartido trata la lista de permitidos del proxy como accesible por otros principales de la misma sesión.
- **La resolución DNS a través del resolutor del sistema no está aislada.** `getaddrinfo()` es atendido por el servicio `Dnscache` que se ejecuta como `NETWORK SERVICE`, por lo que la resolución de nombres tiene éxito aunque el posterior `connect()` del proceso sandbox esté bloqueado. Las herramientas que hacen su propio UDP/53 (`nslookup`, `dig`) sí están aisladas. Esto refleja el comportamiento de macOS.

### Desinstalación```powershell
npx @anthropic-ai/sandbox-runtime windows-uninstall

Elimina el conjunto de filtros WFP, la cuenta srt-sandbox y su perfil, el grupo sandbox-runtime-users, y borra el marcador de credenciales/configuración de state.db (un aviso de UAC). El propio %LOCALAPPDATA%\sandbox-runtime\state.db se deja en su lugar (está marcado con ACL solo-broker); elimina el directorio manualmente para una limpieza completa.

Desarrollo```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

### Construcción de binarios Seccomp

El filtro BPF y el cargador `apply-seccomp` se compilan desde el código fuente C en `vendor/seccomp-src/` mediante `npm run build:seccomp` (solo Linux; requiere `gcc` y `libseccomp-dev`). El CI lo ejecuta antes de las pruebas en cada arquitectura Linux, y el flujo de trabajo de lanzamiento compila ambas arquitecturas y las incluye en el paquete publicado.

## Detalles de Implementación

### Arquitectura de Aislamiento de Red

El sandbox ejecuta servidores proxy HTTP y SOCKS5 en la máquina anfitriona que filtran todas las solicitudes de red según las reglas de permisos:

1. **Tráfico HTTP/HTTPS**: Un servidor proxy HTTP intercepta las solicitudes y las valida contra los dominios permitidos/denegados
2. **Otro tráfico de red**: Un proxy SOCKS5 maneja todas las demás conexiones TCP (SSH, conexiones de bases de datos, etc.)
3. **Aplicación de permisos**: Los proxies aplican las reglas de `permissions` de tu configuración

**Comunicación con proxy específica de la plataforma:**

- **Linux**: Las solicitudes se enrutan a través del sistema de archivos mediante sockets de dominio Unix (usando `socat` para el puente). El espacio de nombres de red se elimina del contenedor bubblewrap, lo que garantiza que todo el tráfico de red deba pasar por los proxies.

- **macOS**: El perfil Seatbelt permite la comunicación solo con puertos locales específicos donde los proxies escuchan. Todo el resto del acceso a la red está bloqueado.

- **Windows**: Un filtro WFP `ALE_AUTH_CONNECT` bloquea toda conexión saliente de la cuenta `srt-sandbox` excepto el loopback al rango de puertos proxy configurado. Los proxies se enlazan dentro de ese rango. Las variables de entorno (`HTTP_PROXY`, `HTTPS_PROXY`, `ALL_PROXY`, …) apuntan las herramientas a los proxies, pero el filtro WFP es el límite: un proceso que las ignore o las desconfigure sigue encerrado.

### Aislamiento del Sistema de Archivos

Las restricciones del sistema de archivos se aplican a nivel del sistema operativo:

- **macOS**: Utiliza `sandbox-exec` con perfiles Seatbelt generados dinámicamente que especifican las rutas de lectura/escritura permitidas
- **Linux**: Utiliza `bubblewrap` con bind mounts, marcando los directorios como de solo lectura o lectura-escritura según la configuración
- **Windows**: Escribe ACE explícitos aditivos `(OI)(CI)` para el SID `srt-sandbox` en las rutas configuradas (ALLOW en `allowRead`/`allowWrite`, DENY en `denyRead`/`denyWrite`) y los elimina en `reset()`

**Permisos predeterminados del sistema de archivos:**

- **Lectura** (denegar-luego-permitir): Permitida en todas partes por defecto. Puedes denegar regiones amplias y luego volver a permitir rutas específicas dentro de ellas. `allowRead` tiene prioridad sobre `denyRead`.

  - Ejemplo: `denyRead: ["~/.ssh"]` para bloquear el acceso a las claves SSH
  - Ejemplo: `denyRead: ["/Users"], allowRead: ["."]` para bloquear todo `/Users` excepto el espacio de trabajo
  - `denyRead: []` vacío = acceso de lectura completo (nada denegado)

- **Escritura** (solo permitir): Denegada en todas partes por defecto. Debes permitir rutas explícitamente.
  - Ejemplo: `allowWrite: [".", "/tmp"]` para permitir escrituras en el directorio actual y /tmp
  - `allowWrite: []` vacío = sin acceso de escritura (nada permitido)
  - `denyWrite` crea excepciones dentro de rutas permitidas (la denegación tiene prioridad)

**La precedencia es intencionadamente opuesta para lecturas y escrituras:** `allowRead` anula `denyRead`, mientras que `denyWrite` anula `allowWrite`. Esto permite delimitar regiones legibles dentro de áreas denegadas y regiones protegidas dentro de áreas escribibles.

### Rutas de Denegación Obligatoria (Archivos Automáticamente Protegidos)

Ciertos archivos y directorios sensibles están **siempre bloqueados contra escrituras**, incluso si se encuentran dentro de una ruta de escritura permitida. Esto proporciona defensa en profundidad contra fugas del sandbox y manipulación de configuración.

**Archivos siempre bloqueados:**

- Archivos de configuración de shell: `.bashrc`, `.bash_profile`, `.zshrc`, `.zprofile`, `.profile`
- Archivos de configuración de Git: `.gitconfig`, `.gitmodules`
- Otros archivos sensibles: `.ripgreprc`, `.mcp.json`

**Directorios siempre bloqueados:**

- Directorios de IDE: `.vscode/`, `.idea/`
- Directorios de configuración de Claude: `.claude/commands/`, `.claude/agents/`
- Hooks y configuración de Git: `.git/hooks/`, `.git/config`

Estas rutas se bloquean automáticamente: no necesitas añadirlas a `denyWrite`. Por ejemplo, incluso con `allowWrite: ["."]`, escribir en `.bashrc` o `.git/hooks/pre-commit` fallará:```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

Nota (Linux): En Linux, las rutas de denegación obligatoria solo bloquean archivos que ya existen. Los archivos inexistentes en estos patrones no pueden ser bloqueados por el enfoque de bind-mount de bubblewrap. macOS usa patrones glob que bloquean tanto archivos existentes como nuevos.

Profundidad de búsqueda en Linux: En Linux, el sandbox usa ripgrep para escanear archivos peligrosos en subdirectorios dentro de las rutas de escritura permitidas. Por defecto, busca hasta 3 niveles de profundidad por rendimiento. Puedes configurar esto con mandatoryDenySearchDepth:```json { "mandatoryDenySearchDepth": 5, "filesystem": { "allowWrite": ["."] } }

- Predeterminado: `3` (busca hasta 3 niveles de profundidad)
- Rango: `1` a `10`
- Los valores más altos proporcionan más protección pero un rendimiento más lento
- Los archivos en el CWD (profundidad 0) están siempre protegidos independientemente de esta configuración

### Restricciones de Sockets Unix (Linux)

En Linux, el sandbox utiliza **seccomp BPF (Berkeley Packet Filter)** para bloquear la creación de sockets de dominio Unix a nivel de llamada al sistema. Esto proporciona una capa adicional de seguridad para evitar que los procesos creen nuevos sockets de dominio Unix para IPC local (a menos que se permita explícitamente).

**Cómo funciona:**

1. **Filtro BPF integrado**: El paquete incluye un binario estático `apply-seccomp` para x64 y arm64 con el filtro BPF de seccomp compilado. El filtro es específico de la arquitectura pero independiente de libc, por lo que el binario funciona tanto con glibc como con musl.

2. **Detección en tiempo de ejecución**: El sandbox detecta automáticamente la arquitectura de su sistema y utiliza el binario `apply-seccomp` correspondiente.

3. **Filtrado de llamadas al sistema**: El filtro BPF intercepta la llamada al sistema `socket()` y bloquea la creación de sockets `AF_UNIX` devolviendo `EPERM`. Esto evita que el código en el sandbox cree nuevos sockets de dominio Unix.

4. **Aplicación en dos etapas mediante el binario apply-seccomp**:
   - El bwrap externo crea el sandbox con restricciones de sistema de archivos, red y espacio de nombres PID
   - Los procesos de puente de red (socat) se inician dentro del sandbox (necesitan sockets Unix)
   - apply-seccomp crea un espacio de nombres anidado user+PID+mount y vuelve a montar `/proc`
   - Dentro del espacio de nombres anidado, apply-seccomp actúa como PID 1 (init/reaper no volcable)
   - apply-seccomp hace fork, aplica el filtro seccomp mediante `prctl()` y ejecuta el comando del usuario
   - El comando del usuario se ejecuta con todas las restricciones del sandbox más el bloqueo de creación de sockets Unix

**Aislamiento del espacio de nombres PID**: El espacio de nombres PID anidado garantiza que el comando del usuario no pueda ver ni direccionar ningún proceso que se ejecute sin el filtro seccomp (el init de bwrap, el wrapper de shell o los ayudantes socat). Esto mantiene intacto el límite de seccomp independientemente de `kernel.yama.ptrace_scope`, ya que los ayudantes sin filtrar no son alcanzables mediante `ptrace` ni `/proc/N/mem`. El PID 1 interno establece `PR_SET_DUMPABLE=0` para que tampoco sea rastreable mediante ptrace. Si falla la creación del espacio de nombres anidado, apply-seccomp aborta en lugar de ejecutarse sin aislamiento.

**Limitaciones de seguridad**: El filtro bloquea `socket(AF_UNIX, ...)` y las llamadas al sistema `io_uring_setup`/`io_uring_enter`/`io_uring_register` (las tres últimas porque `IORING_OP_SOCKET` en Linux 5.19+ podría eludir la regla de `socket()`). No evita operaciones sobre descriptores de archivo de sockets Unix heredados de procesos padre o transmitidos mediante `SCM_RIGHTS`. Para la mayoría de los escenarios de sandboxing, bloquear la creación de sockets es suficiente para evitar IPC no autorizado.

**Cero dependencias en tiempo de ejecución**: Se incluyen binarios estáticos apply-seccomp precompilados y filtros BPF pregenerados para las arquitecturas x64 y arm64. No se requieren herramientas de compilación ni dependencias externas en tiempo de ejecución.

**Soporte de arquitecturas**: x64 y arm64 son totalmente compatibles con binarios precompilados. Otras arquitecturas no son compatibles actualmente. Para usar el sandbox sin bloqueo de sockets Unix en arquitecturas no compatibles, establezca `allowAllUnixSockets: true` en su configuración.

### Detección y Monitorización de Violaciones

Cuando un proceso en el sandbox intenta acceder a un recurso restringido:

1. **Bloquea la operación** a nivel del sistema operativo (devuelve error `EPERM`)
2. **Registra la violación** (mecanismos específicos de la plataforma)
3. **Notifica al usuario** (en Claude Code, esto activa una solicitud de permiso)

**macOS**: El runtime del sandbox se conecta al almacén de registros de violaciones del sandbox del sistema macOS. Esto proporciona notificaciones en tiempo real con información detallada sobre qué se intentó y por qué se bloqueó. Este es el mismo mecanismo que utiliza Claude Code para la detección de violaciones.```bash
# View sandbox violations in real-time
log stream --predicate 'process == "sandbox-exec"' --style syslog

Linux: Bubblewrap no proporciona informes de violaciones integrados. Use strace para rastrear llamadas al sistema e identificar operaciones bloqueadas:```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

### Avanzado: Trae tu propio proxy

Para un filtrado de red más sofisticado, puedes configurar el sandbox para que use tu propio proxy en lugar de los integrados. Esto permite:

- **Inspección de tráfico**: Usa herramientas como [mitmproxy](https://mitmproxy.org/) para inspeccionar y modificar el tráfico
- **Lógica de filtrado personalizada**: Implementa reglas complejas más allá de las simples listas de dominios permitidos
- **Registro de auditoría**: Registra todas las solicitudes de red para cumplimiento o depuración

**Ejemplo con mitmproxy:**```bash
# Start mitmproxy with custom filtering script
mitmproxy -s custom_filter.py --listen-port 8888

Nota: La configuración de proxy personalizada aún no es compatible con el nuevo formato de configuración. Esta característica se agregará en una versión futura.

Consideración de seguridad importante: Incluso con listas de dominios permitidos, pueden existir vectores de exfiltración. Por ejemplo, si se permite github.com, un proceso puede hacer push a cualquier repositorio. Con un proxy MITM personalizado y una configuración de certificados adecuada, puedes inspeccionar y filtrar llamadas API específicas para evitarlo.

Limitaciones de seguridad

  • Limitaciones del sandbox de red: El sistema de filtrado de red opera restringiendo los dominios a los que los procesos pueden conectarse. Aparte de eso, no inspecciona el tráfico que pasa a través del proxy y los usuarios son responsables de asegurarse de que solo permiten dominios de confianza en su política.
Los usuarios deben ser conscientes de los riesgos potenciales que conlleva permitir dominios amplios como `github.com`, que pueden permitir la exfiltración de datos. Además, en algunos casos puede ser posible eludir el filtrado de red mediante [domain fronting](https://en.wikipedia.org/wiki/Domain_fronting).
  • Escalada de privilegios a través de sockets Unix: La configuración allowUnixSockets puede otorgar inadvertidamente acceso a servicios potentes del sistema que podrían provocar evasiones del sandbox. Por ejemplo, si se utiliza para permitir el acceso a /var/run/docker.sock, esto otorgaría efectivamente acceso al sistema anfitrión mediante la explotación del socket de Docker. Se recomienda a los usuarios que consideren cuidadosamente cualquier socket Unix que permitan a través del sandbox.
  • Escalada de permisos del sistema de archivos: Los permisos de escritura excesivamente amplios en el sistema de archivos pueden habilitar ataques de escalada de privilegios. Permitir escrituras en directorios que contienen ejecutables en $PATH, directorios de configuración del sistema o archivos de configuración del shell del usuario (.bashrc, .zshrc) puede conducir a la ejecución de código en diferentes contextos de seguridad cuando otros usuarios o procesos del sistema acceden a estos archivos.
  • Fortaleza del sandbox en Linux: La implementación para Linux proporciona un fuerte aislamiento del sistema de archivos y de red, pero incluye un modo enableWeakerNestedSandbox que permite que funcione en entornos Docker sin espacios de nombres privilegiados. Esta opción debilita considerablemente la seguridad y solo debe utilizarse en casos en los que se aplique aislamiento adicional de otro modo.
  • Aislamiento de red más débil (macOS): La opción enableWeakerNetworkIsolation vuelve a habilitar el acceso a com.apple.trustd.agent, que es necesario para que los programas Go verifiquen certificados TLS a través del framework de seguridad de macOS. Esto abre un posible vector de exfiltración de datos a través del servicio trustd y solo debe habilitarse cuando se requiera la verificación TLS de Go (por ejemplo, al usar httpProxyPort con un proxy MITM y una CA personalizada).
  • Apple Events (macOS): La opción allowAppleEvents vuelve a habilitar el envío de Apple Events y las solicitudes de apertura de Launch Services ((allow appleevent-send), (allow lsopen), y mach-lookups para com.apple.coreservices.appleevents, com.apple.CoreServices.coreservicesd y com.apple.coreservices.quarantine-resolver), que open, osascript y los ayudantes de apertura de URL requieren. Con esto habilitado, un comando dentro del sandbox puede lanzar aplicaciones arbitrarias sin solicitar confirmación al usuario, y las aplicaciones lanzadas se ejecutan completamente fuera del sandbox; por lo tanto, esta opción elimina el aislamiento de ejecución de código, no solo lo debilita. La automatización de aplicaciones ya en ejecución mediante Apple Events está además restringida por el consentimiento de automatización de TCC de macOS, pero el lanzamiento mediante open no lo está. Solo habilita esta opción cuando los comandos dentro del sandbox realmente necesiten abrir URLs o aplicaciones.

Limitaciones conocidas y trabajo futuro

Bypass de proxy en Linux: Actualmente utiliza variables de entorno (HTTP_PROXY, HTTPS_PROXY, ALL_PROXY) para dirigir el tráfico a través de proxies. Esto funciona para la mayoría de las aplicaciones, pero puede ser ignorado por programas que no respetan estas variables, lo que les impide conectarse a Internet.

Mejoras futuras:

  • Soporte para Proxychains: Agregar soporte para proxychains con LD_PRELOAD en Linux para interceptar llamadas de red a un nivel más bajo, haciendo más difícil el bypass

  • Monitoreo de violaciones en Linux: Implementar la detección automática de violaciones basada en strace para Linux, integrada con el almacén de violaciones. Actualmente, los usuarios de Linux deben ejecutar strace manualmente para ver las violaciones, a diferencia de macOS, que tiene monitoreo automático de violaciones a través del almacén de registros del sistema

Leer más

Categorías

Herramientas DefensivasSeguridad de ContenedoresAnálisis Dinámico (Sandboxing)Auditoría de ConfiguraciónVirtualización de SeguridadSeguridad de RedesRespuesta a Incidentes