pascals.blog : Hyper-V

Migration d’Hyper-V vers 2008 R2, et problèmes de carte réseau sur les VM Linux

pascals — Thu, 08 Oct 2009 14:45:04 GMT

J’ai finalement migré mon serveur Hyper-V, de Windows Server 2008 à Windows Server 2008 R2, pour tomber sur un problème délicat avec des machines virtuelles Linux et la disparition de leur carte réseau.

Je n’ai pas forcément pris le chemin habituel. Certains auraient simplement mis à jour le système après avoir pris soin d’arrêter les machines virtuelles. D’autres auraient exporté les VM, réinstallé le système, puis réimporté les VM. Personnellement aucune de ces deux solutions ne me convenait : je suis réticent aux upgrades de systèmes, préférant repartir à chaque fois sur une installation “propre”. Et le mécanisme d’export/import de VM change la structure de stockage des fichiers sur le disque, ce qui ne me convient pas non plus. A tord !

Bien évidemment, les problèmes que j’ai rencontrés ne me seraient pas arrivés si j’avais suivi l’une ou l’autre des solutions “normales”. J’ai donc procédé comme ceci (ce que je ne recommande donc pas si vous êtes pressé) :

Vérifier qu’aucune VM n’a de snapshot.
Eteindre toutes les VM.
Note : dans ma configuration, le système est sur un disque, les VHD sur un autre, et les sauvegardes sur un troisième.
Sauvegarder les VHD –à noter que ce sont les seuls fichiers que je conserve dans la manipulation, car j’ai l’intention de définir les nouvelles machines virtuelles avec ces mêmes VHD.
Noter la définition des VM et des réseaux virtuels.
Installer Windows Server 2008 R2 comme une nouvelle installation (en supprimant la partition existante sur le disque réservé au système). Installer les mises à jour, les comptes utilisateurs, l’adresse IP, etc.
Activer le rôle Hyper-V et utiliser le script HVremote pour mettre en place l’administration à distance.

A ce stade, j’ai donc un système 2008 R2 propre sur le disque système, Hyper-V opérationnel, et mes fichiers VHD d’origine sur le disque d’origine qui leur était dédié.

Réinitialiser les ACL sur tous les fichiers VHD (icacls *.vhd /reset), ceci principalement par souci de détail. Voir ici pour une explication des ACL qu’Hyper-V ajoute sur les VHD. Nettoyer les ACL des permissions laissées par un ancien Hyper-V n’est pas obligatoire, mais c’est une bonne idée, lorsque l’on réutilise un disque sur un nouveau système, de faire le ménage sur les ACL.
Créer les réseaux virtuels tels qu’ils existaient auparavant.
Créer chaque VM avec la même configuration qu’auparavant : mémoire, carte réseau (normale ou legacy selon les cas), VHD... Au passage, Hyper-V 2008 R2 inclut par défaut un contrôleur SCSI dans chaque nouvelle VM : on peut le supprimer si la VM n’en avait pas auparavant.

Jusqu’ici tout va bien, il ne reste plus qu’à démarrer les VM.

Premier déboire : un Windows XP nécessite une réactivation, à cause du changement de matériel. Puis, après mise à jour des composants d’intégration, la carte réseau est vue comme une nouvelle carte, paramétrée par défaut en DHCP. Si une adresse fixe est nécessaire, il faut la redéfinir, ce qui produit un avertissement classique :

Ce qui aurait dû me mettre la puce à l’oreille pour le problème des machines Linux...

Venons-en donc à une machine virtuelle Linux, plus exactement un Debian 4.0 (etch). L’erreur est immédiatement visible au boot :

et à la commande ifconfig :

Plus de carte réseau... alors que la commande dmesg montre que le driver Tulip (la carte Legacy network adapter n’a pas changé entre les versions d’Hyper-V) est bien chargé et reconnait bien la carte et sa nouvelle adresse MAC :

