Rédigé par Rédaction CyberSDF / 15 septembre 2026

Qubes OS : ce qu’apporte la compartimentation par machine virtuelle Xen, et où elle ne suffit pas

Qubes OS est une distribution Linux orientée sécurité, construite sur l’hyperviseur Xen en mode bare-metal, qui fait tourner chaque application dans une machine virtuelle séparée appelée qube. Sa promesse tient en une phrase, publiée sur la page d’accueil du projet (nouvel onglet) : « A reasonably secure operating system ». Concrètement, une compromission dans un qube ne compromet pas les autres qubes présents sur la même machine physique. Qubes n’est pas un pare-feu, pas un antivirus, pas un système d’exploitation anonyme : c’est une architecture de séparation. Ce texte décrit ce que Qubes est, à qui il s’adresse, ce qu’il exige comme matériel, comment il se distingue de Tails, et les limites documentées par le projet lui-même.

Pour situer Qubes dans l’offre Linux du site, voir la rubrique Linux et terminal, la page Tails, qui décrit l’approche amnésique et monolithique, et le guide de survie en ligne de commande pour les premiers gestes dans un terminal. Le contenu qui suit ne remplace ni la documentation officielle de Qubes (doc.qubes-os.org (nouvel onglet)), ni la lecture de la FAQ (nouvel onglet).

Qu’est-ce que Qubes OS, en une phrase que le projet assume ?

La page Introduction de la documentation officielle (nouvel onglet) donne la définition opérationnelle : Qubes OS est un système d’exploitation libre, orienté sécurité, qui s’appuie sur la virtualisation Xen pour créer et gérer des compartiments isolés appelés qubes. Chaque qube est une machine virtuelle à part entière, avec un rôle précis, un système d’exploitation invité au choix, et un niveau de confiance déclaré. Les fenêtres de tous les qubes apparaissent dans un bureau unifié, mais chacune porte une bordure colorée que l’utilisateur ne peut pas oublier : rouge pour ce qui n’est pas fiable, vert pour ce qui est de confiance, bleu et noir pour les niveaux supérieurs. Cette signalétique n’est pas un gadget : c’est l’interface qui permet de ne pas taper un mot de passe bancaire dans le navigateur d’un qube « non fiable ».

Le projet ne promet pas l’anonymat, et le dit en clair dans la FAQ, section « What about privacy in non-Whonix qubes? » (nouvel onglet) : en dehors des qubes Whonix, Qubes ne revendique aucune propriété spéciale de confidentialité. Pour l’anonymat, la recommandation officielle est d’utiliser les qubes Whonix intégrés (la sys-whonix), qui routent tout le trafic Tor via la passerelle Whonix comme n’importe quel Qubes avec une couche Tor supplémentaire.

Quelle est la différence entre Qubes et Tails ?

Le point est central, parce que les deux projets sont régulièrement cités ensemble. La même page de la FAQ le formule ainsi :

• Tails est un système live, amnésique, qui démarre depuis une clé USB et fait passer tout le trafic par Tor. Toutes les applications tournent dans le même système d’exploitation : une compromission atteint l’ensemble de la session.
• Qubes est un système persistant, installé sur le disque, qui fait tourner chaque activité dans une VM séparée. Une compromission reste contenue dans le qube compromis. Qubes ne fait pas passer le trafic par Tor par défaut, sauf à utiliser les qubes Whonix.

Concrètement, le tableau Whonix « Comparison with Others (nouvel onglet) » résume la distinction en trois formules : Tails oublie (à l’extinction, tout disparaît), Whonix route (le trafic passe par Tor via une passerelle dédiée), Qubes sépare (chaque activité est dans son propre compartiment). Tails et Qubes ne s’opposent pas : ils répondent à des besoins différents. Une personne exposée peut utiliser Tails pour un usage ponctuel sur une machine qu’elle ne contrôle pas, et Qubes pour un usage quotidien persistant sur sa propre machine, en reliant éventuellement les deux par les bonnes pratiques documentées dans la FAQ officielle (nouvel onglet).

Trois conséquences pratiques :

