Qubes OS 4.0

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
  • Dom0 (AdminVM+GUIVM)
  • Les VM modèles (TemplateVM)
  • Les VM basées sur un modèle (AppVM)
  • Les VM jetables
  • Les VM classiques
• Des changements majeurs
  • Généralisation des machines virtuelles jetables
  • Une surcouche d’administration
  • Des VM modèles sans TCP/IP
  • Fin de la paravirtualisation
• 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 (425 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)