O UAC é uma arquitetura de múltiplos componentes implementada por vários binários
O Controle de Conta de Usuário (UAC) refere-se a vários componentes que juntos formam a arquitetura do UAC . Analisarei brevemente alguns deles, juntamente com os binários responsáveis por sua implementação, mas primeiro aqui está uma visão geral da arquitetura do UAC no artigo do Microsoft Docs Como funciona o controle de contas de usuário :
Autoridade de Segurança Local (LSA) / Token Filtrado
Conceitualmente, o "primeiro" componente do UAC é implementado pelo subsistema Local Security Authority, que lida com a criação do Token de Acesso de um usuário durante o processo de logon. A partir do Windows Vista, o processo de logon foi modificado para que, quando um administrador efetue logon com o UAC ativado, o subsistema LSA gere dois tokens de acesso separados para o usuário:
- Um com acesso total de administrador e
- Um segundo "token filtrado" com acesso de usuário padrão
Como mostrado aqui, esse processo é diferente daquele de um logon de usuário padrão:
O serviço do subsistema LSA vive no lsass.exe
processo.
Virtualização
Adicionado no Windows 7, o File and Registry Virtualization é um componente do UAC que calha os aplicativos mais antigos que não são compatíveis com o UAC, mas exigem apenas direitos administrativos para acessar determinadas áreas protegidas do sistema de arquivos ou do Registro:
Quando um aplicativo administrativo que não é compatível com o UAC tenta gravar em um diretório protegido, como Arquivos de Programas, o UAC fornece ao aplicativo sua própria exibição virtualizada do recurso que está tentando alterar. A cópia virtualizada é mantida no perfil do usuário.
Fonte
Ao redirecionar essas tentativas de acesso para áreas que não exigem permissões de administrador, esses aplicativos continuam a funcionar, apesar do UAC estar ativado no sistema.
Essa virtualização é implementada no Kernel .
Serviço de Informações do Aplicativo
O Application Information Service (AIS) lê o manifesto de um aplicativo e trabalha com o prompt de consentimento do UAC para determinar se um aplicativo tem permissão para executar com direitos elevados (por exemplo, iniciar no contexto do token de acesso de nível administrativo não filtrado criado no logon) . Esta postagem do blog fornece uma boa visão geral de seu papel no processo do UAC:
AIS Facilita a execução de aplicativos interativos com privilégios administrativos adicionais. Se esse serviço for interrompido, os usuários não poderão iniciar aplicativos com os privilégios administrativos adicionais que possam exigir .... O shell verifica esse serviço quando lança um aplicativo. AIS é aquele que lê o manifesto e a seção xml 'trustInfo' que possui os requisitos para o 'requestExecutionLevel' ...
Aqui está um gráfico que segue a citação acima, detalhando a função do AIS no processo de solicitação de consentimento do UAC:
O AIS é implementado na DLLappinfo.dll
que é executada por svchost.exe
.
Prompt de consentimento
A resposta de @ BenN explica o papel principal do (in) famoso Prompt de Consentimento do UAC. Isso é implementado consent.exe
e é responsável por obter o consentimento do usuário ou as credenciais de um usuário administrativo para permitir o lançamento de um aplicativo que requer direitos de administrador.
Área de trabalho segura
A área de trabalho segura é onde o prompt de consentimento do UAC é exibido por padrão. O UACBlog da Microsoft nos diz o que há de exclusivo nesta área de trabalho em comparação com a área de trabalho do usuário:
Você costuma interagir com [o Secure Desktop] quando faz logon no Windows, pois a interface do usuário de logon é executada no Secure Desktop. A principal diferença do Secure Desktop em relação à Área de trabalho do usuário é que apenas processos confiáveis executados como SYSTEM podem ser executados aqui (ou seja, nada em execução como nível de privilégio do usuário) e o caminho para chegar à Área de trabalho segura a partir da Área de trabalho do usuário também deve ser confiável através toda a cadeia.
A idéia por trás do uso ao solicitar o consentimento do usuário para executar um aplicativo com permissões elevadas é que o malware não pode imitar a Área de Trabalho Segura, a menos que já tenha direitos administrativos; nesse caso, enganar um usuário para concedê-lo é discutível.
Conclusão: o UAC não é apenas um binário. É um tecido de subsistemas entrelaçados.
Ainda existem outros aspectos da arquitetura do UAC não abordados aqui, mas isso deve fornecer evidências suficientes para os fatos que:
- O UAC não é implementado em um único binário.
- Se ativado, é parte integrante da execução de tarefas administrativas.
Desde a sua introdução no Windows Vista, ele foi profundamente integrado às partes principais do sistema operacional, tornando impossível excluir todo o código responsável pelo UAC sem interromper outras coisas (como a capacidade de logon!)
I think it's safe to say that if you "forcefully deleted" UAC you would break Windows.