• Tails convient quand la machine hôte n’est pas de confiance ; Qubes exige au contraire que la machine hôte soit sous le contrôle de l’utilisateur.
• Tails ne laisse aucune trace après extinction ; Qubes conserve tout et demande des sauvegardes structurées (la page How to back up, restore, and migrate (nouvel onglet) décrit la procédure officielle).
• Tails utilise un seul système d’exploitation sous le capot ; Qubes embarque simultanément plusieurs distributions (Fedora, Debian, Whonix, et optionnellement Windows), chacune comme « template » pour de nouveaux qubes.

De quoi est composé un système Qubes par défaut ?

La page Getting started (nouvel onglet) liste l’état d’un Qubes neuf après installation. Cinq familles d’objets cohabitent :

• Les qubes d’application (app qubes). Quatre qubes prédéfinis sont créés par défaut : work (usage courant), personal (données personnelles), untrusted (navigation risquée, pièces jointes inconnues), vault (qubes isolés du réseau pour stocker des clés ou des documents sensibles). L’utilisateur peut en créer d’autres à la demande. La documentation officielle insiste : il n’y a rien de spécial dans ces quatre noms ; un utilisateur avancé les renommera ou les supprimera selon son propre modèle de menace.
• Les templates. Ce sont les systèmes d’exploitation qui servent de racine pour les app qubes. Qubes 4.3 inclut des templates Fedora 41 et Debian 12 par défaut ; chaque template peut servir de base à un nombre arbitraire d’app qubes. Un app qube ne peut pas modifier son template ; si un app qube est compromis, le template reste sain, et donc tous les autres app qubes basés sur ce template aussi. C’est la propriété centrale que la page Templates (nouvel onglet) décrit comme « séparer l’installation du logiciel de son utilisation ».
• Les qubes de service (service qubes). Ils rendent les ressources matérielles aux app qubes de manière isolée. Par défaut, Qubes crée quatre qubes de service : sys-net (accès au réseau physique), sys-firewall (pare-feu central entre les app qubes et sys-net), sys-usb (accès aux périphériques USB), sys-whonix (passerelle Tor via Whonix). Aucun app qube n’a directement accès à la carte réseau ou au contrôleur USB : tout passe par un qube de service.
• Les qubes jetables (disposables). Créés à la volée, ils s’autodétruisent à l’arrêt. Le cas d’usage type, décrit dans la page How to use disposables (nouvel onglet), est l’ouverture d’une pièce jointe suspecte : un disposable est créé pour la durée d’ouverture du fichier, puis disparaît sans laisser de trace.
• Le qube d’administration (dom0). L’unique qube qui contrôle le système entier. Dom0 n’a pas de connectivité réseau, ne sert qu’à administrer la machine (gestionnaire de fenêtres, gestionnaire de qubes, configuration). Si dom0 est compromis, la sécurité du système entier s’effondre. La documentation le dit explicitement : « game over ».

L’ensemble est relié par un pare-feu interne géré par sys-firewall, documenté dans la page Firewall (nouvel onglet). Par défaut, le trafic entre qubes est interdit ; les exceptions sont déclarées explicitement.

Quel matériel pour faire tourner Qubes ?

La page System requirements (nouvel onglet) publie deux niveaux, minimal et recommandé. Les chiffres suivants sont ceux du document officiel au moment de la rédaction.

Pré-requis minimaux :

• Processeur 64 bits Intel ou AMD, avec Intel VT-x + EPT (Extended Page Tables) ou AMD-V + RVI. La virtualisation doit être activée dans le BIOS/UEFI.
• Support IOMMU : Intel VT-d ou AMD-Vi.
• 6 Go de RAM.
• 32 Go d’espace disque.

Configuration recommandée :

• Processeur Intel 64 bits (les processeurs AMD sont « non recommandés » sur plateformes clients, voir plus bas).
• Intel VT-x + VT-d.
• Pour la sécurité : un processeur qui reçoit encore des mises à jour de microcode. Intel maintient une liste de fin de support (nouvel onglet) ; un processeur sorti de cette liste ne peut pas recevoir certaines mitigations.
• 16 Go de RAM.
• 128 Go de stockage SSD rapide.
• Carte graphique Intel intégrée fortement recommandée. Les GPU Nvidia demandent un dépannage documenté (nouvel onglet) ; les GPU AMD Radeon, surtout RX580 et antérieurs, fonctionnent en général.
• Un clavier non-USB ou un contrôleur USB séparé pour le clavier (sinon un keylogger USB compromet l’ensemble).
• Un module TPM pour la fonctionnalité Anti Evil Maid (nouvel onglet).

