Conteneurs rootless de Podman et l’exploit Copy Fail

 (garrido.io)
1 points par GN⁺ 2 시간 전 | 1 commentaires | Partager sur WhatsApp
  • CVE-2026-31431 Copy Fail permet à un utilisateur local non privilégié d’obtenir un shell root, et peut aussi permettre une élévation vers root à l’intérieur d’un conteneur rootless Podman
  • Les conteneurs rootless de Podman combinent les espaces de noms utilisateur, la séparation des UID et les Linux capabilities pour mapper le root du conteneur vers un utilisateur non privilégié sur l’hôte et limiter les privilèges sur l’hôte
  • Lors des tests, l’utilisateur foo d’un conteneur rootless non-root a pu devenir root à l’intérieur du conteneur après l’exécution de Copy Fail, mais ses privilèges restaient limités à ce que l’utilisateur non privilégié bar pouvait faire sur l’hôte, sans pouvoir lire les fichiers appartenant à root sur l’hôte
  • L’application de --security-opt=no-new-privileges ou --cap-drop=all fait qu’après l’exécution de Copy Fail, le shell reste en tant que foo avec des capabilities à none, ce qui empêche l’obtention immédiate d’un shell root et l’élévation des capabilities
  • Les effets de Copy Fail peuvent persister au-delà du cycle de vie du conteneur, ce qui impose un correctif noyau et un redémarrage ; il faut aussi appliquer une défense en profondeur avec un système de fichiers racine en lecture seule, des limites de ressources via cgroups, des images de runtime minimales et un pare-feu

Portée de l’exposition de Copy Fail et des conteneurs rootless Podman

  • CVE-2026-31431 a été rendu public le 29 avril sur copy.fail et l’exécution du script Python publié permet à un utilisateur local non privilégié d’obtenir un shell root
  • Copy Fail peut aussi être exploité dans des conteneurs Linux, et permet également d’obtenir un shell root à l’intérieur des conteneurs rootless Podman
  • Lors des tests, le root du conteneur restait limité, au niveau de l’hôte, au périmètre de privilèges de l’utilisateur non privilégié bar qui avait lancé le conteneur
  • L’implémentation rootless de Podman combine les espaces de noms utilisateur, la séparation des UID et les Linux capabilities pour limiter les privilèges des processus du conteneur sur l’hôte
  • Copy Fail montre que les conteneurs rootless ne sont pas immunisés contre la vulnérabilité, mais que la configuration de Podman peut réduire la portée d’une attaque après compromission

