Journal Retour d'expérience sur Qubes OS: un peu plus de sécurité pour votre desktop

Posté par  . Licence CC By‑SA.
Étiquettes :
42
17
déc.
2016

Bonjour nal,

Je t’écris aujourd’hui pour te narrer mon expérience sur Qubes OS. Alors, d’abord, qu’est-ce ? En 2 mots, c’est un système qui simplifie l’usage de plusieurs VM en desktop pour isoler ses tâches. Concrètement, cela veut dire que l’OS sur lequel vous allez démarrer n’est qu’un hyperviseur dom0 Xen qui démarre d’autres VM. Un point à noter, je n’ai testé que des VM Linux, il est possible d’après la doc d’utiliser d’autres systèmes comme NetBSD1. Voire de démarrer des systèmes obscurs2 comme Windows sur une VM complète.

Une fois que vous démarrez une application graphique dans une VM, vous n’avez pas tout le desktop dans une fenêtre comme on peut s’y attendre mais juste la fenêtre de l’application. On trouve aussi la bordure des fenêtres qui correspond à la couleur attribuée à la VM (les VM sont appelées « domaine » sous Qubes), cette bordure est aussi présente pour les notifications. Cela permet de distinguer des applications de deux VM différentes et donc d’éviter de se tromper en rentrant des informations dans un domaine auquel on ferrait moins confiance. Pour démarrer une application, il y a un menu dans l’hyperviseur qui permet de directement lancer une application dans une VM, sans devoir manuellement lancer la VM et lancer l’application dans la VM (je voulais vous faire une copie d’écran, mais je n’y arrive pas, je pense cependant plus à un bug Xfce que Qubes).

Pour simplifier encore plus la vie de l’utilisateur, le copier-coller entre VM fonctionne très bien (mais uniquement du texte). Une fois que vous avez copié quelque chose dans le presse-papier d’une VM, vous pouvez faire un ctrl-shift-c pour signaler à l’hyperviseur qui doit copier le contenu du presse-papier de la VM. Cela évite que votre hyperviseur garde en mémoire du contenu sensible ou dangereux d’une VM sans que vous le décidiez. Ensuite, vous changer le focus vers l’application qui doit recevoir les donner et appuyez sur ctrl-shift-v, le contenu est dans le presse-papier de la VM, vous pouvez le coller. Cela veut dire que vous pouvez facilement avoir une VM avec vos mots de passe isolés du réseau et facilement les coller dans votre navigateur

Un autre point pour le transfert de données, c’est l’envoi de fichier d’une VM à l’autre géré par l’hyperviseur. Soit vous ouvrez le navigateur de ficher, faites un clic droit et selectionnez « Send to other VM », il suffit de remplir le champ avec le nom de la VM (pas de liste déroulante, cela évite que la VM connaisse le nom des autres VM). Vous avez un popup qui apparaît dans l’hyperviseur (comme dit précédemment, vous reconnaissez que c’est l’hyperviseur à la couleur des bordures) vous demander de confirmer la copie et une fois que cela est fait, vous retrouver les fichiers dans un répertoire de votre autre VM. Vous pouvez donc transférer des fichiers facilement dans et depuis une VM isolée du réseau.

Par défaut on a aussi une VM faisant pare-feu, et l’interface graphique permet de simplement définir des règles qui seront ajoutées à cette machine. Cela veut dire qu’un attaquant devenant root dans une VM ne pourrait quand même pas changer les règles du pare-feu définies.

Un point que j’ai pu mettre en place sur le PC sur lequel j’ai fait le test, c’est l’isolation de l’USB du dom0. Ce n’est pas toujours possible si votre clavier/souris est branché en USB (sur les portables, on retrouve encore souvent du PS/2). On dédie la gestion du contrôleur USB à une VM (isolée du réseau), donc si on branche une clef USB, ce n’est pas le noyau de l’hyperviseur qui va scanner la table de partition mais la VM, diminue donc la surface d’attaque3. Un lsusb ne renvoit rien. Si votre clavier est en USB mais que vous avez plusieurs contrôleurs USB, vous pouvez en dédié un à la VM et ne brancher vos périphériques USB sensibles que sur ces ports

