Freigeben über

Hyper-V : une nouvelle race de SID

  • Artikel

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.

Comments