Vous avez envie de voir à quoi ressemble Googlebook OS , mais pas du tout envie de dégainer +1000 balles pour un ordi bridé ? Ça tombe bien, un développeur a codé gbos-vm , un outil open source sous licence MIT qui lance sur un Mac Apple Silicon l'image de recovery de Google (conçu à l'origine pour le Dell Googlebook), dans une machine virtuelle boostée par le GPU.

Ce n'est donc pas un Android générique habillé en Googlebook mais un script qui télécharge l'image officielle (la build 16471258, ARM64, Android 17), en vérifiant l'empreinte, puis la fait démarrer sous QEMU avec Vulkan traduit vers Metal. Et rien de chez Google n'est redistribué dans le dépôt (pas de Playstore de base donc...).

Côté Mac, il vous faut donc un Mac avec archi Silicon, Homebrew, les outils en ligne de commande de Xcode, un JDK et le SDK Android (plateforme API 34 minimum) avec son NDK. Et comptez 16 Go de RAM en pratique car la VM en squatte 4 mais les compilations successives en auront besoin d'un peu plus. Et le script installera de lui-même tout ce qui vous manquera côté Homebrew, sans jamais vous demander un accès via sudo. Comptez environ 9 Go pour le download de tout ça et minimum 60 Go de libre pour la VM.

git clone https://github.com/skylartaylor/gbos-vm.git
cd gbos-vm
./install.sh

Ensuite, vous ouvrez l'application construite (dispo dans work/host/Googlebook VM.app), dont la mission est de lancer la VM et de l'éteindre proprement quand vous la quittez.

Le premier boot prendra environ 45 secondes sur un MacBook M5 et si un sélecteur d'utilisateur s'affiche, cliquez juste sur "User" et y'a pas de mot de passe. Notez que la souris est capturée par défaut, et que le raccourci ⌃⌥ la libèrera.

Voilà, c'est pas encore parfait car le bluetooth peut crasher, on est limité à 60 images par seconde max et que les échanges entre la VM et l'hôte (le mac) sont un peu instables mais j'imagine que tout ceci se bonifiera avec le temps...

Virtual Mac on iPad est un super projet sous licence libre qui permet de booter un bon vieux macOS dans une machine virtuelle sur... un iPad jailbreaké ! Hé ouais ! Les versions de Monterey à Tahoe sont prises en charge (la 27 étant encore bien bien expérimentale), et vous pouvez ainsi lancer Xcode, le Terminal ou Final Cut Pro, Logic Pro et Pixelmator Pro directement sur votre tablette Apple.

Côté matos, il faut un iPad Pro M1 ou M2, ou un iPad Air M1 (et ça fonctionne aussi semble-t-il sur les iPhone 14 Pro et 14 Pro Max). Les modèles de 1 To et 2 To, qui embarquent 16 Go de mémoire, sont ceux que les développeurs recommandent et niveau perf apparemment, on est au même niveau que ce qu'on peut obtenir avec VirtualBuddy ou UTM quand ils virtualisent macOS sur un Mac M1 ou M2.

Pour l'installer, faudra donc jailbreaker l'iPad (avec Dopamine par exemple), puis ajouter dans Sileo le dépôt du projet, dont voici l'adresse et y rechercher l'app Virtual Mac.

https://nfzerox.github.io/cydia/

Tout le process de jailbreak est décrit dans le readme du projet soit pour iPadOS 15 à 16.3.1 ou pour iPadOS 14 à 14.8.1. Par contre, la variante Dopamine-roothide n'est pas supportée, du coup faudra repasser sur le Dopamine officiel.

Côté utilisation, avoir un Magic Keyboard n'est pas obligatoire puisque le tactile suffit avec un tap pour cliquer, un tap à 2 doigts pour le clic secondaire et le défilement, sans oublier le clavier virtuel sous l'icône du clavier. En revanche, la connexion à iCloud ou à un compte Apple n'est pas prise en charge, donc pendant la configuration de macOS faudra choisir "Configurer plus tard" et vous vous en passez...

Maintenant ce projet exige iPadOS 16.3.1 au maximum, parce qu'Apple a retiré dès iPadOS 16.4, son hyperviseur du noyau. Et sans lui malheureusement, le portage vers les versions ultérieures est devenu très compliqué. Voilà donc cette bidouille de Virtual Mac sur iPad c'est avant tout un petit kiff technique réservé aux possesseurs d'iPad resté sur la 16.3.1 ou inférieur, car downgrader semble compliqué pour pas dire impossible.

Maintenant je tiens à vous rappeler que UTM SE tourne sur iPad sans jailbreak, mais n'a pas de JIT ce qui fait qu'il doit passer par un interpréteur donc c'est beaucoup plus lent. Ça sert donc surtout à faire tourner des systèmes + anciens ou allégés comme DOS ou Alpine Linux.

