Sim, ele é executado com privilégios elevados.
Teste simples:
Você pode testar isso facilmente, abrindo um prompt de comando elevado e um não elevado. Execute o comando notepad.exe
nos dois e tente salvar um arquivo de texto em branco em C:\Windows
. Um salvará, um lançará um erro de permissão.
Teste completo:
Se isso não for suficiente para confirmar isso para você (realmente não me satisfez), você pode usar o AccessChk da SysInternals. Você precisará executar isso em um prompt de comando elevado.
Vamos começar verificando os dois processos do Bloco de Notas em execução:
Bloco de notas: ( 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
Um está sendo executado sob o nome de usuário do meu domínio, o outro está sendo executado no grupo interno Administradores. Também possui um alto nível obrigatório . Você também pode executar com o -f
sinalizador para obter uma discriminação dos privilégios e tokens.
Arquivos MSIExec e MSI
Eu pensei que as coisas poderiam ficar um pouco mais complicadas ao executar msiexec
. Eu tenho um instalador independente do Google Chrome que foi útil para testar.
msiexec.exe iniciando o instalador do Chrome a partir do prompt elevado:
D:\Users\tannerf>accesschk.exe -p msiexec.exe
[10540] msiexec.exe
RW BUILTIN\Administrators
RW NT AUTHORITY\SYSTEM
chrome_installer.exe gerado pelo MSI:
D:\Users\tannerf>accesschk.exe -p chrome_installer.exe
[5552] chrome_installer.exe
NT AUTHORITY\SYSTEM
OWNER RIGHTS
RW NT SERVICE\msiserver
Não é mais tão cortado e seco! Parece que um chrome_installer.exe
processo foi executado através do serviço MSIServer.
Isso me faz pensar em qual comportamento outros instaladores podem ter, então eu executei um Evernote.msi que eu tinha à mão:
Msiexec.exe elevado iniciando um instalador do 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
Interessante; há um msiexec.exe que é executado no nível do sistema neste momento. Usei o Process Monitor para descobrir que a janela de instalação real exibida é proveniente do processo msiexec no nível do sistema. Matar o alto nível obrigatório também matou o processo no nível do sistema.
Msiexec.exe não elevado, iniciando um instalador do 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
Parece que o Evernote terá acesso no nível do sistema de qualquer maneira. Clicar duas vezes no instalador tem o mesmo resultado.
Conclusão:
Eu acho que está muito bem demonstrado que um processo herdará permissões, a menos que especificado de outra forma. Isso não garante que msiexec SomeProgram.msi
será executado com um alto nível obrigatório em todos os processos de processos; pode ser executado no nível do sistema ou no MSIServer. Sua milhagem pode variar, e eu não ficaria surpreso ao ver muitos casos em que essas regras parecem estar "quebradas".
C:\Windows
apesar de ter iniciado o Bloco de Notas no cmd.exe elevado. Existe uma maneira de quebrar a regra "suposto herdar do pai"?Por padrão, os processos do Windows herdarão seu contexto de segurança do pai:
MSDN sobre segurança de processo e direitos de acesso
É, no entanto, possível gerar processos com menos privilégios:
Wikipedia sobre Controle de Integridade Obrigatório relacionado a esta outra página do MSDN , também mencionada aqui . Outra apresentação também menciona a herança do processo.
No entanto, acredito que o cmd.exe iniciará processos filho com o maior nível de herança de privilégios possível, como mostra o teste e a resposta do @ Tanner.
fonte
Pode haver duas maneiras de remover os privilégios do comando executado:
runas /trustlevel:0x20000 "msiexec SomeProgram.msi"
(executerunas /showtrustlevels
para saber que0x20000
é o nível de confiança do usuário padrão - isso funciona até para instalar / executar programas que "exigem" privilégios elevados - sem realmente concedê-los quando executados como administrador. Isso passa no teste do bloco de notas de Tanner ) conforme esta resposta da SUpsexec -l -d msiexec SomeProgram.msi
por esta resposta SU (talvez alguns "" também sejam necessários, eu não testei isso, poisrunas
funciona bem o suficiente para mim)fonte