Volver a actualizaciones
Nuevo releaseAug 27, 2026

sandbox-runtime v0.0.74

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 ligera de sandboxing para imponer restricciones de sistema de archivos y red en procesos arbitrarios a nivel del sistema operativo, sin necesidad de un contenedor.

srt utiliza primitivas nativas de sandboxing del SO (sandbox-exec en macOS, bubblewrap en Linux) y filtrado de red basado en proxy. Puede usarse para aislar 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 con el fin de habilitar agentes de IA más seguros. Se pone a disposición como una vista previa temprana de código abierto para ayudar al ecosistema más amplio a construir sistemas agénticos más seguros. Al ser una vista previa de investigación temprana, las APIs 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

Resumen

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 segura 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 agujeros 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 del sandbox del sistema para alertas en tiempo real

Caso de uso de ejemplo: Sandboxing de servidores MCP

Un caso de uso clave es aislar servidores del Protocolo de Contexto de Modelo (MCP) para restringir sus capacidades. Por ejemplo, para aislar el servidor MCP del 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"]
    }
  }
}

Luego configura las restricciones en ~/.srt-settings.json:```json { "filesystem": { "denyRead": [], "allowWrite": ["."], "denyWrite": ["~/sensitive-folder"] }, "network": { "allowedDomains": [], "deniedDomains": [] } }

Ahora el servidor MCP será 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 contenerización con aislamiento del 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 de bloqueo de salida (egress fence) asociada al SID de esa cuenta y ACEs explícitos 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 aislamiento de archivos, un proceso comprometido podría exfiltrar claves SSH u otros archivos sensibles. Sin aislamiento de red, un proceso podría escapar del sandbox y obtener acceso de red sin restricciones.

Aislamiento del Sistema de Archivos impone restricciones de lectura y escritura:

  • Lectura (patrón de denegar-luego-permitir): De forma predeterminada, 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. Una entrada denyRead que sea más específica que la región allowRead en la que se encuentra (p. ej., denyRead: ["**/.env"] o ["./secrets"] con allowRead: ["."]) permanece denegada.
  • Escritura (patrón de solo-permitir): De forma predeterminada, el acceso de escritura está denegado en todas partes. Debes permitir rutas explícitamente (p. ej., ., /tmp). Una lista de permisos vacía significa que no hay acceso de escritura.

Aislamiento de Red (patrón de solo-permitir): De forma predeterminada, todo el acceso de red está denegado. Debes permitir dominios explícitamente. Una lista allowedDomains vacía significa que no hay acceso de 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 por bind dentro del sandbox)

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

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

Tanto el tráfico HTTP/HTTPS (a través del proxy HTTP) como el resto del tráfico TCP (a través del 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

## Uso

### Como herramienta CLI

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 uso de herramienta) 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 reejecució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

De forma predeterminada, el entorno de ejecución de la sandbox busca la configuración en `~/.srt-settings.json`. Puede especificar una ruta personalizada usando la bandera `--settings`:```bash
srt --settings /path/to/srt-settings.json <command>

Ejemplo de Configuración Completo```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 permitir**: 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 ir entre corchetes, estilo RFC 3986: `[::1]`, `[2001:db8::1]:443`. Una entrada con múltiples dos puntos sin corchetes 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 `*` simple (o `*:22`) para denegar todo.
- `network.deniedDomainReasons` - Mapa opcional desde una entrada de `deniedDomains` (coincidida por cadena exacta) hasta 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": "Los envíos SSH a GitHub están bloqueados; usa un remoto https://"}`). Las entradas sin razón informan una genérica. Para destinos SSH (puerto 22), la razón también se entrega en banda: un cliente SSH tunelizado a través de un ProxyCommand SOCKS sin autenticación (p. ej. `nc -X 5` de BSD) 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, en imperativo primero, ya que OpenSSH trunca y escapa los no ASCII.
- `network.allowLocalBinding` - Permitir la vinculación a puertos locales (booleano, por defecto: false)

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

- `network.tlsTerminate.excludeDomains` - Patrones de dominio (misma sintaxis que `allowedDomains`) que **no** se terminan. Los CONNECTs coincidentes se tunelizan de forma opaca en su lugar: siguen sujetos a la lista de permitidos de dominios, pero el cliente dentro del sandbox completa su propio protocolo de enlace TLS con el servidor ascendente 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:
  - **Servidores ascendentes mTLS** - solo el cliente dentro del sandbox posee el certificado de cliente, por lo que el proxy no puede reoriginar la conexión en su nombre.
  - **Clientes con fijación de certificados** - clientes que verifican la identidad del servidor ascendente por sí mismos (CAs personalizadas, fijación de SAN) y rechazan el certificado MITM.
