Sécurité

Les nouvelles ACL améliorent la sécurité dans Windows Vista

Jesper Johansson

Vue d'ensemble:

• Nouveautés des ACL
• Contrôles plus étroits de l’administrateur
• Autorisations d’installateur de confiance
• Utilisateurs et groupes modifiés

La structure fondamentale des listes de contrôle d’accès (ACL) n’a pas beaucoup changé pour Windows Vista, mais il existe plusieurs petites modifications néanmoins importantes, dont vous devez être conscient. Certaines modifications

étaient nécessaires parce que les ACL intervenaient dans plusieurs problèmes dans Windows® XP. Pour commencer, la plupart des utilisateurs de Windows XP s’exécutent comme administrateurs. C’est-à-dire qu’ils utilisent un compte qui est membre du groupe Administrateurs intégré. Pour les utilisateurs à domicile, il s’agit quasiment d’une certitude, car tous les comptes ajoutés pendant l’installation deviennent administrateurs. Par conséquent, tout programme que ces utilisateurs exécutent s’exécutera également avec les privilèges d’administrateur, en leur donnant l’accès sans limites au système d’exploitation. C’est bien sûr particulièrement problématique si ces programmes sont de source douteuse.

Le deuxième problème qui devait être pris en compte était que les ACL par défaut des versions précédentes de Windows rendaient beaucoup de gens nerveux car elles comprenaient des entrées d’ACL (les ACE) pour Tout le monde, Utilisateurs avec pouvoir et autres. Par exemple, l’ACL par défaut sur la racine du volume de démarrage (normalement C:\) de Windows XP donnait accès en lecture à Tout le monde et accordait l’autorisation de création de dossiers à tous les membres du groupe Utilisateurs. Enfin, dans Windows XP, les opérations pouvant être effectuées comportaient des restrictions. Il n’existait par exemple aucune méthode pour l’attribution d’autorisations au propriétaire actuel d’un objet. Vous pouviez donner des autorisations au propriétaire mais, si le propriétaire était modifié, ces autorisations n’étaient pas transférées. De même, les propriétaires possédaient des droits implicites sur un objet, quelles que soient les autorisations affectées à cet objet.

Avec Windows Vista™, Microsoft a entrepris de résoudre nombre de ces problèmes et de permettre la prise en charge d’autres fonctionnalités, telles que le Contrôle de compte d’utilisateur (User Account Control, UAC). Cet article porte principalement sur les modifications majeures liées au contrôle d’accès dans Windows Vista. Le mois prochain, je continuerai par les outils que vous pouvez utiliser pour gérer le contrôle d’accès.

Utilisateurs et groupes modifiés et nouveaux

Certains utilisateurs et groupes de Windows Vista sont nouveaux et certaines vieilles connaissances de Windows XP ont été supprimées. De plus, la manière dont certains fonctionnent a été modifiée. Chacune des modifications a un certain impact sur la manière dont le contrôle d’accès peut être géré.

Administrateur : désactivé par défaut Le compte Administrateur intégré, avec l’identificateur relatif (RID) 500, est maintenant désactivé par défaut dans la plupart des cas. L’administrateur était prévu pour être un compte d’urgence, utilisé pour sauver l’ordinateur lorsque tout le reste avait échoué. Il a fini par malheureusement être utilisé beaucoup plus souvent comme compte d’administration standard et enfreindre ainsi plusieurs principes de sécurité. Le plus notable de ceux-ci, la responsabilité, signifie que vous perdez la capacité de traquer qui effectue des modifications sur votre système. Le compte a donc partiellement été désapprouvé. Microsoft pourra en fin de compte totalement désapprouver le compte, mais il est pour l’instant désactivé par défaut. Si vous ne disposez pas d’autres comptes locaux dans le groupe Administrateurs, le RID 500 est toujours utilisable dans la console de récupération et en mode sans échec, mais ne peut et ne doit autrement pas être utilisé.

Notez qu’il existe une différence entre le compte Administrateur intégré et les autres comptes du groupe Administrateurs. Nous écrivons généralement avec une majuscule « Administrateur » pour faire référence au compte avec le RID 500 et le distinguer d’un « administrateur », qui est tout autre compte membre du groupe Administrateurs intégré. Les noms de groupes sont également écrits avec une majuscule.

Dans Windows XP, le compte Administrateur intégré possédait plusieurs droits et privilèges spéciaux dont ne disposait aucun autre administrateur. Nombre de ceux-ci ont été supprimés dans Windows Vista, mais il existe deux exceptions notables : Premièrement, un compte administrateur désactivé peut être utilisé dans la console de récupération s’il n’existe pas d’autres administrateurs locaux. Deuxièmement, l’Administrateur n’est pas soumis à l’UAC et disposera toujours d’un jeton administratif complet. Ceci s’applique également à l’Administrateur de domaine (RID 500 sur un domaine).

