gVisor vs seccomp-bpf: Sandboxing para Tools Ofensivos

Dejar que un agente ejecute exploits exige una pregunta incómoda: ¿qué pasa cuando el tool que lanza es malicioso o el propio agente se equivoca? Nuestra primera respuesta fue seccomp-bpf. La segunda, para cargas de mayor riesgo, es gVisor. No compiten: se apilan.

seccomp-bpf: barato y afilado

seccomp-bpf filtra syscalls a nivel de kernel con coste casi nulo. Perfecto para tools conocidos: defines la lista blanca que necesita nmap o ffuf y todo lo demás muere con SIGSYS. El problema: los perfiles son frágiles, y un syscall permitido de más puede ser una vía de escape.

seccomp:
  default_action: SCMP_ACT_ERRNO
  syscalls:
    - names: [read, write, openat, connect, socket]
      action: SCMP_ACT_ALLOW

gVisor: un kernel entre tú y el real

gVisor intercepta las syscalls en un kernel de usuario escrito en Go: el binario cree hablar con Linux, pero habla con Sentry. La superficie del kernel real expuesta se reduce drásticamente. Pagas en rendimiento, pero ganas aislamiento frente a 0-days del kernel.

Cómo elegimos

• Tool de confianza, perfil conocido: seccomp-bpf.
• Binario no confiable, exploit de terceros, malware en análisis: gVisor, y seccomp-bpf dentro.
• Siempre: cgroups para CPU/memoria y network policies por scope.

Lo que enviamos

Gwaihir selecciona el sandbox por nivel de confianza del tool, no por defecto global. El caso común corre con seccomp-bpf por velocidad; lo arriesgado cae en gVisor. Defensa en profundidad, no una sola pared.