Le Blog d’IMS

Tout d’abord je voudrais préciser que cet article est un peu plus technique que d’habitude. Il s’adresse en premier lieu aux développeurs soucieux de créer des logiciels respectant les normes de Windows Vista, il s’agit ici en particulier de la gestion de l’UAC. Mais j’ai essayé de faire une explication abordable à tous qui peut également aider à comprendre un petit peu mieux le fonctionnement de la sécurité de Vista.

Lorsqu’on développe pour Vista, outre la gestion technique du système, un nouveau concept est à prendre en compte : c’est la gestion de l’UAC. L’UAC (User Account Control) est une technologie déjà bien connue sur d’autres systèmes d’exploitation permettant de limiter les droits associés à un login (même et surtout s’il s’agit d’un login administrateur). Ainsi si vous tentez une action nécessitant des droits élevés, vous allez être « prompté » par le système, soit pour confirmer l’action, soit pour saisir un login administrateur.

Windows Vista arrive avec par défaut la mise en place de l’UAC et d’une virtualisation de certains dossiers et ruches du registre. Cela a un impact sur nos applications qui vont à l’avenir devoir s’adapter à ces contraintes. Non seulement l’application risque d’échouer, par un problème de droits insuffisants, mais en plus l’application va être « déroutée » par le système lors de tentatives d’écriture dans des répertoires sensibles, c’est que l’on appelle la virtualisation. Les écritures sont routées de manière transparente vers des dossiers ou des ruches par utilisateur, ce qui limite les corruptions éventuelles d’information dans ces dossiers et clés du registre. Vous trouverez des infos pertinentes sur ce sujet sur : http://blogs.msdn.com/uac/

Entre alors en jeu la notion des manifestes. Les manifestes permettent aux applications tournant sous Vista de préciser leur besoin en termes de droit et donc de travailler finement avec l’UAC. Les exécutables non compatibles UAC (c’est-à-dire qui n’incorporent pas de manifestes) sont toujours lancés avec des droits restreints et des privilèges minimum. Cela peut provoquer les problèmes qui existaient précédemment lorsque des programmes non conçus pour s’exécuter dans des contextes limités tentaient de manipuler des ressources système.

La question qui se pose à nous est de savoir quel manifeste choisir…

Voyons d’abord les possibilités :

• Pas de manifeste : Les applications vont fonctionner comme avant sous Windows XP en exploitant la « Virtualisation » de VISTA (Redirection des écritures dans des zones non autorisées).
• Manifeste Administrateur : à chaque lancement de l’application, l’UAC va se déclencher et demander une validation à l’utilisateur et si l’utilisateur courant n’est pas administrateur, un login et un mot de passe administrateur seront également demandés. Tous les droits seront ensuite accordés à l’application.
• Manifeste Privilèges maximum de l’utilisateur : l’UAC va demander confirmation à chaque lancement de l’exécutable. L’application aura ensuite tous les droits de l’utilisateur courant.
• Manifeste Utilisateur : L’UAC ne demande rien et l’application aura certaines limitations comme l’écriture à la racine du disque système (C:\), l’écriture dans le répertoire de Windows (donc attention à la gestion des .INI), l’écriture dans \Program Files\ (cela peut être contraignant si votre application utilise le répertoire courant des programmes pour les données), l’accès à la base de registre pour « HKEY_LOCAL_MACHINE », etc.

Lequel choisir ?  

• Dans la mesure du possible, il faut prendre comme objectif de créer une application qui fonctionne avec le manifeste Utilisateur car c’est celui qui impose le moins de contraintes à l’utilisateur. Nous adaptons donc nos applications pour respecter ces contraintes.
• Sauf dans certains cas précis il me semble peu recommandé d’utiliser le manifeste de Privilèges maximum de l’utilisateur car il faudrait être sûr de la suffisance du niveau de droits de l’utilisateur final de l’application.
• Enfin le manifeste Administrateur devient indispensable lorsque la manipulation du registre ou de certains répertoires s’impose.

Personnellement pour le confort d’utilisation j’ai choisi pour le moment désactiver l’UAC car trop peu de logiciels l’utilisent encore correctement. Cependant je pense qu’il est important de prendre en compte la gestion de l’UAC dans nos applications et d’éviter d’utiliser des systèmes ne fonctionnant que par compatibilité avec d’anciennes méthodes. Ce mécanisme bien que contraignant va certainement sécuriser les installations et donc a de grandes chances d’être imposé à de nombreux utilisateurs. IMS a donc choisi de livrer toutes ses applications aux normes VISTA dès aujourd’hui.

Partager cet article

Cet article a été publié le Lundi, 20 août 2007 à 9:14 par Jean-François CASANOVA et est classé dans Développement, NTIC. Vous pouvez en suivre les commentaires par le biais du flux RSS 2.0. Vous pouvez Laisser un commentaire, ou faire un trackback depuis votre site.