Après quelques recherches et essais divers, il s’avère que la nouvelle carte est bien présente, mais le noyau l’a nommé eth1 au lieu de eth0 :

Pour remettre les choses en place, trois solutions sont possibles :

Première possibilité, dans le fichier /etc/network/interfaces, remplacer eth0 par eth1. C’est le plus simple, le plus rapide.

Deuxième possibilité, si l’on souhaite appeler eth0 la nouvelle carte, il faut savoir que Linux maintient une correspondance entre les adresses MAC et les noms d’interfaces. Ce fichier se trouve dans /etc/udev/rules.d. Sur un de mes systèmes il s’appelle 70-persistent-net.rules, sur un autre : z25-persistent-net.rules. La règle semble être que le fichier s’appelle <préfixe>-persistent-net.rules :

On voit bien dans ce fichier l’historique des adresses MAC rencontrées par le système, et comment la nouvelle a été numérotée eth1.

Il suffit alors d’éditer ce fichier pour attribuer le nom eth0 à la nouvelle adresse MAC :

Troisième possibilité : dans Hyper-V, configurer la machine virtuelle pour donner à la carte réseau la même adresse MAC que l’ancienne machine virtuelle... Ce qui explique pourquoi il aurait été judicieux de faire un export et un import de la VM, et conserver l’adresse MAC d’origine.

J’espère que cela évitera des déboires à certains, et dépannera ceux qui perdent leur carte réseau.

Et je remercie mon collègue Youssef, et Bing pour avoir trouvé le fichier 70-persistent-net.rules à la vitesse de l’éclair !

Rentrée virtuelle

pascals — Sun, 30 Aug 2009 18:45:36 GMT

La rentrée est riche sur le front de la virtualisation !

Du coté client :

Windows 7 RTM est disponible pour les abonnés Technet et MSDN.
Windows Virtual PC RC. Ce n’est pas encore la version finale, mais cela s’en rapproche. En téléchargement gratuit pour Windows 7 Home Basic, Home Premium, Professional, Enterprise et Ultimate. Voir également le site et le blog. Pour situer le produit : Windows Virtual PC est le successeur de Virtual PC. Il ne fonctionne que sous Windows 7 et bénéficie de nouveautés que j’aborderai plus tard.
Windows XP Mode RC. Pour Windows 7 Professional, Enterprise en Ultimate, une machine virtuelle Windows XP prête à l’emploi, pour en finir avec les problèmes de compatibilité en entreprise.

Du coté serveur :

Windows Server 2008 R2 RTM est disponible pour les abonnés Technet et MSDN. Des VHD d’évaluation sont en téléchargement en version Enterprise et Enterprise Core.
Hyper-V Server 2008 R2. L’hyperviseur est disponible en téléchargement gratuit.
Linux Integration Components for Windows Server 2008 Hyper-V R2. Ces composants sont disponibles en version 2.0 finale pour SUSE Linux Enterprise Server 10 SP2 et 11, x86 et x64. Ils supportent Windows Server 2008 (et 2008 R2) Hyper-V, ainsi que Hyper-V Server 2008 (et 2008 R2).
Remote Server Administration Tools (RSAT) for Windows 7. Ces outils d’administration à distance sont nécessaires pour administrer un serveur Hyper-V depuis un poste Windows 7.
HVRemote. Ce script est indispensable pour l’administration distante d’Hyper-V dans un environnement workgroup ou mixte.
System Center Virtual Machine Manager (SCVMM) 2008 R2. Le produit d’administration est RTM est disponible en version d’évaluation.

Pour tout savoir :

Toutes les questions techniques sont abordées dans ces deux blogs :

Mise à jour 31/8/2009 : RSAT, HVRemote et le Microsoft Virtualization Team Blog.

Plus de détails sur les sources des ICs Hyper-V pour Linux

pascals — Sun, 26 Jul 2009 03:09:54 GMT

