Toute information donnée ici est basée sur des tests effectués sur les différentes versions béta de Windows Vista (principalement les builds 5308 et 5342). Ces informations peuvent être modifiées ou n'être plus valides du jour au lendemain. Prenez-les à leurs justes valeurs informatives.

Lorsqu'un logiciel malveillant s'exécute sur un environnement Windows, il le peut la plupart du temps grâce aux privilèges administrateur dont dispose la session utilisateur en cous d'exécution sur le PC ciblé. Nous savons tous qu'il faudrait travailler dans nos tâches quotidienne depuis un compte utilisateur sans privilèges, et ne se logger en administrateur que pour les tâches le nécessitant. Il est, avec les systèmes Windows actuels, aujourd'hui quasiment impossible de fonctionner de cette manière. Il semble en effet complexe de travailler sans perte de temps sans pouvoir exécuter des taches "simples" comme l'installation de driver ou le changement de la résolution de l'écran.

Néanmoins, le principe d'utilisateur à moindre privilège est une des solutions les plus efficace contre les logiciels malveillants, en effet si une application quel qu'elle soit n'a pas accès aux couches sensibles, la présence de virus ou de malware devient immédiatement moins gênante car ne remet plus en compte la sécurité d'intégrité de la machine, outil de travail nécessaire à beaucoup de nos activités professionnelles.

L'utilisation personnelle des PC nécessite aussi et souvent des privilèges élevés, installer un logiciel ou jouer à un jeu demande et requière des écritures dans des répertoires sensibles (Program Files par exemple). Il est aujourd'hui complexe de les exécuter depuis un compte limité (fonction dite de Run As).

Les utilisateurs d'appareils mobiles se retrouvent souvent confrontés au besoin d'accéder à des fonctions avancées de leurs systèmes : Gestion de l'énergie, installation de driver (imprimante), résolution et configuration matériel simple,...

Il semble donc évidant qu'une utilisation massive de Windows avec des compte de moindre privilège passait par une étape importante et nécessaire de redéfinition des spécificités de ces comptes appelés aujourd'hui limités (mais qui ne sont plus "limités" sous Vista), ceci afin d'obtenir une sécurité importante sans pour autant être un frein à l'utilisation du système.

La réponse à cette problématique de Microsoft dans Windows Vista passe par UAC, UAC pour User Account Manager. Anciennement connu sous le nom de LUA : Limited User Account, mais la notion de "limited" n'ayant plus lieu d'être, celle ci a été supprimée de la désignation.

L'UAC est un ensemble de fonctionnalité permettant à un utilisateur disposant de privilèges élevés d'utiliser sa machine dans un environnement encadré et sécurisé de manière intuitive et clair.

Tous les utilisateurs fonctionnent sans privilège (y compris les comptes dépendant du groupe administrator), en effet les taches courantes sont exécutées sans ces privilèges. Il y aura donc une transition vers les privilèges administrateur lorsque ces dernier seront nécessaires, cette transition passera toujours par une confirmation utilisateur (ce dans la configuration par défaut, elle est désactivable comme vu plus loin).

Il existe deux actions pour disposer de privilèges administrateurs :

- Depuis un compte de moindre privilège, lors d'une action nécessitant les privilèges en entrant les login et mot de passe d'une session administrator de la machine :

- Depuis un compte Administrator, en validant l'utilisation de ses privilèges à l'écran :

Les droits d'utilisateur "standard" ont été revus et redéfinis, en effet accéder au fuseau horaires, régler la gestion de l'alimentation, modifier la résolution de l'écran, installer un driver (imprimante), ajout d'une clé WEP ... ne réclameront plus de privilèges administrator, cette nouvelle architecture rend plus facilement utilisable les comptes de moindre privilège lors une utilisation quotidienne.

L'interface a été également retravaillée, les éléments non accessibles ont été cachés et remplacés par un bouton proposant de se logger en tant qu'administrateur, bouton identifiable facilement par le bouclier multi-color de la sécurité sous Windows. Pour encourager l'utilisation de compte utilisateur (sans privilèges particulier) lors de la création d'un nouveau comte le choix par défaut sera "utilisateur" et non plus "administrateur". La détection des exécutables "installeur" simplifie également l'utilisation, cette détection se traduit notamment par l'ajout (par Windows) d'un bouclier sur l'icone de ces installeurs.

LSASS gère les privilèges, chaque SID appartient à un groupe, à chaque SID on peut associer un ou plusieurs des 24 privilèges dont dispose Windows VISTA. On moment du log, un jeton disposant des privilèges administrateur est créé, mais un second jeton est aussi généré avec des privilèges semblables aux comptes de moindre privilège, c'est ce second jeton qui sera utilisé par défaut, pour utiliser les privilèges du jeton "complet" il faudra passer par : clique droit -> Run as Administrator. Option disponible en administrator dans les propriétés pour un "Run As permanent".