Pour continuer sur le matériel, vu que tous les programmes tournent dans des VM, ils n'ont pas accès à votre matériel, cela veut dire que votre navigateur ne peut pas écouter votre micro ou enregistrer votre webcam (sauf si vous donnez l'autorisation à la VM) ou votre client mail ne peut pas lire votre clef USB (en cas de faille de sécurité).

On se retrouve évidemment avec un système gourmand en ressource, lancer 5-6 VM de base, n’est évidemment pas complètement transparent à ce niveau. Mais c’est tout à fait supportable. Pour l’espace disque, il est mutualisé entre les VM. Il y a un template (par exemple Fedora, ou Debian) qui va gérer le /. Donc, une VM n’a accès en écriture qu’à son /home. Cela permet aussi une certaine protection. Et tout le reste est mutualisé. Par contre, cela veut dire que si vous voulez installer une application, vous devez le faire dans le template et toutes les VM y auront accès. Si vous voulez restreindre la liste des applications disponibles, vous devez créer un autre template et donc perdre un peu d’espace disque. Pour information, après un peu de test, j’ai 11 VM et 28Go d’utilisé. Le système de template permet aussi de mutualiser les mises à jour. Il suffit de mettre à jour le template, de redémarrer les VM qui en dépendent et elles sont toutes à jour. Un autre point intéressant, c’est qu’il est possible d’avoir des VM à usage unique « Disposable VM ». On peut lancer un navigateur, ouvrir un lien potentiellement dangereux et quand on quitte Firefox, la VM est supprimée, il n’y a plus aucune données, plus fort que la navigation privée.

On a donc un système qui ne fait que de « bêtes » VM comme n’importe quelle distribution pourrait le faire mais qui simplifie beaucoup l’isolation entre VM et permet donc de l’utiliser beaucoup plus simplement. Cela améliore donc la sécurité de l’utilisateur.

