Si un cmd.exe Windows s'exécute avec des privilèges élevés, tout ce que j'exécute à partir de son invite s'exécute-t-il également avec des privilèges élevés?

11

Si ma fenêtre cmd.exe indique "Administrateur" dans la barre de titre, indiquant qu'elle a été démarrée avec des privilèges élevés, cela signifie-t-il que tout ce que j'exécute à partir de cette fenêtre de commande est également exécuté avec des privilèges élevés?

Plus précisément, si je lance quelque chose comme:

msiexec SomeProgram.msi

mon programme d'installation s'exécute-t-il avec des privilèges élevés, car il a été exécuté à partir d'un cmd.exe qui s'exécutait avec des privilèges élevés?

Plus précisément: je me demande si les applications qui présentent une interface utilisateur et renvoient immédiatement l'invite dans la fenêtre cmd.exe, comme l' msiexecappel ci-dessus, s'exécutent avec des privilèges élevés.

windows-7 windows command-line administrator uac Ian C.
la source

Réponses:

16

Oui, il s'exécute avec des privilèges élevés.

Test simple:

Vous pouvez tester cela assez facilement en ouvrant une invite de commande élevée et une invite de commande non élevée. Exécutez la commande notepad.exedans les deux et essayez d'enregistrer un fichier texte vide dans C:\Windows. On va enregistrer, on va lancer une erreur de permissions.

Test approfondi:

