UAC est une architecture multi-composants implémentée par plusieurs binaires
Le contrôle de compte d'utilisateur (UAC) fait référence à plusieurs composants qui forment ensemble l' architecture UAC . J'examinerai brièvement certains d'entre eux ainsi que les binaires responsables de leur implémentation, mais voici d'abord un aperçu de l'architecture UAC de l'article Microsoft Docs Comment fonctionne le contrôle de compte d'utilisateur :
Autorité de sécurité locale (LSA) / jeton filtré
Conceptuellement, le «premier» composant de l'UAC est implémenté par le sous-système Local Security Authority qui gère la création du jeton d'accès d'un utilisateur pendant le processus de connexion. À partir de Windows Vista, le processus d'ouverture de session a été modifié de sorte que lorsqu'un administrateur ouvre une session avec l'UAC activé, le sous-système LSA génère deux jetons d'accès distincts pour l'utilisateur:
- Un avec un accès administrateur complet, et
- Un deuxième "jeton filtré" avec un accès utilisateur standard
Comme indiqué ici, ce processus est différent de celui d'une connexion utilisateur standard:
Le service de sous-système LSA vit dans le lsass.exe
processus.
Virtualisation
Ajouté dans Windows 7, la virtualisation des fichiers et du registre est un composant de l'UAC qui shims les applications plus anciennes qui ne sont pas conformes à l'UAC mais qui ne nécessitent que des droits administratifs pour accéder à certaines zones protégées du système de fichiers ou du registre:
Lorsqu'une application administrative qui n'est pas compatible UAC tente d'écrire dans un répertoire protégé, tel que Program Files, UAC donne à l'application sa propre vue virtualisée de la ressource qu'elle tente de modifier. La copie virtualisée est conservée dans le profil de l'utilisateur.
La source
En redirigeant ces tentatives d'accès vers des zones qui ne nécessitent pas d'autorisations d'administrateur, ces applications continuent de fonctionner même si l'UAC est activé sur le système.
Cette virtualisation est implémentée dans le noyau .
Service d'information sur les applications
Le service d'informations sur les applications (AIS) lit le manifeste d'une application et travaille avec l'invite de consentement UAC pour déterminer si une application est autorisée à s'exécuter avec des droits élevés (c'est-à-dire démarrer dans le contexte du jeton d'accès de niveau administratif non filtré créé à l'ouverture de session) . Ce billet de blog donne un bon aperçu de son rôle dans le processus UAC:
AIS Facilite l'exécution d'applications interactives avec des privilèges administratifs supplémentaires. Si ce service est arrêté, les utilisateurs ne pourront pas lancer d'applications avec les privilèges administratifs supplémentaires dont ils pourraient avoir besoin. Le shell vérifie auprès de ce service lors du lancement d'une application. AIS est celui qui lit le manifeste et la section xml 'trustInfo' qui a les exigences pour le 'requiredExecutionLevel' ...
Voici un graphique qui suit la citation ci-dessus détaillant le rôle d'AIS dans le processus d'invite de consentement UAC:
L'AIS est implémenté dans la DLLappinfo.dll
qui est exécutée par svchost.exe
.
Invite de consentement
La réponse de @ BenN explique le rôle clé de la (dans) la célèbre UAC Consent Prompt. Ceci est implémenté dans consent.exe
et est responsable de l'obtention du consentement de l'utilisateur ou des informations d'identification d'un utilisateur administratif afin de permettre le lancement d'une application nécessitant des droits d'administrateur.
Bureau sécurisé
Le bureau sécurisé est l'endroit où l'invite de consentement UAC s'affiche par défaut. L'UACBlog de Microsoft nous dit ce qui est unique à propos de ce bureau par rapport au bureau utilisateur:
Vous interagissez le plus souvent avec [le bureau sécurisé] lorsque vous vous connectez à Windows, car l'interface utilisateur d'ouverture de session s'exécute sur le bureau sécurisé. La principale différence entre Secure Desktop et User Desktop est que seuls les processus approuvés exécutés en tant que SYSTEM sont autorisés à s'exécuter ici (c'est-à-dire rien ne s'exécutant en tant que niveau de privilège de l'utilisateur) et le chemin pour accéder à Secure Desktop à partir du bureau utilisateur doit également être approuvé via toute la chaîne.
L'idée derrière son utilisation lors de la demande du consentement de l'utilisateur pour exécuter une application avec des autorisations élevées est que les logiciels malveillants ne peuvent pas imiter Secure Desktop à moins qu'il ne dispose déjà de droits administratifs, auquel cas inciter un utilisateur à les accorder est théorique.
Conclusion: UAC n'est pas seulement un binaire. C'est un tissu de sous-systèmes entrelacés.
Il y a encore d'autres aspects de l'architecture UAC non couverts ici, mais cela devrait fournir suffisamment de preuves pour les faits que:
- UAC n'est pas implémenté dans un seul binaire.
- S'il est activé, il fait partie intégrante de l'exécution des tâches administratives.
Depuis son introduction dans Windows Vista, il a été profondément intégré dans les parties clés du système d'exploitation, ce qui rend impossible la suppression de tout le code responsable de l'UAC sans casser d'autres choses (telles que votre capacité à vous connecter!)
Je pense qu'il est prudent de dire que si vous "supprimiez de force" l'UAC, vous briseriez Windows.