Sous Windows, si je refuse la demande UAC d'une application, pourquoi ne doit-elle pas continuer à fonctionner?

Venant d'un arrière-plan Linux / Unix, je ne comprends pas comment fonctionne l'UAC sous Windows.

J'ai entendu dire que l'UAC fonctionne comme sudo. Mon application Linux peut faire un autre travail avant d'appeler sudo.

Mais dans Windows, il semble que toutes les applications qui nécessitent une confirmation UAC doivent avoir UAC accordée avant de faire un travail réel! Je lance une application, il me demande une confirmation UAC et je la refuse - l'application ne fonctionnera tout simplement pas.

L'UAC fonctionne-t-il ainsi?

sudo su
./run_app

Plutôt que:

./do_work1
sudo su
./du_work2

Merci pour la bonne réponse de tout le monde!

Lorsque vous vous connectez à Windows en tant qu'utilisateur standard, une session de connexion est créée et un jeton contenant uniquement les privilèges les plus élémentaires est attribué. De cette façon, la nouvelle session d'ouverture de session est incapable d'apporter des modifications qui affecteraient l'ensemble du système. Lors de la connexion en tant qu'utilisateur dans le groupe Administrateurs, deux jetons distincts sont attribués. Le premier jeton contient tous les privilèges généralement accordés à un administrateur, et le second est un jeton restreint similaire à ce qu'un utilisateur standard recevrait. Les applications utilisateur, y compris Windows Shell, sont ensuite démarrées avec le jeton restreint, ce qui entraîne un environnement de privilèges réduits même sous un compte d'administrateur. Lorsqu'une application demande des privilèges plus élevés ou que "Exécuter en tant qu'administrateur" est cliqué, l'UAC demandera une confirmation et, si le consentement est donné,

D'après ce que je comprends, ce que signifie cette dernière phrase est que la boîte de dialogue UAC est affichée avant le chargement de l'application afin qu'elle soit démarrée avec le jeton sans restriction, ou bien si elle est démarrée avec des privilèges utilisateur standard et nécessite des privilèges élevés entre certains pour certains travail, il doit obtenir le consentement de l'utilisateur, puis générer un nouveau processus qui s'exécute ensuite avec des droits élevés . Le jeton attribué au démarrage d'un processus détermine ses droits. Ce jeton ne peut pas être modifié ultérieurement, donc si plus de droits sont requis, un nouveau processus doit être généré.

De cette façon, UAC n'est pas exactement le même que sudo .

Sous Windows, l'invite UAC est déclenchée lorsque vous essayez d'exécuter un exécutable marqué comme nécessitant une élévation dans un manifeste incorporé dans le fichier et que vous n'exécutez pas déjà avec élévation. Le comportement ressemble plus à setuid qu'à su dans la mesure où c'est le fichier, pas la commande qui indique au système d'exploitation que l'exécutable doit être exécuté avec des informations d'identification différentes.

C'est parce qu'ils sont différents, simples et simples. L'UAC aurait pu être implémenté comme ça sudo, mais ce n'était pas le cas.

Vous pouvez le considérer comme une analogie avec la protection du réseau.

sudoc'est comme lorsqu'un programme demande un accès au réseau et que votre pare-feu vous invite à l'accorder ou non. Vous pouvez dire oui et le programme ouvrira le socket, ou vous pouvez dire non et il se plaindra d'un manque de connexion et fera tout ce qu'il peut faire sans accès au réseau (certains programmes mal conçus se bloquent en fait). Par exemple:

function1();
input();
function2();
secure_operation(); //requests access
function3();        //may depend on results of previous operation; error-checking important

UAC ressemble plus à l'avertissement que vous obtenez lorsque vous essayez d'ouvrir un fichier qui a été téléchargé sur un volume NTFS. Windows vous avertit des problèmes potentiels et vous demande si vous souhaitez l'exécuter (pas du tout) ou non. C'est une opération tout ou rien; vous ne pouvez pas choisir de ne faire confiance qu'à une partie du programme et pas aux autres. Par exemple:

if (requires_high_priv(program)) {
  if (request_priv(program))
    program();
}
else {
  program();
}

Vous devez vous rappeler que contrairement à Linux qui est davantage orienté vers les utilisateurs et les applications avancés, Windows est conçu pour être convivial pour le plus grand nombre d'utilisateurs possible, donc la simplification de la sécurité est primordiale. De plus, en raison de sa grande surface d'exposition, c'est une cible fréquente pour les logiciels malveillants, il est donc plus logique de faire entièrement confiance à un programme ou pas du tout.

Je ne connais pas bien l'architecture linux, alors pardonnez-moi si je fais une erreur, mais ma compréhension est que Linux et Windows ne sont pas du tout différents à cet égard ...

Un exemple ... Un script de copie qui fait une copie d'un fichier normal vers un emplacement non protégé et un fichier essayant de copier vers un emplacement protégé, puis une copie régulière à nouveau.

D'après ce que je comprends, sous Linux, une application s'exécute simplement et essaie de faire une action - si elle n'a pas l'autorisation de faire cette action - elle échouera, mais continuera. Dans l'exemple ci-dessus - lors de l'exécution du script de copie sous Linux en tant qu'utilisateur normal, il copiera le fichier normal, donnera un problème d'autorisation et copiera le deuxième fichier - s'il est exécuté avec sudo, il fera les trois copies.

Windows est exactement le même à cet égard - l'exécution du script en tant qu'utilisateur non administrateur en copiera simplement un, autorisera le second et copiera le suivant. Avec l'UAC, il fonctionnera tous les trois.

La différence est que de nombreuses applications Windows ont simplement un ensemble de configuration afin qu'elles demandent l'élévation UAC par défaut et quittent / échouent si elles ne l'ont pas .... mais, cela devient beaucoup moins.