Autorisations d’Utilisateur avec pouvoir supprimées L’ancien groupe Utilisateurs avec pouvoir a, pour des raisons pratiques, été aboli. Le groupe existe toujours, mais la plupart des autorisations qui lui étaient accordées ont été supprimées. Il n’était pas difficile de savoir qu’un utilisateur membre du groupe Utilisateurs avec pouvoir était en fait un administrateur qui ne s’était pas encore promu administrateur. J’ai pris une fois le contrôle d’un ordinateur auquel tous les correctifs logiciels nécessaires avaient été appliqués et sur lequel était exécuté Windows XP Service Pack 2 (SP2), en moins de 45 minutes, en m’accordant les privilèges d’administrateur. La reconnaissance, à l’aide d’un petit programme écrit en C++ et la fermeture puis l’ouverture de session pour terminer la prise de contrôle étaient incluses, et tout ceci était possible car j’étais membre des Utilisateurs avec pouvoir.

De nombreuses organisations ont accordé des autorisations sophistiquées au groupe Utilisateurs avec pouvoir et dépendent d’utilisateurs qui en sont membres ; il n’était donc pas possible de supprimer ce groupe dans Windows Vista. Cependant, Microsoft supprimera probablement complètement le groupe Utilisateurs avec pouvoir dans une version future de Windows. Vous seriez bien avisé de commencer à prévoir votre migration sans groupe Utilisateurs avec pouvoir.

Installateur de confiance L’Installateur de confiance est en fait un service et non un utilisateur, bien que des autorisations lui soient accordées dans l’ensemble du système de fichiers. Le renforcement de la sécurité de service permet à chaque service d’être traité comme une entité de sécurité à part entière à laquelle des autorisations peuvent être affectées, comme à tout autre utilisateur. Pour un aperçu général de cette fonctionnalité, voir le numéro de janvier 2007 de TechNet Magazine. Le livre Windows Vista Security (Grimes et Johansson, Wiley Press, 2007), explore en détail le renforcement de la sécurité de service, y compris la manière dont d’autres fonctionnalités en tirent parti, telles que le pare-feu et IPSec.

Les SID de service ne sont pas émis par les autorités observées précédemment telles que NT AUTHORITY ou un domaine. Le nom complet du compte virtuel de l’installateur de confiance est NT SERVICE\TrustedInstaller et son SID est :

S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464

Vous pouvez voir le SID de tout service, même ceux qui n’existent pas, en exécutant la commande sc showsid, comme indiqué à la figure 1.

Figure 1** sc showsid affiche le SID de tout service, y compris ceux qui n’existent pas encore **(Cliquer sur l'image pour l'agrandir)

Ce SID commence par S-1-5-80. Notez que la première sous-autorité est ici 80, ce qui correspond à SECURITY_SERVICE_ID_BASE_RID et signifie que ce SID est émis par la sous-autorité NT SERVICE d’un service. Ceci se vérifie pour tout service. Les sous-autorités restantes et les RID sont basés sur le nom du service. Ceci permet à un développeur d’accorder des autorisations à son service sans avoir à générer et à installer le service au préalable, car son nom est déterministe et ne variera pas d’un ordinateur à l’autre.

Si vous n’arrivez pas à trouver le service TrustedInstaller dans le gestionnaire de services, son nom complet est « Programme d’installation de modules Windows ».

Comptes d’aide et de prise en charge supprimés Les comptes Support_xxxxxx et HelpAssistant ont tous deux été supprimés sur les nouvelles installations propres de Windows Vista, bien qu’ils soient conservés en cas de mise à niveau à partir d’une version précédente de Windows. Le compte Support_xxxxxx était utilisé pour exécuter des scripts à partir du centre de support. Certains OEM qui fournissaient leur propre contenu d’aide pouvaient également avoir fourni leurs propres comptes de support. Le sort des comptes OEM est incertain, mais il est plus que probable que les OEM arrêteront simplement de les créer. Ils ne sont pour ainsi dire plus nécessaires. En fait, du point de vue de la sécurité, il n’était de toute façon pas très judicieux d’autoriser des utilisateurs à exécuter des scripts à partir du centre d’aide en tant qu’autre utilisateur. Il est donc préférable que ces comptes disparaissent. Windows Vista possède un nouveau mécanisme pour l’accomplissement de cette tâche.

Le compte HelpAssistant était utilisé pour l’assistance à distance. Comme avec le centre d’aide, la fonctionnalité d’assistance à distance a été remaniée afin d’éviter de devoir recourir à l’utilisation du compte HelpAssistant, et il a par conséquent été supprimé.