Fonctionnement des conteneurs rootless

  • Exemple de base : l’utilisateur non privilégié bar exécute un serveur HTTP

    • Dans l’exemple, l’utilisateur non privilégié bar, avec l’UID 1001, construit avec Podman une image basée sur ubuntu:latest et exécute python3 -m http.server
    • Vu depuis l’hôte avec ps, le processus python3 s’exécute sous l’utilisateur bar
    • Podman utilise un modèle fork/exec, de sorte que les processus du conteneur deviennent des descendants du processus podman run, et une séparation classique des UID permet d’isoler les processus du conteneur du root de l’hôte et des autres utilisateurs
    • Dans une configuration Docker classique, même si un utilisateur non privilégié exécute docker run, le client Docker communique avec un démon disposant des privilèges root, et c’est ce démon qui crée finalement les processus du conteneur ; sur l’hôte, ceux-ci peuvent donc apparaître comme appartenant à root

  • Rootless rootful

    • Une image de conteneur exécute généralement sa commande en tant que root interne si aucune directive USER explicite ni aucun flag --user n’est défini
    • Dans la sortie de podman top, le processus du serveur HTTP est mappé sur l’utilisateur hôte 1001, mais s’exécute comme root à l’intérieur du conteneur
    • Cette configuration correspond à un état rootless rootful : non privilégié sur l’hôte, mais root dans le conteneur

  • Espaces de noms utilisateur

    • Les conteneurs rootless de Podman utilisent des espaces de noms utilisateur pour mapper différemment les UID/GID à l’intérieur et à l’extérieur du conteneur
    • Dans l’exemple, l’UID 0 du root à l’intérieur du conteneur est mappé sur l’UID 1001 de bar sur l’hôte
    • Le paramètre bar:165536:65536 dans /etc/subuid définit la plage d’UID pouvant être attribuée aux processus dans l’espace de noms de bar
    • Dans l’exemple, en plus de l’UID 1001 de bar, les UID de 165536 à 231072 peuvent être attribués aux processus de bar
    • Si l’on exécute sleep avec l’utilisateur interne www-data, il apparaît comme www-data dans le conteneur mais comme 165568 sur l’hôte
    • En entrant dans l’espace de noms utilisateur avec podman unshare, le répertoire personnel qui appartient à bar:bar sur l’hôte apparaît comme appartenant à root:root à l’intérieur de l’espace de noms
    • Docker prend aussi en charge les espaces de noms utilisateur, mais cela demande une configuration distincte et n’autorise qu’un seul espace de noms utilisateur, alors que Podman exécute les conteneurs rootless de chaque utilisateur UNIX dans l’espace de noms de cet utilisateur

  • Opérations privilégiées et Linux capabilities

    • Podman utilise les Linux capabilities pour accorder des privilèges root granulaires aux processus du conteneur
    • Lors de la construction d’image, des opérations comme apt install deviennent possibles grâce à une combinaison de capabilities telles que chown, dac_override, fowner, setgid, setuid, net_bind_service et sys_chroot
    • Si l’on retire toutes les capabilities avec podman build --cap-drop=all, apt échoue sur setgroups, setegid, seteuid, chown et d’autres opérations, ce qui fait échouer la construction de l’image
    • Il est aussi possible d’ajouter uniquement les capabilities nécessaires ; dans l’exemple, CAP_SETUID,CAP_SETGID,CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER sont ajoutées pour effectuer l’installation des paquets
    • Dans son état d’exécution par défaut, le serveur HTTP tourne en tant que root à l’intérieur du conteneur et dispose de nombreuses capabilities effectives comme CHOWN,DAC_OVERRIDE,FOWNER,FSETID,KILL,NET_BIND_SERVICE,SETFCAP,SETGID,SETPCAP,SETUID,SYS_CHROOT
    • Comme le serveur HTTP n’a pas besoin de ces privilèges, on peut supprimer toutes les capabilities avec podman run --cap-drop=all ; dans ce cas, podman top affiche none pour les capabilities effectives

  • Rootless non-root

    • Pour exécuter le serveur HTTP en tant qu’utilisateur non privilégié aussi à l’intérieur du conteneur, on peut utiliser un utilisateur existant dans /etc/passwd, par exemple www-data, ou créer un utilisateur dédié lors de la construction de l’image
    • Dans l’exemple, un utilisateur et un groupe foo, avec l’UID 1002, sont créés, des droits de lecture sont accordés sur /var/www/html, puis USER foo:foo est défini
    • Si cette image est lancée avec --cap-drop=all, le processus s’exécute comme foo dans le conteneur, avec l’UID hôte 166537 et des capabilities effectives à none
    • Les processus du conteneur doivent s’exécuter avec le minimum de privilèges nécessaire ; par exemple, si foo doit se lier au port privilégié 80, il faut ajouter --cap-add=CAP_NET_BIND_SERVICE
    • On peut distinguer quatre modes d’exécution des conteneurs
      • utilisateur hôte root + conteneur root : root rootful
      • utilisateur hôte root + utilisateur non privilégié dans le conteneur : root non-root
      • utilisateur hôte non privilégié + conteneur root : rootless rootful
      • utilisateur hôte non privilégié + utilisateur non privilégié dans le conteneur : rootless non-root
    • Podman facilite l’exécution de conteneurs rootless rootful, et si les processus du conteneur peuvent être exécutés sous un utilisateur non privilégié, une configuration rootless non-root reste relativement simple à mettre en place

Montages bind et isolation des UID

  • Lorsque l’on monte un répertoire de l’hôte dans un conteneur, l’accès aux fichiers appartenant à root de l’hôte, à bar de l’hôte et à foo du namespace varie selon le mappage des UID
  • Dans l’exemple, on crée dans le répertoire /var/lib/bar/test un root.txt appartenant à root de l’hôte et un bar.txt appartenant à bar de l’hôte, puis on le monte en lecture/écriture dans le conteneur sur /test
  • Si le conteneur est exécuté en tant que foo, le fichier appartenant à bar de l’hôte apparaît comme root:root dans le conteneur, tandis que le fichier appartenant à root de l’hôte apparaît comme nobody:nogroup car il n’est pas mappé dans le namespace
  • Dans le conteneur, foo ne peut lire ni bar.txt ni root.txt, et un rootless non-root apporte une isolation supplémentaire par rapport à un rootless rootful
  • Le foo.txt créé par foo dans le répertoire monté apparaît sur l’hôte comme appartenant à l’UID 166537, et l’utilisateur hôte bar ne peut pas en lire le contenu
  • Si le conteneur est exécuté avec l’utilisateur interne root, le root du namespace peut lire les fichiers appartenant à bar sur l’hôte ainsi que ceux appartenant à foo, mais pas le fichier appartenant à root sur l’hôte
  • Si l’on exécute avec l’utilisateur interne root tout en appliquant --cap-drop=all, il ne peut plus lire non plus le fichier de foo et ne peut lire que le fichier appartenant à bar sur l’hôte

