Joanna Rutkowska, chef du projet Qubes, fait un excellent travail en documentant les concepts sur lesquels Qubes s'appuie. Je vous conseille donc vivement de vous renseigner à la source, et notamment de lire les deux documents suivants :
- Compartimentation logicielle contre séparation physique (ou pourquoi Qubes OS est plus qu'une simple collection aléatoire de VM)
- En quoi QUbes OS est-il différent de...
Qubes apporte non seulement une amélioration de l'expérience utilisateur par rapport à l'exécution de plusieurs instances vmWare, mais il apporte également une isolation plus fine.
Pour l'expliquer grossièrement, le modèle que vous décrivez revient à placer un ensemble de petites boîtes (les machines virtuelles) dans une seule grande boîte (le système hôte). Toutes les VM passeront par le système hôte pour accéder à n'importe quel appareil (réseau, USB, lecteur de DVD, etc.), et le système hôte contrôle à la fois les VM, les appareils, l'interface utilisateur et fait directement face à Internet.
L'idée derrière Qubes n'est pas de stocker les petites boîtes dans une grande boîte surpuissante, mais plutôt de configurer les petites boîtes dans une sorte de réseau local virtuel afin qu'ensemble, elles regardent comme une grosse boîte sans en être une et sans en utiliser une.
Le besoin de regarder comme quelque chose que les utilisateurs savent déjà est important pour l'adoption de l'utilisateur. Mais derrière la scène, toutes les parties du système sont censées être isolées les unes des autres. Parmi les principales différences, il y a le fait que l'interface utilisateur n'est pas face au réseau et n'a pas de connexion Internet. La VM dédiée à faire face au réseau est isolée du reste des VM par une autre VM dédiée au firewalling. Qubes 3.0 a apporté une fonctionnalité tant attendue permettant d'avoir une VM dédiée aux périphériques USB.
Pour voir cela du point de vue de l'attaquant :
-
Si je veux pirater votre solution basée sur Windows, tout ce que j'ai à faire est de réussir à exploiter votre hôte Windows (point de défaillance unique). Une fois que je l'obtiens, je mets tout sous tension et cela devrait être relativement facile car il fait face au réseau, ce qui permet un large éventail de possibilités, des exploits à distance aux chevaux de Troie inversés.
-
Si je veux pirater Qubes, je n'aurai pas d'autre choix que de commencer en tant qu'invité puisque ni Xen ni le domaine principal Dom0 n'ont de lien direct avec le monde extérieur, et à partir de là, trouver un moyen de migrer d'invité à invité ou de réussir à exploiter le noyau Xen ou accéder à l'interface utilisateur s'exécutant dans Dom0 (sachant que les invités voient leur serveur X remplacé par un serveur d'affichage renforcé spécialement conçu pour éviter précisément une telle possibilité. Toutes les communications inter-VM en général ont été soigneusement conçues pour réduire toute zone d'exposition au minimum), et construisez les tunnels appropriés afin de pouvoir toujours communiquer avec vos logiciels malveillants (entrer n'est pas suffisant, vous voulez aussi que les données puissent sortir, ce qui est trivial sur un système en réseau, mais beaucoup plus difficile sur les systèmes invités isolés).
Je veux juste ajouter que si Qubes OS est le plus connu et le plus documenté comme étant, à ma connaissance, la seule initiative open source mettant en œuvre ce concept, le concept lui-même n'est pas quelque chose de complètement nouveau et révolutionnaire. Polyxene, par exemple, est un système propriétaire adoptant exactement la même approche afin de sécuriser les systèmes de bureau de niveau défense. Je dis cela juste pour souligner le fait que discuter de cette technologie va au-delà de la discussion des systèmes d'exploitation open source et propriétaires.