Vigilance sécuritéOutils de gestion des ACL
Jesper M. Johansson
Dans Windows, les listes de contrôle d’accès (ACL) vous offrent un contrôle très précis sur la possibilité des utilisateurs et des processus d’utiliser des ressources telles que les fichiers et les dossiers. La gestion des ACL peut constituer une des tâches les plus compliquées en ce qui concerne la protection de la sécurité des systèmes de vos utilisateurs. Heureusement, il existe plusieurs utilitaires avantageux
qui aident à automatiser et simplifier les tâches concernant les autorisations et les ACL.
La plupart des lecteurs connaissent l’outil apprécié cacls.exe qui est présent dans chaque version de Windows NT® depuis sa première publication. Si vous exécutez cacls.exe dans Windows Vista™, vous êtes accueilli par ce message :
Microsoft Windows [Version 6.0.5744]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
C:\Windows\system32>cacls
NOTE: Cacls is now deprecated, please use Icacls.
En plus des mises à jour des ACL dans Windows Vista (que j’ai abordées dans le numéro de juin 2007 de TechNet Magazine, voir technetmagazine.com/issues/2007/06), Microsoft a également mis à jour certains des outils que vous utilisez pour gérer les ACL. Il est intéressant de noter que les plus importantes de ces mises à jour sont les outils de ligne de commande.
Icacls.exe est nouveau dans Windows Vista (et également à un bas niveau dans Windows Server® 2003 Service Pack 2). Il remplacera par la suite cacls.exe, qui, comme vous le savez peut-être, n’a jamais été complètement mis à jour pour prendre en charge les autorisations plus précises introduites avec Windows® 2000, ce qui en fait une mise à jour ayant environ sept ans de retard.
Étonnamment, bien qu’il soit désapprouvé, cacls.exe inclut certaines nouvelles fonctionnalités. D’abord, il connaît les points de jonction et les liens symboliques et sait comment les traverser. Deuxièmement, il peut imprimer et déterminer un ACL à l’aide d’une chaîne de langage SDDL (Security Description Definition Language).
Cependant, malgré les mises à jour de cacls.exe, vous souhaitez vraiment disposer des fonctionnalités disponibles dans icacls.exe.
Enregistrement et restauration des ACL
Un souhait constant (du moins pour moi) ces dix dernières années a été la possibilité d’enregistrer un ACL de manière à pouvoir le restaurer à une date ultérieure. Ceci s’avère être une des opérations les plus compliquées à exécuter sur les ACL. Sauf dans certains cas spéciaux, il est peu probable de pouvoir retourner exactement à l’endroit où vous vous seriez trouvé si vous n’aviez pas, pour commencer, corrompu les ACL. Néanmoins, cette fonctionnalité peut être tout à fait utile.
Avant d’examiner comment enregistrer ou restaurer les ACL, laissez-moi d’abord expliquer pourquoi c’est si difficile. Supposons que vous ayez une hiérarchie contenant des données utilisateur pour les étudiants d’une université locale. Vous enregistrez l’ACL le 1er février. Le 17 avril vous découvrez que d’une certaine manière, l’ACL a été corrompu et que vous allez le restaurer à partir de la copie enregistrée. Quelles complications pourrait-il y avoir avec cette opération ?
D’abord, le nouveau trimestre a démarré le 2 avril. Environ 15 % de vos étudiants ont obtenu leurs diplômes. Par conséquent, leurs répertoires n’existent plus. Ainsi, dans le fichier de sauvegarde, certains ACL ne sont pas valides. Vous avez également un lot de nouveaux étudiants, encore 15 %, qui ont démarré ce trimestre. Maintenant ils possèdent des répertoires de base, mais aucun ACL dans le fichier de sauvegarde. Que doivent être leurs ACL ? Ensuite bien sûr vous avez les 70 % qui sont toujours là, mais ils ont créé de nouveaux fichiers et dossiers et en ont supprimés d’autres. Vous pouvez ignorer les dossiers supprimés, mais comment configurez-vous les nouveaux dossiers qu’ils ont créés ? Que se passe-t-il si un étudiant a décidé de partager un dossier avec ses amis le 4 mars ? Changerez-vous cela lorsque vous restaurerez l’ACL ?
L’enregistrement et la restauration des ACL ne sont pas des opérations aussi simples que beaucoup de gens voudraient vous le faire croire. Vous devez être extrêmement prudent en effectuant ces opérations. Par conséquent, il est très possible, même probable, que vous ayez un comportement incertain. La restauration des ACL constitue sans aucun doute un dernier recours. Plus la dernière sauvegarde est ancienne, plus la probabilité de détérioration est grande lorsque vous les restaurez.
Si néanmoins, vous souhaitez essayer cette fonctionnalité, exécutez icacls.exe avec le commutateur /save :
icacls <target> /save acls.bin /t
Cela permet d’enregistrer les ACL sur un fichier appelé acls.bin. Ce fichier contiendra une ligne pour chaque objet avec un ACL suivi d’une ligne spécifiant l’ACL dans le langage SDDL. En utilisant le commutateur /t, la commande agira sur l’objet que vous avez spécifié et tous les objets et conteneurs situés au-dessous de celui-ci.
La fonctionnalité d’enregistrement est un ajout bienvenu dans la boîte à outils, mais elle a quelques défauts. Par exemple, elle enregistre seulement la liste de contrôle d’accès discrétionnaire (DACL), pas la liste de contrôle d’accès de système (SACL). En fait, s’il existe un SACL, elle enregistre une valeur factice qui indique cela, mais n’enregistre aucune partie du SACL.
De plus, la façon dont l’ACL est enregistré crée un problème intéressant. Avant d’ouvrir l’ACL enregistré dans votre éditeur de texte préféré, rappelez-vous de ne pas
modifier votre ACL enregistré !
Si vous deviez ouvrir le fichier contenant votre ACL enregistré dans un éditeur de texte, vous trouveriez qu’il s’agit d’un fichier texte formaté Unicode (UTF-16). En fait, c’est presque de cela qu’il s’agit. Ceci pourrait vous faire penser que vous pouvez le modifier et l’enregistrer à partir d’un éditeur de texte. Ne le faites pas !
Si vous ouvrez le fichier qui contient les ACL enregistrés dans un éditeur de texte et l’enregistrez ensuite, vous ne pourrez pas restaurer les ACL à partir de ce fichier. En fait ce n’est pas un fichier texte Unicode. Ce fichier doit commencer avec les 2 octets 0xfffe. Si vous enregistrez le fichier avec un éditeur de texte, tel que le Bloc-notes, il mettra cet indicateur dans le fichier dans les deux premiers octets. Cependant, l’outil icacls.exe suppose que les données ACL démarrent à l’octet 0 dans le fichier. Par conséquent, l’outil ne pourra pas traiter les ACL dans le fichier comme il suppose que les deux premiers octets font partie de la chaîne spécifiant l’objet sur lequel effectuer les opérations. Votre fichier de sauvegarde sera inutilisable.
Microsoft est conscient de ce problème, mais comme il n’a été signalé que très tard dans le cycle bêta pour Windows Vista, ce défaut n’a pas été corrigé avant la sortie. À ce stade, nous ne savons pas quand il sera corrigé, ni même s’il le sera. Donc pour le moment, le meilleur conseil est de ne pas modifier vos ACL enregistrés. Si vous avez besoin de le faire, enregistrez le fichier comme fichier .bin et utilisez un éditeur hexadécimal, comme par exemple votre environnement de développement préféré.
Une fois que vous avez enregistré un ACL à l’aide du commutateur /save, vous pouvez le restaurer en utilisant icacls.exe avec le commutateur /restore. La commande de restauration dans sa forme la plus simple utilise cette syntaxe :
icacls <directory> /restore acls.bin
La procédure de restauration ne fonctionne pas sur les fichiers. Pour voir cela, examinez la séquence de commandes illustrée à la figure 1. Ici je crée un fichier d’enregistrement en pointant icacls.exe vers un fichier. J’essaie ensuite de le restaurer en remplaçant simplement /restore par /save. Cela échoue parce que la commande de restauration ne fonctionne que sur les répertoires. Les fichiers qu’elle est supposée modifier sont déjà spécifiés dans le fichier acls.bin. Pour restaurer l’ACL, je le pointe vers le répertoire au lieu du fichier. C’est ce que je fais dans la dernière commande où je spécifie « . » comme l’objet sur lequel effectuer les opérations.
Figure 1 Enregistrement et restauration des ACL
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls test.txt /restore acls.bin
test.txt\test.txt: The system cannot find the path specified
Successfully processed 0 files; Failed processing 1 files
C:\Users\Jesper>icacls . /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
Notez également que la commande de restauration doit être exécutée dans le mode élevé ! Vous pouvez exécuter la commande d’enregistrement d’une invite de commande s’exécutant comme utilisateur à faible privilège ou même comme utilisateur standard, tant que vous avez le droit de lire l’ACL. Cependant, pour restaurer l’ACL, vous devez disposer d’un jeton administratif complet et non corrompu.
Remplacement des SID
Une autre fonctionnalité qui est très utile dans icacls.exe, est la possibilité de remplacer les autorisations d’un utilisateur par des autorisations d’un utilisateur différent. Cela s’effectue pendant la restauration à l’aide du commutateur /substitute. La documentation du commutateur de remplacement indique qu’il a besoin d’un SID, mais plus tard elle explique que cela peut en fait être un nom d’utilisateur normal. Ainsi, la séquence illustrée à la figure 2 fonctionne.
Figure 2 Remplacement des SID pendant la restauration
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\foo:(R,W)
VistaRC2-Test\Jesper:(I)(F)
NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls. /substitute foo bar /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\bar:(R,W)
VistaRC2-Test\Jesper:(I)(F)
NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
Successfully processed 1 files; Failed processing 0 files
Comme vous pouvez le voir, je me retrouve avec l’ACL que j’avais avant, mais l’ACE qui spécifiait les autorisations pour foo les spécifie maintenant pour bar à la place.
Modification du propriétaire
L’outil chown a été un élément de base des systèmes UNIX pendant des années. Windows n’avait pas eu au départ de mode intégré pour modifier le propriétaire d’un objet. Puis l’outil setowner a été intégré dans le Kit de ressources. Ensuite l’outil takeown.exe a été fourni dans Windows NT 4.0, mais cet utilitaire vous permettait seulement d’obtenir la propriété, pas d’accorder celle-ci à d’autres à moins que vous ayez leur mot de passe. Maintenant icacls.exe intègre la possibilité de définir le propriétaire d’objets sur lesquels vous avez l’autorisation de définir le propriétaire :
C:\>icacls c:\test /setowner foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
Malheureusement, icacls.exe ne peut pas afficher le propriétaire d’un objet. En fait, il n’y a aucun moyen d’afficher, à partir de la ligne de commande, le propriétaire d’un objet. De plus, si vous enregistrez l’ACL pour un objet, il n’enregistre pas le propriétaire de l’objet.
icacls.exe contient un bogue qui empêche d’invoquer SeTakeOwnershipPrivilege pour modifier le propriétaire. Si vous avez le droit de modifier le propriétaire d’un objet basé sur l’ACL, icacls.exe fonctionne correctement. Cependant, si vous êtes administrateur, mais que vous n’êtes pas autorisé à modifier le propriétaire basé sur l’ACL de l’objet, vous ne pouvez pas utiliser icacls.exe pour le faire à cause de ce bogue. Dans ce cas, vous devez utiliser l’outil takeown.exe, qui invoque SeTakeOwnershipPrivilege, mais peut seulement modifier le propriétaire de votre compte ou du groupe Administrateurs, pas d’un compte arbitraire :
C:\>takeown /f c:\test
SUCCESS: The file (or folder): “c:\test” now owned by user “JJ-VistaRTMTst\Jesper”.
Notez, bien sûr, que l’outil subinacl, qui est téléchargeable à partir du centre de téléchargement Microsoft, possède également un commutateur setowner. Subinacl fonctionne en fait plus intuitivement que icacls dans de nombreux cas, mais il est également beaucoup plus compliqué à utiliser.
Recherche de fichiers pour un utilisateur particulier
Icacls possède une autre fonction utile : il peut trouver des fichiers possédant des autorisations pour des utilisateurs particuliers. Par exemple :
C:\windows\system32>icacls “c:\program files” /findsid jesper /t
SID Found: c:\program files\Passgen\
passgen.exe.
Successfully processed 1808 files; Failed processing 0 files
Cela peut être utile si vous essayez de savoir à quoi un utilisateur particulier pourrait avoir accès.
Réinitialisation et modification des ACL
Si un ACL est corrompu ou détruit, icacls.exe peut le réinitialiser pour hériter de son parent. Cela aurait été extrêmement utile pour une menace sur la sécurité, zero-day, qui a eu lieu à l’automne 2006. L'une des méthodes utilisée pour résoudre le problème dans un composant Windows a été de refuser à tout le monde l’accès à l’objet. Cette partie était facile, mais la suppression de cette entrée de contrôle d’accès (ACE) était pratiquement impossible à l’aide d’outils intégrés dans Windows XP et Windows Server 2003. Cependant, dans Windows Vista, il suffit d’exécuter cette commande :
C:\windows\system32>icacls “c:\program files\passgen\passgen.exe” /reset
processed file: c:\program files\passgen\passgen.exe
Successfully processed 1 files; Failed processing 0 files
Icacls.exe, dispose, bien entendu, de toutes les opérations grant/deny/remove. Le seul nouvel élément dans cette liste est remove. À l’aide de ce commutateur, vous pouvez supprimer tous les ACE d’autorisation, tous les ACE de refus d’accès, ou les deux, pour un utilisateur donné d’un objet ou d’une hiérarchie spécifique. La figure 3 présente des exemples de différentes opérations grant, remove et deny.
Figure 3 Opérations grant, deny et remove
C:\>icacls c:\test /grant foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test /remove:g foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test /deny foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(N)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test /remove:d foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
La possibilité de supprimer uniquement les ACE de refus d’accès peut être très utile si vous souhaitez ouvrir l’accès d’un objet à un groupe ou un utilisateur particulier.
Configuration de niveaux d’intégrité
Icacls.exe a également la capacité d’afficher et de définir des niveaux d’intégrité. Windows Vista prend en charge l’affichage d’étiquettes d’intégrité sur les objets. Icacls.exe est l’outil de ligne de commande à utiliser pour cela :
C:\>icacls c:\test /setintegritylevel high
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Mandatory Label\High Mandatory Level:(NW)
Successfully processed 1 files; Failed processing 0 files
Notez que icacls.exe n’affiche l’étiquette d’intégrité que si un objet est doté d’une étiquette explicitement définie. Ce n’est pas le cas pour la plupart des fichiers, donc il est rare de voir des étiquettes.
Enfin, icacls.exe peut vérifier qu’un objet possède un ACL canonique. Comme mentionné précédemment, les outils tiers sont connus pour placer les ACE dans le desordre dans les ACL. Icacls.exe peut vérifier et réparer ces types de problèmes, comme indiqué ici :
C:\>icacls c:\test /verify
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
Interface utilisateur de l’ACL
L’IU de l’ACL, ou l’interface utilisateur de l’ACL, a été légèrement modifiée par rapport à celle de Windows XP. Les figures 4 et 5 présentent les boîtes de dialogue de l’interface utilisateur de l’ACL de Windows XP et de Windows Vista, respectivement.
Figure 4** Boîte de dialogue de l’interface utilisateur de l’ACL dans Windows XP **
Figure 5** Boîte de dialogue de l’interface utilisateur de l’ACL dans Windows Vista **
Comme vous pouvez le voir, quelques modifications ont eu lieu ici. Tout d’abord, la boîte de dialogue affiche très clairement l’objet sur lequel porte l’opération, ce qui peut être utile si vous traitez plusieurs objets à la fois. Deuxièmement, il existe un lien hypertexte vers l’aide en bas. Cependant, le changement le plus notable est la suppression des boutons Ajouter et Supprimer remplacés par le bouton Modifier qui est principalement présent pour la prise en charge du contrôle d’accès d’utilisateur (UAC) dans Windows Vista. Comme vous pouvez le voir par l’icône de protection placée sur le bouton, l’utilisateur qui a lancé cette boîte de dialogue n’a pas l’autorisation de modifier l’ACL et donc nécessitera une élévation avant de pouvoir modifier les autorisations. Notez que cela n’est pas la valeur par défaut si vous créez un dossier dans la racine du lecteur C: et vérifiez tout de suite les propriétés de celui-ci. En tant que propriétaire du dossier, vous auriez des autorisations implicites pour modifier l’ACL et la protection manquerait. La protection représente un nom COM qui est un mécanisme utilisé pour lancer une invite d’élévation pour une partie d’un processus en cours d’exécution. Si vous cliquez sur le bouton Modifier, vous obtenez la boîte de dialogue d’élévation familière, et si dans celle-ci vous cliquez sur Continuer, vous obtenez une boîte de dialogue presque identique à celle qui s’ouvre dans Windows XP en cliquant sur le bouton Ajouter. L’interface utilisateur de l’ACL suit ce concept de double dialogue à plusieurs emplacements. Vous obtenez une boîte de dialogue jusqu’à ce que vous éleviez les privilèges, puis une fois que c’est fait, vous obtenez la boîte de dialogue familière des versions précédentes de Windows.
Si vous cliquez sur le bouton Avancé puis sur l’onglet Audit, vous obtenez toujours un bouton d’élévation, comme illustré à la figure 6. Vous ne pouvez pas modifier l’audit sans élévation, même si vous disposez du contrôle total sur l’objet et que vous êtes le propriétaire. C’est parce que la capacité de modifier un objet SACL est régie par le privilège SE_SECURITY_NAME, nommé « Gérer le journal d’audit et de sécurité » dans les outils d’interface graphique. Seuls les administrateurs possèdent ce droit par défaut. Cependant, le privilège est retiré à un administrateur dans le mode Approbation administrateur (lorsque l’UAC est activé), ce qui nécessite l’élévation même si vous êtes administrateur.
Figure 6** La modification des paramètres d’audit dans Windows Vista nécessite toujours une élévation **
Une remarque finale sur la nécessité d’élévation lorsque vous modifiez les ACL : toutes ces stratégies sont déterminées par le fait que vous n’avez pas désactivé l’UAC. Si vous désactivez l’UAC, tous les comportements reviennent à ceux de Windows XP, à l’exception des boîtes de dialogue qui paraissent différentes. Cependant, aucune élévation ne sera nécessaire si vous ouvrez une session en tant qu’administrateur, puisque maintenant le SID des administrateurs sera toujours présent dans le jeton.
Autres outils
Icacls.exe est un outil très utile et constitue une amélioration majeure par rapport à cacls.exe, mais il possède encore des défauts. Le plus notable est sans doute qu’il ne peut pas gérer l’accès aux objets autres que les fichiers et les répertoires. Windows Vista fait peu de modifications aux ACL d’autres objets par rapport à Windows XP, mais il existe encore des occasions où vous souhaitez gérer des ACL dans un service, une clé de registre ou même un objet Active Directory®.
Si vous êtes un fan de lignes de commande, il vous faut pour cela subinacl.exe. Subinacl.exe fait partie des outils de support et est également disponible en tant que téléchargement.
Cependant, je dois vous avertir que subinacl.exe n’est pas facile à utiliser. En effet, il est parfois complètement obscur. Cependant, subinad.exe est un outil incroyablement puissant pour gérer le contrôle d’accès. Chaque administrateur avec pouvoir a besoin de cet outil.
Les ACL de registre
Les ACL de registre ont subi des modifications tout comme les ACL de système de fichiers. Néanmoins, ces modifications sont beaucoup moins importantes que celles apportées au système de fichiers. La différence la plus évidente avec les versions précédentes de Windows est que, en raison de la désapprobation des Utilisateurs avec pouvoir, presque tous les ACE des utilisateurs avec pouvoir ont disparu. Les utilisateurs avec pouvoir ne sont pas censés être plus puissants que les autres utilisateurs. Cela démontre à quel point les ACL sont compliqués, même si tous les ACE pour les Utilisateurs avec pouvoir n’ont pas disparu. Quelques-uns ont malheureusement été oubliés.
Lorsque vous examinez les ACL dans le Registre, vous voyez à certains emplacements un ACE pour un SID RESTREINT. Ce n’est pas nouveau dans Windows Vista, mais c’est un SID intéressant et incompris. Le SID RESTREINT désigne un processus qui présente un jeton restreint. Un jeton restreint est créé en utilisant une fonctionnalité spéciale de l’API CreateRestrictedToken. Ce jeton possède un ou plusieurs SID restreints utilisés dans une vérification d’accès séparée. Imaginons que nous avons un processus s’exécutant avec un jeton limité. Si ce processus tente d’accéder à un objet avec un ACE pour le SID RESTREINT, Windows exécute deux vérifications d’accès. La première est la vérification d’accès normale. La seconde fonctionne exactement comme la première, mais a lieu seulement par rapport aux SID restreints dans le jeton. Les deux vérifications d’accès doivent réussir.
Actuellement, il existe plusieurs ACL qui utilisent le SID RESTREINT, en particulier sur le registre. Une capture d’écran de ce type d’ACL est illustrée à la figure 7.
Figure 7** Les ACL de Registre incluent un ACE pour RESTREINT à plusieurs emplacements **
En ce moment, peu de processus utilisent la fonctionnalité de jeton restreint, en particulier pour ce qui concerne les SID restreints. Un exemple de processus qui utilise cette fonctionnalité est le processus de service qui héberge le pare-feu Windows, le moteur de filtrage de base et le service de stratégie des diagnostics. Il utilise également un jeton d’écriture restreinte. D’après mes découvertes, seuls neuf services utilisent actuellement des jetons RESTREINTS et d’écriture restreinte dans Windows Vista.
Comme avec les versions précédentes récentes de Windows, concernant les autorisations de registre, il est conseillé de procéder avec prudence. Sauf circonstances exceptionnelles et extrêmement ciblées, ne modifiez pas les autorisations dans le Registre. Compte tenu du modèle compliqué d’héritage et des opérations sensibles exécutées sur le registre, la probabilité de défaillance fatale est particulièrement élevée, si vous modifiez négligemment des ACL dans le registre.
Résumé
Comme avec la plupart des versions de Windows, il existe certaines modifications subtiles pour accéder au contrôle dans Windows Vista. Cependant, contrairement à certaines des autres versions récentes, il existe en fait beaucoup de modifications mineures qui s’ajoutent à une modification assez significative de comportement. L’UAC, en particulier, a nécessité plusieurs modifications, telles que les étiquettes d’intégrité et les modifications apportées à l’interface utilisateur des ACL. De plus, il s’agit historiquement du premier nettoyage majeur des ACL.
D’une manière générale, les ACL par défaut dans Windows sont simplifiés dans Windows Vista, ce qui n’était jamais arrivé auparavant. Comme avec les versions précédentes, cependant, vous devez procéder avec beaucoup de prudence concernant le contrôle d’accès pour en obtenir une compréhension exhaustive. C’est surtout vrai avec les nouvelles versions du système d’exploitation. Espérons que les outils présentés dans cet article faciliteront votre exploration des ACL.
Jesper M. Johansson est ingénieur de sécurité principal, chargé des problèmes de sécurité de logiciel et contribue à l’élaboration de TechNet Magazine. Il est titulaire d’un doctorat en systèmes d’information de gestion et possède plus de 20 ans d’expérience dans le domaine de la sécurité informatique. Cet article est une adaptation du nouveau livre de Roger Grimes et Jesper Johansson, Windows Vista Security: Securing Vista Against Malicious Attacks (Wiley, 2007).
© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.