On reçoit tous des mails un peu bizarres avec des liens qu'on n'ose pas ouvrir, et pourtant on est curieux, on est tenté parfois... C'est difficile de résister mais heureusement l'équipe de Linuxserver.io a pondu un truc super pour ça.

Il s'agit tout simplement d'une instance de Firefox qui tourne dans un conteneur Docker et qui est totalement pilotable depuis votre navigateur habituel.

Comme ça, quand vous recevez un lien louche que vous voulez ouvrir, vous le mettez là-dedans, dans une session jetable qui est totalement coupée de votre vraie machine. Et comme ça, si ça part en couille, vous butez le conteneur et on n'en parle plus.

Voilà, ça se présente juste comme une page HTTPS avec un navigateur dedans. Et comme c'est LinuxServer qui maintient l'image, vous êtes tranquilles parce que c'est du sérieux.

L'avantage d'avoir ce truc, c'est qu'un Firefox en conteneur ne voit ni votre répertoire personnel, ni vos cookies, ni vos sessions Google, ni vos extensions, absolument rien, il est totalement isolé. Donc si un site tente un drive-by download ou un exploit navigateur, eh bien en principe les dégâts resteront coincés dans le conteneur. Et le simple fait de le redémarrer remettra tout à 0.

Attention quand même, un conteneur, ce n'est pas une machine virtuelle. Une vulnérabilité au niveau du noyau pourrait en théorie s'en échapper. Mais c'est pas le genre d'attaque qui se fait avec juste un clic douteux sur une page web.

Les chercheurs en sécu s'en servent pour ouvrir des pièces jointes chelou, les marketeux pour jongler avec 12 comptes ad sans cookie cross-tracking , et les paranos dans mon genre pour cliquer sur les liens des mecs bizarres de Discord sans rien flinguer chez eux..