- `network.tlsTerminate.extraCaCertPaths` - Rutas a archivos de certificados CA en PEM añadidos a ese paquete de confianza, después de la CA MITM y las raíces habituales del host. Los hosts excluidos (no terminados) son verificados por el cliente dentro del 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 paquete o esos hosts nunca podrán verificarse. Solo los bloques `CERTIFICATE` de cada archivo se copian en el paquete (cualquier otra cosa, p. ej. una clave privada en un PEM combinado, nunca se expone al sandbox); los archivos que faltan, no se pueden leer o no contienen un 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 Unix Sockets (comportamiento específico de la plataforma):

ConfiguraciónmacOSLinux
allowUnixSockets: string[]Lista de rutas de sockets 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 todos.
  • 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 están permitidas por defecto:

  • filesystem.denyRead - Matriz de rutas para denegar acceso de lectura. Matriz vacía = acceso de lectura completo.
  • filesystem.allowRead - Matriz de rutas para volver a permitir 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 están denegadas por defecto:

  • filesystem.allowWrite - Matriz de rutas para permitir acceso de escritura. Matriz vacía = sin acceso de escritura.
  • filesystem.denyWrite - Matriz de rutas para denegar acceso de escritura dentro de 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 incluyendo / (p. ej., src/**/*.ts coincide con todos los archivos .ts en src/)
  • ? - Coincide con cualquier carácter individual 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 al directorio SSH
  • "denyRead": ["/Users"], "allowRead": ["."] - Denegar lectura a todo /Users, pero volver a permitir el directorio actual
  • "denyWrite": [".env"] - Denegar escritura al archivo .env (incluso si el directorio actual está permitido)

Sintaxis de Rutas (Linux):

Linux actualmente no admite coincidencia glob. Usa solo rutas literales:

  • "allowWrite": ["src/"] - Permitir escritura al directorio src/
  • "denyRead": ["/home/user/.ssh"] - Denegar lectura al directorio SSH
  • "denyRead": ["/home"], "allowRead": ["."] - Denegar lectura a 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 de inicio del usuario

Otra Configuración

  • ignoreViolations - Objeto que mapea patrones de comandos a matrices de rutas donde las violaciones deben ignorarse
  • enableWeakerNestedSandbox - Habilitar modo de sandbox más débil para entornos Docker (booleano, predeterminado: false)
  • enableWeakerNetworkIsolation - Permitir acceso a com.apple.trustd.agent en el sandbox de macOS (booleano, predeterminado: false). Esto es necesario para que los programas Go (gh, gcloud, terraform, kubectl, etc.) verifiquen certificados TLS al usar httpProxyPort con un proxy MITM y CA personalizado. Advertencia de seguridad: habilitar esto abre un posible vector de exfiltración de datos a través del servicio trustd.
  • allowAppleEvents - Permitir enviar Apple Events y solicitudes de apertura de Launch Services desde el sandbox de macOS (booleano, predeterminado: false). Sin esto, comandos como open, osascript y cualquier cosa que abra URLs o ejecute scripts de otras aplicaciones mediante AppleScript fallan con el error de AppleScript -600 ("La aplicación no se está ejecutando") o errores de LaunchServices (-10822, -54). Advertencia de seguridad: habilitar esto significa que el sandbox ya no proporciona aislamiento de ejecución de código. Un comando en 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 del sandbox; ejecutar scripts de aplicaciones ya en ejecución mediante Apple Events está además controlado por el consentimiento de automatización TCC por aplicación del usuario. Los integradores solo deben obtener esta opción de configuración confiable a nivel de usuario, nunca de archivos locales del proyecto en un repositorio verificado, 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 dentro 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 bandera `--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: Alfa — utiliza un helper empaquetado srt-win.exe (sin dependencias adicionales). Consulta Windows (alfa) a continuación para la configuración, el modelo de seguridad y las limitaciones conocidas

Dependencias específicas de la 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 - Retransmisor 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. Deshabilita 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 las arquitecturas x86-64 y arm. Estas dependencias solo son necesarias si estás en una arquitectura diferente donde los filtros pregenerados no están disponibles:

- `gcc` o `clang` - Compilador de C
- `libseccomp-dev` - Archivos de desarrollo de la librería 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
  - Instálalo vía Homebrew: `brew install ripgrep`
  - O descárgalo desde: https://github.com/BurntSushi/ripgrep/releases

**Windows requiere:**

- Sin dependencias adicionales. El helper `srt-win.exe` (x64 y arm64) viene 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`, aislada del usuario que la invoca mediante primitivas de seguridad nativas de Windows — una valla de salida de Windows Filtering Platform (WFP) basada en el SID de la cuenta de sandbox, y ACEs explícitas por sesión que conceden o deniegan a ese SID el acceso a las rutas de sistema de archivos configuradas.

