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.exe
dans 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' -f
indicateur 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.exe
processus 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.msi
l'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".