Test de Copy Fail

  • Conditions de test

    • Pour le test de Copy Fail, on utilise la version exploit du commit publié à l’origine 8e918b5
    • L’image de conteneur d’exemple ajoute curl à une image de serveur HTTP existante afin de pouvoir télécharger le script d’exploit depuis le conteneur
    • L’image est buildée sous le nom copyfail
    • Le noyau testé est le 6.12.74+deb13+1-amd64 de Debian, et côté Debian on considère qu’une version récente inférieure à 6.12.85 peut encore servir de noyau non corrigé
    • En temps normal, si l’utilisateur non privilégié foo appelle su, le mot de passe root est demandé
    • Dans chaque test, l’utilisateur du conteneur télécharge le script Copy Fail dans /tmp, l’exécute, puis appelle sleep après avoir obtenu un shell root
    • Copy Fail persistant au-delà du cycle de vie du conteneur, la VM est redémarrée avant chaque test

  • Résultats en rootless rootful

    • Si le conteneur est lancé avec --user=root, le processus dans le conteneur est déjà root
    • Dans cet état, si l’on exécute le script Copy Fail puis que l’on appelle su, on obtient un shell uid=0(root), mais comme l’utilisateur root peut déjà ouvrir un autre shell root avec su sans mot de passe, Copy Fail n’apporte concrètement rien de plus
    • Dans podman top, /bin/bash, python3 copy_fail_exp.py, su et sleep apparaissent tous comme root dans le conteneur et comme utilisateur hôte 1001
    • Le même ensemble de capabilities est conservé, avec CHOWN,DAC_OVERRIDE,FOWNER,FSETID,KILL,NET_BIND_SERVICE,SETFCAP,SETGID,SETPCAP,SETUID,SYS_CHROOT
    • Le root interne peut lire bar.txt et foo.txt dans le /test monté, mais pas root.txt, qui appartient à root sur l’hôte

  • Résultats en rootless non-root

    • Si l’on exécute le conteneur en tant que foo, puis que l’on lance le script Copy Fail et appelle su, les privilèges sont élevés vers le root interne au conteneur
    • Le id du shell obtenu s’affiche comme uid=0(root) gid=1002(foo) groups=1002(foo)
    • Dans podman top, le /bin/bash initial, le processus exécutant l’exploit et l’appel à su apparaissent avec l’UID hôte 166537, l’utilisateur conteneur foo et des capabilities à none
    • Après l’élévation de privilèges, [sh] et sleep apparaissent comme utilisateur hôte 1001, utilisateur conteneur root, et récupèrent le même ensemble de capabilities que le rootless rootful
    • Même ce root de conteneur ayant obtenu des privilèges ne peut pas lire root.txt, qui appartient à root sur l’hôte
    • Dans cet état, le conteneur est compromis, mais le périmètre d’attaque reste limité à ce qui est accessible au conteneur et à l’utilisateur non privilégié bar sur l’hôte

  • Résultats avec no-new-privileges

    • Podman permet, avec --security-opt=no-new-privileges, d’empêcher un processus de conteneur d’obtenir plus de privilèges qu’au moment de son démarrage
    • Si l’on applique cette option à un conteneur rootless non-root et que l’on exécute Copy Fail, un shell s’ouvre mais reste en uid=1002(foo)
    • Dans podman top, tous les processus restent aussi avec l’UID hôte 166537, l’utilisateur conteneur foo et des capabilities à none
    • Dans le /test monté également, foo ne peut lire que son propre fichier, et non bar.txt ni root.txt
    • Le conteneur est compromis, mais reste limité à l’utilisateur interne non privilégié foo sans capabilities

  • Résultats avec --cap-drop=all

    • Même si l’on lance un conteneur rootless non-root avec --cap-drop=all, foo n’a de toute façon aucune capability au départ
    • Dans cet état, si l’on exécute Copy Fail puis que l’on appelle su, le shell ouvert reste en uid=1002(foo)
    • Dans podman top, /bin/bash, l’exécution de l’exploit, su, le shell et sleep restent tous en foo avec des capabilities à none
    • L’exploit échoue à obtenir un shell root, et foo ne peut lire que son propre fichier dans /test
    • Ce résultat est similaire au test no-new-privileges, et ces deux mesures peuvent être utilisées ensemble pour réduire efficacement l’exposition aux capabilities

  • Persistance de l’exploit

    • Si l’obtention immédiate d’un shell root et de capabilities a pu être bloquée par no-new-privileges ou --cap-drop=all, les effets de l’exploit lui-même persistent
    • Si l’on lance ensuite un nouveau conteneur sans restriction de capabilities, l’utilisateur non privilégié foo du conteneur peut devenir root du conteneur simplement en appelant su
    • Un correctif du noyau et un redémarrage restent donc nécessaires