### Configuración

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

Esta aprovisiona la cuenta de usuario local srt-sandbox (con una contraseña aleatoria almacenada cifrada con DPAPI en HKLM\SOFTWARE\sandbox-runtime — a nivel de máquina, de modo que las instalaciones en flotas que se ejecutan como SYSTEM funcionan y la rotación de un usuario actualiza la copia que leen los demás), el grupo local sandbox-runtime-users, e instala un conjunto de filtros WFP a nivel de máquina basado en el SID de srt-sandbox. Es idempotente — volver a ejecutarlo rota la contraseña de la cuenta sandbox y reconcilia el conjunto de filtros.

No se requiere cerrar sesión. Los filtros WFP se basan en el SID de la cuenta sandbox dedicada, por lo que tu propia red, servicios y cualquier otro principal en la máquina no se ven afectados.

Después de la instalación, SandboxManager.initialize() y la CLI srt funcionan como en otras plataformas. initialize() verifica que la cuenta sandbox y la valla WFP estén activas, y falla con un error accionable si no es así.

La instalación/desinstalación programática se exporta como installWindowsSandbox() / uninstallWindowsSandbox().

Modelo de seguridad

El comando en sandbox se ejecuta como la cuenta srt-sandbox, no como el usuario que lo invoca. El helper incluido srt-win.exe realiza un lanzamiento de dos saltos: el broker llama a CreateProcessWithLogonW para iniciar un runner como srt-sandbox, y el runner genera el objetivo bajo un token restringido dentro de un objeto job. El proceso hijo hereda el perfil aislado de la cuenta sandbox (%USERPROFILE%, %TEMP%, HKCU) y un entorno nuevo superpuesto solo con el PATH del broker y las variables de proxy generadas.

Ejecutarse bajo un SID de usuario distinto cierra estructuralmente la clase de escape de generación de procesos sustitutos (Task Scheduler, PROC_THREAD_ATTRIBUTE_PARENT_PROCESS hacia un proceso propiedad del broker, BITS, COM fuera de proceso con RunAs="Interactive User"): cualquier proceso que el hijo logre generar fuera de banda sigue llevando el SID de srt-sandbox, por lo que permanece sujeto a la valla de salida WFP y no tiene derechos sobre los archivos del usuario que lo invoca.

El aislamiento de red es un conjunto WFP de dos filtros en FWPM_LAYER_ALE_AUTH_CONNECT_V4/V6: un PERMIT para destinos de loopback dentro del rango de puertos de proxy configurado (por defecto 60080–60089), y un BLOCK para cualquier conexión cuyo token lleve el SID de srt-sandbox. El proceso en sandbox llega a internet solo a través de los proxies JS HTTP/SOCKS5 que escuchan en ese rango; un proceso que elimine su entorno de proxy y se conecte directamente es bloqueado en el kernel.

El aislamiento del sistema de archivos se aplica mediante ACL discrecionales de NTFS. La cuenta srt-sandbox no tiene derechos inherentes sobre los archivos del usuario que lo invoca, por lo que en initialize() la sandbox escribe ACE explícitas aditivas e heredables solo para el SID de srt-sandbox — nunca reescribe ni reemplaza el descriptor de seguridad existente de una ruta:

  • filesystem.allowWrite → una ACE ALLOW MODIFY heredable (READ|WRITE|EXECUTE|DELETE, con FILE_DELETE_CHILD retenido). El proceso en sandbox puede crear, modificar y eliminar archivos dentro del árbol de trabajo; retener FILE_DELETE_CHILD de la concesión es defensa en profundidad para las marcas de denegación siguientes, no una protección sobre la raíz del árbol.
  • filesystem.allowRead → una ACE ALLOW READ|EXECUTE heredable
  • filesystem.denyRead / filesystem.denyWrite → una ACE DENY heredable sobre el objetivo, más una DENY FILE_DELETE_CHILD heredable sobre su padre — junto con el FILE_DELETE_CHILD retenido en la concesión del árbol de trabajo, esto impide que el proceso en sandbox renombre o elimine una ruta denegada a través de su directorio padre