Deux points méritent un signalement honnête :

• AMD est techniquement supporté, mais non recommandé. La page officielle l’explique : sur les plateformes AMD client (par opposition aux processeurs serveur), les mises à jour de microcode ne peuvent pas être chargées depuis le système d’exploitation ; elles dépendent du constructeur de la carte mère, qui doit publier une mise à jour BIOS/UEFI. Intel, par contraste, distribue ses microcodes de manière régulière, ce qui permet à Qubes de réagir vite aux vulnérabilités récentes. Pour un système orienté sécurité, c’est un argument matériel qui pèse.
• Qubes ne tourne pas dans une machine virtuelle elle-même. La page System requirements le dit en garde explicite : « Installing Qubes in a virtual machine is not recommended, as it uses its own bare-metal hypervisor (Xen) ». Qubes est un hyperviseur Type 1 (bare-metal) ; il a besoin d’un accès direct au matériel. Une tentative d’installation dans VirtualBox ou VMware se termine par un échec ou un système instable.

Pour valider un achat, la page Certified hardware (nouvel onglet) liste les machines certifiées par le projet : peu de modèles, exigeant un firmware open source (coreboot) et des interrupteurs physiques pour les microphones intégrés. La Hardware Compatibility List (HCL) (nouvel onglet) communautaire recense les configurations testées par les utilisateurs ; elle est non recommandée et non déconseillée, juste informative.

Quelle version de Qubes installer aujourd’hui ?

La page Supported releases (nouvel onglet) publie le calendrier officiel. Au moment de la rédaction :

• Qubes 4.3 est la version stable supportée, publiée le 21 décembre 2025, basée sur Fedora 41 pour dom0. Date de fin de support : non définie (TBD).
• Qubes 4.2 est sortie le 18 décembre 2023, fin de support le 21 juin 2026. Une installation sur Qubes 4.2 reçoit encore des mises à jour critiques de sécurité pour ses composants internes (Xen, outils Qubes, kernel dom0), mais la distribution Fedora 37 sous-jacente est elle-même en fin de vie.
• Les versions antérieures (4.1, 4.0, 3.x, 2, 1) sont toutes marquées « Unsupported ».

La règle de cycle publiée par le projet : chaque release majeure ou mineure reçoit six mois de support après la release suivante. Pour une nouvelle installation, la recommandation implicite est donc la version stable courante (4.3). L’ISO est disponible sur la page Downloads (nouvel onglet), avec sa signature et son SHA-256 ; la page Installation guide (nouvel onglet) détaille la procédure, et la page Installation security (nouvel onglet) liste les vérifications à effectuer avant le premier démarrage.

Pour les utilisateurs qui n’ont pas de machine compatible, Qubes peut aussi être installé sur une clé USB ou un disque externe USB 3.0, comme l’indique la même page System requirements : c’est un mode supporté, qui permet notamment de tester la compatibilité matérielle sur plusieurs machines avant un achat.

Comment s’organise un utilisateur Qubes, concrètement ?

La page How to organize your qubes (nouvel onglet) propose des exemples concrets, recueillis par questionnaire auprès d’utilisateurs et de développeurs. Trois profils documentés :