Bref, avant de jailbreaker quoi que ce soit comme des petits fifous, regardez bien dans les Réglages quelle version d'iPadOS tourne sur votre iPad pour voir si c'est jouable !

Source : Tom Dörr sur X

La société de sécurité Depthfirst a publié un billet que j'ai trouvé intéressant dans lequel ils expliquent en gros que les conteneurs (Docker et compagnie) ne sont plus une barrière de sécurité suffisamment solide. La thèse du papier, c'est qu'il faut désormais partir du principe qu'un attaquant (hacker ou malware) saura sortir d'un conteneur quand il le veut, sans grande difficulté.

En effet, un conteneur comme ceux que font tourner Docker ou Kubernetes, donne à un programme l'impression d'avoir sa propre machine. Sauf qu'en réalité, il n'embarque pas de système d'exploitation. Tous les conteneurs d'un serveur passent par le même noyau Linux qui est celui de l'hôte et dont le rôle est de gérer pour eux la mémoire, le processeur ainsi que le réseau.

Toutefois, beaucoup d'organisateurs de CTF notamment s'y fient les yeux fermés et hébergent plusieurs épreuves sur le même serveur, chacune dans son conteneur, en comptant uniquement sur la sécurité de l'hôte. Mais c'est un faux sentiment de sécurité, j'en veux pour preuve ce bulletin de sécurité d'AWS daté de novembre 2025 où il est expliqué que l'entreprise ne considère plus les conteneurs comme une barrière de sécurité et ne s'en sert donc plus pour isoler ses clients les uns des autres.

Ce qui a changé depuis quelques mois, vous le savez, c'est le prix d'entrée de la recherche de failles puisqu'avec les modèles d'IA de pointe, même un attaquant avec des moyens modestes peut fabriquer sans effort, dès la publication d'une faille, un exploit contre des machines qui ne sont pas encore corrigées, alors qu'avant ça demandait de sérieuses compétences.

source : Depthfirst

Et les chiffres publiés par Depthfirst montrent que tout ça s'accélère puisque 249 CVE ont été publiées pour le noyau Linux en janvier, et en août on en a eu 1 650 !

Depthfirst relève également que sur les 36 CVE divulguées via le kernelCTF de Google, 13 sont réalisables via des interfaces ordinaires comme celles qu'un conteneur reçoit par défaut (dont les sockets locaux). En fait, on en croise sans le savoir dès qu'on passe systemd, Docker ou une base de données locale.

Le 24 juillet dernier, Depthfirst a même décroché une place au kernelCTF avec un exploit 0day (donc avant tout correctif) et aujourd'hui, le PoC est en accès libre sur GitHub. Rassurez-vous, côté noyau Linux, le correctif est sorti le 6 août mais malheureusement, côté Ubuntu la mise à jour au 24 septembre, affichait encore que le noyau de la 26.04 était en "Vulnerable, work in progress" et celui de la 24.04 en "Vulnerable". Bref, trouver des vulns ça va vite. Fixer ces vulns sur TOUTES les releases et les machines, ça prend du temps. Alors qu'avant c'était l'inverse. Bref, tout a été chamboulé et c'est un peu la merde maintenant niveau cybersécurité pour patcher rapidement.

Alors comment se protéger de tout ça ?

Hé bien la solution de Depthfirst va vous mettre en PLS car eux proposent carrément de ne plus partager le noyau. Ils recommandent à la place de migrer les charges non fiables vers des microVM, autrement dit des machines virtuelles légères où chaque charge aura son propre noyau. Le projet Firecracker en fait partie tout comme Kata Containers comme ça, en théorie, si un attaquant casse l'un de ces noyau, il ne compromet que sa propre instance et pas l'hôte dans son entièreté ni ses voisins.

Reste que Firecracker s'appuie sur KVM, la brique de virtualisation du noyau Linux de l'hôte. Et comme vous le savez, KVM a eu ses propres failles. En effet, cet été, la faille Januscape ouvrait en grand la porte de la machine physique à un attaquant pourtant enfermé dans sa VM, à condition bien sûr que l'hôte autorise la virtualisation imbriquée (une VM dans la VM). Alors certes, la surface d'attaque est plus petite mais loin d'être nulle.

Voilà, en attendant, si vous êtes sous Ubuntu 24.04 ou 26.04, surveillez bien la mise à dispo du prochain noyau. Canonical a d'ailleurs annoncé il y a peu, une publication hebdomadaire des noyaux pour tenter de compenser cet emballement.

Source : le billet de recherche de depthfirst

Sous Proxmox VE, vos interfaces s'appellent nic0, nic1… Voici comment les renommer avec pve-network-interface-pinning sans perdre l'accès au serveur.

Le post Proxmox VE : renommer les interfaces réseau avec pve-network-interface-pinning a été publié sur IT-Connect.