Suite à l’annonce de lundi 20 sur la contribution au noyau Linux des sources des composants d’intégration Hyper-V, quelques détails ont été publiés par Hank Janssen sur le blog Port25 :

More on the Hyper-V Linux Integration Components – quelques éléments sur l’histoire du projet.
Introduction to the Linux Integration Components – quelques détails techniques sur l’architecture des composants publiés.

Pour référence, voir également l’annonce de Greg Kroah-Hartman à la communauté Linux, ainsi que les patches dans son arborescence de test.

Composants d’Intégration Linux RC2 pour Hyper-V R2

pascals — Wed, 22 Jul 2009 16:56:39 GMT

La RC2 des Composants d’Intégration Linux (Linux IC’s v2 RC2) pour Hyper-V vient d’être mise à disposition sur le site Connect. Il s’agit ici de la version binaire de ces composants, pour les distributions supportées par Microsoft :

Red Hat Enterprise Linux 5.2 (x86/x64)
Red Hat Enterprise Linux 5.3 (x86/x64)
SUSE Linux Enterprise Server 10 SP2 (x86/x64)
SUSE Linux Enterprise Server 11 (x86/x64)

Ces composants en version RC2 fonctionnent pour :

Windows Server 2008 Hyper-V
Hyper-V Server 2008
Windows Server 2008 R2 Hyper-V RC
Hyper-V Server 2008 R2 RC

Cette sortie n’est pas liée à l’annonce précédente sur la mise à disposition des sources de ces composants : en attendant leur intégration dans le noyau de Linux, ces composants binaires seront maintenus pour les distributions indiquées.

Notez que le support de la souris n’est pas inclus dans ces composants. Pour cet aspect, reportez-vous au Projet Satori de Citrix.

Drivers Linux pour Hyper-V sous GPL

pascals — Mon, 20 Jul 2009 20:06:32 GMT

Grande nouvelle ! Microsoft vient d’annoncer à l’occasion de l’OSCON (Open Source Convention) 2009 la mise à disposition du code source des drivers pour Linux dans l’environnement de virtualisation Hyper-V, représentant environ 20 000 lignes de code. Ces composants sont fournis sous licence GPLv2 pour compatibilité avec la licence du noyau de Linux. Outre le fait que c’est la première fois que Microsoft fournit du code sous cette licence, l’intérêt technique est que cela va permettre le fonctionnement de toute distribution Linux de façon optimisée dans Hyper-V.

Ces drivers représentent l’équivalent des composants d’intégration qui permettent aux machines virtuelles Windows d’utiliser les composants synthétiques fournis par Hyper-V : SCSI, IDE et Ethernet. Les machines virtuelles Linux pourront donc bénéficier des mêmes performances, quelle que soit leur distribution. J’attends avec impatience la mise en œuvre sur Debian et ses dérivés...

Ils sont fournis à la communauté Linux dans le cadre du Linux Driver Project, sous licence GPLv2.

Voir l’annonce.

Mise à jour 21/7/2009 : Voir également ce post pour les infos sur l’intégration de ce code dans le noyau Linux.

Devoir de vacances : un routeur léger pour Hyper-V

pascals — Mon, 20 Apr 2009 19:35:20 GMT

Les congés sont faits pour changer d’air. Et, si le temps le permet, creuser quelques petits sujets mis de côté. C’est le cas de celui-ci, qui peut intéresser tous ceux qui utilisent la virtualisation pour monter des maquettes un peu conséquentes. Prenons par exemple ce que je viens de mettre en œuvre : un réseau géré par SBS (Small Business Server) 2008. Pour plus d’infos sur SBS 2008, jetez un œil chez mon collègue Pierre ou sur Technet. Pour une telle maquette, il faut un réseau privé isolé, derrière un routeur NAT avec des fonctions de redirection de port (port forwarding) : dans mon cas, il est nécessaire de rediriger un certain nombre de ports vers le serveur SBS.

