Il n'y a pas beaucoup d'articles sur Habré consacrés au système d'exploitation Qubes, et ceux que j'ai vus ne décrivent pas beaucoup l'expérience de son utilisation. En dessous de la coupe, j'espère corriger cela en utilisant l'exemple de l'utilisation de Qubes comme moyen de protection (contre) l'environnement Windows et, en même temps, estimer le nombre d'utilisateurs russophones du système.
Pourquoi Qubes ?
L'histoire de la fin du support technique de Windows 7 et l'anxiété croissante des utilisateurs ont conduit à la nécessité d'organiser le travail de cet OS, en tenant compte des exigences suivantes :
- assurer l'utilisation de Windows 7 entièrement activé avec la possibilité pour l'utilisateur d'installer des mises à jour et diverses applications (y compris via Internet) ;
- mettre en œuvre une exclusion complète ou sélective des interactions réseau en fonction de conditions (modes de fonctionnement autonome et de filtrage du trafic) ;
- offrent la possibilité de connecter sélectivement des supports et des périphériques amovibles.
Cet ensemble de restrictions présuppose un utilisateur clairement préparé, puisqu'une administration indépendante est autorisée, et les restrictions ne sont pas liées au blocage de ses actions potentielles, mais à l'exclusion d'éventuelles erreurs ou effets logiciels destructeurs. Ceux. Il n’y a pas de délinquant interne dans le modèle.
Dans notre recherche d'une solution, nous avons rapidement abandonné l'idée de mettre en œuvre des restrictions à l'aide d'outils Windows intégrés ou supplémentaires, car il est assez difficile de restreindre efficacement un utilisateur disposant de droits d'administrateur, lui laissant la possibilité d'installer des applications.
La solution suivante était l'isolement grâce à la virtualisation. Les outils bien connus pour la virtualisation des postes de travail (par exemple, tels que VirtualBox) sont mal adaptés pour résoudre les problèmes de sécurité et les restrictions répertoriées devront être appliquées par l'utilisateur en changeant ou en ajustant constamment les propriétés de la machine virtuelle invitée (ci-après dénommée comme VM), ce qui augmente le risque d’erreurs.
Dans le même temps, nous avions l'expérience de l'utilisation de Qubes comme système de bureau utilisateur, mais nous avions des doutes quant à la stabilité du travail avec Windows invité. Il a été décidé de vérifier la version actuelle de Qubes, car les limitations indiquées s'intègrent très bien dans le paradigme de ce système, notamment la mise en œuvre de modèles de machines virtuelles et l'intégration visuelle. Ensuite, j'essaierai de parler brièvement des idées et des outils de Qubes, en utilisant l'exemple de la résolution du problème.
Types de virtualisation Xen
Qubes est basé sur l'hyperviseur Xen, qui minimise les fonctions de gestion des ressources processeur, de la mémoire et des machines virtuelles. Tous les autres travaux avec les appareils sont concentrés dans dom0 basé sur le noyau Linux (Qubes pour dom0 utilise la distribution Fedora).
Xen prend en charge plusieurs types de virtualisation (je vais donner des exemples pour l'architecture Intel, bien que Xen en prenne en charge d'autres) :
- paravirtualisation (PV) - un mode de virtualisation sans recours à un support matériel, rappelant la virtualisation de conteneurs, peut être utilisé pour les systèmes dotés d'un noyau adapté (dom0 fonctionne dans ce mode) ;
- virtualisation complète (HVM) - dans ce mode, la prise en charge matérielle est utilisée pour les ressources du processeur et tous les autres équipements sont émulés à l'aide de QEMU. Il s'agit du moyen le plus universel d'exécuter divers systèmes d'exploitation ;
- paravirtualisation du matériel (PVH - ParaVirtualized Hardware) - un mode de virtualisation utilisant le support matériel lorsque, 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, mémoire partagée), éliminant le besoin d'émulation QEMU et augmenter les performances d'E/S. Le noyau Linux à partir de la version 4.11 peut fonctionner dans ce mode.
A partir de la version Qubes 4.0, pour des raisons de sécurité, l'utilisation du mode paravirtualisation est abandonnée (notamment en raison de vulnérabilités connues de l'architecture Intel, qui sont partiellement atténué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), QEMU est lancé dans une VM isolée appelée stubdomain, réduisant ainsi les risques d'exploitation d'erreurs potentielles dans l'implémentation (le projet QEMU contient beaucoup de code, notamment pour la compatibilité).
Dans notre cas, ce mode doit être utilisé pour Windows.
Machines virtuelles de service
Dans l'architecture de sécurité Qubes, l'une des fonctionnalités clés de l'hyperviseur est le transfert de périphériques PCI vers l'environnement invité. L'exclusion matérielle vous 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 le second cas, il nécessite la prise en charge d'IOMMU (Intel VT-d) - gestion de la mémoire matérielle pour les appareils virtualisés.
Cela crée plusieurs machines virtuelles système :
- sys-net, vers lequel les périphériques réseau sont transférés et qui sert de pont pour d'autres VM, par exemple celles qui implémentent les fonctions d'un pare-feu ou d'un client VPN ;
- sys-usb, vers lequel les contrôleurs USB et autres périphériques sont transférés ;
- sys-firewall, qui n'utilise pas de périphériques, mais fonctionne comme un pare-feu pour les machines virtuelles connectées.
Pour travailler avec des périphériques USB, des services proxy sont utilisés, qui fournissent, entre autres :
- pour la classe de périphériques HID (dispositif d'interface humaine), envoi de commandes à dom0 ;
- pour les supports amovibles, redirection des volumes des périphériques vers d'autres VM (sauf dom0) ;
- redirection directement vers un périphérique USB (à l'aide d'USBIP et d'outils d'intégration).
Dans une telle configuration, une attaque réussie via la pile réseau ou les appareils connectés peut conduire à la compromission uniquement de la VM de service en cours d'exécution, et non de l'ensemble du système dans son ensemble. Et après avoir redémarré la VM du service, elle sera chargée dans son état d'origine.
Outils d'intégration de machines virtuelles
Il existe plusieurs façons d'interagir avec le bureau d'une machine virtuelle : installer des applications dans le système invité ou émuler une vidéo à l'aide d'outils de virtualisation. Les applications invitées peuvent être divers outils d'accès à distance universels (RDP, VNC, Spice, etc.) ou adaptées à un hyperviseur spécifique (ces outils sont généralement appelés utilitaires invités). Une option mixte peut également être utilisée, lorsque l'hyperviseur émule les E/S pour le système invité et offre en externe la possibilité d'utiliser un protocole qui combine les E/S, par exemple, comme Spice. Dans le même temps, les outils d'accès à distance optimisent généralement l'image, car ils impliquent de travailler via un réseau, ce qui n'a pas d'effet positif sur la qualité de l'image.
Qubes fournit ses propres outils pour l'intégration de VM. Tout d'abord, il s'agit d'un sous-système graphique : les fenêtres de différentes machines virtuelles sont affichées sur un seul bureau avec leur propre cadre de couleur. En général, les outils d'intégration sont basés sur les capacités de l'hyperviseur - mémoire partagée (table de subvention Xen), outils de notification (canal d'événements Xen), stockage partagé xenstore et protocole de communication vchan. Avec leur aide, les composants de base qrexec et qubes-rpc, ainsi que les services d'application sont implémentés - redirection audio ou USB, transfert de fichiers ou du contenu du presse-papiers, exécution de commandes et lancement d'applications. Il est possible de définir des politiques qui vous permettent de limiter les services disponibles sur une VM. La figure ci-dessous est un exemple de la procédure d'initialisation de l'interaction de deux VM.
Ainsi, le travail dans la VM s'effectue sans utiliser de réseau, ce qui permet d'utiliser pleinement les VM autonomes pour éviter les fuites d'informations. C’est par exemple ainsi qu’est mise en œuvre la séparation des opérations cryptographiques (PGP/SSH), lorsque les clés privées sont utilisées dans des VM isolées et ne les dépassent pas.
Modèles, applications et machines virtuelles uniques
Tout le travail des utilisateurs dans Qubes est effectué sur des machines virtuelles. Le système hôte principal est utilisé pour les contrôler et les visualiser. Le système d'exploitation est installé avec un ensemble de base de machines virtuelles basées sur des modèles (TemplateVM). Ce modèle est une machine virtuelle Linux basée sur la 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 sont effectuées par un gestionnaire de packages standard (dnf ou apt) à partir de référentiels configurés avec vérification obligatoire de la signature numérique (GnuPG). Le but de ces VM est d'assurer la confiance dans les VM d'application lancées sur leur base.
Au démarrage, une VM d'application (AppVM) utilise un instantané de la partition système du modèle de VM correspondant et, une fois terminé, supprime cet instantané sans enregistrer les modifications. Les données requises par l'utilisateur sont stockées dans une partition utilisateur unique pour chaque VM d'application, qui est montée dans le répertoire personnel.
Utiliser des VM jetables (disposableVM) peut être utile d’un point de vue sécurité. Une telle VM est créée sur la base d'un modèle au moment du démarrage et est lancée dans un seul but : exécuter une application, en terminant le travail après sa fermeture. Les machines virtuelles jetables peuvent être utilisées pour ouvrir des fichiers suspects dont le contenu pourrait conduire à l'exploitation de vulnérabilités spécifiques d'applications. La possibilité d'exécuter une VM unique est intégrée au gestionnaire de fichiers (Nautilus) et au client de messagerie (Thunderbird).
La VM Windows peut également être utilisée pour créer un modèle et une VM unique en déplaçant le profil utilisateur vers une section distincte. Dans notre version, un tel modèle sera utilisé par l'utilisateur pour les tâches d'administration et l'installation des applications. Sur la base du modèle, plusieurs machines virtuelles d'application seront créées - avec un accès limité au réseau (capacités de pare-feu système standard) et sans accès au réseau du tout (un périphérique réseau virtuel n'est pas créé). Toutes les modifications et applications installées dans le modèle seront disponibles pour fonctionner sur ces machines virtuelles, et même si des programmes de favoris sont introduits, ils n'auront pas d'accès au réseau en cas de compromission.
Combattez pour Windows
Les fonctionnalités décrites ci-dessus sont la base de Qubes et fonctionnent de manière assez stable ; les difficultés commencent avec Windows. Pour intégrer Windows, vous devez utiliser un ensemble d'outils invités Qubes Windows Tools (QWT), qui comprend des pilotes pour travailler 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 Web du projet, nous partagerons donc notre expérience d'application.
La principale difficulté réside essentiellement dans le manque de support des outils développés. Les développeurs clés (QWT) semblent indisponibles et le projet d'intégration Windows attend un développeur principal. Par conséquent, il était tout d’abord nécessaire d’évaluer ses performances et de comprendre la possibilité de le soutenir de manière indépendante, si nécessaire. Le plus difficile à développer et à déboguer est le pilote graphique, qui émule la carte vidéo et l'affichage pour générer une image en mémoire partagée, vous permettant d'afficher l'intégralité du bureau ou la fenêtre de l'application directement dans la fenêtre du système hôte. Lors de l'analyse du fonctionnement du pilote, nous avons adapté le code pour l'assemblage dans un environnement Linux et élaboré un schéma de débogage entre deux systèmes invités Windows. Au stade du crossbuild, nous avons apporté plusieurs changements qui ont simplifié les choses pour nous, principalement en termes d'installation « silencieuse » des utilitaires, et ont également éliminé la dégradation gênante des performances lorsque l'on travaille longtemps dans une VM. Nous avons présenté les résultats des travaux dans un document séparé , donc pas pour longtemps Développeur principal Qubes.
L'étape la plus critique en termes de stabilité du système invité est le démarrage de Windows, ici vous pouvez voir l'écran bleu familier (ou même ne pas le voir). Pour la plupart des erreurs identifiées, il existait diverses solutions de contournement : éliminer les pilotes de périphérique de bloc Xen, désactiver l'équilibrage de la mémoire de la machine virtuelle, corriger les paramètres réseau et minimiser le nombre de cœurs. Nos outils invités s'installent et fonctionnent sur Windows 7 et Windows 10 entièrement mis à jour (sauf qvideo).
Lors du passage d'un environnement réel à un environnement virtuel, un problème survient lors de l'activation de Windows si des versions OEM préinstallées sont utilisées. Ces systèmes utilisent une activation basée sur les licences spécifiées dans l’UEFI de l’appareil. Pour traiter correctement l'activation, il est nécessaire de traduire l'une des sections ACPI entières du système hôte (table SLIC) vers le système invité et de modifier légèrement les autres, en enregistrant le fabricant. Xen permet de personnaliser le contenu ACPI des tables supplémentaires, mais sans modifier les principales. Un correctif d'un projet OpenXT similaire, adapté pour Qubes, a aidé à la solution. Les correctifs ne nous ont pas seulement semblé utiles et ont été traduits dans le référentiel principal Qubes et la bibliothèque Libvirt.
Les inconvénients évidents des outils d'intégration Windows incluent le manque de prise en charge de l'audio, des périphériques USB et la complexité du travail avec les médias, car il n'y a pas de prise en charge matérielle pour le GPU. Mais ce qui précède n'empêche pas l'utilisation de la VM pour travailler avec des documents bureautiques, ni le lancement d'applications d'entreprise spécifiques.
L'exigence de passer en mode de fonctionnement sans réseau ou avec un réseau limité après la création d'un modèle de machine virtuelle Windows a été remplie en créant les configurations appropriées des machines virtuelles d'application, et la possibilité de connecter sélectivement des supports amovibles a également été résolue par les outils standard du système d'exploitation - une fois connectés , ils sont disponibles dans la VM système sys-usb, d'où ils peuvent être "transférés" vers la VM requise. Le bureau de l'utilisateur ressemble à ceci.
La version finale du système a été positivement (dans la mesure où une solution aussi complète le permet) acceptée par les utilisateurs, et les outils standards du système ont permis d'étendre l'application au poste de travail mobile de l'utilisateur avec accès via VPN.
Au lieu d'une conclusion
La virtualisation en général vous permet de réduire les risques liés à l'utilisation de systèmes Windows laissés sans support - elle n'impose pas la compatibilité avec le nouveau matériel, elle vous permet d'exclure ou de contrôler l'accès au système via le réseau ou via des appareils connectés, et elle vous permet de mettre en œuvre un environnement de lancement unique.
Basé sur l'idée d'isolement grâce à la virtualisation, Qubes OS vous aide à exploiter ces mécanismes et d'autres pour la sécurité. De l’extérieur, beaucoup voient Qubes avant tout comme une volonté d’anonymat, mais c’est un système utile aussi bien pour les ingénieurs, qui jonglent souvent entre projets, infrastructures et secrets pour y accéder, que pour les chercheurs en sécurité. La séparation des applications, des données et la formalisation de leur interaction sont les premières étapes de l'analyse des menaces et de la conception du système de sécurité. Cette séparation permet de structurer l'information et de réduire le risque d'erreurs dues au facteur humain - précipitation, fatigue, etc.
Actuellement, l'accent principal du développement est mis sur l'extension des fonctionnalités des environnements Linux. La version 4.1 est en cours de préparation, elle 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 créé par des professionnels de la sécurité de l'information qui publient toujours rapidement des mises à jour si de nouvelles menaces ou erreurs sont identifiées.
Postface
L'une des capacités expérimentales que nous développons nous permet de créer des machines virtuelles prenant en charge l'accès invité au GPU basé sur la technologie Intel GVT-g, ce qui nous permet d'utiliser les capacités de l'adaptateur graphique et d'étendre considérablement la portée du système. Au moment de la rédaction, cette fonctionnalité fonctionne pour les versions de test de Qubes 4.1 et est disponible sur .
Source: habr.com