Exemple, voici deux Bloc-notes qui ont été lancé, l'un sans privilège, l'autre avec les privilèges administrator, depuis une session administrateur. Le premier dispose des éléments de sécurité similaire à ceux d'un utilisateur de moindre privilège, le second de tous les privilèges de l'utilisateur administrateur qui est loggé. On remarquera dans le cas de l'utilisateur de moindre privilège hérite tout de même des interdictions (deny) du compte administrator dont il gère les tâches courantes :

Un bureau séparé gérera les affichages de demande d'élévation de privilège, de cette manière il sera nettement plus complexe pour les applications malveillantes d'interagir avec cette fenêtre et valider l'élévation de privilège.(pas encore en place sur la build 5342)

Pour gérer UAC, 6 nouveaux paramètres sont réglables dans les options de sécurités :

-Comportement de la demande d'élévation de privilège : prompt / redemande log - mot de passe / always enabled
-Type d'interface (pour acquerir les privilèges d'un administrateur) pour les utilisateur standard : no request / saisie de log _ mot de passe
-Détection des installeurs : enabled / disabled
-UAC : enabled/disabled
-Vérification de signature de .exe : enabled / disabled
-Virtualisation des fichiers et registre : enabled / disabled

La signature des exécutables prend aussi part dans UAC, en effet le liseré supérieur de la fenêtre de demande de privilèges administrateur sera grisé si l'éditeur est connu, et orange-rouge si inconnu :

Afin de présenter une compatibilité importante avec les applicatifs nécessitant des privilèges élevé, Microsoft a choisi la solution de la virtualisation.

La virtualisation garantie la compatibilité, en permettant l'écriture sur program files ou dans le registre du point de vue DU LOGICIEL, alors qu'en réalité on retrouve ces écritures dans c:.../AppliData/local/VirtualStore/... donc sans impact sur le fonctionnement de la machine.
La lecture se fait d'abord dans le répertoire virtuel et ensuite dans les répertoires réels, ainsi Microsoft annonce 95 % de compatibilité avec les applicatifs existants pour le grand publique.

Afin d'aider les entreprises dans la définition de la compatibilité de leurs applicatifs sous Windows Vista, Microsoft proposera en parallèle à la sortie de Vista un Kit de compatibilité, ce dernier se présentera comme un ensemble de logiciels et d'utilitaires. Citons par exemple UAC Predictor, qui permettra de prévoir si la virtualisation sera supportée ou non par un applicatif existant.

Les répertoires et registres ne sont pas tous virtualisables, d'autre part si les précédentes conditions sont respectées il faut que les applications puissent être virtualisables (les applications sont par défaut virtualisables sauf : les Installeurs, les processus et applications System, et les applications marquées par les éditeurs)

Un grand nombre d'attaques et de failles vient de la capacité d'application de moindre privilège de prendre la main sur une application de haut niveau, et de se servir de ses accès élevés dans des buts malveillants. Pour combattre cette situation, Vista gérera ses niveaux de privilège du point de vue applicatif de manière intègre et indépendante dans l'ascendance des communications entre applications.

En effet, une application de moindre privilège ne pourra en aucun cas écrire dans une application de privilège supérieur. A ce titre et pour l'exemple, une application comme le clavier virtuel lancé en privilège utilisateur ne pourra en aucun cas écrire dans un bloc-notes lancé avec des privilèges administrateurs.

Le MIC est donc une succession de couches d'intégrités : Limité / Moindre privilège / Privilège administrator / Execution System / Execution Driver / Driver Microsoft / Noyau ... Chaque application lancée dans une couche d'intégrité ne peut pas envoyer d'information à un applicatif de privilège supérieur.

Ce contrôle d'intégrité permet notamment de protéger le système des attaques de type injection de DLL ou encore de type Shatter.

Cependant, cette vérification d'intégrité ne bloque que les écritures ascendantes en terme de privilèges, il ne bloque en aucun cas les tentatives de lecture ascendante, ce risque de sécurité en terme de confidentialité doit donc toujours être pris en compte.

Dans le même souci de sécurité, deux objets graphiques ne pourront communiquer que s'ils disposent du même niveau de privilège. Afin de ne pas bloquer le fonctionnement applicatif, les nouveaux logiciel Microsoft sous Vista étant exposés en terme de sécurité sont développés en deux modules, le premier qui s'exécute avec un haut niveau de privilège, et un second, de moindre privilège qui gère les aspects graphiques et interface avec l'utilisateur.
Par exemple IE7 s'exécute sous deux process, le process de bas niveau ieuser.exe de privilège élevé, et iexplorer.exe de moindre privilège, qui gère l'affichage graphique.

Vista va marquer un tournant dans l'histoire du système d'exploitation Windows, et ce, en limitant de manière significative l'utilisation permanente de privilèges administrateurs. En réorganisant la communication entre application il etait impossible d'assurer une compatibilité avec l'ensemble du parc logiciel existant, mais la virtualisation répond a beaucoup de ces problèmes, et selon moi, le gain en sécurité est assez significatif pour justifier ces problèmes de compatibilité.