Stratégies de défense en profondeur

  • Images en lecture seule

    • ajouter --read-only à podman run monte le système de fichiers racine du conteneur en lecture seule
    • Podman monte par défaut certains répertoires comme /tmp, /run et /var/tmp en écriture ; pour obtenir un mode entièrement en lecture seule, il faut donc aussi ajouter --read-only-tmpfs=false
    • si un conteneur en lecture seule est compromis, les écritures sur le système ne sont pas autorisées, ce qui peut limiter certaines attaques après l’exploit
    • toutefois, comme il est possible de rediriger la sortie de curl vers python3, le mode lecture seule à lui seul n’empêche pas l’exécution même de l’exploit
    • dans l’exemple, le serveur HTTP python3 n’a pas besoin d’écrire sur le système de fichiers, ce qui permet d’utiliser cette option en toute sécurité
    • beaucoup d’images préconstruites partent du principe qu’elles ont un accès en écriture à certains répertoires et peuvent donc ne pas fonctionner correctement avec un système de fichiers racine en lecture seule
    • un système de fichiers racine en lecture seule est indépendant des volumes en écriture attachés au conteneur ; en cas de compromission, il reste donc possible d’écrire dans ces répertoires de montage

  • Limitation des ressources

    • Docker et Podman peuvent utiliser les cgroups pour limiter les ressources fournies aux conteneurs
    • un conteneur n’a pas besoin d’une quantité illimitée de mémoire, de CPU ou de PID
    • podman stats permet de vérifier l’utilisation des ressources du conteneur, puis d’appliquer des limites adaptées

  • Limiter les binaires disponibles

    • l’exemple utilise l’image ubuntu pour simplifier, mais l’image ubuntu contient de nombreux binaires qu’un attaquant peut exploiter en cas de compromission
    • la plupart de ces binaires ne sont pas nécessaires pour exécuter un serveur HTTP
    • il est préférable de garder les images d’exécution aussi minimales que possible
    • les builds multi-étapes permettent de séparer l’environnement de build de l’environnement d’exécution
    • vous pouvez partir d’images spécialisées comme python3, des variantes Debian -slim, ou de distributions plus petites comme alpine
    • si le processus du conteneur est compatible, vous pouvez utiliser des distroless images ou scratch afin de créer un runtime sans shell, gestionnaire de paquets ni utilitaires système

  • Pare-feu

    • il est possible d’utiliser iptables ou nftables pour restreindre les processus de conteneur via un pare-feu
    • seules les connexions entrantes et sortantes strictement nécessaires au processus du conteneur doivent être autorisées
    • dans l’exemple du serveur HTTP, aucune connexion vers DNS ni vers des serveurs locaux ou distants n’est nécessaire ; on peut donc le restreindre, par exemple, à n’autoriser que les paquets tcp provenant de connexions entrantes déjà établies