reset() elimina cada ACE que esta sesión añadió (con recuento de referencias entre los hosts concurrentes de este usuario mediante la base de datos de sesión por usuario; un pase de recuperación tras un fallo en el siguiente initialize() limpia después de una salida no limpia). Se admiten objetivos de directorio (las ACE heredan a todo el subárbol). Los patrones glob se expanden a rutas concretas en el momento de initialize() — una ruta coincidente que aparezca más tarde no queda cubierta.

Terminación TLS en Windows

network.tlsTerminate requiere que la CA de MITM esté presente en el almacén de certificados CurrentUser\Root del usuario sandbox (schannel — el backend TLS utilizado por System32\curl.exe, PowerShell Invoke-WebRequest, .NET y git con backend predeterminado — confía solo en el almacén del sistema operativo, no en variables de entorno). Este es un paso en el momento de la instalación, separado de windows-install:```typescript import { windowsTrustCa } from '@anthropic-ai/sandbox-runtime' windowsTrustCa('/path/to/mitm-ca.crt') // or: srt-win user trust-ca 

`initialize()` compara la huella digital de la CA de la sesión con la instalada y falla con un mensaje accionable 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 de 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 bucle local de WFP solo cubre ese rango.
- `windows.sublayerGuid` — GUID de la subcapa de WFP bajo la cual se instalaron los filtros. Omítelo para usar el valor predeterminado de compilación; establécelo solo cuando las herramientas empresariales hayan instalado los filtros bajo una subcapa personalizada.
- `windows.srtWin.path` — ruta al binario `srt-win`. Omítela para resolver el `vendor/srt-win/<arch>/srt-win.exe` empaquetado. Establécelo al incrustar la CLI de `srt-win` en un binario multicall; los procesos derivados pasan entonces `--srt-win` como `argv[1]` para que el despachador del incrustador pueda enrutar a `srt_win::run_from_args`.

### Limitaciones conocidas

- **Revocación de certificados bajo schannel.** La obtención de CRL/OCSP de CryptoAPI sale a través de WinHTTP bajo el token del llamador, ignorando el entorno de proxy, por lo que queda 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 se desactive por herramienta: `curl --ssl-no-revoke`, `git -c http.schannelCheckRevoke=false`, `CARGO_HTTP_CHECK_REVOKE=false`. `Invoke-WebRequest`, `HttpClient` de .NET y `gh` no verifican la revocación por defecto y no se ven afectados. Está previsto un punto de distribución de CRL servido desde el proxy de bucle local para eliminar esta solución alternativa.
- **Las instalaciones de herramientas por usuario no son accesibles.** El proceso en sandbox se ejecuta como `srt-sandbox`, no como tú, por lo que las herramientas instaladas bajo 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 abrirse desde la cuenta del sandbox. Prefiere instalaciones a nivel de máquina (`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 de 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 en sandbox pueda autenticarse ante el proxy de bucle local, por lo que no es un secreto frente al 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 mediante el resolver del sistema no está vallada.** `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()` desde el proceso en sandbox esté bloqueado. Las herramientas que hacen su propio UDP/53 (`nslookup`, `dig`) sí están valladas. 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 elimina la clave HKLM\SOFTWARE\sandbox-runtime (credencial, marcador, registro de CA) — un aviso de UAC. %ProgramData%\sandbox-runtime (el material de clave de CA) se deja en su lugar; elimínelo (y %LOCALAPPDATA%\sandbox-runtime por usuario) 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

### Compilación de Binarios Seccomp

El filtro BPF y el cargador `apply-seccomp` se compilan desde el código fuente en C en `vendor/seccomp-src/` mediante `npm run build:seccomp` (solo Linux; requiere `gcc` y `libseccomp-dev`). 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 host 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 de proxy específica por 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, garantizando que todo el tráfico de red deba pasar por los proxies.

- **macOS**: El perfil Seatbelt permite la comunicación solo a puertos específicos de localhost donde escuchan los proxies. Todo el demás acceso a la red está bloqueado.

- **Windows**: Un filtro WFP `ALE_AUTH_CONNECT` bloquea cada conexión saliente desde la cuenta `srt-sandbox` excepto el loopback al rango de puertos de proxy configurado. Los proxies se vinculan 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 estando cercado.

### Aislamiento del Sistema de Archivos

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

