El diseño de Sandbox2 se basa en tecnologías conocidas y establecidas, un marco de políticas y dos procesos: el ejecutor de la zona de pruebas y el Sandboxee.
Tecnologías involucradas
En las siguientes secciones, se abarcan las tecnologías que forman la capa base de Sandbox2.
Espacios de nombres de Linux
Los espacios de nombres de Linux son un intento de proporcionar virtualización a nivel del sistema operativo. Si bien varios espacios de usuario se ejecutan de forma aparentemente independiente entre sí, comparten una sola instancia del kernel. Sandbox2 usa los siguientes tipos de espacios de nombres:
- IPC
- Red (a menos que se inhabilite de forma explícita llamando a
PolicyBuilder::AllowUnrestrictedNetworking()) - Montaje (con una vista personalizada del árbol del sistema de archivos)
- PID
- Usuario
- UTS
Obtén más información sobre los espacios de nombres de Linux en Wikipedia o en la página de manual relacionada.
IPC
Sandbox2 permite intercambiar datos arbitrarios entre el ejecutor de la zona de pruebas y el Sandboxee no confiable. Admite mensajes de tipo-longitud-valor (TLV), el paso de descriptores de archivos y el intercambio de credenciales a través de tokens y controladores.
Seccomp-BPF
Sandbox2 se basa en seccomp-bpf, que es una extensión del modo de computación segura (seccomp) que permite usar reglas de Berkeley Packet Filter (BPF) para filtrar llamadas al sistema.
seccomp es una función del kernel de Linux que restringe las llamadas al sistema de un proceso para permitir solo exit, sigreturn, read y write. Si un proceso intenta ejecutar otra llamada al sistema, se finalizará. La extensión seccomp-bpf permite más flexibilidad que seccomp. En lugar de permitir un conjunto fijo de llamadas al sistema, seccomp-bpf ejecuta un programa BPF en los datos de la llamada al sistema y, según el valor que devuelve el programa, puede ejecutar la llamada al sistema, omitirla y devolver un valor ficticio, finalizar el proceso, generar una señal o notificar al rastreador.
Ptrace
La llamada al sistema ptrace (seguimiento de procesos) proporciona una funcionalidad que permite que el proceso de rastreo observe y controle la ejecución del proceso de seguimiento. El proceso de rastreo tiene control total sobre el proceso de seguimiento una vez que se adjunta. Obtén más información sobre ptrace en Wikipedia o en la página de manual relacionada.
Política de la zona de pruebas
La política de la zona de pruebas es la parte más importante de una zona de pruebas, ya que especifica las acciones que el Sandboxee puede y no puede ejecutar. Una política de la zona de pruebas tiene 2 partes:
- Política de llamadas al sistema
- Configuración del espacio de nombres
Política de llamadas al sistema predeterminada
La política predeterminada bloquea las llamadas al sistema que siempre son peligrosas y tiene prioridad sobre la política extendida proporcionada por el usuario.
Política de llamadas al sistema extendida
La política de llamadas al sistema extendida se puede crear con nuestra
PolicyBuilder. Esta clase define una serie de reglas de conveniencia (p.ej., AllowStaticStartup, AllowDynamicStartup, AllowOpen) que se pueden usar para mejorar la legibilidad de tu política.
En la mayoría de los casos, debes comenzar con
DefaultPolicyBuilder
(sapi::Sandbox2Config::DefaultPolicyBuilder()), que devuelve un
PolicyBuilder preconfigurado con una política de referencia para las bibliotecas típicas de un solo subproceso y se puede personalizar aún más con reglas adicionales
(como .AllowDynamicStartup() y .AddLibrariesForBinary() cuando se coloca en la zona de pruebas
un objeto binario). En la API de Sandboxed (SAPI), DefaultPolicyBuilder() se usa con sapi::SandboxConfig::DefaultConfig(), sapi::SandboxConfig::DefaultFlags(), sapi::SandboxConfig::DefaultEnvironmentVariables() y sapi::Sandbox2Config::DefaultLimits(). La construcción de un PolicyBuilder directamente
solo se debe usar cuando no se puede usar DefaultPolicyBuilder() o cuando se requiere una
configuración precisa.
Si quieres restringir aún más las llamadas al sistema o necesitas reglas más complejas, puedes
especificar macros BPF sin procesar con AddPolicyOnSyscall y AddPolicyOnSyscalls. En el ejemplo de
crc4, se usa este
mecanismo para restringir los argumentos de las llamadas al sistema read, write y close.
En general, cuanto más estricta sea la política de la zona de pruebas, mejor, ya que la política confinará la explotación de cualquier vulnerabilidad presente en el código. Si puedes especificar exactamente qué llamadas al sistema y argumentos se requieren para el funcionamiento normal del programa, cualquier atacante que explote una vulnerabilidad de ejecución de código también estará restringido a los mismos límites.
Una política de la zona de pruebas muy estricta podría rechazar todas las llamadas al sistema, excepto las lecturas y escrituras en los descriptores de archivos de entrada estándar y salida estándar. Dentro de esta zona de pruebas, un programa podría tomar la entrada, procesarla y devolver el resultado. Sin embargo, si el proceso intentara realizar cualquier otra llamada al sistema, se finalizaría debido a un incumplimiento de la política. Por lo tanto, si el proceso se ve comprometido (ejecución de código por un usuario malicioso), no puede hacer nada más nefasto que producir un resultado incorrecto (que el ejecutor y otros aún deben controlar correctamente).
Configuración del espacio de nombres
El objeto PolicyBuilder también se usa para configurar la vista individual del sistema de archivos de un Sandboxee. Se pueden asignar archivos individuales (AddFile / AddFileAt), directorios completos
(AddDirectory / AddDirectoryAt), así como almacenamiento temporal (AddTmpfs)
al entorno de Sandboxee. Además, se puede usar AddLibrariesForBinary para asignar automáticamente todas las bibliotecas que necesita el ejecutable vinculado de forma dinámica especificado.
Marcas de línea de comandos
Cualquier política de Sandbox2 se puede inhabilitar si se especifica una de las siguientes marcas de línea de comandos. Estas marcas están destinadas a fines de prueba (p.ej., mientras se refina la política de llamadas al sistema extendida).
--sandbox2_danger_danger_permit_all--sandbox2_danger_danger_permit_all_and_log
Ejecutor de la zona de pruebas
El ejecutor de la zona de pruebas es un proceso que no está en la zona de pruebas. Es el proceso de rastreo de ptrace que se adjunta al Sandboxee (proceso de seguimiento de ptrace). El ejecutor de la zona de pruebas también configura y ejecuta una instancia de Monitor que realiza un seguimiento del Sandboxee y proporciona información de estado.
Sandbox2 permite tres modos de ejecución: independiente, Sandbox2 Forkserver y Custom Forkserver. Si usas un forkserver, el Sandboxee se crea como un proceso secundario del ejecutor de la zona de pruebas. Estos modos se explican en detalle aquí.
Sandboxee
El Sandboxee es el proceso que se ejecuta en el entorno restringido de la zona de pruebas que se definió en la política de la zona de pruebas. El ejecutor de la zona de pruebas envía la política al Sandboxee a través de IPC. Luego, el Sandboxee aplica la política. Cualquier incumplimiento de la política provocará la finalización del proceso, a menos que se configure de otra manera (consulta Política de la zona de pruebas).