Implications opérationnelles

  • les conteneurs rootless Podman standard offrent par défaut une meilleure isolation que la configuration standard des conteneurs Docker
  • Docker prend aussi en charge l’exécution rootless et l’utilisation d’espaces de noms utilisateur non privilégiés, mais cela demande plus d’efforts de configuration que Podman, et les différences d’architecture jouent également
  • Docker reste très largement utilisé, et des outils de self-hosting comme Dokku, Kamal, Coolify, Dokploy utilisent aussi Docker par défaut
  • si vous exécutez des images Docker Hub sans les examiner soigneusement ou sans appliquer de mesures de verrouillage, vos services peuvent fonctionner avec une surface d’attaque plus large que nécessaire
  • il faut comprendre les détails d’implémentation des images de conteneur
    • vous devez savoir quel utilisateur, ou quels utilisateurs, exécutent les processus du conteneur
    • vous devez savoir de quels répertoires du système de fichiers racine dépendent les processus du conteneur
    • vous devez distinguer les capabilities Linux nécessaires de celles qui ne le sont pas
  • en combinant les différents mécanismes fournis par Podman et par les conteneurs, il est possible de renforcer les conteneurs et de réduire le rayon d’impact en cas de compromission
  • selon la charge de travail, il ne faut pas considérer le conteneur comme l’unique frontière de sécurité
  • l’utilisation conjointe de conteneurs et de machines physiques ou virtuelles distinctes permet une isolation efficace
  • Podman offre aussi un moyen d’isoler les workloads sur un même hôte en exécutant chacun avec un utilisateur non privilégié distinct et son propre espace de noms utilisateur

Ressources complémentaires

À lire aussi

