Linux : le moteur derrière Landlock
Sous Linux, la cage du moteur est Landlock, un module de sécurité dans le noyau. Ce que le moteur a le droit de faire relève du noyau - le trafic sortant est refusé avant qu'un octet ne quitte la machine.
Landlock : deny-by-default dans le noyau
Sous Linux, la cage est Landlock, un module de sécurité du noyau (LSM), là encore deny-by-default. Ce n'est pas un wrapper dans notre code, mais une règle que le noyau impose. Le moteur peut faire exactement trois choses :
- lire uniquement le fichier du modèle - rien d'autre sur le disque ;
- exécuter uniquement son propre binaire - il ne peut lancer aucun autre programme ;
- se lier à l'unique port local sur lequel il répond - et rien de plus.
Les connexions sortantes sont refusées par le noyau avec 'permission denied' - avant qu'un seul octet ne quitte le système. Ce n'est pas une promesse dans notre code ; la garantie vit dans le noyau, sous tout ce que fait le moteur. Aucune écriture sur disque, aucun lancement de processus étrangers, aucun egress réseau.
Statique contre musl, pour que 'uniquement le modèle' tienne
« Lire uniquement le fichier du modèle » n'est vrai que si le moteur n'a réellement besoin de rien d'autre depuis le disque. C'est pourquoi le moteur Linux est construit entièrement statiquement contre musl, sans loader dynamique ni libc partagée, sur les deux architectures (amd64 et arm64). Un binaire lié normalement devrait lire et exécuter /lib64/ld-linux et la libc système au démarrage, forçant ces chemins dans l'allowlist ; le moteur statique lit exactement un fichier et exécute exactement un binaire, lui-même.
Ce que Landlock exige de votre noyau
Il vous faut un noyau ≥ 5.13 avec Landlock actif. Cela couvre Ubuntu ≥ 22.04, Debian ≥ 12 et RHEL ≥ 9.6 d'origine ; sur d'autres distributions, vous l'activez avec le paramètre de boot lsm=landlock,…. À l'intérieur des conteneurs, le profil seccomp Docker par défaut bloque les appels système Landlock - il vous faut donc un profil ajusté là.
Sans Landlock : pas d'analyse sur l'appareil
Là où Landlock ne peut pas être activé, il n'y a pas d'analyse sur l'appareil sur cet hôte. Le moteur ne démarre tout simplement pas (fail-closed) : un changement suspect est conservé sur place et exposé plutôt que laissé passer hors sandbox.
Comment la même cage se présente sous macOS et Windows se trouve dans l'aperçu du sandbox du moteur.
Une analyse qui ne quitte jamais la machine.
PoisonZero exécute le moteur sur l'appareil sous Linux derrière Landlock - ne lire que le modèle, répondre sur localhost, rien d'autre.
Sign me up