Nouveaux SID d’emplacement réseau Les systèmes d’exploitation basés sur Windows NT® ont toujours eu certains SID basés sur l’emplacement réseau, tels que NETWORK et INTERACTIVE, qui indiquent des utilisateurs ouvrant une session depuis le réseau et de manière interactive. Il existe également un SID REMOTE INTERACTIVE LOGON, attribué aux utilisateurs ouvrant une session à l’aide des services Terminal Server. (Notez que les utilisateurs des services Terminal Server dispose de REMOTE INTERACTIVE LOGON et de INTERACTIVE LOGON dans leurs jetons.) Dans Windows Vista, deux SID supplémentaires ont été ajoutés : DIALUP et INTERNET. Le raisonnement exact derrière l’ajout d’un compte indiquant une ouverture de session par ligne commutée est quelque peu incertain, particulièrement lorsqu’un nombre toujours plus grand d’utilisateurs ne se connecte pas en ligne si le seul réseau disponible est une ligne téléphonique, mais ce SID est maintenant disponible. INTERNET correspond évidemment à un utilisateur ayant ouvert une session au-delà du réseau local. NETWORK, cependant, indique toujours tout utilisateur ouvrant une session depuis le réseau, y compris Internet.

DROITS DU PROPRIÉTAIRE et droits du propriétaire Il existe maintenant un SID pour les DROITS DU PROPRIÉTAIRE, qui s’applique à quiconque étant propriétaire d’un fichier au moment où un accès à celui-ci a lieu. Il est principalement utilisé pour limiter ce que le propriétaire peut faire avec le fichier. Il existe deux modifications notables du fonctionnement des droits du propriétaire par rapport à Windows XP. Tout d’abord, si vous êtes propriétaire de l’objet, mais qu’il existe un ACE sur l’objet qui s’applique à vous, les droits de l’ACE supplanteront le fait que vous êtes le propriétaire. Il s’agit d’une modification majeure qui aura un impact significatif sur certains aspects d’administration de système car nous sommes habitués à ce que le propriétaire dispose de droits implicites. Deuxièmement, le SID DROITS DU PROPRIÉTAIRE peut être utilisé pour limiter davantage ce que le propriétaire peut faire avec un objet.

Supposons que nous disposions d’un dossier, dont l’utilisateur Jesper est propriétaire, avec un ACL, comme à la figure 2. L’utilisateur, Jesper, possède uniquement l’autorisation Lecture sur le dossier, bien qu’il en soit le propriétaire. S’il essaie de copier un fichier dans celui-ci, la copie échouera car Jesper n’a pas l’autorisation d’écriture dans le dossier. Cependant, ceci n’est pas entièrement intuitif en ce qui concerne les messages d’erreur. Si vous tentez de copier un fichier avec l’Explorateur Windows® dans un dossier que vous possédez mais pour lequel vous ne disposez pas des autorisations d’écriture, voici ce qui se passe : Premièrement, l’Explorateur Windows indique que vous devez élever les autorisations pour copier le fichier et vous demande de le faire, mais la copie de fichier échoue parce que vous n’avez pas les droits de copie de quoi que ce soit dans ce dossier. Vous obtenez un message d’erreur indiquant « Vous devez disposer d’une autorisation pour effectuer cette action » et un bouton pour « Réessayer » (comme si cela pouvait vous aider) et « Annuler ». Ceci, en dépit du fait que vous êtes le propriétaire.

Figure 2** Seul le Système local et un autre utilisateur ont accès à ce dossier **(Cliquer sur l'image pour l'agrandir)

Si Jesper essaie de modifier l’ACL sur le fichier, il sera invité à élever son jeton pour le faire. Puisqu’il est propriétaire du fichier, il peut le faire. Le propriétaire conserve des droits implicites de lecture et de modification de l’ACL (READ_CONTROL et WRITE_DAC) à moins qu’un ACE pour DROITS DU PROPRIÉTAIRE spécifie autre chose.

Pour comprendre l’effet du SID DROITS DU PROPRIÉTAIRE, ajoutons-le à l’ACL ci-dessus. Nous avons maintenant les autorisations illustrées à la figure 3.

Figure 3** L’ajout des autorisations DROITS DU PROPRIÉTAIRE au dossier modifie les autorisations de Jesper **(Cliquer sur l'image pour l'agrandir)

