Sommaire
Demat Inal,
Je me suis beaucoup retrouvé dans le journal de lezardbreton : début avec linux fin des années 90, beaucoup d'apprentissage avec des randoms distribution, linux from scratch (ma plus grosse pente au niveau de l'apprentissage), et au bout d'un moment je me suis fixé sur ubuntu et une utilisation sans heurt pendant une dizaine d'années.
En 2018, profitant d'un changement de PC portable, j'ai pu basculer sur QubesOS et ressentir de nouveau les sensations que j'avais eu fin 90/début 2000, je ne vous raconte pas le plaisir que c'est de rajeunir de 20 ans ! Mais, pour une raison ou une autre, et de manière plus rapide cette fois, je suis retombé dans une utilisation sans heurt. Donc mon message d'aujourd'hui sera essayez QubesOS, mais pas juste tester comme beaucoup le faisaient il y a des années avec un linux installé en dual boot et au final très rarement utilisé. Non, vraiment, profitez du renouvellement d'un équipement pour n'installer QUE ce système, et utilisez le au quotidien. La plupart des documents qu'on peut trouver sur Qubes sont complets (aussi je ne suis pas certain qu'un témoignage supplémentaire puisse vous aider dans cette décision) mais ils datent souvent un peu et parlent d'un système compliqué avec plein de machines virtuelles (VM dans la suite), une communication inter-VM difficile (c'est pas simple de faire une capture d'écran, de faire un copier/coller entre deux machines, de partager un fichier etc.). Je ne me souhaite pas minimiser l'impact ergonomique du système sur la plupart des opérations basiques décrites, mais la situation a beaucoup progressé, on s'y habitue vite et l'usage devient progressivement aisé.
Je vais donc clore cette longue introduction sur le tl;dr suivant : installez QubesOS et donnez-vous 6 mois d'utilisation au quotidien.
QubesOS et les performances
Quand je parle de Qubes, j'ai souvent la remarque indiquant qu'utiliser des machines virtuelles vient dégrader les performances de l'ordinateur, et je pense que c'est surtout lié à la visibilité des machines virtuelles utilisées au travers d'un hyperviseur de type 2 comme par exemple virtualbox. Ce type de machine virtuelle, qui s'exécute sur du matériel virtuel proposé par l'hyperviseur existe aussi dans Qubes (Qubes utilise un hyperviseur de type 1 Xen ), ce sont les machines dites HVM où le matériel est virtualisé. Quand on lance une machine de ce type, en fait on en lance deux, une pour accéder au vrai matériel et une qui va accéder au matériel virtualisé et où notre système sera réellement lancé. C'est par exemple le cas des VM qui s'occupent du réseau ou de l'usb, ces machines n'accèdent pas directement au matériel, mais uniquement à une machine virtualisant le matériel proposée par l'hyperviseur.
Pour les autres machines, elles sont la plupart du temps dans un mode para-virtualisé et accèdent donc au matériel (par l'interface proposée par l'hyperviseur) avec un coût très légèrement supérieur à un accès direct. Il y a donc une très légère dégradation des performances, mais vraiment pas de l'ordre de grandeur qui peut être imaginé quand on pense virtualisation complète (à la type 2).
Comme je l'avais indiqué dans plusieurs commentaires, le principal reproche que je peux faire à QubesOS est de consommer pas mal de mémoire. Actuellement la commande xentop (l'équivalent de top mais pour les machines virtuelles) m'indique :
xentop - 09:21:13 Xen 4.8.5-27.fc25
12 domains: 2 running, 10 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 33410148k total, 30319924k used, 3090224k free CPUs: 4 @ 1800MHz
Oui, sur 32Go de mémoire, 30Go sont actuellement utilisé (j'ai 4 VM applicatives, 5 VM fonctionnelles, 1 VM d'administration et 2 VM virtualisant du matériel). Les VM applicatives représentent environ 20Go sur les 30Go, elles occupent entre 4 et 6Go à chaque fois, il faut juste le voir comme 4 PCs différents. Le reste est surtout occupé par les VM fonctionnelles, dont en particulier le pare-feu qui prend 4Go à lui tout seul (linux aime bien avoir plein de chose en cache :) ).
QubesOS et la mémoire
Afin de proposer une réduction de l'empreinte mémoire, l'idée des unikernels est une bonne piste, en particulier pour les VM fonctionnelles. Alors bien sûr un unikernel n'est probablement pas réaliste pour la gestion du réseau, de l'usb, de l'administration de Xen ou de l'affichage car les pilotes nécessaires sont nombreux et complexes, mais pour des fonctions plus simples comme le pare-feu, ou l'utilisation d'un vpn c'est très envisageable (la communication réseau inter VM passant par les interfaces de l'hyperviseur).
Ainsi le projet qubes-mirage-firewall a été proposé dans l'optique d'avoir un pare-feu utilisant une taille très réduite de mémoire (de l'ordre de 32 ou 64Mo). Ce projet commencé en 2016 utilisait jusqu'à récemment le mode HVM car mirageOS (le noyau sur lequel se base qubes-mirage-firewall) ne permettait pas d'avoir un mode para-virtualisé et une issue avait été ouverte à ce sujet (https://github.com/mirage/qubes-mirage-firewall/issues/29). Vous l'avez sans doute compris, mais le passage à un mode para-virtulisé est un sujet concernant les performances.
Depuis la sortie de mirageOS 3.9, il est maintenant possible de démarrer un unikernel utilisant mirageOS en para-virtualisation dans Xen (et donc d'avoir un firewall limité à 64Mo de mémoire).
Le problème de la consomation de mémoire devrait donc logiquement pouvoir diminuer dans un futur proche :)
Prochaines évolutions
Je suis assez enthousiaste concernant la prochaine version QubesOS 4.1 et en particulier le fait que l'interface graphique sorte de la VM d'administration (actuellement elle fait tourner X11) pour avoir sa propre VM.
Pour conclure, j'espère que j'ai pu vous donner au moins une petite envie de rajeunir si cela fait un moment que tout se passe bien sur votre système :)
# Para-virtualisation
Posté par Anonyme . Évalué à 2.
Merci pour ce journal, j'avais testé Qubes en version 3.2 et ça marche effectivement bien, après un peu d'apprentissage.
Sur la para-virtualisation, j'avais en tête que depuis la version 4.0, c'était en voie d'extinction : https://blog.invisiblethings.org/2017/07/31/qubes-40-rc1.html.
Another important change in this release (this time Xen-specific) is that we have ditched para-virtualized mode and embraced fully-virtualized mode for Qubes VMs.
Un des points forts de Qubes OS, c'est peut-être le fait de compartimenter les activités de manière poussée, ce qui est pertinent dans le cadre du télé-travail : je travaille dans une VM "Boulot", associée à la VM "VPN boulot". Et lorsque ces VM sont éteintes, je ne bosse pas.
[^] # Re: Para-virtualisation
Posté par palainp . Évalué à 1.
Tu as complètement raison, c'est moi qui me suis trompé de terme, partout où j'ai mis paravirtualisation il faut comprendre virtualisé sans passer par la virtualisation du matériel : https://www.qubes-os.org/doc/glossary/#pvhvm je ne sais pas quel est le terme pour remplacer ?
Toutes mes confuses.
[^] # Re: Para-virtualisation
Posté par Anonyme . Évalué à 1.
Aucune idée pour la traduction… C'est un tel bestiaire exotique, qu'il n'est pas aisé de le traiter !
# Merci
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 11 décembre 2020 à 13:00.
Merci pour ce journal.
J'avais effectivement été intéressé par qubes-os mais quand je l'avais testé je n'avais qu'un vieux pc desktop à dispo que je n'utilisais réellement pas. Pour moi le côté nomade est important, je veux pouvoir passer du salon à la terrasse ou la cuisine avec le même pc. J'avais peur de remplacer la Fedora sur mon laptop par un truc inconnu sur un pc qui me sert aussi à me connecter à mon travail et sur lequel je ne voulais pas risquer de perdre certaines fonctionnalités (accès vpns, docking/dedocking avec configurations d'écrans changeantes, partage d´écran, screencasting). Du coup je ne l'avais pas beaucoup testé mais je suis toujours aussi intéressé et ce journal m'y fait rappeler, merci.
J'ai maintenant un autre laptop sous le coude, sur lequel je voulais en profiter pour retester quelques BSD et éventuellement nix/guix, j'imagine que je peux profiter de l'hyperviseur intégré à qubeos pour les tester en parallèle.
Qu'en est-il de wayland vis à vis de qubes-os ?
[^] # Re: Merci
Posté par Psychofox (Mastodon) . Évalué à 4.
Je viens de faire une recherche rapide wayland/qubes-os qui m'a amené vers une issue github mentionnant un autre projet, spectrum-os encore à un stage de développement qui à priori ne permet pas de fournir d'images d'installations mais qui reste très intéressant. Il utiliserait nix, kvm/libvirt, wayland pour tenter de répondre aux mêmes problématiques que qubes-os. C'est un projet supporté par NGI-zero donc avec support de l'union européenne.
[^] # Re: Merci
Posté par Psychofox (Mastodon) . Évalué à 3.
Je me réponds de nouveau à moi-même. Le financement via l'EU est à priori très limité et c'est pour l'instant un one woman effort. J'ai décidé de sponsoriser la dev par manque de possibilité de contribuer mais ce projet gagnerait à être popularisé pour y voir plus de contributeurs.
[^] # Re: Merci
Posté par palainp . Évalué à 0.
Le principal problème que tu vas rencontrer pour tester du BSD/windows/whatever c'est que sans les drivers spéciaux pour utiliser un mode PVH tu seras contraint d'utiliser un mode HVM (matériel virtualisé) ce qui est probablement malheureusement trop lent pour garder une bonne image de Qubes :)
[^] # Re: Merci
Posté par Psychofox (Mastodon) . Évalué à 3.
rassures-moi même sans faire du paravirtualisé l'hyperviseur Xen sait utiliser les extensions Intel VT non ?
[^] # Re: Merci
Posté par legranblon (site web personnel) . Évalué à 1.
Il y a déjà un bon bout de temps que j'ai tenté qubesos (pendant six mois peut-être, vers 2016/2017 si ma mémoire ne me fait pas défaut) et voulant tester du pci-passthrough j'avais lâché l'affaire avec qubes pour la facilité de centos dans ce domaine.
# Sinon il y a aussi ClipOS en version cocorico ;)
Posté par nekopep . Évalué à 6.
En équivalent ANSSI il y a aussi:
https://clip-os.org/fr/
Les projets CLIP OS et Qubes OS se ressemblent d’un point de vue objectifs fonctionnels mais diffèrent sur plusieurs points :
Le mécanisme principal d’isolation est différent :
Qubes OS utilise la virtualisation matérielle via un hyperviseur (Xen), ainsi qu’une machine virtuelle (dom0) comprenant un système GNU/Linux et des services chargés d’échanger avec d’autres machines virtuelles.
L’administrateur d’un système CLIP OS n’est pas en mesure de compromettre l’intégrité du système ni d’accéder aux données des utilisateurs. Il a à sa disposition uniquement un ensemble restreint d’options de configuration.
Pas encore eu le temps de tester mais les deux concepts me plaisent bien :)
[^] # Re: Sinon il y a aussi ClipOS en version cocorico ;)
Posté par abriotde (site web personnel, Mastodon) . Évalué à 3.
J avoue que j avais mis de côté CLIP OS car, venant du gouvernement français, je me méfiais. Mais il a l'air vraiment libre et assez intéressant d'un point de vue choix technique. Je trouve que CLIP OS est une bonne évolution de SubgraphOS.
QubesOS est sans doute plus sécurisé sur le fond mais j'aime pas le principe de mettre tout en VM c est une surcouche qui consomme.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# Bon j'ai sauté le pas...
Posté par Psychofox (Mastodon) . Évalué à 2.
…et le moins que l'on puisse dire c'est que le début est laborieux. J'ai installé la 4.1rc1.
Au premier démarrage je n'avais pas de réseau car la vm sys-net ne démarrait pas en raison d'un problème de PCI passthrough documenté ici. Bon ça a été résolu au final mais l'UI est mal fichu quand tu essaies de le faire via la gui ce qui fait perdre un temps inutile.
Je n'ai pour l'instant pas encore pu utiliser ma docking station display-link, à voir après un reboot. En voulant installer le driver evdi j'ai d'ailleurs pu me rendre compte que le dom0 tourne sous Fedora 25 qui n'est plus supportée depuis belle lurette. C'est un peu fâcheux pour une distrib qui veut s'orienter sécurité.
Sinon:
- XFCE, je l'ai utilisé dans le passé mais franchement je n'aime plus. À voir s'il y a des possibilités de customisation mais la config de base est à chier, lente à utiliser et anti-ergonomique avec son paradigme des années 90.
- tu changes le keymap du dom0, tu dois rebooter toutes les vms déjà démarrées pour en profiter. Chiant.
- copie de fichier entre vms et entre vm et dom0 hyper lourd à utiliser. Il ne faut pas en avoir besoin trop souvent.
- copier/coller entre vm et dom0 c'est aussi hyper lourd. Entre 2vms c'est 4 raccourcis claviers.
- je voulais voir un programme tv sur zattoo, impossible de lire la vidéo correctement. Pour l'instant je ne sais pas si c'est un problème de lenteur réseau, de firefox, de problème lié à l'usage de l'extension nordvpn pour firefox dans une vm ou autre…
Donc début poussif et peu engageant de prime abord même si le concept est intéressant.
[^] # Re: Bon j'ai sauté le pas...
Posté par palainp . Évalué à 1.
Quelques remarques (mais qui ne vont pas vraiment aller dans le bon sens pour toi je le crains :( ) :
- La version fc25 de dom0 n'est pas un soucis car dom0 n'est pas reliée aux autres VM (c'est comme vault qui ne sert en gros qu'à exécuter keepassxc), les mises à jour ne sont permises qu'avec les dépôt officiels, les hash sont systématiquement vérifiés, il y a le minimum de code qui s'exécute dedans et la copie vers dom0 est plutôt compliquée. Cependant c'est la fc32 qui sera utilisée pour la prochaine version 4.1. Toujours en 4.1, la GUI sera séparée de dom0 (pour limiter le nombre de processus tournant dans dom0) et il y aura peut-être plus de latitude dans le choix de l'interface.
- La mise à jour de keymap dans les AppVM est une issue qui est toujours en cours depuis un moment. Je ne change pas souvent de keymap dans les VM, par contre j'ai actuellement un bug que je n'ai pas pu creuser, quand j'attache un périphérique USB à une VM, celle-ce passe en keymap us au lieu de fr :(
- La copie de fichier était il y a longtemps possible en ligne de commande (
qvm-copy vm-name files) mais le fait de passer par une popup pour indiquer le nom de la vm destination est justement une fonctionnalité de sécurité, il n'est plus possible de le faire de manière transparente pour l'utilisateur, on est forcément conscient de l'action qu'on réalise.- C'est la même idée pour le presse-papier inter VM, le fait de ne pas avoir de tampon commun entre les VM (et de n'avoir que du texte quand on passe par le mécanisme géré par dom0) permet d'éviter de dégrader la sécurité d'une VM en ayant une copie d'item d'une VM moins sécuritaire. La encore ce passage d'une VM à une autre est forcément conscient (mais plus long à réaliser oui). Pour les copies d'écrans c'est encore pire tu vas voir, il faut sauver la copie dans dom0 puis la déplacer dans la VM souhaitée avec
{copy,move}-to-vm…- Là tu ne vas sans doute pas rire (voir supprimer tout le système), j'ai également des soucis de connexion avec un dock USB-C thunderbolt. Pour utiliser le port réseau inclus au dock, comme le dock est usb, je dois transférer le contrôle d'une partie du hub usb à sys-net pour gérer le réseau et je me retrouve avec le noyau qui considère que mon cable est de mauvaise qualité (j'ai pu creuser jusqu'à comprendre qu'en fait c'est un ack qui n'est pas renvoyé correctement). Pour le moment je ne m'en sert donc pas pour le réseau (pour l'affichage multiple ou recharger le portable cela ne pose pas de soucis).
Comme je le disais, c'est une utilisation très différente de mon usage d'un ordinateur quand j'avais encore une distribution classique (la séparation VMs travail et VMs perso est très marquée), et j'ai vraiment eu l'impression de rajeunir de 20 ans :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.