Qubes : environnement de travail Xen sécurisé

Posté par (page perso) . Modéré par Xavier Teyssier.
15
7
avr.
2010
Sécurité
InvisibleThings et plus précisément Joanna Rutkowska, chercheuse polonaise en sécurité, vient d'annoncer Qubes, un environnement Xen de travail sécurisé. J. Rutkowska a publié de nombreuses attaques (avec leur implémentation) sur Xen, la virtualisation matérielle ou plus récemment TrueCrypt.

L'objectif du projet est de fournir un environnement sécurisé par isolation (une VM pour le travail, une pour le surf, une pour le surf sécurisé etc) tout en fournissant les fonctionnalités nécessaires à sa réelle exploitation au quotidien. La mise en oeuvre de la sécurité par isolation s'accompagne des concepts suivants afin de garantir utilisabilité et sécurité :
  • Isolation dans trois VM dédiées et non privilégiées des fonctions de stockage, de réseau et de GUI/administration de la solution ;
  • Partage en lecture seule entre toutes les VM du système de fichiers root (/boot, /usr et /bin) ;
  • Mécanisme de partage de fichiers sécurisé ;
  • Mécanisme de copier/coller inter VM sécurisé. Toutes les opérations sont déclenchées depuis Dom0 par l'utilisateur.


Le document d'architecture est très détaillé et est vraiment centré sur la sécurité de la solution.

