Architecture

Windows : le moteur dans un AppContainer isolé du réseau

Sous Windows, PoisonZero exécute le moteur d'analyse à l'intérieur d'un AppContainer isolé du réseau - le système d'exploitation lui refuse purement et simplement le réseau - avec en complément un token restreint, une intégrité basse et un Job Object.

~4 min de lecture · Architecture

AppContainer : aucun réseau, imposé par l'OS

Sous Windows, le moteur tourne à l'intérieur d'un AppContainer isolé du réseau - une cellule du système d'exploitation créée sans aucune capacité réseau. Le moteur ne peut pas ouvrir de connexion réseau, et rien ne peut l'atteindre par le réseau - pas même localhost. Ce n'est pas une vérification dans notre code ; c'est une frontière tracée par le noyau Windows, sur le même principe que Seatbelt sous macOS et Landlock sous Linux : l'analyse sur l'appareil n'a aucune voie vers le réseau.

Comme le conteneur n'a aucune capacité réseau, même les voies indirectes qu'une simple liaison à localhost laisserait ouvertes sont fermées. Le moteur parle au service privilégié via un socket local que le système d'exploitation garde sur la machine, jamais un port réseau.

Une exception : l'accélération GPU

Melira Enterprise Ultra calcule sur la carte graphique, ce qui est impossible dans un AppContainer Windows : Windows n'accorde l'accès au pilote graphique qu'aux programmes dotés d'une identité d'application, qu'un conteneur créé par nos soins n'a pas. Le pilote n'y démarre pas - quels que soient les droits accordés au conteneur. Chromium procède de même : son processus GPU ne tourne pas non plus dans un AppContainer.

Sur Windows, le moteur tourne donc sans AppContainer uniquement avec l'accélération GPU - et en plus sans abaissement du niveau d'intégrité. La raison est mesurée : en intégrité basse, Windows refuse au moteur la lecture de son propre fichier de modèle et de clé dans le répertoire de données ; ni une étiquette d'intégrité sur le fichier ni une entrée de droits supplémentaire n'y change quoi que ce soit.

CoucheDémarrage CPUDémarrage GPU
AppContainer isolé du réseauouinon
Token restreint, privilèges retirésouioui
Intégrité basseouinon
Job Object : un processus, pas d'enfant, mémoire plafonnéeouioui
Blocage réseau lié au programme, fail-closed avant le démarrageouioui

Un démarrage GPU conserve donc les privilèges retirés, le Job Object et le blocage réseau. Ce blocage ne dépend ni du conteneur ni du token : c'est un filtre du système d'exploitation lié au programme lui-même, armé avant le démarrage ; s'il échoue, le moteur ne démarre pas. Seul disparaît le niveau d'intégrité, qui limite les objets que le processus pourrait écrire : dans cette mesure, le processus GPU tourne au même niveau que le service qui le lance.

En exploitation : Windows sans accélération GPU est la variante la plus cloisonnée - l'AppContainer isolé du réseau s'y ajoute comme couche supplémentaire. Si l'isolation maximale prime sur la vitesse, faites tourner Melira Enterprise sur le CPU.

En complément : token restreint, intégrité basse et Job Object

À l'intérieur de ce conteneur, le moteur tourne aussi sous un token restreint dont pratiquement chaque privilège est retiré (seul le privilège inoffensif « notifier au changement » demeure) et en intégrité basse, il ne peut donc pas écrire d'objets en intégrité normale. Ces couches ferment d'emblée les voies par lesquelles un processus cassé se propagerait autrement.

La cage repose sur quatre piliers :

  • AppContainer isolé du réseau - aucune capacité réseau, aucun egress, pas même localhost ;
  • token restreint - les privilèges du processus sont retirés ;
  • intégrité basse - aucune écriture sur des objets en intégrité normale ;
  • Job Object - exactement un processus, pas de processus enfant, mémoire plafonnée.
La cage Windows est bâtie sur des fonctions standard du système d'exploitation : AppContainer, token, niveau d'intégrité et Job Object. Rien de tout cela n'a à être installé à part - c'est simplement actif.

Job Object : exactement un processus, pas d'enfant

Le Job Object permet au moteur d'exécuter exactement un processus : il ne peut pas créer d'enfant, le noyau le bloque, et sa mémoire est plafonnée. Un exploit qui téléchargerait ou lancerait autrement un programme auxiliaire se heurte ici à un mur : il n'y a pas de réseau à atteindre ni de second processus où s'échapper.

Strictement fail-closed

Comme partout, la règle tient : si la cage n'est pas en place, le moteur ne démarre pas. Si l'AppContainer ne peut pas être construit, il n'y a pas de dégradation vers un run moins isolé ; le changement suspect est alors conservé sur place et exposé plutôt que laissé passer sans évaluation (fail-closed).

Comment la même cage se présente sous macOS et Linux se trouve dans l'aperçu du sandbox du moteur.

Est-ce utile ?

Une analyse qui ne peut pas être retournée contre vous.

PoisonZero exécute le moteur sur l'appareil sous Windows à l'intérieur d'un AppContainer isolé du réseau - aucun réseau, un seul processus, rien d'autre.

Sign me up