Hyper-V ne fournit pas de fonction de routeur, ni de NAT, ni de redirection de port. Il est donc nécessaire d’ajouter à notre maquette une machine virtuelle dédiée à la fonction de routage, configurée avec une carte réseau externe (sur le réseau physique) et une carte réseau interne (sur le réseau privé dédié à la maquette). Une machine Windows avec le service RRAS, ou le produit ISA Server, ferait l’affaire. Mais à quel prix sur les ressources du serveur Hyper-V ?

Voici un schéma de principe (notez mes talents de graphiste), dans lequel Routeur 2 est mon objectif :

      Internet
          |
      ____|____
     |         |
     |Routeur 1|
     |_________|
          |
      ____|___________réseau_physique__
               |
     _ _ _ _ _ | _ _ _ _ _ _ _ _Hyper-V_
    |      ____|____                    |
          |Routeur 2|
    |     | virtuel |                   |
          |_________|
    |          |                        |
      _________|_________réseau_privé__
    |      |           |                |
       ____|____   ____|____
    | |         | |  Autre  |           |
      | Serveur | | machine |
    | | virtuel | |virtuelle|           |
      | interne | | interne |
    | |_________| |_________|           |

    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|

Il existe plusieurs solutions à base d’autres OS (c'est-à-dire Linux) et j’ai choisi pour cet usage bien précis le « firewall sur une disquette » : floppyfw. Ses caractéristiques intéressantes sont :

Il tient sur une disquette (donc une disquette virtuelle) en lecture seule et fonctionne en RAM : pas d’état à maintenir, il est possible de l’arrêter brutalement sans l’endommager.
Il fonctionne avec 12 Mo de RAM ! Qui dit mieux ? D’autant qu’avec un serveur SBS demandant au moins 4 Go, on économise la RAM comme on peut (Vista fonctionne très bien avec 384, voire 256 Mo.)
Configuration simple depuis une machine Windows : la disquette est formatée en FAT et les fichiers de configuration sont éditables depuis Windows.
Il assure le routage, le NAT, un serveur DHCP optionnel et la redirection de ports vers un serveur interne.

Voici comment procéder :

Commencez par télécharger la dernière version de l’image de floppyfw (fichier .img) et parcourir la documentation disponible. Renommer ou copier le fichier floppyfw-version.img en quelquechose.vfd (vfd est l’extension des images de disquettes pour Hyper-V, mais le format est le même.)

Chargez la disquette virtuelle dans une machine virtuelle Windows. Il y a deux fichiers à éditer : config et firewall.ini. Le second doit être édité uniquement s’il doit y avoir redirection de port vers une machine interne. Les fichiers sont au format Unix : le bloc-note (notepad.exe) de Windows ne sera pas adapté car il ne reconnaît pas les fins de lignes de type Unix (CR). Utilisez plutôt Wordpad, ou un éditeur de texte comme Notepad++.

En supposant que vous n’ayez pas besoin du serveur DHCP puisque vous utilisez le votre dans le réseau interne, et si la carte externe du routeur est cliente DHCP, alors il y a une seule modification à faire dans le fichier config. Dans la section INSIDE settings, modifiez l’adresse IP de la carte interne : INSIDE_IP=<adresse interne>. Le fichier est assez clair si votre configuration est différente.

S’il y a besoin de rediriger des ports vers un serveur interne, alors il faut éditer le fichier firewall.ini : en premier lieu l’adresse IP du serveur interne est à placer dans la ligne SERVER_IP=<adresse IP>.

Toujours dans firewall.ini, chercher la section Forwarding outside ports to an internal server. Cette section contient des exemples en commentaire. Il suffit de s’inspirer de ces exemples pour construire vos propres règles de redirection avec iptables. Par exemple dans mon cas pour SBS j’avais besoin de rediriger les ports 25, 80, 443 et 987 vers le serveur interne 192.168.20.2.

Vers le début du fichier :

SERVER_IP=192.168.20.2

Et un peu plus loin, ce n’est qu’un peu de copier-coller, pour chaque port à rediriger :

# SMTP (Internal mail server): 
  
iptables -A PREROUTING -t nat -p tcp -d ${OUTSIDE_IP} --dport 25 -j DNAT --to ${SERVER_IP}:25 

  
iptables -A FORWARD -p tcp -d ${SERVER_IP} --dport 25 -o ${INSIDE_DEVICE} -j ACCEPT 

  
iptables -A POSTROUTING -t nat -p tcp -d ${SERVER_IP} --dport 25 -s ${INSIDE_NETWORK}/${INSIDE_NETMASK} -j SNAT --to ${OUTSIDE_IP} 

  


  
# Web: 

  
iptables -A PREROUTING -t nat -p tcp -d ${OUTSIDE_IP} --dport 80 -j DNAT --to ${SERVER_IP}:80 

  
iptables -A FORWARD -p tcp -d ${SERVER_IP} --dport 80 -o ${INSIDE_DEVICE} -j ACCEPT 

  
iptables -A POSTROUTING -t nat -p tcp -d ${SERVER_IP} --dport 80 -s ${INSIDE_NETWORK}/${INSIDE_NETMASK} -j SNAT --to ${OUTSIDE_IP} 

  


  
# Port 443: HTTPS Web traffic 

  
iptables -A PREROUTING -t nat -p tcp -d ${OUTSIDE_IP} --dport 443 -j DNAT --to ${SERVER_IP}:443 

  
iptables -A FORWARD -p tcp -d ${SERVER_IP} --dport 443 -o ${INSIDE_DEVICE} -j ACCEPT 

  
iptables -A POSTROUTING -t nat -p tcp -d ${SERVER_IP} --dport 443 -s ${INSIDE_NETWORK}/${INSIDE_NETMASK} -j SNAT --to ${OUTSIDE_IP} 

  


  
# Port 987: HTTPS Web traffic for Windows SharePoint Services through Remote Web Workplace 

  
iptables -A PREROUTING -t nat -p tcp -d ${OUTSIDE_IP} --dport 987 -j DNAT --to ${SERVER_IP}:987 

  
iptables -A FORWARD -p tcp -d ${SERVER_IP} --dport 987 -o ${INSIDE_DEVICE} -j ACCEPT 

  
iptables -A POSTROUTING -t nat -p tcp -d ${SERVER_IP} --dport 987 -s ${INSIDE_NETWORK}/${INSIDE_NETMASK} -j SNAT --to ${OUTSIDE_IP}

Pour finir, il s’agit de construire le routeur. La VM doit avoir deux cartes réseaux de type Legacy Network Adapter, la première sur le réseau externe (physique) et la seconde sur le réseau interne (privée). Pour le reste : 12 Mo de RAM, aucun disque dur, et la disquette virtuelle chargée, sans oublier la configuration du BIOS pour que la VM démarre sur la disquette :

Pour vérifier que le routeur est correctement configuré, démarrez et connectez-vous à la VM. Ouvrez une session avec root, sans mot de passe (ce n’est pas un article sécurité !)

La commande ifconfig eth0 vous donnera l’IP externe, et ifconfig eth1 l’IP interne :

Fermez la session (Ctrl+D).

Une fois la VM du routeur prête, vous pouvez la démarrer et l’arrêter (turn off) à volonté, sans risquer de compromettre sa disquette virtuelle. Et à 12 Mo de RAM le routeur, pourquoi se priver ?

Bon test !

Le guide de sécurité d’Hyper-V

pascals — Fri, 03 Apr 2009 15:24:46 GMT

Le Hyper-V Security Guide vient d’être publié :

http://go.microsoft.com/fwlink/?LinkId=140066

Ce guide est structuré en trois parties :

Sécurisation d’Hyper-V
Délégation de l’administration des machines virtuelles
Protection des machines virtuelles

Guide de sécurité d’Hyper-V

pascals — Fri, 13 Feb 2009 13:02:49 GMT

Voici une bonne nouvelle qui vient compléter ma présentation d’hier aux Techdays sur la sécurité d’Hyper-V. Le Guide de sécurité d’Hyper-V est disponible en version Beta :

The Hyper-V Security Guide

Au programme :

Sécurisation d’Hyper-V, de la partition parente, configuration du réseau et du stockage.
Délégation de l’administration des machines virtuelles (avec l’inévitable AzMan).
Protection des machines virtuelles.

La Beta est disponible jusqu’au 4 mars prochain.

Techdays 2009 : mes présentations

pascals — Fri, 13 Feb 2009 11:48:36 GMT

En attendant la publication des présentations et enregistrements vidéo sur le site des Techdays, j’ai déposé nos fichiers dans mon Skydrive, ici :

La famille Le Boulet remercie chaleureusement toutes les personnes présentes à leur présentation “Le virus est mort, vive le malware !” pour leur participation active… :)