Les failles qui permettent à une machine virtuelle de s'échapper vers la machine qui l'héberge, ça court pas les rue. Et celle qui vient de débarquer est plutôt impressionnante ! En effet, il y a quelques jours, le chercheur Hyunwoo Kim a publié la CVE-2026-89775, qui est une évasion "invité vers hôte" bien planquée dans KVM (sur les archis ARM64). Pour rappel, KVM c'est la brique de virtualisation du noyau Linux. Et le score CVSS grimpe même jusqu'à 9,3 sur 10 ! Donc, autant dire que c'est du sérieux.

En fait, cette faille permet à la VM de lire et d'écrire dans la mémoire du noyau de l'hôte à grand coups de 64 bits à la fois ^^, sans même déclencher le garde-fou censé lui rendre la main. C'est possible à cause d'un simple calcul de taille qui retombe à zéro. Du coup, le noyau considère que ce zéro est une taille valide, ce qui permet d'éviter l'invalidation du cache mémoire.

Kim décrit deux façons de s'en servir. La première, c'est l' évasion classique où depuis une VM on peut débouler sur la machine hôte. Autant dire que c'est le cauchemar de quiconque loue de l'ARM à plusieurs clients.

La seconde, quand à elle, est plus vicieuse et souvent oubliée. Sur des distributions comme RHEL, le fichier /dev/kvm est ouvert à tout le monde en écriture. Cela permet ainsi à un simple utilisateur sans droits de se servir de la faille comme d'un ascenseur vers root, sans avoir à lancer la moindre VM.

Alors, est-ce que vous êtes concerné ??

Il y a de bonnes chances que non car sur ARM64, la virtualisation imbriquée n'est pas un mode par défaut de KVM. Il faut l'activer soi-même au démarrage avec kvm-arm.mode=nested, et être sur une puce assez récente.

Mais si vous administrez pour de vrai un hôte ARM64 avec la virtualisation imbriquée active, là oui ! Un uname -r vous donnera votre version mais sachez que rien n'est impacté avant le noyau 6.16 et que le trou est colmaté à partir des versions 6.18.51 et 7.2.5. Red Hat prévient qu'aucun contournement "propre" n'existe, donc ce sera le correctif ou rien, déso ^^.

À ce jour, le chercheur en sécurité, Kim, a livré le mécanisme mais pas de code d'exploitation. Donc, prenez le temps de corriger le problème sans traîner, mais ne paniquez pas non plus car ce n'est pas encore exploité activement.

Source : la divulgation de Hyunwoo Kim sur oss-security .

Apprenez à sécuriser l'accès SSH de Proxmox VE avec une clé, à désactiver le mot de passe root et à éviter les pièges courant dont l'authorized_keys partagé.

Le post Proxmox VE : configurer l’accès SSH avec une authentification par clé a été publié sur IT-Connect.

Si vous avez déjà voulu essayer une distrib sans toucher à votre machine, vous connaissez la corvée... Faut dénicher la bonne ISO (32/64 bits, ARM...etc), créer la VM, et passer 20 minutes dans des réglages pour que ce soit joli ou qu'on puisse y faire du copier coller dans l'hôte et l'invité. Boxes , l'application de virtualisation du projet GNOME, vous permet d'éviter tout ça et c'est top si vous aimez économiser un peu de jus de cervelle. Vous choisissez le système dans une liste, et il va chercher l'image et l'installe tout seul en VM pendant que vous faites autre chose, par exemple venir sur Twitch regarder mon live .

La liste couvre Debian, Fedora, Ubuntu, OpenSUSE, CentOS Stream, Red Hat Enterprise Linux et Windows. Pour son fonctionnement Boxes s'appuie sur du solide avec qemu-kvm, libvirt-glib et spice-gtk, donc le code de votre système invité s'exécute directement sur le processeur de l'hôte via KVM, pour obtenir ce que la doc de GNOME appelle des "performances proches du natif".

Une fois la VM créée, vous lui fixez la quantité de mémoire et le stockage qu'elle a le droit de prendre sur votre système, histoire qu'elle ne vous freeze pas la machine. Et bien sûr, vous pouvez prendre des instantanés pour la ramener à un état antérieur, ce qui est la fonction qu'on utilise tout le temps, si comme moi vous aimez casser volontairement vos OS avec des bidouilles alternatives des enfers.

Le reste, c'est du confort : vous branchez une clé USB sur votre machine et vous la redirigez dans la VM, le presse-papiers est partagé entre les deux, et vous déposez un fichier depuis votre gestionnaire de fichiers dans la fenêtre de Boxes pour l'envoyer à l'invité.

L'affichage des VMs dans Boxes se redimensionne tout seul quand vous changez la taille de la fenêtre, et il y a même de l'accélération 3D pour certains des systèmes supportés.

