Windows: el motor dentro de un AppContainer aislado de red
En Windows PoisonZero ejecuta el motor de análisis dentro de un AppContainer aislado de red - el sistema operativo le niega la red por completo - superpuesto a un token restringido, integridad baja y un Job Object.
AppContainer: sin red, impuesto por el SO
En Windows el motor corre dentro de un AppContainer aislado de red - una celda del sistema operativo creada sin ninguna capacidad de red. El motor no puede abrir una conexión de red, y nada puede alcanzarlo por la red - ni siquiera localhost. Esto no es una comprobación en nuestro código; es un límite que traza el núcleo de Windows, la misma idea que Seatbelt en macOS y Landlock en Linux: el análisis on-device no tiene salida hacia la red.
Una excepción: la aceleración por GPU
Melira Enterprise Ultra calcula en la tarjeta gráfica, y dentro de un AppContainer de Windows eso no es posible: Windows concede el acceso al controlador gráfico solo a programas con identidad de aplicación, que un contenedor creado por nosotros no tiene. El controlador no se inicializa dentro de él, sin importar qué permisos reciba el contenedor. Chromium lo resuelve igual: su proceso de GPU tampoco corre en un AppContainer.
Por eso, en Windows el motor corre sin AppContainer solo con aceleración por GPU - y además sin rebajar el nivel de integridad. El motivo está medido: con integridad baja Windows le niega al motor la lectura de su propio archivo de modelo y de clave en el directorio de datos; ni una etiqueta de integridad en el archivo ni una entrada de permisos adicional lo cambia.
| Capa | Arranque en CPU | Arranque en GPU |
|---|---|---|
| AppContainer aislado de red | sí | no |
| Token restringido, privilegios retirados | sí | sí |
| Integridad baja | sí | no |
| Job Object: un proceso, sin hijo, memoria limitada | sí | sí |
| Bloqueo de red ligado al programa, fail-closed antes del arranque | sí | sí |
Un arranque en GPU conserva por tanto los privilegios retirados, el Job Object y el bloqueo de red. Ese bloqueo no depende ni del contenedor ni del token: es un filtro del sistema operativo ligado al propio programa, armado antes del arranque; si no puede armarse, el motor no arranca. Lo único que desaparece es el nivel de integridad, que limita qué objetos podría escribir el proceso: en esa medida el proceso de GPU corre al mismo nivel que el servicio que lo inicia.
Superpuesto con token restringido, integridad baja y un Job Object
Dentro de ese contenedor el motor también corre bajo un token restringido al que prácticamente se le quitan todos los privilegios (solo queda el inocuo privilegio de 'notificar al cambiar') y con integridad baja, de modo que no puede escribir objetos de integridad normal. Estas capas cierran de antemano las vías por las que un proceso roto se propagaría.
La jaula se apoya en cuatro pilares:
- AppContainer aislado de red - sin capacidad de red, sin salida, ni siquiera localhost;
- token restringido - se retiran los privilegios del proceso;
- integridad baja - sin escrituras en objetos de integridad normal;
- Job Object - exactamente un proceso, sin proceso hijo, memoria limitada.
Job Object: exactamente un proceso, sin hijo
El Job Object deja al motor ejecutar exactamente un proceso: no puede lanzar un hijo, el núcleo lo bloquea, y su memoria está limitada. Un exploit que de otro modo descargaría o lanzaría un programa auxiliar choca aquí contra un muro: no hay red que alcanzar ni un segundo proceso al que escapar.
Estrictamente fail-closed
Como en todas partes, la regla se mantiene: si la jaula no está en su sitio, el motor no arranca. Si el AppContainer no se puede construir no hay degradación a una ejecución menos aislada; el cambio sospechoso se conserva en su sitio y se expone en vez de pasar sin evaluar (fail-closed).
Cómo se ve la misma jaula en macOS y Linux está en el resumen de la sandbox del motor.
Un análisis que no pueden volver contra ti.
PoisonZero ejecuta el motor on-device en Windows dentro de un AppContainer aislado de red - sin red, un proceso, nada más.
Sign me up