Techdays 2009, J-15

pascals — Mon, 26 Jan 2009 12:14:39 GMT

Dans 15 jours démarrent les Techdays 2009 au Palais des Congrès Porte Maillot à Paris. Inscription et programme : http://www.microsoft.com/france/mstechdays/.

J’anime ou co-anime cette année 4 sessions et ateliers :

INT205 NAP et les systèmes non Windows (le 10/2 à 17:30)
Découvrez dans cette session l'interopérabilité du contrôle d'accès au réseau, NAP, avec les postes clients non Windows (Linux, Mac OS).
Cyril Voisin et moi-même.
SEC211 Le virus est mort, vive le malware !? (le 12/2 à 14h30)
Motivés par le profit, les criminels ne cessent de faire évoluer les logiciels malveillants et leurs vecteurs de propagation. Venez découvrir dans cette session riche en démonstrations et en bonne humeur le nouveau visage de ces menaces et les différents moyens d'atténuer les risques associés.
Coproduction Stanislas Quastana, Cyril Voisin, Mathieu Malaise, et moi-même.
DYN314 Virtualisation et sécurité (le 12/2 à 13:00)
Cette session aborde les nouveaux défis soulevés par l'omniprésence de la virtualisation en terme de sécurité. Nous nous concentrerons sur les caractéristiques d'Hyper-V et sur les aspects pratiques de la sécurité des serveurs et machines virtuelles Hyper-V.
Moi-même.
WKS215 Atelier dirigé : 60 minutes pour mettre en œuvre WSUS comme outil de gestion des mises à jour Microsoft (le 11/2 à 16:00 et le 12/2 à 16:00)
Dans cet atelier vous mettrez un œuvre un serveur WSUS pour gérer les mises à jour de sécurité des produits Microsoft.
Mathieu Malaise et moi-même, avec des machines et Hyper-V pour les manips.