Avec ces autorisations, si le compte de Jesper tente de copier quelque chose dans le dossier, cette action réussit immédiatement parce que Jesper est propriétaire et possède les droits appropriés. Cependant, si Jesper essaie de modifier l’ACL sur l’objet, cette action échoue ! L’ACE DROITS DU PROPRIÉTAIRE spécifie que le propriétaire aura uniquement le privilège Modifier, pas la capacité de modifier la liste de contrôle d’accès discrétionnaire (DACL). Par conséquent, DROITS DU PROPRIÉTAIRE est principalement utilisé pour supprimer WRITE_DAC, la capacité de modifier le descripteur de sécurité du propriétaire.

Si un administrateur modifie le propriétaire de l’objet, les autorisations DROITS DU PROPRIÉTAIRE ne sont pas automatiquement transférées au nouveau propriétaire. Dans ce cas, l’ACE DROITS DU PROPRIÉTAIRE est désactivé en le marquant comme pouvant être uniquement hérité, sans l’appliquer aux conteneurs ou aux objets (en d’autres termes en ne l’appliquant pas du tout). Ceci est effectué pour s’assurer que les administrateurs ne sont pas entièrement bloqués pour accéder à l’objet. Pour faire en sorte que l’ACE DROITS DU PROPRIÉTAIRE prenne de nouveau effet, l’Administrateur doit réactiver manuellement cet ACE. Ainsi, il peut être marqué comme s’appliquant à ce dossier, ses sous-dossiers et ses fichiers, selon les besoins.

Il existe plusieurs scénarios intéressants dans lesquels le SID DROITS DU PROPRIÉTAIRE peut être utile, comme lorsque l’administrateur souhaite que les utilisateurs puissent créer des fichiers et des dossiers sur un serveur de fichiers, mais qu’il ne veut pas qu’ils puissent modifier des ACL sur ces dossiers. Une autre situation probable survient lorsque les utilisateurs étaient membres d’un groupe à certain point et ont créé certains objets mais, peut-être pour des raisons professionnelles, ont été plus tard supprimés de ce groupe. À ce stade, ils ne devraient pas pouvoir modifier les paramètres sur ces objets.

DROITS DU PROPRIÉTAIRE est considérablement utilisé pour renforcer la sécurité de service. Lorsqu’un service crée un objet transitoire au moment de l’exécution, le créateur de l’objet est le SID principal du processus de service, généralement LocalSystem, NetworkService ou LocalService, et non le SID du service lui-même. Ceci signifie que tout autre service s’exécutant dans le même contexte de processus peut modifier l’objet, ce qui est sans aucun doute peu souhaitable. En définissant un SID DROITS DU PROPRIÉTAIRE sur de tels objets, le système d’exploitation peut empêcher d’autres services d’accéder à ceux-ci.

ACL par défaut

Les ACL par défaut dans Windows XP étaient en fait essentiellement bons. En dehors de certains problèmes mineurs, tels que l’autorisation de placer des fichiers dans la racine du volume de démarrage accordée aux utilisateurs, ils étaient généralement sensés. Cependant, certains OEM ont apparemment décidé qu’ils savaient mieux ce qui constituait une sécurité raisonnable. L’écran de la figure 4 correspond à l’image de l’ACL sur le répertoire Windows d’un ordinateur exécutant Windows XP Édition Media Center pour un OEM important. L’OEM a essentiellement désactivé la sécurité du système de fichiers.

Figure 4** Un ACL configuré par l’OEM **

Microsoft a effectué quelques réglages des ACL dans Windows Vista. Premièrement, si vous êtes habitué à Windows XP, vous savez que tous les fichiers de système d’exploitation sont la propriété du groupe Administrateurs et que les administrateurs disposent du contrôle total sur ces fichiers. En tant que membre de ce groupe, vous disposez par conséquent d’un accès sans limites à ces fichiers. Cela n’est pas le cas dans Windows Vista.

Installateur de confiance Dans Windows Vista, la plupart des fichiers du système d’exploitation sont la propriété du SID TrustedInstaller, et seul ce SID dispose du contrôle total sur ceux-ci. Ceci est le résultat de la tâche d’intégrité de système qui a été mise en œuvre dans Windows Vista et a spécifiquement pour but d’empêcher un processus qui s’exécute comme administrateur ou Système local de remplacer automatiquement les fichiers. Pour pouvoir supprimer un fichier de système d’exploitation, vous devez par conséquent prendre possession du fichier puis lui ajouter un ACE qui vous autorise à le supprimer. Ceci offre une mince couche de protection contre un processus qui s’exécute comme Système local et possède un libellé d’intégrité Système. Un processus possédant une intégrité plus réduite n’est pas supposé pouvoir s’élever lui-même pour modifier la propriété. Certains services peuvent par exemple s’exécuter avec une intégrité moyenne, bien qu’ils s’exécutent comme Système local. De tels services ne peuvent pas remplacer les fichiers système pour qu’un exploit qui en prend possession puisse remplacer certains fichiers du système d’exploitation, ce qui rend plus difficile l’installation d’un rootkit ou autre logiciel malveillant sur le système. Il devient également plus difficile pour les administrateurs système qui s’offusquent de la simple présence de certains fichiers binaires système de supprimer ces fichiers.