Après y'a des petits inconvénients. Je pense aux perfs graphiques qui prennent une claque par rapport à un Firefox natif ou encore l'audio qui transite par le pipeline du navigateur, du coup ça crachote parfois sur les vidéos lourdes. Le copier-coller marche, mais en passant par la section presse-papiers de la barre latérale Selkies , pas en direct. Et la persistance ne tient que si vous mappez le volume /config comme il faut, sinon vos onglets et vos bookmarks gicleront dès que le conteneur sera recréé (à la première mise à jour d'image, typiquement).

Côté vie privée c'est plutôt une qualité mais pour un usage quotidien, ça peut devenir relou.

Installation en une commande

L'image officielle, c'est lscr.io/linuxserver/firefox:latest. Elle tourne sur Selkies depuis juin 2025 (avant c'était KasmVNC) et démarre en Wayland par défaut depuis mars 2026. Maintenant, si un site part en vrille à cause de ça, vous ajoutez le paramètre PIXELFLUX_WAYLAND=false à la commande Docker et vous serez de retour en X11.

La commande minimale ressemble à ça :

docker run -d \
--name=firefox \
-e PUID=1000 \
-e PGID=1000 \
-e TZ=Europe/Paris \
-e LC_ALL=fr_FR.UTF-8 \
-p 3001:3001 \
-v $HOME/firefox-config:/config \
--shm-size=1gb \
--restart unless-stopped \
lscr.io/linuxserver/firefox:latest

Le --shm-size=1gb, c'est la mémoire partagée de Docker et vous n'y couperez pas, désolé. Si vous le zappez, YouTube comme les sites un peu lourds vous planteront le navigateur. Le port 3001, c'est l'accès HTTPS, avec un certificat auto-signé qui fera râler votre Firefox principal (c'est normal, faut l'accepter). Y'a aussi un port 3000, mais lui c'est du HTTP en clair, à réserver derrière un reverse proxy genre SWAG et rien d'autre.

Ensuite, direction https://localhost:3001/ et un joli Firefox vous attend. Notez que par défaut, il n'y a AUCUNE authentification. Personne ne vous demande rien, alors si vous voulez l'exposer sur votre réseau, définissez bien un CUSTOM_USER et PASSWORD pour activer le basic auth avant qu'un petit malin de votre réseau ne tombe dessus.

La version docker-compose, plus propre

Envie d'un setup versionnable, que vous pouvez reproduire ailleurs sans réfléchir ? Le compose fait ça mieux :

---
services:
firefox:
image: lscr.io/linuxserver/firefox:latest
container_name: firefox
environment:
- PUID=1000
- PGID=1000
- TZ=Europe/Paris
- LC_ALL=fr_FR.UTF-8
- CUSTOM_USER=korben
- PASSWORD=changezmoi
- HARDEN_DESKTOP=true
- HARDEN_OPENBOX=true
volumes:
- ./firefox-config:/config
ports:
- 3001:3001
shm_size: "1gb"
restart: unless-stopped

Ensuite, un docker compose up -d et roulez jeunesse. Le volume ./firefox-config conserve votre profil entre deux redémarrages avec bookmarks, extensions installées depuis le store Mozilla, tout reste en place.

Et si vous avez envie de repartir de zéro, on met le dossier à la poubelle, on relance, et voilà. Et pour glisser des outils tiers dans le conteneur (filezilla, un éditeur, ce genre de bidule), [proot-apps install](https://github.com/linuxserver/proot-apps) les posera dans $HOME, où ils survivront aux mises à jour de l'image.

Le hardening qu'il faut absolument activer

Maintenant, le piège que la doc évoque du bout des lèvres et qui mérite d'être écrit en gros c'est que l'interface web embarque un terminal avec sudo passwordless . Traduction : quiconque accède à votre Firefox conteneurisé devient root dans le conteneur en deux clics. Exposez ça sur votre réseau, ou pire sur Internet, sans durcir le machin, et vous ouvrez un boulevard.

La parade tient en une variable : **HARDEN_DESKTOP=true**, qui pose les principaux verrous d'un coup. Ça coupe sudo, ça vire les terminaux, et ça bloque xdg-open et exo-open, qui pourraient lancer des trucs hors conteneur. Vous pouvez empiler ça avec HARDEN_OPENBOX=true par-dessus, histoire de neutraliser les raccourcis clavier dangereux genre Alt+F4, de désactiver le clic droit et de masquer le bouton de fermeture. Firefox reste parfaitement utilisable, mais impossible de s'évader pour faire mumuse avec le système derrière.

Et pour une exposition sur Internet, le basic auth CUSTOM_USER/PASSWORD ne suffira pas car c'est trop léger. Moi ce que je vous recommande, c'est de coller le tout derrière un reverse proxy SWAG avec une vraie couche OAuth2 ou Authelia. Le basic auth, gardez-le pour le LAN entre potes ou collègues de confiance, mais pas au-delà.

SealSkin, le bonus qui change tout

SealSkin , c'est la cerise sur le conteneur ^^. C'est une extension navigateur, dispo pour Chrome et Firefox, qui monte la garde sur votre navigateur principal et détourne ce qui sent mauvais vers le conteneur isolé. Un lien repéré comme suspect ? Hop, il s'ouvre direct dans le Firefox conteneurisé. Pareil pour les téléchargements, qui atterrissent dans le conteneur au lieu de finir sur votre machine.

Du coup, l'isolation devient un réflexe permanent au lieu d'un machin que vous activez à la main quand vous y pensez (c'est-à-dire jamais). Seule contrainte par contre, faudra héberger le serveur SealSkin vous-même, et installer l'extension dans votre vrai Firefox. Mais vous verrez, après quelques jours à ce régime, vous aurez du mal à faire autrement.

Et sur tablette ou mobile ?

J'imagine que vous comptiez sur l'ancien tag kasm pour le tactile ? Eh bien c'est raté, puisque LinuxServer l'a déprécié début juillet. En échange, la barre latérale Selkies embarque désormais un trackpad virtuel et un clavier à l'écran, donc de quoi rendre l'interface utilisable depuis un iPad ou un smartphone sans bidouille en plus. On reste loin, c'est vrai, du confort d'un vrai desktop, et taper Ctrl+Tab au doigt c'est toujours la misère, mais pour dépanner ça fait le job.

Et voilà, votre Firefox jetable vit désormais dans son petit conteneur, bien au chaud. Comme ça, le prochain lien douteux, vous l'ouvrirez sans trembler... pour tester des sites au calme, difficile de trouver mieux, je pense.

Anthropic, l'entreprise derrière l'IA Claude, a corrigé en douce deux failles dans le bac à sable réseau de Claude Code, son assistant de programmation. Un bac à sable, dans le jargon, c'est un enclos de sécurité : il est censé empêcher l'outil de se connecter à des serveurs non autorisés, pour éviter qu'il envoie vos données n'importe où. Sauf que pendant cinq mois et demi, cet enclos avait une porte dérobée.

La plus récente faille est en fait une jolie bidouille. Claude Code vous laisse définir une liste blanche, par exemple "autorise uniquement les connexions vers *.google.com". Un attaquant envoyait alors une adresse du genre "serveur-pirate.com<a target="_blank" rel="noreferrer noopener" href="http://0.google.com/">0.google.com", avec un caractère invisible (un octet nul) glissé au milieu.

Le filtre de sécurité, lui, lit la fin de la chaîne, voit ".google.com" et valide. Mais le système d'exploitation s'arrête au caractère invisible et se connecte en réalité à serveur-pirate.com. Le filtre et le système ne lisent pas la même adresse. La faille est là.

Combinée à une injection de prompt (le fait de cacher des instructions piégées dans un texte que l'IA va lire), la faille permettait d'exfiltrer des choses sensibles : identifiants cloud, jetons d'accès GitHub, accès aux services internes.

En clair, un dépôt de code piégé pouvait pousser Claude Code à expédier vos secrets vers le serveur de l'attaquant. Le trou a traversé plus de 130 versions de l'outil avant d'être bouché fin mars. Tout utilisateur de Claude Code qui faisait confiance à son bac à sable réseau était donc exposé sans le savoir, du développeur isolé à l'équipe en entreprise.

C'est le chercheur Aonan Guan, de Wyze Labs, qui a remonté le problème. Et sa phrase résume tout : un bac à sable troué, c'est pire que pas de bac à sable du tout. Celui qui n'a aucune protection le sait et reste prudent. Celui qui se croit protégé baisse la garde.

Anthropic affirme avoir trouvé et corrigé la faille de son côté avant le signalement, mais le souci, c'est qu'il n'y a eu ni CVE (le numéro de référence public qui catalogue une faille), ni note dans le journal des versions. Moche moche.

Source : The Register

Sandbox-exec, c'est un utilitaire en ligne de commande dont pas grand monde ne parle mais qui est intégré à macOS et qui permet de lancer n'importe quel programme dans un bac à sable sécurisé, avec des restrictions sur mesure. Apple l'a déprécié, mais ça marche toujours... et c'est franchement pratique.

Avec ce truc, il suffit de créer un petit fichier de profil (extension .sb) et vous lancez votre commande avec sandbox-exec -f profil.sb votre_commande. En faisant ça, le programme de votre choix tournera dans un environnement verrouillé où il ne pourra accéder qu'à ce que vous autorisez explicitement.

Ensuite, vous avez deux philosophies. Soit vous bloquez tout par défaut et vous n'autorisez que le strict nécessaire, c'est-à-dire l'approche parano parfaite pour tester du code louche. Soit vous autorisez tout et vous ne bloquez que ce qui craint. La première est plus sûre, la seconde plus rapide à mettre en place.

Voici un exemple concret pour avoir un terminal coupé du réseau. Suffit de 3 lignes de profil (c'est du LISP) :

(version 1)
(allow default)
(deny network*)

J'avoue que faire tourner un agent IA en mode YOLO sur votre machine, y'a de quoi flipper un peu. Un mauvais prompt et hop, votre répertoire home part en fumée.

Mais heureusement, pour ça y'a Yolobox , un outil en Go qui fait tourner vos agents IA dans un conteneur Docker isolé. En gros, l'agent a les pleins pouvoirs dans son bac à sable par défaut comme ça, votre répertoire home reste intouchable. Claude Code, Codex, Gemini CLI, GitHub Copilot, tout est compatible, préconfiguré et prêt à l'emploi.

En fait avec Yolobox, seul votre dossier projet est monté en lecture-écriture avec le même chemin que sur votre machine et comme ça, l'agent bosse comme si de rien n'était. Sauf que tout le reste (vos clés SSH, vos credentials, vos photos de vacances à la plage naturiste et j'en passe...) est inaccessible depuis le conteneur. L'agent peut faire sudo, installer ce qu'il veut, déglinguer sa config... en fait RIEN ne s'échappe.

L'installation tient en une ligne :

brew install finbarr/tap/yolobox

Par contre, faut Docker Desktop qui tourne derrière, car sans ça, rien ne démarre. Ensuite c'est yolobox claude pour lancer Claude Code, yolobox codex pour Codex, yolobox gemini pour le CLI Google. Ou yolobox run suivi de n'importe quelle commande si vous avez un agent custom...

Côté sécu, y'a 4 niveaux qui vont du basique au parano. Le mode par défaut avec isolation conteneur standard. Un cran au-dessus avec --no-network et --readonly-project pour couper le réseau et passer le projet en lecture seule. Ensuite du Podman rootless. Et le niveau max avec isolation VM complète, parce que des fois faut pas déconner. Ça supporte aussi le runtime Apple Container pour ceux qui veulent rester full macOS.

Et les outils de dev sont déjà embarqués dans l'image : Node.js 22, Python 3, Go, Bun, ripgrep, fzf, jq... Les volumes persistants gardent également vos installations entre les sessions, donc pas besoin de tout réinstaller à chaque lancement.

Attention quand même, ça ne marche pas contre un escape de conteneur délibéré car hé, Docker reste Docker. Mais si vous utilisez Claude Code en mode autonome et que vous faites du vibe coding, c'est le minimum vital pour éviter qu'un agent aille fouiller là où il faut pas .

Bref, allez voir ça et merci à Lorenper pour le partage !

Si vous faites du "vibe coding" avec Claude ou Codex, vous savez que laisser un agent IA faire sa life, c'est un peu risqué. Si celui-ci se met à exécuter des rm -rf sur votre ordi de boulot, vous êtes dans la merde !

Heureusement, Kevin Lynagh a sorti Vibe et pour vous résumer le délire, c'est une VM Linux ultra-légère capable de sandboxer vos agents IA.

Ce qu'il vous faut

• Un Mac ARM (M1, M2, M3...)
• macOS 13 Ventura minimum
• Temps estimé : 5 minutes

Installation

Hop, on commence par installer Vibe. Plusieurs options s'offrent à vous :

curl -LO https://github.com/lynaghk/vibe/releases/download/latest/vibe-macos-arm64.zip

unzip vibe-macos-arm64.zip

sudo mv vibe /usr/local/bin

Et là, c'est prêt. C'est du Rust pur compilé avec le framework Virtualization.framework d'Apple, donc ça va viiiiite !

Et ce que vous pouvez voir au lancement de Vibe, c'est le mapping entre vos dossiers locaux liés à Claude, Codex et compagnie, et les dossiers qui sont dans la VM.

Premier lancement

Pour démarrer une VM, c'est aussi simple que ça :

./vibe

Oui, c'est tout. 10 secondes plus tard, vous avez un shell Linux avec un accès réseau et un partage automatique de vos dossiers. Notez jute que la première fois il faut une connexion réseau pour télécharger l'image de base de Debian. Après, tout est en local.

Le truc cool, c'est que Vibe utilise un système copy-on-write où chaque VM part d'une image de base commune et seules les modifications sont stockées. Comme ça même si vous lancez 10 VMs, ça bouffe pas votre SSD.

Bon ok, j'en ai lancé que 2 en vrai mais l'idée est là ^^

Configurer Claude ou Codex

Ensuite c'est simple, il suffit de lancer la commande Claude ou Codex directement dans le terminal que ça vous a créé, de les configurer comme si vous étiez sur votre ordinateur et puis c'est parti, vous pouvez les lancer avec le mode --yolo pour Codex ou avec --allow-dangerously-skip-permissions pour Claude.

Et c'est tout ! Si ça fait de la merde, ce sera dans la VM et vous ne risquerez rien ! Les fichiers sont bien sûr créés et dispo dans le répertoire dans lequel vous avez lancé vibe. Mais tout sera exécuté dans la VM donc y'a plus aucun risque.

Bref, si vous faites du vibe coding et que vous voulez pas finir avec un sudo rm -rf / généré par une IA un peu trop enthousiaste... bah voilà quoi. Le tout en moins de 1200 lignes de Rust, open source sous licence MIT.

Taaadaaaa ! À découvrir ici !

TwoFace est un outil développé par Synacktiv qui permet de créer des binaires Linux ayant 2 comportements bien distincts. Un comportement parfaitement inoffensif qui s’active dans 99% des cas et un comportement malveillant qui ne se déclenche que sur une machine ciblée spécifiquement pour l’occasion.

Comme ça, votre sandbox verra toujours la version “propre” parce qu’elle n’aura pas le bon UUID de partition.

D’après la doc de Synacktiv, voici comment ça fonctionne : Vous avez deux binaires en fait… Y’en a un qui est inoffensif et un autre malveillant. TwoFace les fusionne alors en un seul exécutable. Ainsi, au moment du build, le binaire malveillant est chiffré avec une clé dérivée depuis l’UUID des partitions disque de la machine cible. Cet UUID est unique, difficile à deviner, et stable dans le temps ce qui est parfait pour identifier une machine spécifique.

Ensuite au lancement, quand le binaire s’exécute, il extrait l’UUID du disque de la machine. Pour ce faire, il utilise HKDF (Hash-based Key Derivation Function) pour générer une clé de déchiffrement depuis cet UUID et tente de déchiffrer le binaire malveillant caché. Si le déchiffrement réussit (parce que l’UUID match), il exécute le binaire malveillant. Par contre, si ça échoue (parce que l’UUID ne correspond pas), il exécute le binaire inoffensif.

Le projet est écrit en Rust et c’est open source ! Et c’est une belle démo (PoC) d’un problème que tous ceux qui font de l’analyse de binaires ont. En effet, d’ordinaire, pour révéler le vrai comportement d’un malware on l’exécute dans une sandbox et on peut ainsi observer en toute sécurité ce qu’il fait, les fichiers qu’il crées, les connexions réseau qu’il établit etc…

Mais avec TwoFace ça casse cette façon de faire. Et c’est pareil pour les antivirus qui verront toujours la version inoffensive tant que l’UUID ne correspond pas.

Techniquement, TwoFace utilise memfd_create() pour exécuter le binaire déchiffré en mémoire, sans toucher au disque, ce qui veut dire zéro trace sur le système de fichiers. Le binaire malveillant apparaît directement en RAM, s’exécute, puis disparaît. Et si vous utilisez io_uring pour l’écriture mémoire, il n’y a même pas de trace syscall visible via strace.

Et ça, c’est la version basique car le document de Synacktiv mentionne également d’autres techniques avancées possibles comme du déchiffrement dynamique page par page du binaire ELF, des mécanismes anti-debugging, des chained loaders multi-niveaux…etc…

Le parallèle avec la backdoor XZ Utils backdoor est très instructif car celle-ci a failli compromettre des millions de serveurs Linux parce qu’un seul mainteneur a poussé du code malveillant dans une lib compressée. Elle a alors été découverte parce qu’un dev a remarqué un ralentissement SSH bizarre et a creusé… Et TwoFace montre qu’on peut faire encore pire sans toucher à la supply chain.

Pas besoin de corrompre un mainteneur de projet, de pousser un commit suspect chez Github. Là suffit d’écrire du code parfaitement propre, de le compilez avec TwoFace pour une machine spécifique, et de le déployez. Le code source sera alors auditable ainsi que le binaire mais l’audit ne révèlera rien parce qu’il se fera dans un environnement qui n’aura pas le bon UUID.

Après, techniquement, une défense existe. Vous pouvez par exemple détecter les appels à memfd_create(), monitorer les exécutions en mémoire, tracer les déchiffrements crypto à la volée…etc., mais ça demande du monitoring profond, avec un coût performance non-négligeable. Et ça suppose aussi que vous savez ce que vous cherchez…

Bref, si ça vous intéresse, c’est dispo sur GitHub !

Vous venez de claquer plusieurs milliers d’euros dans une solution antivirus dernier cri pour votre boîte car le commercial vous a convaincu avec du machine learning, de l’IA comportementale, du threat hunting prédictif et j’en passe…

Cool story ! Mais si je vous disais qu’un petit exécutable open source gratuit peut potentiellement passer à travers ? Ce programme s’appelle al-khaser et je vous assure qu’il va vous faire déchanter, car ce truc, c’est le détecteur de mensonges des solutions de cybersécurité.

Al-khaser est outil qui ne fait rien de méchant en soi… C’est ce qu’on appelle un PoC, un “proof of concept” avec de bonnes intentions car il rassemble dans un seul programme toutes les techniques que les vrais malwares utilisent pour se planquer tels que la détection de machines virtuelles, le contournement des débogueurs, l’échappement aux sandbox, et j’en passe.

Comme ça, si votre antivirus ne détecte pas al-khaser, il y a de bonnes chances qu’il rate aussi les vraies menaces qui utilisent les mêmes techniques.

Faut dire que les éditeurs d’antivirus et d’EDR adorent nous vendre leurs nouvelles fonctionnalités IA de fou alors que certaines de leurs solutions ne détectent même pas des techniques pourtant connues depuis longtemps.

Al-khaser met donc tout ça en lumière de façon assez brutale en enchaînant des dizaines de vérifications. Par exemple, il va regarder si votre processeur a vraiment le bon nombre de cœurs ou si c’est une simulation. Il va checker l’adresse MAC de votre carte réseau pour voir si elle correspond à un hyperviseur VMware ou VirtualBox. Il va mesurer le temps d’exécution de certaines opérations pour détecter si le système est accéléré artificiellement, comme dans une sandbox d’analyse. Il va même tester des API Windows classiques comme IsDebuggerPresent ou CheckRemoteDebuggerPresent pour voir si quelqu’un espionne son exécution.

Maintenant si vous voulez tester les protections anti-debug de votre système, vous tapez :

al-khaser.exe –check DEBUG –sleep 30

Oui si vous voulez voir si votre virtualisation VMware ou QEMU est bien masquée :

al-khaser.exe –check VMWARE –check QEMU

Bien sûr, ces techniques ne sortent pas de nulle part car elles sont documentées depuis des années notamment dans ce référentiel dont je vous déjà parlé .

Les équipes de pentest et les red teams adorent al-khaser car ça leur permet de montrer aux décideurs que leur gros investissement en cybersécurité n’est peut-être pas aussi solide qu’ils le pensaient. Vous lancez l’outil un vendredi après-midi dans un environnement de test, et vous voyez instantanément ce que votre EDR détecte ou pas.

Voilà, une fois encore, rassurez-vous, al-khaser ne fait rien de malveillant… Il ne vole pas de données, ne chiffre pas vos fichiers, ne lance pas de ransomware mais se contente juste de lever la main et de dire “hé ho, je suis là, regardez moi, je fais plein de des trucs louches !!”.

Bien sûr, ne lancez pas al-khaser sur n’importe quelle machine car c’est un outil de test qui doit rester dans un environnement contrôlé. Si vous le lancez sur le réseau de prod sans prévenir votre équipe sécu, vous allez déclencher des alertes partout et recevoir des appels pas très sympathiques. Et surtout, juridiquement, vous devez avoir l’autorisation du propriétaire de l’infrastructure, sinon, vous risquez de gros ennuis.

Ce projet est open source, écrit essentiellement en C++, et disponible sur GitHub . Y’a plus qu’à vous monter une VM isolée, récupérer al-khaser, et voir ce que ça donne.