Cette initiative, menée par des chercheurs indépendants et plutôt pointus (euphémisme !), est vraiment à tester car il s'agit d'une implémentation (et non une preuve de concept) entièrement centrée sur la sécurité et son utilisabilité.
  • # offline

    Posté par . Évalué à 1.

    Pour ceux qui attendent comme moi :
    posted by joanna at Wednesday, April 07, 2010
    Update 7-Apr-2010 18:28 CEST: The server has been brought offline for RAM upgrade. Should be back online in some 15 minutes...

    Il est bien up mais semble être encore dans un état critique...
    • [^] # Intérêt

      Posté par . Évalué à 4.

      je vois bien l'intérêt de la virtualisation pour des serveurs en terme de sécurité mais surtout de disponibilité.

      Pour un poste de travail, vu le nombre de personnes qui ont du mal à maintenir un seul OS, alors 3 VM ? Pourquoi vouloir déporter la sécurité de l'OS derrière une solution de virtualisation ? Ça rend pas plus sûr l'OS de base...
      • [^] # Re: Intérêt

        Posté par . Évalué à 4.

        J'ai lu le papier en diagonal uniquement mais grosso modo, l'argument c'est l'isolation.

        Une faille dû au code d'un driver, dans la VM qui s'occupe du réseau, ne compromet qu'elle.

        Le dom0 est le seul chef d'orchestre entre les VM et le nombre de programmes et drivers qui y tourne est très réduit, justement pour diminuer la surface d'attaque.
      • [^] # Re: Intérêt

        Posté par (page perso) . Évalué à 2.

        pourquoi déporter la sécurité de l'OS derrière une solution de virtualisation

        Ce n'est pas vraiment l'objet.

        On cherche à se prémunir aussi des bugs dans les applications et pas uniquement de l'OS.

        On peut ainsi compartimenter son environnement en contextes plus ou moins sécurisés avec des données plus ou moins sensibles.

        Par exemple, surfer dans une VMx n'expose pas les données sensibles de la VMy.
        • [^] # Re: Intérêt

          Posté par . Évalué à 0.

          On peut ainsi compartimenter son environnement en contextes plus ou moins sécurisés avec des données plus ou moins sensibles.

          Par exemple, surfer dans une VMx n'expose pas les données sensibles de la VMy.


          Pour un serveur mais pour un poste de travail normal, je vois pas trop. Beaucoup de choses sont déjà chiantes au niveau de la gestion mais si je dois en plus compartimenter mes données pour chaque VM. De plus on ne fait que rajouter couches sur couches (il y a bien quelqu'un qui va me répondre qu'on en est plus à une près, m'enfin..).

          Ce business n'est pas sans rappeler les antivirus : une pauvre solution pour pallier une mauvaise sécurité de l'OS. Et là, on nous la virtualisation pour pallier à une appli qui peut planter tout le système. Où va t'on...

          A part enfin trouver une bonne raison au 10.000 coeurs / processeur avec instructions de la mort dédiées à la virtualisation.
          • [^] # Re: Intérêt

            Posté par . Évalué à 2.

            Le but est pas de pallier a une appli qui peut planter tout le systeme, le but est d'empecher qu'une faille de securite dans une appli permette de s'approprier tout ton compte utilisateur avec ses donnees, etc...

            Je suis bien d'accord que c'est un peu lourd comme solution, mais c'est efficace.
          • [^] # Re: Intérêt

            Posté par . Évalué à 1.

            Perso je vois pas d'intérêt encore à ce stade pour ma pauvre utilisation, mais peut être dans des organisations qui ont des choses à cacher ou sont la cible d'attaques (armée, labo de recherche, etc...), ça peut se révéler efficace.

            C'est un peu invasif mais pas tant que ça, à priori, puisque tout est sur le même bureau. On peut quand même individualiser des contexte de travail distinct dans un cadre professionnel.
            • [^] # Re: Intérêt

              Posté par (page perso) . Évalué à 3.

              ça a aussi l'air d'être limité aux ordis qui ont un CPU Intel qui va bien (Trusted eXecution Technology + VT-d)
              ça limite quand même pas mal....
  • # Bravo ! \o/

    Posté par . Évalué à 5.

    J'ai parcouru le site web.
    La "Faq" est très explicite (pour qui comprend de quoi on parle, quand même).
    Le PDF est très soigné.
    Je note que le projet est basé sur Fedora 12.

    Je suis rentré dans le code vite fait :
    - c'est en GPL V2 (dans le fichier LICENCE) et V2 et + si affinité dans des en-têtes de code que j'ai parcourus ;
    - 2,3 Mo de fichiers (moins 1,5 Mo d'icones) ;
    - Python 2.6, du C et du script shell ;

    Je le trouve un peu léger au niveau commentaire. J'ai regardé particulièrement "core/dom0/qvm-core/qubes.py". Surprise : pas de descriptif en tête du fichier python, mais 1 à 4 lignes en tête de chaque classe (enfin dans 90 % des cas) et des commentaires qui émaillent les blocs fonctionnels (mais pas de façon systématique). Le code me semble tout de même assez explicite de lui-même vu les noms de fonctions.

    Vous pouvez y aller pour Zino. Inspiration libre à partir de cette approche :o)
  • # fenêtres

    Posté par (page perso) . Évalué à 2.

    Ca semble intéressant tout ça, surtout d'un point de vue intégration des diverses fenêtres provenant de plusieurs vm, dans un même bureau.
    D'ailleurs, quelqu'un sait comment ça fonctionne ? Pour chaque programme on fait un export display depuis la vm vers le serveur du dom0 ?

    Dans tous les cas c'est un truc que je trouve pas mal, en général je travail avec 2 vm sur mon poste et plusieurs depuis un esx (oui pas libre...). Le but pour moi est essentiellement la séparation des environnements, avoir différents environnements de tests, de dev, etc et ne pas polluer l'un avec les dépendances de l'autre. De la même manière mes mails ne sont en général pas sur la même vm que les applis de dev, machine qui n'est en général pas propre très longtemps.
    Evidemment ça demande un ordi suffisamment puissant, mais avec un core2duo à 2.5Ghz et 4Go de ram, j'ai 2 vm qui tournent sans problème + des softs en local (en incluant 2 eclipses)

    Je trouve que se projet est pas mal surtout pour la partie intégration et transparence des vm, on a finalement les avantages du découpage avec peu d'inconvénients (hors perfs graphiques...)

Suivre le flux des commentaires

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