• Alice, développeuse free-lance. Elle a un qube de code, un qube de build, un qube de test, un qube de production, par client. Les qubes de code utilisent un template Debian ou Fedora selon les outils disponibles. Le pare-feu Qubes limite l’accès réseau de chaque qube de code au seul dépôt Git du client, pour qu’un dépot tiers compromis ne puisse pas exfiltrer du code. Les clés GPG sont stockées dans un qube vault isolé du réseau ; les qubes qui en ont besoin passent par Split GPG (nouvel onglet) sans jamais voir la clé privée. Le gestionnaire de mots de passe (KeePassXC) est dans un autre qube vault également isolé.
• Bob, journaliste d’investigation. Il ouvre les pièces jointes dans des disposables jetables, pour qu’un éventuel beacon (un mécanisme qui appelle un serveur externe à l’ouverture du fichier) ne puisse pas identifier la machine. Il a plusieurs qubes e-mail : un pour les contacts publics, un pour les sources, chacun avec Thunderbird configuré pour ouvrir les pièces jointes en disposable. Les communications (Signal, Zoom, Telegram) tournent chacune dans un qube dédié ; la webcam et le micro sont attachés au qube actif puis détachés à la fin de l’appel, ce qui neutralise un éventuel programme d’espionnage activé à distance.
• Carol, activiste sous surveillance étatique. Elle utilise sys-whonix pour tout ce qui touche à Internet, et garde ses données personnelles dans un vault sans réseau. Les documents d’identité sont dans un autre vault. Chaque action sensible est précédée d’une décision explicite : « dans quel qube j’ouvre ce fichier, et vers quel qube je copie le résultat ».

Le projet insiste : il n’y a pas de configuration universelle correcte. La règle de raison publiée dans la page How to organize your qubes est « when in doubt, compartmentalize », c’est-à-dire créer plus de qubes plutôt que moins. Mais le projet ajoute l’avertissement symétrique : trop de compartimentation rend la machine inutilisable ; le bénéfice marginal décroît. La sécurité utile commence avec quatre qubes bien nommés et un modèle de menace explicite.

Ce que Qubes fait, et ce qu’il ne fait pas

La page FAQ (nouvel onglet) distingue explicitement Qubes d’autres approches.

Qubes fait :

• Sécurité par compartimentation. Une compromission dans un qube reste dans ce qube. C’est la propriété centrale, défendue dans Software compartmentalization vs physical separation (nouvel onglet), un document publié par l’Invisible Things Lab (la structure qui a créé Qubes). Le document argue que la compartimentation logicielle est, dans certains cas, plus robuste qu’une séparation physique, parce qu’elle peut être reconfigurée sans déplacer du matériel.
• Isolement des vecteurs d’attaque courants. La carte réseau est dans sys-net, le contrôleur USB dans sys-usb. Une clé USB compromise ne peut pas atteindre un qube qui n’a pas explicitement demandé à y accéder.
• Intégration Whonix native. Les qubes Whonix permettent d’utiliser Tor système entier, en s’appuyant sur les deux VMs de Whonix (passerelle et station) comme qubes de service. Le projet considère cette intégration comme la voie officielle pour la confidentialité sur Qubes.
• Persistance avec sauvegardes vérifiables. Le système de sauvegarde documenté dans How to back up, restore, and migrate (nouvel onglet) exporte un état complet qui peut être restauré à l’identique.

Qubes ne fait pas :

• Anonymat en dehors de Whonix. La FAQ le dit noir sur blanc : « Qubes OS does not claim to provide special privacy (as opposed to security) properties in non-Whonix qubes. This includes disposables. » Pour l’anonymat réseau, la voie est l’usage de Whonix via sys-whonix. Sans Whonix, Qubes isole des activités mais ne cache pas qui fait quoi.
• Anti-virus ni anti-malware traditionnel. Qubes part du principe que tout logiciel contient des bugs et que les exploits seront exploités. Sa réponse est la compartimentation, pas la détection. La page FAQ, section « Aren’t antivirus programs and firewalls enough? », explique pourquoi cette voie est considérée comme insuffisante.
• Protection contre un firmware compromis. Le projet documente le risque (« Evil Maid attack ») et propose Anti Evil Maid (nouvel onglet), mais AEM exige TPM 1.2 et Intel TXT, et son installation entre en conflit avec les règles de sécurité de dom0 (un USB dans dom0 est un risque en soi). C’est un compromis que chaque utilisateur doit arbitrer.
• Substitution à la documentation de chaque outil. Le navigateur est Firefox ESR dans un template, mais c’est toujours Firefox : ses failles restent ses failles, contenues dans le qube du navigateur.

Qui utilise Qubes, et pourquoi ce n’est pas anecdotique