ACE de refus d’accès Vous constaterez que beaucoup d’objets du système de fichiers possèdent des ACE de refus d’accès pour Tout le monde, ce qui a provoqué une grande consternation parmi de nombreux administrateurs. Si vous activez l’option Afficher les fichiers et dossiers cachés, vous verrez le dossier familier Documents and Settings. Cependant, si vous cliquez dessus, vous obtiendrez une erreur de refus d’accès. Pour comprendre ce qui se passe avec Documents and Settings, examinez le listing de répertoire de la figure 5.

Figure 5** Documents and Settings est en fait un point de jonction et non un répertoire **(Cliquer sur l'image pour l'agrandir)

Documents and Settings n’est en fait pas du tout un répertoire, mais un point de jonction. Rappelez-vous que les points de jonction sont similaires aux liens symboliques qui redirigent simplement l’accès à un autre emplacement. Dans ce cas, la jonction va directement vers un répertoire nommé C:\Users. Microsoft a en fait modifié l’espace de noms du système de fichiers de manière significative dans Windows Vista et les données utilisateur sont maintenant transférées dans C:\Users. Les autres éléments situés au-dessous de l’ancien espace de noms « C:\Documents and Settings\<Nom d’utilisateur> » ont également été déplacés. Par exemple, « C:\Documents and Settings\<Nom d’utilisateur>\Application Data » a été transféré vers C:\Users\<nom d’utilisateur>\appdata\roaming. Vous pouvez voir les modifications très clairement à l’aide d’une ligne de commande utilisant la commande dir /a, comme je l’ai fait à la figure 5. La raison pour laquelle l’espace de noms a été modifié si radicalement est pour qu’il soit plus intuitif pour les utilisateurs et pour obtenir une séparation claire entre les documents et les données. Au lieu d’enregistrer tous les fichiers de données sous le dossier Mes Documents, les développeurs peuvent maintenant créer leurs propres dossiers sous le profil de l’utilisateur et l’utilisateur les verra à cet emplacement. Les données d’application pour tous les utilisateurs sont maintenant dans un dossier masqué appelé %systemroot%\ProgramData plutôt que sous Documents and Settings\All Users\Application Data.

Microsoft n’a pas supprimé l’espace de noms « C:\Documents and Settings » car l’utilisation de ce nom peut être codée en dur dans les anciennes applications au lieu d’utiliser des variables d’environnement telles que %USERPROFILE%. Ces applications ne fonctionneraient pas si « C:\Documents and Settings » disparaissait. Ceux-ci sont plutôt représentés comme des points de jonction ou des liens symboliques, pour la compatibilité ascendante. Les applications dans lesquelles ces chemins sont codés en dur peuvent toujours tomber en panne, en fonction de la méthode dont elles effectuent l’accès aux données, mais elles ne fonctionnent déjà pas dans les versions de Windows différentes de l’anglais. C’est vraiment le point essentiel. Lorsqu’une mise à jour de Windows, telle que Windows XP SP2 ou Windows Vista, provoque une panne de programmes tiers, c’est presque toujours parce que les développeurs de ces programmes ont fait des suppositions non valides ou utilisé Windows d’une manière dont ils n’étaient pas supposés le faire.

Si vous essayez d’ouvrir un fichier, par exemple, en tapant « C:\Documents and Settings\<Nom d’utilisateur>\Mes Documents\foo.txt », cela devrait fonctionner, en supposant que vous disposez à cet emplacement d’un fichier appelé foo.txt. Cependant, si vous essayez de naviguer vers « C:\Documents and Settings\<Nom d’utilisateur>\Mes documents », un message d’erreur « Accès refusé » s’affichera. Pour comprendre ce qui se passe, examinez l’ACL de la figure 6.

Figure 6** ACE de refus d’accès sur Documents and Settings **(Cliquer sur l'image pour l'agrandir)