Après, cette "simplicité" se paye puisque des choses comme la config des adaptateurs réseau ou la mise à jour du matériel virtuel, n'est pas visible dans l'interface . Et comme le Flatpak embarque toute la pile de virtualisation dans son propre conteneur, vous n'irez pas rattraper ça en douce dans les fichiers. Donc si vraiment vous avez besoin de mettre les mains dans le cambouis au niveau de ces réglages-là, prenez plutôt virt-manager dès le départ, c'est fait pour.

Son auteur, Felipe Borges a d'ailleurs réécrit entièrement l'application en GTK4 et partage ses résultats depuis août . Cette version-là installe dorénavant Windows 11 sans le moindre contournement manuel, en configurant Secure Boot et un TPM virtuel automatiquement. C'était la fonction la plus réclamée sur la version classique et elle ajoute aussi un périphérique VSOCK, qui permet de se connecter directement en SSH sur les VM en systemd 256 ou plus récent.

Attention quand même, ça reste une bêta destinée aux tests et pas à la production, et son auteur conseille de sauvegarder les données de vos VM avant d'y aller. Il précise aussi qu'il travaille là-dessus sur son temps libre, en plus de maintenir GNOME Settings et de son job à temps plein chez Red Hat ! Encore un hyperactif !! lol. Donc soyez patient si vous ouvrez un ticket de support.

Pour ce qui est disponible aujourd'hui, Boxes ne tourne que sur Linux, la version stable est la 50.0 sortie depuis mars 2026, et ça se télécharge via Flathub comme ceci :

flatpak install flathub org.gnome.Boxes

Dernier truc à savoir, Felipe, le mainteneur, a proposé de retirer Boxes du cœur de GNOME pour en faire une application indépendante, et le retrait est programmé pour GNOME 52 en mars 2027. Flathub deviendra alors le seul canal officiellement supporté, et le nom perdra son "GNOME" pour devenir simplement Boxes. L'identifiant Flatpak ne bougeant pas, les installations existantes continueront de se mettre à jour sans rien casser.

Et si vous voulez comparer avec une autre solution similaire, je vous avais déjà parlé de QuickEmu pour monter des VM sans y passer l'après-midi, mais Boxes, lui, joue sur le terrain du tout à la souris, et ça j'imagine que ça vous plait plus !

Merci à Hub pour le partage !!

Ce serait trop cool non, si avec un double-clic sur un .docx dans votre gestionnaire de fichiers Linux, Word s'ouvrait directement ? Et je ne vous parle pas d'un bureau Windows complet en plein écran ou d'une session de bureau à distance. Juste une fenêtre Word tout ce qu'il y a de plus classique, avec son icône dans votre barre des tâches, épinglable et "alt-tabbable" comme le reste.

Hé bien, c'est ce que fait WinPodX , qui fait tourner un conteneur Windows sous KVM en arrière-plan et découpe l'affichage application par application via FreeRDP RemoteApp. Comme ça, les liens mailto: partent vers Outlook ou les schémas slack: ou vnc: vers l'application qui les a déclarés.

Tout ce qui est presse-papiers, son, imprimantes et votre dossier personnel sont partagés d'office, et le conteneur se met en pause tout seul quand personne ne s'en sert.

Jusque-là, WinApps dont je vous ai déjà causé, qui fait tourner Office sous Linux , faisait déjà l'essentiel avec les fenêtres détachées, le dossier personnel partagé, le clic droit qui envoie un fichier vers une application Windows. Mais WinPodX se distingue aussi dans l'autre sens puisque vos applications Linux remontent également dans le menu "Ouvrir avec..." du Windows, et dans un dossier "Linux Apps" du menu Démarrer. Bref, l'accès aux apps et aux fichiers marche dans les 2 sens, pour plus de transparence dans vos usages.

Si ça vous intéresse, sachez qu'il vous faut une licence Windows valide, car WinPodX ne la fournit pas (logique), que la virtualisation doit être activée dans le BIOS, avoir un accès à /dev/kvm, 8 Go de RAM et une trentaine de gigas de libre. La première installation prend cinq à dix minutes le temps de télécharger l'ISO, et les suivantes sont quasi instantanées.

Pour l'installer :

curl -fsSL https://raw.githubusercontent.com/kernalix7/winpodx/main/install.sh | bash

Il y a également un paquet pour openSUSE, Fedora, Debian, Ubuntu, Arch et NixOS, un AppImage pour les autres. C'est sous licence MIT, et sans aucune télémétrie puisque celle de Windows a été elle-même coupée par défaut. Ah et l'interface du OuinOuin peut être configurée en français.

Par contre, pas d'accélération GPU, ce qui exclut les jeux et la 3D à moins de monter un passthrough à la main. Préférez Wine pour ça...