Il n'y a pas beaucoup d'articles sur Habr consacrés au système d'exploitation Qubes, et ceux que j'ai vus décrivent peu l'expérience d'utilisation. Dans cet article, j'espère remédier à cela en montrant l'utilisation de Qubes comme moyen de protection de l'environnement Windows et, en passant, évaluer le nombre d'utilisateurs russophones du système.
Pourquoi Qubes ?
L'achèvement du support technique de Windows 7 et l'anxiété croissante des utilisateurs ont conduit à la nécessité d'organiser le fonctionnement de cet OS, en tenant compte des exigences suivantes :
- assurer l'utilisation d'un Windows 7 entièrement activé avec la possibilité pour l'utilisateur d'installer des mises à jour et diverses applications (y compris via Internet) ;
- réaliser une exclusion complète ou sélective des interactions réseau selon une condition (modes de fonctionnement hors ligne et de filtrage du trafic) ;
- offrir la possibilité de connecter sélectivement des supports amovibles et des dispositifs.
Un tel ensemble de restrictions suppose un utilisateur clairement préparé, car l'auto-administration est autorisée et les restrictions ne sont pas liées à un blocage de ses actions potentielles, mais à l'exclusion possible d'erreurs ou d'impact destructif des logiciels. Autrement dit, il n'y a pas d'intrus interne dans le modèle.
À la recherche d'une solution, nous avons rapidement abandonné l'idée de mettre en œuvre des restrictions par des moyens intégrés ou supplémentaires de Windows, car il est assez difficile de limiter efficacement un utilisateur ayant des droits d'administrateur tout en lui permettant d'installer des applications.
La solution suivante était l'isolement via la virtualisation. Les outils bien connus pour la virtualisation de bureau (comme VirtualBox) sont mal adaptés aux problèmes de sécurité, et les restrictions mentionnées doivent être appliquées par l'utilisateur en configurant constamment ou en basculant les propriétés de la machine virtuelle (ci-après VMs), ce qui augmente le risque d'erreurs.
En même temps, nous avons eu l'expérience d'utiliser Qubes en tant que système de bureau pour les utilisateurs, mais des doutes subsistaient quant à la stabilité du travail avec Windows en tant qu'invité. Il a été décidé de tester la version actuelle de Qubes, car les restrictions imposées s'intègrent très bien dans la paradigm de ce système, en particulier la mise en œuvre de modèles de machines virtuelles et l'intégration visuelle. Je vais ensuite essayer de parler brièvement des idées et des outils de Qubes, en prenant pour exemple la solution du problème posé.
Types de virtualisation Xen
Au cœur de Qubes se trouve l'hyperviseur Xen, qui minimise les fonctions de gestion des ressources processeur, mémoire et machines virtuelles. Tout le reste du travail avec les dispositifs est concentré dans dom0 basé sur le noyau Linux (dans Qubes, la distribution Fedora est utilisée pour dom0).
Xen prend en charge plusieurs types de virtualisation (je donnerai des exemples pour l'architecture Intel, bien que Xen prenne également en charge d'autres) :
- virtualisation paravirtuelle (PV) — mode de virtualisation sans utilisation de prise en charge matérielle, rappelant la virtualisation par conteneurs, elle peut être utilisée pour des systèmes avec un noyau adapté (dom0 fonctionne dans ce mode) ;
- virtualisation complète (HVM) — dans ce mode, une prise en charge matérielle est utilisée pour les ressources processeur, et tout le reste du matériel est émulé par des moyens QEMU. C'est la manière la plus universelle de lancer différents systèmes d'exploitation ;
- virtualisation paravirtuelle de matériel (PVH — Hardware ParaVirtualisé) — mode de virtualisation utilisant une prise en charge matérielle où, pour travailler avec le matériel, le noyau du système invité utilise des pilotes adaptés aux capacités de l'hyperviseur (par exemple, la mémoire partagée), éliminant le besoin d'émulation QEMU et améliorant les performances d'entrée-sortie. Le noyau Linux à partir de la version 4.11 peut fonctionner dans ce mode.
À partir de la version 4.0 de Qubes, pour des raisons de sécurité, l'utilisation du mode de paravirtualisation est abandonnée (en raison des vulnérabilités connues de l'architecture Intel, qui sont partiellement abordées par l'utilisation de la virtualisation complète), le mode PVH est utilisé par défaut.
Lors de l'utilisation de l'émulation (mode HVM), le lancement de QEMU se fait dans une VM isolée appelée stubdomain, réduisant ainsi les risques d'exploitation de potentielles erreurs dans l'implémentation (le projet QEMU contient beaucoup de code, y compris pour la compatibilité).
Ce mode doit être utilisé pour Windows dans notre cas.
Machines virtuelles de service
Dans l'architecture de sécurité de Qubes, l'une des fonctionnalités clés de l'hyperviseur est le passage des périphériques PCI à l'environnement invité. L'exception de matériel permet d'isoler la partie hôte du système des attaques externes. Xen prend en charge cela pour les modes PV et HVM, dans ce dernier cas, cela nécessite le support de l'IOMMU (Intel VT-d) — gestion matérielle de la mémoire pour les dispositifs virtualisés.
Cela crée plusieurs machines virtuelles système :
- sys-net, à laquelle sont attribués les dispositifs réseau et qui est utilisée comme pont pour d'autres VM, par exemple, celles réalisant des fonctions de pare-feu ou de client VPN ;
- sys-usb, à laquelle sont attribués les contrôleurs USB et autres périphériques ;
- sys-firewall, qui ne utilise pas de dispositifs, mais fonctionne comme un pare-feu pour les VM connectées.
Pour travailler avec des dispositifs USB, des services proxy sont utilisés, qui assurent notamment :
- pour les dispositifs de classe HID (human interface device) la transmission de commandes vers dom0 ;
- pour les supports amovibles, le redirection des volumes de dispositifs vers d'autres VM (à l'exception de dom0) ;
- la redirection directe d'un dispositif USB (utilisation de USBIP et d'outils d'intégration).
Dans cette configuration, une attaque réussie via la pile réseau ou des dispositifs connectés peut compromettre uniquement la VM de service en cours d'exécution, et non l'ensemble du système. De plus, après le redémarrage de la VM de service, elle sera chargée dans son état d'origine.
Outils d'intégration VM
Il existe plusieurs façons d'interagir avec le bureau d'une machine virtuelle : installation d'applications dans le système invité ou émulation vidéo à l'aide de la virtualisation. Les applications invitées peuvent être divers outils d'accès à distance (RDP, VNC, Spice, etc.) ou adaptés à un hyperviseur spécifique (ces outils sont généralement appelés utilitaires invités). Un variant mixte peut également être utilisé, où l'hyperviseur émule l'entrée/sortie pour le système invité, tout en offrant la possibilité d'utiliser un protocole combinant l'entrée/sortie, comme c'est le cas avec Spice. Dans ce cas, les outils d'accès à distance optimisent généralement l'image, car ils supposent un travail à travers le réseau, ce qui affecte négativement la qualité de l'image.
Qubes fournit ses propres outils pour l'intégration des VM. Tout d'abord, cela concerne le sous-système graphique : les fenêtres provenant de différentes VM sont affichées sur un bureau unique avec un encadrement coloré propre. En général, les outils d'intégration reposent sur les capacités de l'hyperviseur : mémoire partagée (table de subventions Xen), mécanismes d'alerte (canal d'événements Xen), stockage partagé xenstore et protocole de communication vchan. Grâce à cela, les composants de base qrexec et qubes-rpc, ainsi que des services applicatifs — redirection audio ou USB, transfert de fichiers ou contenu du presse-papiers, exécution de commandes et lancement d'applications — sont réalisés. Il est possible d'établir des politiques pour restreindre les services disponibles sur la VM. Dans l'image ci-dessous, un exemple de procédure d'initialisation de l'interaction entre deux VM.
Ainsi, le travail dans la VM se fait sans utiliser le réseau, ce qui permet d'utiliser pleinement des VM autonomes pour éviter les fuites d'informations. Par exemple, cela permet de séparer les opérations cryptographiques (PGP/SSH), lorsque les clés privées sont utilisées dans des VM isolées et ne sortent pas de leurs limites.
Modèles, applications et VM jetables
Tout le travail de l'utilisateur dans Qubes s'effectue dans des machines virtuelles. Le système hôte principal est utilisé pour gérer leur fonctionnement et leur visualisation. Le système d'exploitation est installé avec un ensemble de machines virtuelles de base basé sur des modèles (TemplateVM). Un tel modèle est une VM Linux basée sur une distribution Fedora ou Debian, avec des outils d'intégration installés et configurés, ainsi que des partitions système et utilisateur dédiées. L'installation et la mise à jour des logiciels se font via le gestionnaire de paquets standard (dnf ou apt) à partir des dépôts configurés avec vérification obligatoire de la signature numérique (GnuPG). La fonction de ces VM est d'assurer la confiance envers les VM appliquées qui en dérivent.
La VM appliquée (AppVM) utilise au démarrage un instantané de la partition système du modèle de VM correspondant, et à la fin de son exécution, elle supprime cet instantané sans enregistrer les modifications. Les données nécessaires à l'utilisateur sont stockées dans une partition utilisateur unique pour chaque VM appliquée, qui est montée dans le répertoire personnel.
L'utilisation de VMs jetables (disposibleVM) peut être bénéfique en termes de sécurité. Cette VM est créée sur la base d'un modèle au moment du démarrage et est lancée dans un but unique : exécuter une application, et se termine après sa fermeture. Les VMs jetables peuvent être utilisées pour ouvrir des fichiers suspects, dont le contenu pourrait conduire à l'exploitation de vulnérabilités d'applications spécifiques. La possibilité de lancer une VM jetable est intégrée dans le gestionnaire de fichiers (Nautilus) et le client de messagerie (Thunderbird).
Une VM Windows peut également être utilisée pour créer un modèle et une VM jetable, pour cela le profil utilisateur est transféré dans une partition séparée. Dans notre scénario, ce modèle sera utilisé par l'utilisateur pour des tâches d'administration et d'installation d'applications. Sur la base du modèle, plusieurs VM appliquées seront créées — avec un accès réseau limité (les capacités standard de sys-firewall) et sans accès réseau du tout (aucun périphérique réseau virtuel n'est créé). Dans ces VMs, toutes les modifications et applications installées dans le modèle seront disponibles et même en cas d'introduction de logiciels malveillants, l'accès au réseau leur sera inaccessible pour compromettre.
La lutte pour Windows
Les fonctionnalités décrites ci-dessus constituent la base de Qubes et fonctionnent de manière assez stable ; les complications commencent avec Windows. L'intégration de Windows nécessite l'utilisation du kit d'outils invités Qubes Windows Tools (QWT), qui comprend des pilotes pour fonctionner avec Xen, un pilote qvideo et un ensemble d'utilitaires pour l'échange d'informations (transfert de fichiers, presse-papiers). Le processus d'installation et de configuration est documenté en détail sur le site du projet, donc nous partagerons notre expérience d'application.
La principale difficulté réside en réalité dans l'absence de support de l'outillage développé. Les développeurs clés (QWT) semblent inaccessibles et le projet d'intégration avec Windows est en attente d'un développeur principal. Il était donc crucial d'évaluer la fonctionnalité et de comprendre la possibilité de le supporter soi-même si nécessaire. Le driver graphique, qui émule l'adaptateur vidéo et l'écran pour générer une image dans la mémoire partagée, permettant d'afficher l'intégralité du bureau ou la fenêtre d'application dans la fenêtre du système hôte, est le plus difficile à développer et à déboguer. Au cours de l'analyse du fonctionnement du pilote, nous avons adapté le code pour la compilation dans un environnement Linux et avons élaboré un schéma de débogage entre deux systèmes Windows invités. Lors de la phase de cross-compilation, nous avons apporté quelques modifications simplificatrices principalement concernant l'installation « silencieuse » des utilitaires, et nous avons également éliminé une dégradation gênante des performances lors d'une utilisation prolongée dans la VM. Nous avons documenté les résultats de notre travail dans un document séparé. , tout en inspirant temporairement L'étape la plus critique en termes de stabilité du système invité est le démarrage de Windows, où l'on peut voir l'écran bleu familier (ou même ne rien voir). Pour la plupart des erreurs identifiées, diverses solutions de contournement ont été trouvées : abandon des pilotes Xen pour les disques, désactivation de l’équilibrage de la mémoire de la VM, fixation des paramètres réseau et minimisation du nombre de cœurs. Notre version des outils invités s'installe et fonctionne sur Windows 7 et Windows 10 entièrement mis à jour (à l'exception de qvideo).
L'étape la plus critique pour la stabilité du système hôte est le démarrage de Windows, où l'on peut voir un écran bleu familier (ou même ne pas le voir). Pour la plupart des erreurs identifiées, il existait diverses solutions de contournement : abandon des pilotes Xen pour les dispositifs de bloc, désactivation de l'équilibrage de la mémoire des machines virtuelles, fixation des paramètres réseau et minimisation du nombre de cœurs. Notre compilation d'outils hôtes s'installe et fonctionne sur Windows 7 et Windows 10 entièrement mis à jour (à l'exception de qvideo).
Lors du passage d'un environnement physique à un environnement virtuel, un problème d'activation de Windows se pose en cas d'utilisation de versions OEM préinstallées. Ces systèmes utilisent une activation basée sur des licences inscrites dans l'UEFI de l'appareil. Pour un fonctionnement correct de l'activation, il est nécessaire de transposer dans le système invité l'une des sections ACPI du système hôte dans son intégralité (table SLIC) et d'apporter quelques corrections, en spécifiant le fabricant. Xen permet de configurer le contenu des tables ACPI supplémentaires, mais sans modifier les principales. Une solution a été trouvée grâce à un patch d'un projet similaire, OpenXT, qui a été adapté pour Qubes. Les corrections se sont avérées utiles non seulement pour nous et ont été intégrées dans le dépôt principal de Qubes et la bibliothèque Libvirt.
Parmi les inconvénients évidents des outils d'intégration de Windows, on peut citer l'absence de prise en charge du son, des périphériques USB et la difficulté de travailler avec des médias, car il n'y a pas de prise en charge matérielle du GPU. Cependant, cela n'empêche pas l'utilisation de VM pour le traitement de documents bureautiques et ne fait pas obstacle au lancement d'applications d'entreprise spécifiques.
L'exigence de passer en mode hors réseau ou avec une connexion limitée après la création d'un modèle de VM Windows a été satisfaite en créant les configurations appropriées pour les VM applicatives, tandis que la possibilité de connexion sélective de périphériques amovibles a également été résolue avec les moyens natifs du système d'exploitation : lors de la connexion, ils sont accessibles dans la VM système sys-usb, d'où ils peuvent être "transmis" à la VM requise. Le bureau de l'utilisateur ressemble à peu près à ceci.
La version finale du système a été acceptée positivement par les utilisateurs (dans la mesure où une solution aussi complexe le permet), et les outils natifs du système ont permis d'étendre l'utilisation à un poste de travail mobile avec accès via VPN.
En conclusion
La virtualisation en général permet de réduire les risques liés à l'utilisation de systèmes Windows laissés sans support — elle n'impose pas de compatibilité avec de nouveaux matériels, permet d'exclure ou de contrôler l'accès au système via le réseau ou des périphériques connectés, et permet de créer un environnement pour un lancement unique.
Le système d'exploitation Qubes, basé sur l'idée d'isolation via la virtualisation, aide à exploiter ces mécanismes et d'autres pour garantir la sécurité. De l'extérieur, beaucoup considèrent Qubes avant tout comme une quête d'anonymat, mais c'est un système utile tant pour les ingénieurs souvent impliqués dans des projets, des infrastructures et des secrets d'accès, que pour les chercheurs en sécurité. La séparation des applications, des données et la formalisation de leurs interactions sont les premières étapes de l'analyse des menaces et de la conception d'un système de protection. Cette séparation aide à structurer l'information et à réduire la probabilité d'erreurs dues à des facteurs humains tels que la précipitation, la fatigue, etc.
Actuellement, l'accent est mis sur l'expansion des fonctionnalités des environnements Linux. Une version 4.1 est en préparation, qui sera basée sur Fedora 31 et inclura les versions actuelles des composants clés Xen et Libvirt. Il convient de noter que Qubes est développé par des professionnels de la sécurité de l'information, qui publient rapidement des mises à jour dès qu'une nouvelle menace ou un bug est identifié.
Postface
Une des fonctionnalités expérimentales que nous développons permet de créer des machines virtuelles avec un accès invité au GPU grâce à la technologie Intel GVT-g, ce qui permet de tirer parti des capacités du processeur graphique et d'élargir considérablement le champ d'application du système. Au moment de la rédaction de cet article, cette fonctionnalité est opérationnelle pour les versions de test de Qubes 4.1 et est disponible sur .
Source : habr.com