Dès que mes présentations seront prêtes (c’est loin d’être le cas aujourd’hui…), je placerai les fichiers dans mon SkyDrive.

Venez nombreux !

Outils pour Hyper-V

pascals — Mon, 29 Dec 2008 12:50:28 GMT

Aujourd'hui deux outils pour Hyper-V. Pas tout neufs, mais extrêmement utiles. Le premier vous servira tous les jours sur votre poste Windows Vista SP1 : Hyper-V Monitor Gadget est un gadget pour la Windows Sidebar de Windows Vista présentant la liste des VM de vos serveurs Hyper-V, avec leur état et des contrôles pour démarrer, arrêter ou suspendre chacune d'elles individuellement. De plus, un double clic sur le nom d'une VM lance vmconnect.exe sur celle-ci, vous donnant ainsi un accès direct à la console de chaque VM. L'utilisation du gadget nécessite que les outils d'administration d'Hyper-V soient installés sur la station Windows Vista SP1.

Nous avons déjà vu ici le problème de l'administration à distance d'Hyper-V hors domaine. Si vos serveurs Hyper-V et votre station d'administration sont dans une même forêt Active Directory, vous avez de la chance, tout marchera à merveille. Sinon la configuration est plus complexe : il y a quelques mois John Howard décrivait dans 5 articles (1 2 3 4 5) le détail des étapes nécessaires à la configuration manuelle de l'administration à distance d'Hyper-V en fonction des différents cas de figure.

