Qubes OS 4.0

Posté par . Édité par Davy Defaud, Nils Ratusznik, palm123, ZeroHeure et Trollnad Dump. Modéré par Nils Ratusznik. Licence CC by-sa.
31
21
mai
2018
Distribution

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.

Logo de Qubes OS

Sommaire

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.

Un petit dessin pour illustrer l’architecture

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.

API d’administration de Qubes OS

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.

  • # Architecture à VM vs. architecture à conteneurs ?

    Posté par (page perso) . É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 . É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 (page perso) . É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 . É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 . Évalué à 3. Dernière modification le 22/05/18 à 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 à ceux qui les ont postés. Nous n'en sommes pas responsables.