L’équipe de Qubes OS a publié la version 4.0 de sa distribution le 28 mars 2018. Qubes OS est un système d’exploitation focalisé sur la sécurité qui se situe à mi‐chemin entre une distribution classique et un hyperviseur. Il s’appuie sur l’hyperviseur Xen et propose un système sécurisé basé sur l’isolation.
Sommaire
- Rappels
- Des changements majeurs
- La surcouche d’administration
- Retour sur XSA-254 : Metldown et Spectre
- La suite ?
Rappels
Pour rappel, on distingue différents éléments dans Qubes OS : le dom0, les machines virtuelles modèles, les machines virtuelles basées sur un modèle, les machines virtuelles jetables et enfin les machines virtuelles classiques.
Dom0 (AdminVM+GUIVM)
C’est le chef d’orchestre. Il est basé sur Fedora, contrôle l’hyperviseur Xen et permet d’administrer l’ensemble des machines virtuelles (VM). Il a un accès au réseau et aux périphériques présents très limité.
Les VM modèles (TemplateVM)
Ce sont des machines virtuelles portant une distribution GNU/Linux. On y accède uniquement en ligne de commande pour gérer les paquets installés. L’équipe de développement de Qubes OS propose trois modèles : Fedora, Fedora minimal et Debian. La communauté propose également des modèles pour Whonix, Ubuntu et Arch Linux.
Les VM basées sur un modèle (AppVM)
Elles disposent de quelques répertoires en propre (/home
, /usr/local
et /rw/config
). Toute modification des fichiers présents dans les autres répertoires est faite avec une copie à la volée (copy on write) et n’est pas pérenne : elle sera détruite lorsque la machine virtuelle va être éteinte ou redémarrée.
Les VM jetables
Ce sont des machines virtuelles ne disposant d’aucun répertoire en propre. Toute modification est donc perdue lors de l’extinction de la machine virtuelle.
Les VM classiques
Elles ne sont pas basées sur un modèle, et l’on peut y installer une distribution GNU/Linux, BSD, ou Windows.
Des changements majeurs
Généralisation des machines virtuelles jetables
Dans Qubes OS 3.2, on ne pouvait utiliser des VM jetables qu’avec un modèle. Il est maintenant possible d’utiliser une VM jetable pour chaque VM basée sur un modèle. Ainsi, pour lancer Firefox dans une VM jetable basée sur la VM work depuis Dom0 :
[user@dom0 ~]$ qvm-run --dispvm=work --service qubes.StartApp+firefox
Une surcouche d’administration
On détaille plus amplement cette nouveauté ci‐dessous. C’est un pas important vers les environnements professionnels, ainsi que vers les systèmes multi‐utilisateurs. Cette surcouche s’appuie sur une réécriture en profondeur des entrailles du système.
Des VM modèles sans TCP/IP
Les machines virtuelles modèles n’ont plus besoin d’avoir d’interface réseau, d’où une surface d’attaque réduite. Les mises à jour passent pas les API Qubes.
Fin de la paravirtualisation
Par défaut, la quasi‐totalité des machines virtuelles n’utilise plus la paravirtualisation. Comme détaillé ci‐dessous, on se protège ainsi partiellement des failles de type Meltdown et Spectre (XSA-254), et l’on réduit significativement la surface d’attaque de l’hyperviseur Xen (voir XSA-182 et XSA-260, par exemple). Il faudra cependant utiliser du matériel adéquat.
Pour certains utilisateurs, cette dernière modification tire la consommation électrique vers le haut et réduit l’autonomie des machines portables (discussion consultable sur groups.google.com/qubes-users).
La surcouche d’administration
La version 4.0 de Qubes OS permet d’utiliser des machines virtuelles pour modifier certaines caractéristiques de certaines autres machines virtuelles. La granularité est assez fine, ce qui donne la possibilité d’avoir plusieurs familles de VM de type admin (c.‐à‐d. admin-Net, admin-IO, admin-root, etc.), chacune ayant la possibilité de modifier certains aspects spécifiques de certaines VM.
Ainsi, les machines virtuelles de la famille admin-Net pourraient uniquement modifier l’interface réseau des VM qui ne sont pas de type admin. Celles de la famille admin-IO pourraient uniquement autoriser ou bloquer l’accès au presse‐papiers et au partage de fichiers des machines virtuelles. On pourrait également avoir une règle qui autorise la création d’une VM depuis toute VM, à condition que la nouvelle VM soit basée sur le modèle fedora_by_XYZ.
Dans une certaine mesure, cette surcouche d’administration permet d’avoir des administrateurs qui ont un pouvoir limité et un accès limité aux données des utilisateurs, tout en administrant effectivement la machine. Dans de nombreux systèmes d’exploitation, l’administrateur est tout‐puissant, et a donc de lourdes responsabilités.
Retour sur XSA-254 : Metldown et Spectre
N. D. A. : On propose ici un (très) bref résumé de ce document.
Pour rappel, sous ces deux noms se cachent trois failles :
- Spectre 1 (CVE-2017-5753, aka « Bounds-check bypass ») ;
- Spectre 2 (CVE-2017-5715, aka « Branch Target Injection ») ;
- Meltdown (CVE-2017-5754, aka « Rogue Data Load »).
La plus sérieuse des trois, Meltdown, ne peut être exploitée que depuis une machine virtuelle paravirtualisée. La nouvelle version de Qubes OS protège donc contre cette faille. En outre, les dernières mises à jour de Xen (utilisation de Xen Page Table Isolation) devraient colmater la brèche pour les machines virtuelles paravirtualisées.
La faille Spectre 2 aurait également été colmatée avec les dernières mises à jour de Xen, mais il faut mettre à jour le BIOS.
Ces trois failles permettent d’accéder en lecture à la mémoire vive. Ainsi, une machine virtuelle compromise ne peut accéder qu’à la mémoire des machines virtuelles qui fonctionnent simultanément. En évitant d’utiliser en même temps des machines virtuelles dont le niveau de confiance diffère, on se protège efficacement. En outre, l’utilisation de machines virtuelles jetables permet de ne pas pérenniser l’infection. Enfin, on notera que l’on peut laisser tourner une machine virtuelle compromise si elle n’a pas accès au réseau.
La suite ?
La principale modification attendue pour la version 4.1, c’est l’éclatement de Dom0. Actuellement, l’interface graphique permettant d’administrer le système réside, avec les services effectuant l’administration, dans Dom0. Dans un futur proche, on devrait avoir une machine virtuelle portant l’interface graphique dédiée à l’administration distincte de Dom0. L’objectif étant de minimiser le nombre d’entités fonctionnant dans Dom0, où le niveau de sécurité doit être maximal. Un gestionnaire de fenêtres et un serveur X.Org représentent en effet un grand nombre de programmes et services, qui n’ont rien à faire dans Dom0.
Aller plus loin
- Annonce de sortie de la version 4.0 (424 clics)
- Page GitHub de Qubes OS (167 clics)
- Documentation de Qubes OS (193 clics)
- Portail Qubes OS (ToR v2) (92 clics)
- Portail Qubes OS (ToR v3) (173 clics)
- Dépêche sur Qubes OS Bêta 3 (133 clics)
- Dépêche sur Qubes OS 1.0 (121 clics)
- Journal sur Qubes OS 3.2 (149 clics)
- Dépêche : L’heure du test sur Qubes OS 3.2 (186 clics)
- Notes de version de Qubes OS 4.0 (113 clics)
# Architecture à VM vs. architecture à conteneurs ?
Posté par Miguel Moquillon (site web personnel) . Évalué à 6.
A la lecture de la dépêche, si je comprend bien :
- on a des VM modèles qui définissent un environnement GNU/Linux minimal
- à partir d'un de ces modèles, on peut avoir un environnement virtuel plus complet comprenant un ensemble de programmes précis
- à partir des ces environnement, on peut lancer des programmes eux même dans une VM à part
Je suppute, du fait de la lourdeur inhérentes aux VM, que QubesOS se destine avant tout aux serveurs.
Pourquoi QubesOS repose t'il sur une architecture à VM ? Pourquoi pas plutôt sur une architecture à conteneurs (LXC, docker, …) qui est bien plus légère ? Qu'est ce que de nos jours une telle approche apporte comparée à celles des conteneurs ?
[^] # Re: Architecture à VM vs. architecture à conteneurs ?
Posté par Anonyme . Évalué à 8.
C'est exact, modulo le fait qu'une VM modèle n'est pas forcément minimale. En gros, on installe tout ce dont on a besoin dedans, mais on n'utilise ces logiciels que dans les VM basée sur le modèle, jamais directement depuis le modèle. On peut avoir un grand nombre de modèles installés en même temps.
QubesOS ne se destine pas aux serveurs. C'est pensé pour les applications 'Desktop'. Effectivement, c'est plus lourd que du container. Mais ce serait mieux cloisonné et plus sur.
Comme toujours dans la sécurité, il y a des équilibres à trouver qui dépendent de l'utilisateur, du niveau de sécurité recherché et du modèle de menace. À l'utilisation, je vous confirme que QubesOS est un peu plus lourd qu'une distribution GNU/Linux classique, mais on s'y habitue très vite!
[^] # Re: Architecture à VM vs. architecture à conteneurs ?
Posté par Aris Adamantiadis (site web personnel) . Évalué à 5.
Les conteneurs sont développés principalement pour augmenter la vitesse de déploiement des applications, et pas vraiment pour rajouter de la sécurité. Les conteneurs tournent directement sur le noyau de l'hôte, ce qui les rend vulnérable à la première vulnérabilité priv-esc du noyau. C'est une surface d'attaque assez grande et historiquement assez prolifique en exploits. Il n'y a rien que Qubes puisse faire pour se protéger contre ce type d'attaques s'ils avaient décidé d'utiliser des conteneurs légers. En utilisant des VMs, ils peuvent partir du principe que le noyau de certaines VM est compromis et continuer à apporter des garanties de sécurité au système dans son ensemble.
# Présentation en vidéo
Posté par seveso . Évalué à 2.
Ça a déjà été signalé dans un commentaire de la précédente dépêche mais je rappelle quand même que Benjamin Sonntag avait fait une assez bonne présentation de Qubes en 2016 à Pas sage en Seine.
Ça date un peu mais ça peut aider à savoir si Qubes est adapté à nos attentes.
# XSA-263 - Spectre 3a et 4 - CVE-2018-3640 et CVE-2018-3639
Posté par Anonyme . Évalué à 3. Dernière modification le 22 mai 2018 à 11:31.
Concernant les récentes failles de type Spectre mentionnées dans le sujet, il n'y aurait pas de possibilité de compromission entre VM. cf https://xenbits.xen.org/xsa/advisory-263.html et https://www.us-cert.gov/ncas/alerts/TA18-141A
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.