Examinez l’ACE de la liste. Il s’agit d’un ACE de refus d’accès pour Tout le monde de la liste du contenu du dossier. Les programmes peuvent traverser les points de jonction et ouvrir des documents avec des chemins absolus car le groupe Tout le monde possède le privilège Contourner la vérification de parcours (également connu sous le nom SeChangeNotifyPrivilege). Les tentatives d’énumération par un utilisateur ou un processus des répertoires qu’ils représentent échoueront en raison de l’ACE de refus d’accès. C’est pourquoi il n’est en fait pas possible d’afficher le contenu de C:\Documents and Settings et qu’il n’est pas non plus possible de supprimer ce « répertoire ». Le but principal de la mise en place de l’ACE de refus d’accès est la prévention de la suppression de la jonction par les utilisateurs, ce qui provoquerait des pannes dans les anciennes applications. Elle permet également de rappeler aux développeurs de ne pas écrire d’applications utilisant l’ancien espace de noms et de commencer plutôt à utiliser les variables d’environnement ou les chaînes de Registre pour mettre l’application à l’abri des modifications futures et des différences dues à la langue.

Notez que tous ces points de jonction sont masqués par défaut et que la vaste majorité des utilisateurs ne les verra jamais. Pour empêcher ceux qui les voient de les supprimer, Microsoft a mis en place un ACE de refus d’accès pour « Lister le dossier ».

Contourner la vérification de parcours La raison pour laquelle les utilisateurs peuvent accéder à des fichiers pour lesquels ils possèdent des droits à l’intérieur de dossiers (ou points de jonction) pour lesquels ils ne possèdent pas de droits d’accès, est que tout le monde dispose du privilège Contourner la vérification de parcours. Contourner la vérification de parcours, ou SeChangeNotifyPrivilege, est en fait le privilège le plus fondamental de Windows. Il est accordé à un processus dont tous les autres privilèges ont été supprimés, sauf si ce processus demande spécifiquement que ce privilège soit aussi supprimé. C’est ce qui se passe lorsque vous lancez un processus utilisant la ligne runas /trustlevel:0x10000 < dans Windows Vista. Le programme spécifié dans <commande> s’exécutera avec un jeton limité et tous les privilèges, sauf SeChangeNotifyPrivilege, sont dépouillés du jeton du processus.

Il est intéressant de noter que trustlevel 0x20000 procure un jeton avec l’ensemble normal de SID, mais des privilèges dépouillés. 0x40000 procure un jeton complètement normal.

Autorisations par défaut

Les autorisations par défaut sur le système de fichiers dans Windows Vista ont été quelque peu modifiées dans Windows XP. Si vous examinez l’ACL sur %systemdrive% (habituellement le lecteur C:, le volume de démarrage) sur Windows XP ou Windows Server® 2003, vous verrez ceci (ou quelque chose de très similaire sur les premières versions de Windows XP) :

D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU) 

Voici le même ACL sur le même répertoire dans Windows Vista :

D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU) 

Plusieurs différences sont à noter. Premièrement, il existe maintenant deux ACE pour BA (BUILTIN\Administrators) au lieu d’un seul. Cependant, l’effet direct est identique. Dans Windows Vista, un ACE n’est pas hérité et accorde l’accès complet à la racine ; et l’un des ACE est un ACE E/S (à héritage uniquement), hérité par les conteneurs et les objets, et celui-ci accorde les permissions GA (ensemble générique, ou contrôle total). Ceci est également vrai pour le remplacement d’un ACE SY (LocalSystem) par deux dans Windows Vista. Dans Windows XP, cet ACE unique accordait l’accès total et était hérité par les objets et les conteneurs. Ici encore, il n’y a aucune modification directe. La raison principale pour laquelle l’ACL a été modifié était de clarifier et de séparer les privilèges pour que l’ACL soit plus facile à gérer et même, potentiellement, à restaurer.

De manière plus intéressante, vous noterez que l’ACE pour CO (Creator/Owner, Créateur/Propriétaire) a été supprimé. Ceci signifie que si un utilisateur crée un objet dans la racine du système de fichiers, aucune autorisation spéciale n’est maintenant accordée au créateur.

Vous noterez également que l’ACE pour WD (Tout le monde) a été supprimé. De nombreuses personnes intéressées par la sécurité, bien que ne comprenant pas complètement les implications de leurs actions, étaient indûment préoccupées par cet ACE. Microsoft a essayé en vain pendant des années d’expliquer que le groupe Tout le monde était fonctionnellement identique au groupe intégré Utilisateurs, mais il semble qu’ils y aient finalement renoncé et aient simplement supprimé cet ACE. Puisqu’il existe un ACE identique pour BU (BUILTIN\Users) également hérité par les conteneurs et les objets, l’effet direct est que rien n’a été modifié.