- **macOS**: Usa `sandbox-exec` con perfiles Seatbelt generados dinámicamente que especifican rutas de lectura/escritura permitidas
- **Linux**: Usa `bubblewrap` con montajes bind, marcando directorios como de solo lectura o lectura/escritura según la configuración
- **Windows**: Escribe ACEs explícitas aditivas `(OI)(CI)` para el SID `srt-sandbox` en las rutas configuradas (ALLOW en `allowRead`/`allowWrite`, DENY en `denyRead`/`denyWrite`), y luego las 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 las rutas permitidas (la denegación tiene prioridad)

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

### Rutas de Denegación Obligatoria (Archivos Auto-Protegidos)

Ciertos archivos y directorios sensibles están **siempre bloqueados contra escrituras**, incluso si caen dentro de una ruta de escritura permitida. Esto proporciona defensa en profundidad contra escapes del sandbox y manipulación de la 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 agregarlas 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 que coinciden con estos patrones no pueden bloquearse mediante el enfoque de montaje bind de bubblewrap. macOS utiliza patrones glob que bloquean tanto archivos existentes como nuevos.

Profundidad de búsqueda en Linux: En Linux, el sandbox utiliza ripgrep para escanear archivos peligrosos en subdirectorios dentro de las rutas de escritura permitidas. De forma predeterminada, busca hasta 3 niveles de profundidad por motivos de 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 brindan más protección pero un rendimiento más lento
- Los archivos en el directorio de trabajo actual (profundidad 0) siempre están 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 seccomp BPF 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 tu 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 de usuario+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 bifurca, 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 envoltorio 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 accesibles mediante `ptrace` o `/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+ de otro modo eludiría la regla de `socket()`). No evita operaciones en descriptores de archivo de sockets Unix heredados de procesos padre o pasados 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 precompilados de apply-seccomp 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 sandboxing sin bloqueo de sockets Unix en arquitecturas no compatibles, establece `allowAllUnixSockets: true` en tu configuración.

### Detección y monitoreo 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 un aviso de permiso)

**macOS**: El runtime del sandbox se conecta al almacén de registros de violaciones del sandbox del sistema de 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 Claude Code utiliza 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. Usa strace para rastrear las 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 usar 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 listas de permitidos de dominios simples
- **Registro de auditoría**: Registra todas las solicitudes de red para cumplimiento normativo 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 personalizado aún no es compatible con el nuevo formato de configuración. Esta funcionalidad se añadirá en una versión futura.

Consideración de seguridad importante: Incluso con listas de dominios permitidos, pueden existir vectores de exfiltración. Por ejemplo, permitir github.com permite que un proceso haga 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 evitar esto.

Limitaciones de Seguridad

  • Limitaciones del Sandbox de Red: El sistema de filtrado de red funciona restringiendo los dominios a los que los procesos pueden conectarse. 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 evadir el filtrado de red mediante [domain fronting](https://en.wikipedia.org/wiki/Domain_fronting).
  • Escalada de Privilegios mediante 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 host explotando el 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: Permisos de escritura demasiado 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 de shell del usuario (.bashrc, .zshrc) puede provocar la ejecución de código en diferentes contextos de seguridad cuando otros usuarios o procesos del sistema acceden a estos archivos.
  • Robustez del Sandbox en Linux: La implementación en Linux proporciona un fuerte aislamiento del sistema de archivos y de red, pero incluye un modo enableWeakerNestedSandbox que permite que funcione dentro de entornos Docker sin namespaces privilegiados. Esta opción debilita considerablemente la seguridad y solo debe utilizarse en casos donde se aplique aislamiento adicional por otros medios.
  • 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 mediante el 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 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 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 requieren open, osascript y los asistentes de apertura de URL. Con esto permitido, un comando en el sandbox puede lanzar aplicaciones arbitrarias sin aviso al usuario, y las aplicaciones lanzadas se ejecutan completamente fuera del sandbox, por lo que esta opción elimina el aislamiento de ejecución de código, no solo lo debilita. El scripting de aplicaciones ya en ejecución mediante Apple Events está además controlado por el consentimiento de automatización TCC de macOS, pero el lanzamiento mediante open no lo está. Solo habilita esto cuando los comandos dentro del sandbox necesiten genuinamente abrir URLs o aplicaciones.

Limitaciones Conocidas y Trabajo Futuro

Evitación 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 provoca que no puedan conectarse a internet.

Mejoras futuras:

  • Soporte de Proxychains: Añadir soporte para proxychains con LD_PRELOAD en Linux para interceptar llamadas de red a un nivel más bajo, haciendo la evasión más difícil

  • Monitoreo de violaciones en Linux: Implementar 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 mediante el 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