La page Qubes endorsements (nouvel onglet) publie des déclarations publiques de personnes et d’organisations qui utilisent Qubes au quotidien. Sans inventer d’usage, voici ce que le projet lui-même met en avant :

• Edward Snowden déclare utiliser Qubes et le recommande.
• Freedom of the Press Foundation utilise Qubes pour la station de travail des journalistes qui reçoivent des SecureDrop, d’après la page SecureDrop (nouvel onglet) du projet SecureDrop.
• Let’s Encrypt, la plus grande autorité de certification au monde, utilise Qubes pour l’accès distant à ses serveurs de production.
• Mullvad, fournisseur de VPN, utilise Qubes pour son infrastructure interne.
• Micah Lee, directeur de la sécurité de l’information à The Intercept, déclare utiliser Qubes pour ses investigations.

Ces usages sont cités par le projet Qubes lui-même, sur sa propre page d’endorsements. Ce ne sont pas des recommandations de CyberSDF, ce sont des faits publiés par les organisations ou les personnes concernées.

Quelle est la situation juridique de Qubes ?

Qubes est un logiciel libre. La page FAQ, section « Is Qubes OS free and open-source software? », distingue deux sens du mot « free » :

• Free as in beer. Le téléchargement est gratuit ; les dons sont appréciés.
• Free as in speech. Le code créé par le projet Qubes lui-même est sous licence libre (GPL pour l’essentiel). Le code source est publié sur GitHub (nouvel onglet).

Le projet précise une nuance : Qubes intègre des firmwares non libres (microcode processeur) nécessaires pour se protéger de vulnérabilités connues. Les templates Fedora et Debian incluent aussi des firmwares et drivers non libres, pour faciliter l’installation sur un large éventail de machines. Cette transparence est cohérente avec la pratique de la majorité des distributions Linux généralistes. La licence complète est documentée dans License (nouvel onglet).

Pour un usage en France, Qubes ne présente pas de particularité juridique : c’est un système d’exploitation comme un autre, qui n’a pas d’usage prohibé en soi. La même logique que pour Tails ou Kali s’applique : la légalité dépend de ce que l’utilisateur en fait, pas du logiciel lui-même.

Repères et sources pour aller plus loin

• Page d’accueil du projet Qubes (nouvel onglet) : énoncé de la promesse et endorsements publics.
• Documentation officielle Qubes 4.3.1 (nouvel onglet) : introduction technique, fonctionnalités, organisation des qubes.
• System requirements (nouvel onglet) : pré-requis minimaux et recommandés, avertissement AMD, avertissement « ne pas installer dans une VM ».
• Getting started (nouvel onglet) : état d’un système neuf, app qubes, templates, service qubes, dom0.
• FAQ officielle (nouvel onglet) : définition, comparaison avec Tails et avec les hyperviseurs Type 2, propriétés de confidentialité.
• How to organize your qubes (nouvel onglet) : exemples concrets (développeuse, journaliste, activiste) et règles de compartimentation.
• Supported releases (nouvel onglet) : calendrier des versions, statut de support, OS utilisé pour dom0.
• Firewall (nouvel onglet) : fonctionnement du pare-feu interne entre qubes, configuration via qvm-firewall.
• Comparison with Others (Whonix) (nouvel onglet) : tableau comparatif Tails / Whonix / Qubes / Tor Browser / corridor.
• Software compartmentalization vs physical separation (Invisible Things Lab, 2014) (nouvel onglet) : argumentaire technique pour la compartimentation logicielle.

Ce que la documentation Qubes couvre déjà, ce qu’il reste à vérifier côté utilisateur

Ce texte décrit ce que Qubes publie lui-même sur son fonctionnement, ses pré-requis et ses limites, en citant les versions et les pages de la documentation officielle. Il ne recommande pas un usage particulier, ne propose pas de procédure d’évasion, et ne présente pas Qubes comme une garantie de sécurité. Le projet publie ses propres avertissements, notamment en FAQ sur les limites hors Whonix et sur les risques firmware, qui sont reproduits ici plutôt qu’édulcorés. La décision d’adopter Qubes reste conditionnée au matériel disponible, au modèle de menace et au temps disponible pour apprendre à s’en servir. Elle n’est pas triviale, et la documentation officielle reste la référence de détail.