Tak, działa z podwyższonymi uprawnieniami.
Prosty test:
Możesz to dość łatwo przetestować, otwierając jeden wiersz polecenia z podwyższonym poziomem uprawnień i jednym bez podniesionego poziomu uprawnień. Uruchom polecenie notepad.exe
w obu przypadkach i spróbuj zapisać pusty plik tekstowy w C:\Windows
. Jeden zapisze, jeden rzuci błąd uprawnień.
Szczegółowy test:
Jeśli to nie wystarczy, aby to potwierdzić (naprawdę mnie to nie satysfakcjonowało), możesz użyć AccessChk z SysInternals . Musisz uruchomić to z wiersza polecenia z podwyższonym poziomem uprawnień.
Zacznijmy od sprawdzenia dwóch uruchomionych procesów Notatnika:
Notatnik: ( 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
Jeden działa pod moją nazwą użytkownika domeny, drugi działa pod wbudowaną grupą Administratorów. Ma również wysoki poziom obowiązkowy . Możesz także biegać z -f
flagą, aby uzyskać zestawienie uprawnień i tokenów.
Pliki MSIExec i MSI
Myślałem, że może się trochę bardziej skomplikować podczas biegania msiexec
. Mam samodzielnego instalatora Google Chrome, który był przydatny do przetestowania.
msiexec.exe uruchamiający instalator Chrome z podwyższonego monitu:
D:\Users\tannerf>accesschk.exe -p msiexec.exe
[10540] msiexec.exe
RW BUILTIN\Administrators
RW NT AUTHORITY\SYSTEM
chrome_installer.exe spawnowany przez MSI:
D:\Users\tannerf>accesschk.exe -p chrome_installer.exe
[5552] chrome_installer.exe
NT AUTHORITY\SYSTEM
OWNER RIGHTS
RW NT SERVICE\msiserver
Już nie tak cięte i suche! Wygląda na to, że chrome_installer.exe
procesy zostały uruchomione za pośrednictwem usługi MSIServer.
To sprawia, że zastanawiam się, jakie zachowanie mogą mieć inni instalatorzy, więc uruchomiłem Evernote.msi, które miałem pod ręką:
Podwyższony msiexec.exe uruchamiający instalator 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
Ciekawy; jest msiexec.exe, który tym razem jest uruchamiany na poziomie systemu. Użyłem Process Monitora do stwierdzenia, że wyskakujące okno instalacji pochodzi z procesu msiexec na poziomie systemu. Zabicie wysokiego poziomu obowiązkowego zabiło również proces na poziomie systemu.
Plik msiexec.exe bez podniesionego poziomu uprawnień uruchamiający instalator 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
Wygląda na to, że Evernote uzyska dostęp na poziomie systemu w obie strony. Podwójne kliknięcie instalatora daje ten sam wynik.
Wniosek:
Myślę, że całkiem dobrze wykazano, że procesy odziedziczą uprawnienia, chyba że określono inaczej. To nie gwarantuje, że msiexec SomeProgram.msi
będzie działać z wysokim obowiązkowym poziomem we wszystkich procesach; może działać na poziomie systemu lub MSIServer. Twój przebieg może się różnić i nie byłbym zaskoczony, widząc wiele przypadków, w których zasady te wydają się „złamane”.