Permissão de execução no Windows

Apesar de uso não muito difundido, o Windows tem o conceito de permissão de execução para arquivos e diretórios, de forma similar aos Unix-like: em diretórios, permite atravessá-los ^[1] e, em arquivos, permite sua execução se for um programa — os arquivos continuam podendo ser lidos, modificados, ou quaisquer sejam as demais permissões. A permissão em questão é "Percorrer pasta/executar arquivo".

Para manter a semântica de acesso ao sistema de arquivos compatível com o MS-DOS, o Windows NT mantém o comportamento de criar todos arquivos com permissão de execução por padrão.

Nas permissões simplificadas, RX (Ler & executar) é garantido a todos praticamente.

Há pela internet quem recomende removê-la recursivamente (via herança, de preferência) no diretório do perfil do usuário. No entanto, não me parece ser boa ideia, visto que provavelmente quebrará instaladores que usem %TEMP% e aplicativos que coloquem executáveis em %APPDATA% e/ou %LOCALAPPDATA%, como uTorrent e Chrome. Até pode ser uma opção em sistemas bem travados, onde nada mais será instalado. Ainda assim são necessários testes.

Abordagem mais segura é remover a permissão apenas em pastas específicas do perfil, em particular na Downloads.

icacls "%USERPROFILE%\Downloads" /deny *S-1-3-0:(OI)(IO)(X)

O comando adiciona uma permissão de negação (/deny) de execução ((X)) ao proprietário criador (*S-1-3-0), que aplica-se apenas a arquivos, deixando o diretório e subdiretórios de fora, e é propagada a todos objetos descendentes ((OI)(IO)).

Funciona bem.

A mensagem de erro é confusa. O Windows pôde sim acessar o arquivo, só não pôde executá-lo...

O problema é que não é trivial adicionar seletivamente a permissão de volta. Como negação tem prioridade, precisamos copiar as permissões, desabilitando a herança, e só então removê-la.

Usei propositadamente proprietário criador com intuito de tornar as coisas (um pouco) mais simples a quem roda com usuário limitado e tem uma conta administrativa separada. Infelizmente a opção "Executar como administrador" do menu de contexto leva em consideração a proibição do usuário corrente e exibe a mesma mensagem de erro acima. Porém através do comando runas dá certo.

runas /user:Administrador <programa>

Claro, podemos também simplesmente copiar ou mover o arquivo para outro diretório sem a restrição. Idealmente poderíamos restringir o perfil inteiro. Programas bem feitos não deveriam colocar executáveis no perfil e instaladores usariam a pasta %TEMP% da conta administrativa. Isso pressupõe, contudo, que o usuário use uma conta limitada e o mundo esteja repleto de lindos unicórnios.

Por fim, é possível desfazer com:

icacls "%USERPROFILE%\Downloads" /remove:d *S-1-3-0

A permissão é propagada a partir do diretório inicial apenas. Ao removê-la, a propagação é automaticamente desfeita. O comando icacls existe a partir do Vista e Server 2003 SP1.

Este post foi inspirado por Even though the target audience may be programmers, it can still be seen by users do blog The Old New Thing.

---

^[1] Permite "passar" por um diretório. Imagine que, no caminho C:\aaa\bbb\ccc\, determinado usuário tenha controle total em aaa e ccc, mas não em bbb, onde não tenha permissão alguma. Se em bbb for concedida a permissão "Percorrer pasta/executar arquivo", este conseguirá de aaa chegar em ccc (sem poder listar o conteúdo de bbb nem acessar os arquivos que estiverem dentro). É ignorada para usuários e grupos listados na GPO "Configuração do Computador → Configurações do Windows → Configurações de segurança → Diretivas locais → Atribuição de direitos de usuário → Ignorar a verificação completa" — em instalações fora de domínios Microsoft, efetivamente é ignorada para todos os usuários. Neste post, apenas negamos a permissão a arquivos, de forma que essa configuração não tem importância.