En novembre dernier, le même John Howard publiait un script permettant enfin d’automatiser cette procédure : HVRemote. Si vous mettez en œuvre des serveurs Hyper-V dans des environnements hors domaine, ce script est un must pour la configuration de l'administration à distance.

Hyper-V Monitor Gadget : http://mindre.net/
HVRemote : http://code.msdn.microsoft.com/HVRemote

Bonnes fêtes !

Hyper-V et les clusters

pascals — Thu, 18 Dec 2008 14:11:42 GMT

Quelques documentations mises en ligne en novembre intéresseront ceux qui veulent mettre leurs Hyper-V en cluster :

Schéma extrait de ces documentations :

Surface d'attaque d'Hyper-V

pascals — Mon, 22 Sep 2008 10:00:24 GMT

Je suis tombé récemment sur cet article de Tony Soper, indiquant que le tableau de référence de la surface d'attaque d'Hyper-V était téléchargeable ici. Il s'agit d'un tableau Excel listant les fichiers, services et règles de firewall ajoutés par le rôle Hyper-V sur Windows Server 2008. Le guide de sécurisation de Windows Server 2008 ne contient pas encore ces informations, mais sera mis à jour prochainement.

Hyper-V : une nouvelle race de SID

pascals — Fri, 18 Jul 2008 03:29:04 GMT

Si vous savez ce que sont des jetons, des SID et des DACL, passez le début et allez directement à la première image ci-dessous...

Depuis que Windows est "NT", c'est à dire depuis Windows NT 3.1, un principe de base de la sécurité de Windows, le contrôle d'accès discrétionnaire, utilise des SID et des ACL. Pour l'explication détaillée, je vous conseille le chapitre 8 du livre de Mark Russinovich et David Solomon : Windows Internals. Une autre source est le chapitre Authorization and Access Control Technologies dans la librairie technique de Windows Server 2003.

Pour l'explication rapide, voici une tentative de résumé : dans Windows, tout processus est authentifié et s'exécute dans le contexte de sécurité de l'utilisateur. Un jeton (token) est attaché à chaque process, et ce jeton contient entre autres les identifiants de l'utilisateur et de tous les groupes auxquels cet utilisateur appartient. Si vous exécutez la commande whoami /all dans une ligne de commande, vous obtenez une vue lisible de votre jeton. Comme les utilisateurs et groupes peuvent changer de nom, on les repère par des identifiants numériques, des SID (Security Identifiers). Windows saura en général faire la traduction pour vous.