En outre, deux des ACE pour BU (utilisateurs intégrés) ont été remplacés par des ACE pour AU (utilisateurs authentifiés). Ceci s’explique par le fait que le compte Invité est membre des utilisateurs intégrés (en vertu du fait que INTERACTIVE est membre du groupe intégré des utilisateurs), mais Invité n’est pas membre du groupe des utilisateurs authentifiés. Pour permettre au compte invité de lire et d’exécuter des fichiers, l’ACE 0x1200a9 (dans la pratique, Lire et Exécuter) demeure accordé à BU. Cependant, les ACE qui accordent des autorisations de création de fichiers et de dossiers sont plutôt accordés aux utilisateurs authentifiés. Il s’agit d’une modification par rapport à Windows XP. Dans Windows XP, un Invité pouvait créer des fichiers dans la racine. Dans Windows Vista, un Invité ne peut pas créer de tels fichiers. Gardez cependant à l’esprit que ceci ne sert à rien, sauf si le compte Invité est activé et que les invités peuvent d’une manière ou d’une autre atteindre la racine du volume de démarrage. Par défaut, le compte Invité est désactivé.

J’ai réservé le meilleur pour la fin. Il existe quelques ACE très intéressants et en apparence difficiles dans les deux listes ci-dessus. Dans Windows XP, un ACE est hérité par les conteneurs et spécifie 0x100004 pour les utilisateurs intégrés. Cet ACE accorde aux utilisateurs le droit de créer des sous-dossiers, des sous-dossiers de sous-dossiers etc., puisqu’il est hérité par les conteneurs. Il existe également un ACE d’héritage uniquement, hérité par les sous-dossiers pour 0x100002. Cet ACE accorde aux utilisateurs le droit de créer des fichiers et des sous-dossiers dans les dossiers qu’ils créent sous la racine. En d’autres termes, ces deux ACE autorisent les utilisateurs, y compris les invités, à créer des fichiers et des dossiers sous la racine, comme je l’ai mentionné précédemment.

Dans Windows Vista, les ACE y correspondant sont un ACE d’héritage uniquement, hérité par les conteneurs et les fichiers, accordant GR (lecture générique), GX (exécution générique) et GW (écriture générique) ainsi que SD (Descripteur de sécurité de lecture) et un ACE qui s’applique uniquement à la racine et qui accorde le privilège LC. LC est en fait une abréviation qui s’applique aux ACE d’Active Directory®. Dans Active Directory, il signifie qu’un utilisateur peut lister des objets enfants. Cependant, la valeur hexadécimale de LC est 0x4. Pour un répertoire, 0x4 signifie FILE_ ADD_SUBDIRECTORY, ce qui devient fonctionnellement équivalent à 0x100004, puisque nous avons déjà 0x100000 (la capacité d’utiliser l’objet pour la synchronisation) de l’ACE 0x1200a9. En d’autres termes, il fournit exactement le même effet que dans Windows XP : les utilisateurs peuvent créer des sous-répertoires sous la racine.

D’où proviennent ces valeurs hexadécimales ? Pour commencer, que sont les valeurs hexadécimales ? Comme vous devez l’avoir maintenant remarqué, le contrôle d’accès regorge de nombres hexadécimaux (en base 16), tels que 0x1200a9. Ce sont en fait des représentations par masques de bits d’un masque d’accès qui sont définies sur « activées », pour indiquer qu’elles sont utilisées dans un ACE particulier. Lorsque vous utilisez un outil, tel que icacls, sc ou secedit, pour lister un ACL, les masques de bits sont représentés par des chaînes de texte plus conviviales, s’il existe une correspondance 1 à 1.

Par conséquent, pour déterminer ce que signifie LC vous devez simplement accéder au site Web MSDN®, rechercher la chaîne LC et examiner la colonne des valeurs de droits d’accès (Access right value) pour y trouver ADS_RIGHT_ACTRL_DS_LIST. Si vous ouvrez ensuite le fichier d’en-tête Iads.h et recherchez cette chaîne, vous trouverez qu’elle correspond à 0x4. Pour les chaînes qui ne proviennent pas d’Active Directory (qui ne sont pas précédées de « ADS_RIGHT »), vous trouverez généralement la valeur hexadécimale dans AccCtrl.h. Une fois que vous disposez de la valeur hexadécimale, il est facile de la rechercher dans le masque d’accès dans WinNt.H ou AccCtrl.h pour voir ce qu’elle signifie vraiment.

Si vous avez besoin d’aide pour ceci, vous pouvez vous procurer une copie du livre Protect Your Windows Network (de Jesper Johansson et Steve Riley, Addison-Wesley, 2005). Le chapitre 17 détaille en profondeur comment analyser les chaînes et les ACE du langage SDDL (Security Description Definition Language).

Les autorisations accordées à ces sous-répertoires (A;OICIIO;SDGXGWGR;;;AU) sont uniquement gouvernées par l’ACE dans Windows Vista, ce qui constitue la plus grande différence entre Windows Vista et Windows XP. Plutôt que d’accorder un contrôle total au créateur de sous-répertoires, comme dans Windows XP, Windows Vista accorde des privilèges de modification aux utilisateurs authentifiés.

