A configuração padrão do UAC é muito fraca

A configuração padrão do UAC, Controle de Conta de Usuário do Windows 7, é mais leve. Ela não exibe tantos avisos como no Vista. Todavia não aparenta ser tão segura: há relatos de que programas conseguem burlar facilmente algumas ações, já que ao alterar algumas configurações o Windows não exibe o aviso. Isso abre brechas para que programas maliciosos tentem clicar sozinhos na tela para liberar alguma outra coisa e então obter mais privilégios (simular cliques do mouse em programação é algo extremamente simples…). Recomendo deixar a proteção no máximo, operando como é no Vista.

Esse recurso foi um dos melhores já inclusos no Windows, possibilitando uma redução no número de vírus e malwares (exceto os que convencem os usuários mesmo, aí não há o que fazer). No painel de controle do Windows 7, vá na seção Sistema e Segurança e clique no link Alterar configurações de Controle de Conta de Usuário. Arraste o controle deslizante para cima, e clique em OK:

5a469643

Se quiser desativar completamente, arraste para baixo. Pode ser necessário reiniciar ao ativar ou desativar completamente. Como se vê, no 7 ele oferece quatro níveis.

Muita gente pensa que esse sistema trabalha unicamente com avisos, “inúteis” para usuários [que se acham]mais bem entendidos. Não é bem assim. Com o UAC ativo, o Windows não libera privilégios administrativos para os usuários quando se logam na máquina. Até mesmo os administradores rodam com um token de usuário limitado, sem poder gravar na chave do registro HKEY_LOCAL_MACHINE (onde ficam configurações globais, que afetam todas as contas e o sistema do Windows) nem alterar arquivos importantes do sistema.

Quando alguma ação precisa ser executada como administrador, como a instalação de um programa ou alteração de configuração global (como por exemplo, a definição do idioma da tela de logon e o default para novas contas), o Windows pede a confirmação num desktop separado. Isso impede que um programa tente simular um clique na tela, pois o clique seria dado no desktop anterior ao do aviso, onde os programas de usuário comum rodam. Na prática parece ser no mesmo desktop, mas não é. O Windows tira um bitmap da tela anterior, escurece a imagem e coloca de fundo num desktop isolado (por isso o Print Screen na tela do UAC nem funciona, o bitmap é copiado num ambiente isolado que é fechado logo que a janela do UAC sumir). Assim, um programa malicioso não tem como “clicar” no botão de confirmação do UAC, pois estará rodando no desktop do usuário.

Portanto não são meros avisos, há todo um sistema de bloqueio por trás. Um malware não consegue ser instalado corretamente, no máximo prejudicaria a conta em uso, trabalhando de forma parecida com os programas no Linux, onde o uso de conta limitada para usuários normais é bastante divulgado. É claro que se o malware pedir confirmação do UAC e o usuário aceitar, já era. É como se um ladrão disfarçado de funcionário da companhia telefônica perguntasse se pode entrar na sua casa e você autoriza explicitamente. No Windows, como falei anteriormente, boa parte da culpa de programas não rodarem como usuário comum fica por conta dos desenvolvedores. Uma aplicação certificada para Windows deve operar bem em modo de usuário limitado, ou então declaradamente exigir direitos administrativos, se for ferramenta de configuração ou algo que exige acesso diferenciado ao hardware.

As aplicações incluem uma “flag” para dizer como elas devem funcionar. Essa flag define basicamente se o programa pode rodar como usuário limitado ou se exige direitos administrativos (ou seja, se ele respeita as normas do Windows, grava configurações só na HKEY_CURRENT_USER e em pastas do usuário, nunca em pastas do sistema nem dentro da Arquivos de programas, etc). Geralmente programas específicos ou de administração, ou instaladores, exigem direitos administrativos, o que faz o aviso do UAC “pipocar” na tela. Sem autorizar, o programa não roda. Já boa parte dos programas de uso no dia-a-dia (um editor de textos, gravador de CD/DVD, editor de imagens, navegador web, etc) vêm com uma flag que permite o uso por usuários comuns, caso estejam logados ou sob UAC, ou por administradores, se for o caso de ter um administrador com UAC desativado.

Em programas anteriores ao Vista, que não incluem essa flag, é necessário rodá-los explicitamente como administrador, como comentei na parte de compatibilidade. É preciso rodar manualmente como administrador porque, sem a flag, o Windows não tem como saber se o programa deve rodar ou não de forma liberada. O redirecionamento do registro que comentei no começo do texto também não funciona em aplicações com essa flag, ele é uma ajuda para compatibilidade com aplicações antigas; não é um recurso que deve ser usado e explorado ao máximo (pelos desenvolvedores preguiçosos).

Se você desativar o UAC o Windows passa a se comportar exatamente como os NTs anteriores (há algumas diferenças de permissões nas contas de usuários comuns, power users e administradores entre o NT4, 2000, XP, 2003, etc, mas são pequenas). Com o UAC desativado os programas rodam diretamente como administrador, caso um administrador esteja logado. Isso permite que eles alterem arquivos do sistema, se programem para iniciar automaticamente para todas as contas, desativem serviços (seja diretamente ou via linha de comando do Windows, chamando os executáveis com parâmetros específicos), etc. O sistema fica muito mais vulnerável. Ainda assim pode-se dizer que é seguro, desde que o usuário saiba o que rode. Se você nunca infectou um PC com Windows XP ou 2000 usando diretamente a conta de administrador, provavelmente não irá infectar um Vista ou 7 com UAC desativado. Se precisa rodar programas suspeitos ou baixados de fontes não confiáveis, o melhor hoje em dia é usar uma máquina virtual, qualquer PC razoável atual roda bem um sistema virtualizado (recomendo ter 2 GB ou mais de RAM, mas dá para rodar com menos).

Só de curiosidade, essa flag é inclusa num recurso do executável (você pode ver e até mesmo editar usando o Resource Hacker ou sua ferramenta de programação preferida). É o mesmo recurso que ativa o suporte a temas visuais no Windows XP ou superior, na verdade uma adição no XML deste. Ele pode ser incluso num arquivo .manifest também (mas foge do tema abordar isso agora, é para programadores mesmo). Veja o do Firefox:

m5cdc17a8

Usando o Resorce Hacker você pode inclusive editar executáveis de terceiros. Colocando asInvoker o programa roda como for (se um usuário iniciar, vai como usuário; se um administrador iniciar, vai como administrador). Colocando requireAdministrator força o programa a sempre exigir direitos administrativos, o que impede que ele rode com contas limitadas, e caso o UAC esteja ativo, ele instrui o Windows a exibir o aviso solicitando elevação de privilégios. A MS destaca que a edição incorreta desse recurso pode fazer o Windows XP dar um erro de tela azul ao rodar o programa, então cuidado caso queira se aventurar. Ah, por fim, ao usar ambientes de desenvolvimentos não certificados para o Windows Vista pelo menos, pode ser um pouco difícil aplicar esse recurso na primeira vez. No caso do Delphi, por exemplo. Se você usar a unidade XPMan (XPManifest) e tentar embutir um recurso desse ele não vai deixar, pois duplicará o recurso. Nesse caso, remova de todos os arquivos do projeto a unidade XPMan e embuta o recurso por si mesmo, compilando usando o brcc32 ou outra ferramenta, ou até mesmo o Resource Hacker. Se você é usuário comum, ignore essas explicações 😛

Sobre o Autor

Redes Sociais:

Deixe seu comentário

X