Les objets, comme par exemple les fichiers, ont un Security Descriptor (SD) qui contient une DACL (liste de contrôle d'accès discrétionnaire). Cette liste contient des ACE (Access Control Entries) et chaque ACE indique un SID et un type d'accès ; par exemple : Utilisateurs / Lecture, Administrateurs / Lecture et Ecriture. Si vous exécutez la commande icacls nom_fichier dans une ligne de commande, vous obtenez une vue lisible de la DACL du fichier (si icacls ne marche pas, essayez cacls.)

Pour faire simple, lorsqu'un processus veut accéder à un objet pour un type d'accès donné (par exemple pour le modifier), le Security Reference Monitor (SRM) de Windows contrôle la DACL de l'objet, le jeton du process, et regarde si un des SID du jeton se trouve dans une ACE qui lui permet l'accès demandé.

Au fil des versions de Windows ce mécanisme est toujours resté, et des concepts nouveaux sont venus l'utiliser sans jamais le modifier. Par exemple, depuis Windows Vista, il existe une nouvelle sorte de SID : les SID de service. Il s'agit de SID qui identifient un service au lieu d'un utilisateur ou d'un groupe. Ils servent à faire en sorte que, même si deux services S1 et S2 s'exécutent sous le même compte (par exemple LOCAL SERVICE), alors on peut faire en sorte qu'un fichier ne soit accessible que par S1 en lui attachant une ACE relative au SID de service NT SERVICE\S1. C'est la notion d'isolation des services, abordée notamment dans cet article de Cyril Voisin et Jean-Yves Poublan.

On trouve donc depuis Windows Vista des fichiers qui ont des ACE faisant référence à des SID de service, comme par exemple :

c:\Windows\notepad.exe
    NT SERVICE\TrustedInstaller:(F)
    BUILTIN\Administrators:(RX)
    NT AUTHORITY\SYSTEM:(RX)
    BUILTIN\Users:(RX)

Ce qui signifie que seul le service TrustedInstaller (nom complet : Windows Modules Installer) a tous les droits sur les fichiers de Windows.

C'était un bien longue introduction pour aborder une nouvelle sorte de SID définis par Hyper-V : les SID de machines virtuelles. Un peu comme les SID de service, les SID de VM vont servir à isoler les VM, c'est à dire à assurer que les ressources propres à une VM ne sont accessibles en écriture que par cette VM.

Voici la DACL sur le fichier VHD d'une machine virtuelle déclarée dans Hyper-V :

Rappelons qu'un fichier VHD est le disque dur virtuel de la VM. Remarquez le SID de la forme NT VIRTUAL MACHINE\<GUID>. Ce GUID (090928A5- etc.) est l'identifiant Hyper-V unique de cette machine virtuelle. On peut le vérifier en regardant le fichier C:\ProgramData\Microsoft\Windows\Hyper-V\<GUID>.xml.

Dans Process Explorer, on peut afficher les propriétés du processus (worker process) vmwp.exe correspondant à cette VM :

Et voici, toujours affiché dans Process Explorer, le jeton du process (propriétés du process, onglet Security) :

Ce jeton et cette DACL assurent donc (1) que le process (qui s'exécute en tant que NETWORK SERVICE) aura accès en lecture et écriture (mais pas suppression) au VHD, et (2) que les autres VM ou autres services n'y auront pas accès en écriture.

Au passage, avez-vous remarqué que icacls et Process Explorer profitaient de Windows pour toujours traduire les SID en noms lisibles ? Quoique, je ne sais pas si NT VIRTUAL MACHINE\090928A5-E592-47E1-A819-85F56654EBCF est plus lisible que S-1-5-83-1-151595173-1205986706-4119140776-3488306278... :)

Si vous souhaitez en savoir plus sur les fonctions avancées des jetons de sécurité dans Windows, consultez la série d'articles de Cyril et Jean-Yves sur le durcissement des services dans Windows Vista et Windows Server 2008.

Mise à jour 18/7/2008 - Quelques fautes de frappes corrigées.

Linux sur Hyper-V

pascals — Thu, 17 Jul 2008 02:00:02 GMT

C'est, semble-t-il, un sujet qui vous intéresse. J'ai déjà commis quelques articles ici sur les éternels problèmes de l'installation de Linux sur Virtual PC 2007. Manifestement, Cela se passe beaucoup mieux sur Hyper-V, et pas uniquement avec les versions supportées, à savoir SUSE Linux Enterprise Server 10.

Sean Earp explique dans un article récent comment se passe l'installation dans Hyper-V de OpenSuse 11, Ubuntu 8.04 x64 et Fedora 9 x64. Bonne nouvelle, ces systèmes fonctionnent, et plutôt bien !

Lire l'article : Linux on Hyper-V.