1 commentaires

 
GN⁺ 2 시간 전
Avis sur Lobste.rs

  • Il faut se concentrer sur le comportement primitif rendu possible par la vulnérabilité, plutôt que sur l’exploit publié
    Cette vulnérabilité permet d’écrire dans le page cache qu’un fichier soit en lecture seule ou non, ce qui permet à un conteneur malveillant de modifier des pages appartenant à des fichiers de l’image de base d’overlayfs, avec un impact possible sur d’autres conteneurs selon la manière dont ils sont déployés
    Dans la configuration rootless ici, les cibles seraient d’autres conteneurs exécutés sur l’hôte avec le même utilisateur
    Une autre voie d’exploitation consiste à lancer ou trouver un conteneur basé sur une image de base déjà connue pour être utilisée, puis à altérer le page cache à l’intérieur de ce conteneur afin qu’un autre conteneur partageant le même runtime et les mêmes données overlayfs exécute ce code
    Le mode rootless et les user namespaces sont importants, mais n’aident pas beaucoup ici, et comme le dit le site copy.fail, il faudrait envisager de bloquer dans les conteneurs l’appel système seccomp socket(AF_ALG, ...)

    • Je n’avais pas vraiment réfléchi en profondeur au comportement primitif sous-jacent, et je me suis davantage concentré sur l’inventaire des namespaces et capabilities fournis par les conteneurs rootless pour évaluer l’étendue de l’exposition d’un conteneur compromis
      J’aimerais bien plus de précisions sur ce que signifie exactement « selon la manière dont les conteneurs sont déployés »
      L’un des avantages de Podman rootless est que, selon la charge de travail, il n’est pas nécessaire d’exécuter les conteneurs sur l’hôte avec le même utilisateur
      Si vous parlez du cas où plusieurs conteneurs rootless tournent sous l’utilisateur principal d’un poste de travail, je suis d’accord, mais sur serveur on peut isoler chacun sous un utilisateur distinct, et exécuter la même image de conteneur avec différents utilisateurs non privilégiés
      C’est assez différent du défaut de Docker qui exécute la plupart des choses en root, mais j’ai aussi écrit à la fin de l’article que ce n’était pas une frontière de sécurité ultime, et qu’il faut juger au cas par cas si répartir des conteneurs rootless entre plusieurs utilisateurs non privilégiés est pertinent
      J’isole certaines charges de travail dans des VM
      Je me demande si le fait de dire que rootless et les user namespaces n’aident pas ici signifie qu’ils n’empêchent pas l’exploitation
      Je n’ai pas traité seccomp parce que je n’ai encore jamais défini de politique explicite pour des conteneurs, mais c’est une bonne occasion d’approfondir le sujet

  • J’aime Podman et les conteneurs rootless, mais après avoir vu CopyFail, je suis arrivé à la même conclusion que le commentaire voisin
    Même avec les avantages de contrôle d’accès supplémentaires de podman+rootless, cela confirme au fond le conseil classique selon lequel un conteneur n’est pas une frontière de sécurité, et qu’un seul exploit kernel peut tout faire tomber
    Je fais de l’administration système en amateur, mais comme nouveauté intéressante dans cet espace, j’ai regardé le backend libkrun pour crun avec podman
    La promesse est de gérer la plupart des workloads conteneurisés tels quels, tout en les exécutant en interne dans une MicroVM avec son propre guest kernel séparé, mais je ne sais pas vraiment où ça en est côté maturité, validation en conditions réelles et niveau d’audit de sécurité, et certains aspects semblent très cutting-edge
    Les MicroVM sont adoptées activement par les outils de codage LLM, donc cet état de fait pourrait durer
    podman machine semblait aussi prometteur, mais malheureusement il a manifestement été pensé uniquement pour un usage de poste de travail développeur, avec un modèle d’une seule VM d’exécution de conteneurs par système hôte
    Cela dit, je trouve que dire « un conteneur n’est pas une frontière de sécurité » est trop simpliste. Les conteneurs sont bien une frontière de sécurité, simplement pas aussi solide qu’on voudrait le croire

    • C’est aussi pour cela que la plupart des déploiements de conteneurs dans le cloud utilisent des VM. Une VM est une frontière défendable
      En déploiement local, cette ligne devient plus floue
      Du point de vue matériel, une VM n’est pas intrinsèquement plus sûre qu’un processus, mais sa frontière est plus défendable pour trois raisons
      Les évasions de VM sont moins fréquentes que les appels système, ce qui laisse plus de marge pour appliquer des mitigations de canaux auxiliaires sans dégrader les performances
      L’interface hôte d’une VM est bien plus simple. Un périphérique bloc expose une interface de lecture/écriture par blocs, et un périphérique réseau envoie et reçoit des trames
      L’appel setsockopt que Linux ou *BSD fournit sur les sockets représente une surface d’attaque bien plus large que la plupart des pilotes émulés ou paravirtualisés, et ce n’est pourtant qu’une toute petite partie de la surface d’attaque totale du kernel
      L’interface d’une VM est aussi bien moins riche en état. Il peut y avoir des transactions en cours dans un anneau de type requête-réponse, mais à part cela il y a très peu d’état
      Les identifiants, UID, GID, tables de descripteurs de fichiers et autres ajoutent de la complexité basée sur l’état dans le kernel, et s’il y a des bugs, un processus peut en tirer parti
      La difficulté des variantes pour poste de travail est qu’elles réintroduisent cette complexité
      Par exemple, la couche de base d’un conteneur pourrait être exposée comme un périphérique bloc contenant un système de fichiers immuable, mais les volumes et dossiers partagés seraient probablement montés via 9pfs ou VirtIO-FS, donc 9p ou FUSE au-dessus de VirtIO
      La surface d’attaque s’agrandit alors de nouveau
      Avec un peu de chance, il faut une chaîne d’exploitation complète
      Je suis plus familier de FreeBSD, où l’on sandboxe généralement avec Capsicum les composants qui fournissent les périphériques paravirtualisés ou émulés, de sorte qu’il faut d’abord compromettre un processus hôte, puis, pour accéder à quelque chose auquel la VM n’avait pas accès, il faut ensuite encore percer jusqu’au kernel
      Mais sans ce sandboxing supplémentaire, on retombe dans un monde où une évasion de conteneur permet de faire tout ce que l’utilisateur peut faire, ce qui n’est guère mieux qu’une compromission de root sur un poste de travail
    • Kata Containers et Firecracker sont déjà des technologies assez anciennes, et je pense qu’elles sont raisonnablement matures, étant donné qu’elles ont déjà été étudiées par des chercheurs
      Personnellement, je préfère gVisor. Ce n’est pas un runtime VMM, mais il existe depuis des années, et il est utilisé par des entreprises comme Tencent. Dans mon environnement, où tous les conteneurs tournent déjà dans des VM Proxmox, c’est un bon compromis
      J’expérimente aussi syd-oci, qui me semble avoir reçu un peu moins d’attention que les recommandations de base que sont les MicroVM ou gVisor
    • Cette formulation correspond aussi à mon expérience, et écrire cet article relevait presque d’un exercice d’acceptation de ce fait
      Merci aussi pour la référence à libkrun, cela semble être une piste prometteuse
    • L’adoption active côté outils de codage LLM a de fortes chances de faire mûrir davantage les MicroVM, et de conduire à une validation en production ainsi qu’à un durcissement renforcé
      Il semble aussi assez probable que cela débouche sur davantage d’audits de sécurité