Copie d’écran d’exemple


  1. En fait n’importe quel système qui peut démarrer sur un domU Xen.  

  2. Sortie de Rogue One oblige 

  3. Mais ne protège évidemment pas d’un USB killer 

  • # Merci beaucoup !

    Posté par  . Évalué à 5.

    Merci beaucoup pour ce retour d'expérience ! QubesOS me fait les yeux doux depuis longtemps, mais devoir lui dédier une machine physique m'a jusqu'à présent dissuadé de franchir le pas. Qu'en est-il du support matériel / sur quel matériel l'as-tu testé ?

    • [^] # Re: Merci beaucoup !

      Posté par  . Évalué à 8.

      Alors, j'étais dans le même état que toi avec Qubes mais un collègue a amené un laptop avec Qubes d'installé hier, du coup, ça m'a pas mal motivé parce que je pensais que c'était dans un état moins utilisable que ça.

      Pour le matos, c'est un portable Samsung NP300E5A. i5-2450M, 8Gb de ram, SSD changé par mes soins. Je dois dire que je n'ai rien testé comme périphérique (Bluetooth, webcam, micro). Le WiFi fonctionne, ça me suffit pour le moment.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Merci beaucoup !

      Posté par  . Évalué à 6.

      mais devoir lui dédier une machine physique

      En fait, si on lit les System requirement. On voit que si on ne fait pas de HVM (vraie VM comme Windows), il n'y a pas besoin de VT-x, donc ça devrait tourner dans une VM. Pour tester, ça doit être suffisant.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Attention avec les couleurs

    Posté par  (site web personnel) . Évalué à 0.

    Il reste un problème pour la distinctions des VM par couleur: en fait, un application peut très bien décider de créer une fenêtre avec une bordure de la couleur qu'elle veut. C'est mieux expliqué ici: https://lwn.net/Articles/704287/

    • [^] # Re: Attention avec les couleurs

      Posté par  . Évalué à 6.

      Justement dans l'article que tu cite, c'est écrit que le bug est corrigé (sauf si tu parle du fait qu'une fenêtre peut dessiner ce qu'elle veut à l'intérieur, y compris un password prompt vert dans une fenêtre rouge)

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Un peu plus de sécurité ? Beaucoup plus

    Posté par  . Évalué à 9. Dernière modification le 21 décembre 2016 à 17:43.

    La sécurité des distributions Linux est cassée aujourd'hui, car la surface d'attaque est beaucoup trop importante à tous les niveaux, et parce que les applications ne sont pas conçues en respectant le principe de moindre autorité (Least Authority, Least Privilege). On utilise, en essence, des architectures obsolètes du point de vue de la sécurité. (Les mondes fermés de Windows et iOS essaient de faire un peu mieux.)

    Qubes OS a le potential d'apporter beaucoup plus de sécurité, en changeant radicalement la donne par une nouvelle architecture logicielle beaucoup mieux compartimentée. La surface d'attaque de Qubes OS est bien moindre—essentiellement Xen et un peu de code spécifique. Aujourd'hui c'est le seul système d'exploitation libre et utilisable qui soit un peu sécurisé. (J'ai entendu parler de Subgraph OS mais pas encore regardé les détails, et FreeBSD fait de bons progrès du point de vue de Capsicum au fil des releases.)

    Bien sûr Qubes OS n'apporte qu'une sécurité de compartementalisation entre les composants: chaque AppVM derrière est aussi peu sécurisée que le système qu'elle fait tourner, c'est-à-dire pas beaucoup. Il faut aussi qu'on fasse tous un effort pour avoir des userspaces plus sécurisés, à la fois en faisant des progrès incrémentaux (le Linux kernel hardening project est un bon pas en avant pour les gens qui ne sont pas sous PaX) et des progrès sur la conception de fond (Capsicum, sandboxing, etc.).

    • [^] # Re: Un peu plus de sécurité ? Beaucoup plus

      Posté par  . Évalué à 3.

      la surface d'attaque est beaucoup trop importante à tous les niveaux

      Un des plus gros problème, c'est que la sécurité Unix est prévue pour du multiutilisateur et qu'actuellement, aussi bien côté client que serveur, il n'y a qu'un seul utilisateur1

      (Les mondes fermés de Windows et iOS essaient de faire un peu mieux.)

      Je dirais que c'est beaucoup mieux. Et Android (la version de Google avec ses mises à jour mensuelles) et le nouveau système de permission avec les deux autres.

      chaque AppVM derrière est aussi peu sécurisée que le système qu'elle fait tourner, c'est-à-dire pas beaucoup

      Il y a quand même / qui est repris du template au reboot, ça permet d'éviter une partie des problèmes.


      1. s'il n'y a qu'un seul process web avec le même utilisateur, il aura quand même accès à toutes les données sensibles. 

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Un peu plus de sécurité ? Beaucoup plus

        Posté par  . Évalué à 2.

        Je raisonne en terme de surface d'attaque et de capacité du code qui fait cette surface à nous donner confiance en l'absence de failles dans le futur (sur une certaine période de temps). Android et iOS ont une bonne compartementalisation, sans doute comparables à ce qu'un très bon administrateur peut faire avec les approches de Mandatory Access Control sur des machines Linux (SELinux bien configuré par exemple), mais leur surface d'attaque pour la décompartementalisation (la complexité du système qu'il suffit de pervertir pour échapper à son compartiment) reste très importante. Après je connais mal la structure de leurs kernels; je sais que Darwin est parti d'une architecture Mach, avec surface réduite, mais j'imagine que c'est un modèle hybride qui a beaucoup augmenté depuis.

        En comparaison, QubesOS repose sur Xen, qui n'est pas parfait mais dont la surface est énormément plus petite. Pour la sécurité du code qui fait cette surface, j'ai l'impression que ça a longtemps été "pas mal mais sans plus", et que ça va en s'améliorant. Il y a des hyperviseurs plus sûrs, mais qui ne permettent pas de faire tourner un systèmes comme Qubes confortablement aujourd'hui.

        • [^] # Re: Un peu plus de sécurité ? Beaucoup plus

          Posté par  . Évalué à 3.

          Mais cette compartementalisation est pour moi essentielle pour arriver à diminuer la surface d'attaque (même si ce n'est pas encore fait). Cela permet d'avoir un framework qui permet une isolation plus grande de manière transparente. Le fait que les applications n'aient pas directement accès aux ressources des autres (même si ça pourrait être amélioré, en tout cas sur Android, je connais mal iOS) permet beaucoup plus facilement d'avoir d'isoler les applications.

          Par exemple, pour poster une photo, on peut avoir une application qui demande à l'application photo de se lancer et de prendre la photo. On peut beaucoup plus facilement dédier une VM à l'appareil photo sans avoir de problème1


          1. alors qu'actuellement avec Qubes, si on a deux applications de chat vidéos dans deux domaines différents (par exemple, perso et travail), cela devient compliqué. 

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.