Si cela ne suffit pas pour le confirmer (cela ne m'a pas vraiment satisfait), vous pouvez utiliser AccessChk de SysInternals. Vous devrez l'exécuter à partir d'une invite de commandes élevée.

Commençons par vérifier les deux processus du Bloc-notes en cours d'exécution:

Bloc-notes: ( accesschk.exe -v -p notepad)

[11140] notepad.exe
  Medium Mandatory Level [No-Write-Up, No-Read-Up]
  RW DOMAIN\Tannerf
        PROCESS_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        PROCESS_ALL_ACCESS
[11004] notepad.exe
  High Mandatory Level [No-Write-Up, No-Read-Up]
  RW BUILTIN\Administrators
        PROCESS_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        PROCESS_ALL_ACCESS

L'un s'exécute sous mon nom d'utilisateur de domaine, l'autre s'exécute sous le groupe intégré Administrateurs. Il a également un niveau obligatoire élevé . Vous pouvez également exécuter avec l' -findicateur pour une ventilation des privilèges et jetons.

Fichiers MSIExec et MSI

Je pensais que les choses pourraient devenir un peu plus compliquées lors de la course msiexec. J'ai un programme d'installation autonome de Google Chrome qui était pratique à tester.

msiexec.exe lance le programme d'installation de Chrome à partir d'une invite élevée:

D:\Users\tannerf>accesschk.exe -p msiexec.exe

[10540] msiexec.exe
  RW BUILTIN\Administrators
  RW NT AUTHORITY\SYSTEM

chrome_installer.exe généré par MSI:

D:\Users\tannerf>accesschk.exe -p chrome_installer.exe

[5552] chrome_installer.exe
     NT AUTHORITY\SYSTEM
     OWNER RIGHTS
  RW NT SERVICE\msiserver

Plus coupé et sec! Il semble qu'un chrome_installer.exeprocessus ait été exécuté via le service MSIServer.

Cela me fait me demander quel comportement les autres installateurs pourraient avoir, alors j'ai exécuté un Evernote.msi que j'avais à portée de main:

Elevated msiexec.exe lançant un programme d'installation Evernote:

[6916] msiexec.exe
  High Mandatory Level [No-Write-Up, No-Read-Up]
  RW BUILTIN\Administrators
        PROCESS_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        PROCESS_ALL_ACCESS
[4652] msiexec.exe
  System Mandatory Level [No-Write-Up, No-Read-Up]
  R  BUILTIN\Administrators
        PROCESS_QUERY_INFORMATION
        PROCESS_QUERY_LIMITED_INFORMATION

Intéressant; il y a un msiexec.exe qui est exécuté sous le niveau système cette fois. J'ai utilisé Process Monitor pour constater que la fenêtre d'installation réelle qui apparaît provient du processus msiexec au niveau système. Tuer le niveau obligatoire élevé a également tué le processus au niveau du système.

Msiexec.exe non élevé lançant un programme d'installation Evernote:

[7472] msiexec.exe
  Medium Mandatory Level [No-Write-Up, No-Read-Up]
  RW DOMAIN\Tannerf
        PROCESS_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        PROCESS_ALL_ACCESS
[4404] msiexec.exe
  System Mandatory Level [No-Write-Up, No-Read-Up]
  R  BUILTIN\Administrators
        PROCESS_QUERY_INFORMATION
        PROCESS_QUERY_LIMITED_INFORMATION

On dirait qu'Evernote obtiendra un accès au niveau du système de toute façon. Double-cliquer sur le programme d'installation a le même résultat.

Conclusion:

Je pense qu'il est assez bien démontré qu'un processus héritera des autorisations, sauf indication contraire. Cela ne garantit pas msiexec SomeProgram.msil'exécution avec un niveau obligatoire élevé dans tous les processus de processus; il pourrait s'exécuter au niveau du système ou sous MSIServer. Votre kilométrage peut varier, et je ne serais pas surpris de voir de nombreux cas où ces règles semblent être "enfreintes".

Tanner Faulkner
la source
2
Outre les tests empiriques, les processus Windows sont censés hériter des autorisations du parent.
Bob
Grand point avec le test. Je l'ai essayé à partir d'un cmd.exe qui a été démarré avec des autorisations élevées et j'obtiens l'autorisation refusée d'essayer d'enregistrer le fichier C:\Windowsmalgré le démarrage du Bloc-notes à partir de l'élévation cmd.exe. Existe-t-il un moyen de rompre la règle "supposé hériter du parent"?
Ian C.
@IanC. Il est possible d'exécuter un processus enfant avec moins de privilèges. J'aurais dû formuler mon commentaire précédent comme "supposé hériter par défaut ". J'ai modifié ma réponse pour inclure cette information. Toutefois, le Bloc-notes doit avoir hérité des privilèges administratifs.
Bob
@IanC. Bizarre, ça a marché pour moi. Vous est-il arrivé d'essayer accesschk? Je ne sais pas quelle pourrait être la différence.
Tanner Faulkner
11

Par défaut, les processus Windows héritent de leur contexte de sécurité du parent:

Les listes de contrôle d'accès dans le descripteur de sécurité par défaut d'un processus proviennent du jeton principal ou d'emprunt d'identité du créateur.

MSDN sur la sécurité des processus et les droits d'accès

Il est cependant possible de générer des processus avec moins de privilèges:

Alors que les processus héritent du niveau d'intégrité du processus qui l'a engendré, le niveau d'intégrité peut être personnalisé au moment de la création du processus. En plus de définir la limite des messages de fenêtre dans la technologie d'isolement des privilèges de l'interface utilisateur, le contrôle d'intégrité obligatoire est utilisé par des applications comme Windows Explorer, Internet Explorer, Google Chrome et Adobe Reader pour isoler les documents des objets vulnérables du système.

Wikipedia sur le contrôle d'intégrité obligatoire relatif à cette autre page MSDN , également mentionné ici . Une autre présentation mentionne également l'héritage des processus.

Cependant, je crois que cmd.exe lancera des processus enfants avec le plus haut niveau d'héritage de privilèges possible, comme le montrent les tests et les réponses de @ Tanner.

Bob
la source
2

Il peut y avoir deux façons de supprimer les privilèges de la commande exécutée:

  • runas /trustlevel:0x20000 "msiexec SomeProgram.msi"(exécutez runas /showtrustlevelspour savoir qu'il 0x20000s'agit du niveau de confiance de l'utilisateur par défaut - cela fonctionne même pour l'installation / l'exécution de programmes qui "nécessitent" des privilèges élevés - sans les octroyer réellement lorsqu'ils sont exécutés en tant qu'administrateur. Cela passe le test du bloc-notes de Tanner ) selon cette réponse SU
  • psexec -l -d msiexec SomeProgram.msipar cette réponse SU (peut-être que certains "" sont également requis, je n'ai pas testé cela car cela runasfonctionne assez bien pour moi)
Tobias Kienzler
la source