Le résultat direct de ce nouvel ACL est que le créateur d’un objet ne dispose plus de droits spéciaux et que les choses sont un peu plus claires. La plus importante modification est peut-être que les utilisateurs authentifiés disposent de privilèges Modifier même dans les sous-dossiers créés par les administrateurs, ce qui est très différent de Windows XP. Dans Windows XP, les utilisateurs et les utilisateurs authentifiés ne disposent pas de droits sur les objets créés par les administrateurs sous la racine. Dans l’ensemble, cependant, bien que ces ACE semblent difficiles, l’effet direct n’est pas très différent de celui de Windows XP.

Pour résumer, dans Windows Vista, tout le monde, y compris l’utilisateur Invité, peut lire et peut exécuter des fichiers dans la racine. Seuls les utilisateurs authentifiés peuvent créer de nouveaux fichiers et dossiers et, lorsque les utilisateurs le font, ils obtiennent des autorisations de modification sur ces fichiers et dossiers. En d’autres termes, les autorisations sont légèrement plus efficaces dans Windows Vista que dans Windows XP, bien qu’il soit important de noter que le compte invité est par défaut désactivé.

Modifications apportées aux jetons

Lorsqu’un utilisateur membre du groupe Administrateurs de Windows XP ouvre une session, son jeton contient le SID du groupe Administrateurs et il peut faire tout ce que le groupe Administrateurs peut faire. Dans Windows Vista, par contre, ceci n’est plus le cas en raison du Contrôle de compte d’utilisateur. Le SID des administrateurs est toujours présent dans le jeton, mais il est défini sur Refuser uniquement, comme illustré dans la capture d’écran de Process Explorer à la figure 7.

Figure 7** Avec le Contrôle de compte d’utilisateur, le SID Administrators est uniquement utilisé pour refuser l’accès, sauf en cas d’élévation des privilèges **(Cliquer sur l'image pour l'agrandir)

En exécutant le contrôle d’accès, une telle entrée dans le jeton est uniquement utilisée pour refuser l’accès, en d’autres termes pour correspondre à un ACE de refus d’accès (DENY). Tous les ACE d’autorisation pour ce SID sont ignorés. Ceci signifie que vous n’êtes pas véritablement administrateur à tout moment, même si vous ouvrez une session sur le système en tant que tel.

Niveau d’intégrité

Windows prend maintenant en charge le libellé des processus et des objets avec des niveaux d’intégrité. Ces niveaux d’intégrité sont en fait également représentés comme des ACE, mais pas dans le DACL. Ils font au lieu de cela partie de la liste de contrôle d’accès du système (SACL), avec quelques indicateurs spéciaux. Par exemple, l’indicateur NW est utilisé pour indiquer le blocage d’un processus à un niveau d’intégrité plus bas pour l’écriture vers un objet de niveau d’intégrité plus élevé (SDDL_NO_WRITE_UP). Mark Russinovich explique ceci en détail dans son article « Au cœur du Contrôle de compte d’utilisateur de Windows Vista » de ce numéro de TechNet Magazine.

Conclusion

Bien qu’il n’existe aucune modification dramatique et unique du contrôle d’accès dans Windows Vista, comme c’était le cas dans Windows 2000, de nombreuses petites modifications ont été mises en place. Individuellement, elles peuvent ne pas être particulièrement remarquables mais, prises dans leur ensemble, elles signifient en fait que vous devez reconsidérer une grande quantité des opérations d’administration de votre système. De plus, ces modifications prennent en charge plusieurs autres initiatives, notamment le Contrôle de compte d’utilisateur et le renforcement de la sécurité de service. Certains administrateurs pourront être particulièrement embêtés lorsqu’ils commenceront à utiliser Windows Vista. J’ai déjà vu des commentaires tels que « systèmes d’exploitation tyranniques » qui limitent la capacité de supprimer des parties du système d’exploitation qui, pour une raison ou une autre, semblent gênantes. Cependant, toutes ces modifications s’appuient sur des raisons solides et, si vous passez quelques temps à analyser ce qui a été fait, vous comprendrez très probablement pourquoi.

Jesper Johansson est architecte sécurité pour une grande entreprise de commerce électronique, responsable de la stratégie de sécurité des applications de toute la gamme de propriétés et de services. Il a travaillé dans la sécurité pendant 20 ans et a écrit de nombreux articles et de deux livres sur la sécurité. Lorsqu’il ne travaille pas sur la sécurité des informations, il enseigne la plongée sous-marine.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.