Uac windows et delphi

Disponible uniquement sur Etudier
  • Pages : 7 (1542 mots )
  • Téléchargement(s) : 0
  • Publié le : 6 décembre 2011
Lire le document complet
Aperçu du document
L’UAC et DELPHI

Avec l’arrivée de VISTA, nous avons eu pour la plupart d’entre nous quelques ennuis de compatibilité avec nos programmes ou ceux que nous utilisons. La faute à qui me direz-vous !

A l’UAC (Contrôle de compte utilisateur), c’est du moins ce que l’on entend un peu partout sur les forums

Depuis quelques temps, pas mal d’infos sont disponibles sur les solutions à cesproblèmes de compatibilité. Le but de cet article est de centraliser les informations disponibles et d’expliquer le plus simplement possible ce que fait l’UAC, pourquoi et comment elle le fait.

En découlera, pour nous programmeurs, ce qu’il est nécessaire d’ implémenter dans nos programmes Delphi, pour une prise en compte correcte de l’UAC et ainsi contribuer à la sécurité du système de nosutilisateurs.

Pourquoi UAC

La plateforme Windows a toujours été la cible de nombreux virus et autres joyeusetés. Placer judicieusement un verrou lorsque nécessaire est une action de nature à limiter l’exposition du système à du code malveillant.

La philosophie est assez simple. Elle se résume principalement en deux points :

1/ les données n’ont plus leur place dans certainsrépertoires comme program files, windows et system32 et dans une bonne partie de la registry.

Tout programme existant ne remplissant pas ce premier point ne se comportera pas sous VISTA de manière similaire à XP. Même avec le lancement du programme en mode administrateur vous n’avez aucune garantie que le code s’exécutera correctement, puisque :

Les écritures à destination d’un répertoireprotégé par L’UAC seront redirigées vers un répertoire virtuel situé sous \appdata\Local\VirtualStore….

Et

L’écriture des données à destination de la Registry subit le même sort. Elle est redirigée vers HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE.

Ces deux emplacements on été introduit pour assurer un certain niveau de compatibilité, force est de constater que même si ladémarche est louable, dans les faits il existe beaucoup trop de limites à ce dispositif pour être utilisé avec efficacité …

2/Que vous soyez utilisateur standard ou administrateur, tout lancement d’un processus devant accéder au système doit provoquer l’appel d’un écran de confirmation d’exécution. Deux boites de dialogues différentes assurent cette tâche. 

[pic]

En modeutilisateur, demande du mot de passe pour une élévation de privilège.

[pic]

En mode administrateur, une simple confirmation.

Important

C’est le processus (l’exe ou le COM) dans sa globalité qui fonctionne en mode administrateur ou utilisateur. N’envisagez donc pas d’avoir dans le même programme une partie du code demandant l’élévation de privilège administrateur. C’estau lancement du programme vous qu’il faut déterminer si le mode utilisateur standard suffit ou si le mode administrateur sera nécessaire.

Quelques règles de bonne conduite

Un ensemble de règles pour les nouveaux développements et bien sûr pour la reprise des anciens programmes peu facilement être appliqué.

1/Placer les données utilisateurs dans le répertoire de l’utilisateur ou dans unrépertoire commun.

2/ Séparation du code en deux exécutables (ou 1 exécutable + 1 composant COM ). Toutes les fonctions ne nécessitant pas une élévation de privilège seront placées dans le programme principal. Les fonctions réservées à l’administrateur seront regroupées dans le second programme. Le premier ou le second processus devra disposer d’un mécanisme d’élévation de privilège pour lesfonctions administrateurs.

3/Définir le niveau de sécurité que requière votre programme et créer un fichier manifest avec un des trois niveaux suivants (voir comment plus loin pour la création du fichier manisfest).

AsInvoker = le programme s’exécute avec le même niveau de droit que le parent.

HighestAvailable = l’application s’exécute avec les privilèges les plus hauts que...
tracking img