Segurança

Bloqueio do aplicativo com diretivas de restrição de software

Chris Corio and Durga Prasad Sayana

À primeira vista:

• Como funcionam as diretivas de restrição de software
• Inventariando aplicativos no ambiente
• Criando e impondo diretivas

Quando os profissionais de TI procuram reduzir o custo total de propriedade, ou TCO, das máquinas desktop, existem duas estratégias principais que normalmente vêm à mente. A primeira é retirar as contas dos usuários de desktop

do grupo Administradores. E a segunda é limitar os aplicativos que os usuários podem executar. Abordar esses problemas pode ser um desafio e tanto em um ambiente corporativo, mas o Windows Vista® oferece algumas tecnologias capazes de ajudá-lo a alcançar essas metas.

O Windows Vista e seu recurso UAC (Controle de Conta de Usuário) deram um enorme passo na direção de ajudar os profissionais de TI na execução dos usuários corporativos como membros do grupo Usuários (Usuários Padrão). O UAC alterou o contexto de segurança padrão para que todos os aplicativos fossem um usuário, e não um administrador. Essa migração para o grupo Usuários continua sendo uma tarefa formidável, mas à medida que o setor se ajustar a esse novo paradigma, a tarefa ficará mais fácil com o passar do tempo.

Depois de analisar os desafios da migração dos usuários para o grupo Usuários ou, às vezes, durante esse processo, muitos administradores catalogam quais aplicativos os usuários precisam executar e consideram as etapas necessárias para permitir exclusivamente esses aplicativos. O recurso da diretiva de restrição de software foi projetado para ajudar os profissionais de TI a fazer exatamente isso.

Basta você especificar quais são os aplicativos que têm permissão de execução e, em seguida, implantar a diretiva usando a Diretiva de Grupo. A imposição dessa diretiva em toda a empresa pode reduzir o TCO, porque esse bloqueio limitará os problemas relacionados a aplicativos para os quais não há suporte. (Além disso, é possível usar as diretivas de restrição de software de formas interessantes e extremadas, como abordamos na barra lateral "A diretiva de restrição de software básica".)

Como funciona a diretiva de restrição de software

A diretiva de restrição de software pretende controlar exatamente o código que um usuário pode executar em uma máquina com Windows Vista. Você, o administrador, cria uma diretiva que define o que pode (ou não pode) ser executado no ambiente. Depois, essa diretiva será avaliada sempre e onde o código for executado. Isso inclui o momento de criação do processo, em uma chamada para ShellExecute, e quando um script for executado. (Veremos isso mais detalhadamente daqui a pouco.)

Se for determinado que um aplicativo tem permissão de execução, ele será iniciado. Mas, se for determinado que um aplicativo não tem permissão de execução, ele será bloqueado e o usuário, notificado. Por exemplo, se tentasse executar Paciência no menu Iniciar e isso não fosse permitido, você receberia uma caixa de diálogo semelhante à mostrada na Figura 1.

Figura 1** Uma caixa de diálogo é exibida quando um aplicativo é bloqueado **(Clique na imagem para uma visão ampliada)

A interface do usuário para definir uma diretiva de restrição de software é exposta no GPOE (Editor de Objeto de Diretiva de Grupo), onde a diretiva de bloqueio é criada. Há vários métodos para definir qual código pode ser executado e qual não pode. Assim que a diretiva for concluída e testada, você poderá implantá-la.

Definindo a diretiva de restrição de software

A primeira grande decisão que você tomará, uma decisão que afetará drasticamente a forma como a diretiva de restrição de software funcionará no ambiente, é escolher um tipo de regra padrão. As diretivas de restrição de software podem ser implantadas de dois modos: lista de permissões ou lista de negações. Basicamente, você está escolhendo se deseja criar uma diretiva que descreve todos os aplicativos com permissão de execução no ambiente ou uma diretiva que define todos os aplicativos que não podem ser executados.

No modo Lista de Permissões, a regra padrão na diretiva é Restrito, que bloqueará todos os aplicativos que não tenham permissão de execução explícita. No modo Lista de Negações, a regra padrão na diretiva é Irrestrito, que restringe apenas os aplicativos listados explicitamente por você.

O modo Lista de Negações, como você pode imaginar, é uma abordagem irreal caso você esteja em busca de uma redução maior do TCO e mais benefícios de segurança resultantes de um bloqueio de aplicativo. Criar e manter uma lista extensa que bloqueie todo malware e demais aplicativos problemáticos seria praticamente impossível; por isso, recomendamos que a diretiva de restrição de software seja implementada no modo Lista de Permissões, que significa uma regra padrão Restrito.

Inventariando aplicativos no ambiente

Caso pretenda criar uma diretiva que especifique o que os aplicativos podem executar, você precisa determinar exatamente quais são os aplicativos dos quais os usuários precisam. O recurso da diretiva de restrição de software oferece um recurso de registro em log avançado com uma diretiva muito simples para compreender exatamente quais são os aplicativos em execução no ambiente.

Em um conjunto de máquinas de exemplo no ambiente, implante a diretiva de restrição de software com a regra padrão definida como Irrestrito e não se esqueça de remover todas as demais regras adicionais. O plano é habilitar a diretiva de restrição de software, mas não permitir que ela restrinja aplicativos; pelo contrário, você a está usando apenas para monitorar o que está em execução.

Em seguida, crie o seguinte valor do Registro para habilitar o recurso do registro em log avançado e defina o caminho em que o arquivo de log deve ser gravado:

"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\
CodeIdentifiers"
String Value: LogFileName, <path to a log file>

Agora, quando um aplicativo é executado e a diretiva de restrição de software, avaliada (avaliada mesmo que haja permissão de execução para tudo), uma entrada é gravada no arquivo de log.

Cada entrada de log inclui o chamador da diretiva de restrição de software e a PID (identificação do processo) do processo de chamada, o destino avaliado, o tipo de regra de restrição de software atingido e um identificador da regra. Eis uma entrada de exemplo gravada quando um usuário clica duas vezes em notepad.exe:

explorer.exe (PID = 3268) identified
C:\Windows\system32\notepad.exe as Unrestricted using
path rule, Guid =
{191cd7fa-f240-4a17-8986-94d480a6c8ca}

Esse arquivo de log representa todas as partes do código executável que a diretiva de restrição de software verificará quando for habilitada e definida para bloquear aplicativos. Isso significa que você deve optar por uma das entradas no arquivo de log, independentemente de serem levadas em conta na Lista de Permissões. Observe que você verá vários binários verificados que fazem parte do Windows® e que são obrigatórios ao funcionamento do sistema.

A técnica de registro de log que descrevemos aqui oferece uma forma clara para que você compreenda exatamente quais aplicativos a diretiva de restrição de software encontrará no ambiente. Mas essa não é a única maneira de realizar essa tarefa.

O Inventory Collector incluído como parte do Kit de Ferramentas de Compatibilidade de Aplicativos da Microsoft® 5.0 oferece a possibilidade de inventariar os aplicativos que estão sendo usados no ambiente. Essa ferramenta oferece várias formas diferentes para que você saiba quais são os aplicativos instados no ambiente, além de também consolidar os resultados em um banco de dados central.

Criando regras adicionais

Agora que conta com uma lista dos aplicativos que devem ter permissão de execução no ambiente, você está pronto para criar as regras reais que permitirão a execução desses aplicativos. O recurso da diretiva de restrição de software usa duas formas para identificar a diretiva – uma baseada nas propriedades criptográficas de um aplicativo (como, por exemplo, seu hash) e outra que define um caminho confiável ou pasta em que os aplicativos confiáveis devem residir.

A Figura 2 mostra onde você adicionaria regras a fim de permitir a execução dos aplicativos no nó Diretivas de Restrição de Software do GPOE (gpedit.msc). A forma mais direta de definir os aplicativos no ambiente é criando uma regra de hash para todos os binários únicos encontrados durante a fase de registro em log.

Figura 2** Usando gpedit.msc para criar diretivas de restrição de software **(Clique na imagem para uma visão ampliada)

Como o hash é um valor exclusivo retornado para um determinado conjunto de bits, cada binário da diretiva terá um hash diferente. Essa abordagem é especialmente segura e só permitirá a execução dos binários específicos da diretiva.

Obviamente, existem algumas desvantagens nessa abordagem. Por exemplo, o ambiente poderia ter facilmente muitos milhares de binários. Poderia ser difícil criar todas essas regras na interface do usuário da diretiva de restrição de software e, na medida em que o número de regras fica especialmente grande, o desempenho pode ser afetado. Além disso, cada atualização feita no aplicativo exigirá a implantação de uma ou mais regras de hash novas no ambiente. Atualizar uma diretiva tão grande à medida que os aplicativos são atualizados pode ser uma tarefa gigantesca.

Felizmente, isso pode ser evitado porque há outras duas formas de identificar regras que facilitam o uso de diretivas de restrição de software no ambiente. Indo mais além na rota de segurança criptográfica, é possível criar uma regra que permitirá a execução de qualquer binário assinado por um determinado certificado.

Fazer isso ajuda a simplificar a manutenção da lista de diretivas porque, quando um aplicativo é atualizado, os novos binários serão normalmente assinados pelo mesmo certificado dos anteriores. No entanto, se não quiser que uma versão anterior do binário seja executada no ambiente, você precisará adicionar uma regra de hash Restrito para impedir a permissão do arquivo.

Por padrão, a avaliação das regras de certificado permanece desabilitada para diretivas de restrição de software. Há duas razões pelas quais isso tinha que ser feito.

A primeira: as regras de certificado nas diretivas de restrição de software são definidas pelo que se encontra no repositório Editores Confiáveis do sistema. Como o repositório Editores Confiáveis é usado para outros fins que não sejam o de regras da diretiva de restrição de software, isso exige mais tempo e consideração quando usado no recurso das diretivas de restrição de software.

A segunda razão é que, para determinar se a assinatura de um arquivo é válida, você deve usar um hash do arquivo e compará-lo com as informações da assinatura. O hash de um arquivo é uma operação muito cara – todo o arquivo deve ser lido no disco e processado para calcular esse hash.

Para habilitar as regras de certificado, navegue até o nó Diretivas de Restrição de Software e selecione Objeto de Imposição no painel de resultados. Em seguida, clique duas vezes para abrir a caixa de diálogo de propriedades e selecione a opção de regras de certificado.

A outra forma comum de identificar o código é usando seu caminho na máquina local. Trata-se de uma técnica efetiva e eficiente, mas com uma desvantagem: você deve tomar o cuidado de garantir que as configurações de segurança estejam definidas corretamente na pasta.

Se você adicionasse uma determinada regra de caminho e esse caminho permitisse aos usuários gravar arquivos (na área de trabalho, por exemplo), eles poderiam executar o que quisessem apenas colocando o executável nessa pasta. No entanto, caso não sejam do grupo Administradores, os usuários normalmente não têm a possibilidade de modificar nada em Arquivos de Programas ou nos diretórios do Windows. Isso significa que caso todos os aplicativos estejam no diretório Arquivos de Programas e os usuários não sejam Administradores, você deve observar as regras de caminho para contar com uma diretiva bastante simples e eficiente.

As regras de caminho oferecem outros recursos que as fazem mais adequadas a alguns ambientes. Isso possibilita curingas e permite que você use variáveis do sistema para facilitar a definição de regras portáteis no ambiente – afinal, %systemdrive% talvez não seja c:\ para todos os usuários.

Em relação ao desempenho e à manutenção, essa talvez seja a forma mais fácil de identificar códigos. Certamente, as regras de caminho são algo a ser considerado, mas você precisa estar atento a considerações adicionais quanto à segurança.

Regras da zona de rede

A diretiva da restrição de software não inclui um tipo de regra chamada de zona de rede, embora esse tipo de regra esteja sendo preterido. A intenção original dessas regras se baseava na idéia de que a origem do código executável em especial poderia ser identificada e era confiável, o que permitia a execução do código. Infelizmente, isso é especialmente difícil de fazer e, assim, nunca funcionou muito bem. Atualmente, esse tipo de regra não é imposto na maioria dos locais dos pontos de entrada da diretiva de restrição de software.

Nos casos em que a maior parte dos aplicativos está instalada no diretório %Program Files%, mas há outros arquivos executáveis instalados nos demais lugares e assinados por um certificado específico, talvez faça sentido usar regras de tipos diferentes. Algumas regras de hash, outras regras de caminho, e você saberá que encontrou a diretiva certa.

Apenas se lembre de que existe uma ordem na qual as regras são processadas (como mostrado na Figura 3). As regras de certificado são as mais específicas, depois vêm as regras de hash e, em seguida, as regras de caminho e as regras de caminho com curingas. Dessa forma, se um código for identificado por uma regra de hash e por uma regra de caminho, o nível de segurança da regra de hash terá prioridade.

Figura 3** Ordem de processamento da regra **(Clique na imagem para uma visão ampliada)

Imposição de diretivas

O recurso das diretivas de restrição de software fornece uma ampla cobertura no sistema que está sendo protegido. A idéia é de que qualquer local no qual o código possa ser executado deva ser integrado à diretiva de restrição de software e, assim, verificar a diretiva para saber se o código executável tem permissão de execução.

Embora haja vários locais que verifiquem a diretiva de restrição de software, o ponto de entrada mais direto é CreateProcess. Em CreateProcess, a diretiva é verificada para se determinar se o binário que representa o aplicativo tem permissão de execução. A verificação da diretiva é feita pela API SaferIdentifyLevel, documentada publicamente. O processo geral é ilustrado na Figura 4. (Abordaremos SaferIdentifyLevel mais detalhadamente daqui a pouco.)

Figura 4** Usando SaferIdentifyLevel para determinar se um binário pode ser executado **(Clique na imagem para uma visão ampliada)

Depois de CreateProcess, a API mais usada em que a diretiva de restrição de software é imposta é ShellExecute. Trata-se da API chamada quando o usuário clica em um aplicativo do menu Iniciar ou clica duas vezes em algo na área de trabalho.

ShellExecute pode ser chamada em vários formatos de arquivo. Em casos como, por exemplo, um arquivo .txt, chamar ShellExecute no arquivo não resulta efetivamente na execução do arquivo – tecnicamente, é claro, o arquivo é aberto. Por esse motivo, a diretiva de restrição de software contém uma lista dos tipos de arquivo executáveis para que possa controlar quais tipos são verificados quando ShellExecute é chamada. É possível personalizar essa lista de tipos de arquivo executáveis na interface do usuário da diretiva de restrição de software.

Além de CreateProcess e ShellExecute, há outros dois pontos de integração principais: LoadLibrary e hosts de script. LoadLibrary é, obviamente, um local importante para verificar o código executável, mas infelizmente apresenta algumas restrições especiais.

A maior parte dos aplicativos tem um executável e várias DLLs carregadas. E normalmente há muitos aplicativos em execução no sistema. Isso significa que LoadLibrary exigiria muita verificação em relação à diretiva. Dependendo da diretiva de identificação do código, esse poderia ser um ponto de entrada cuja imposição é cara – imagine verificar o hash de todas as DLLs carregadas no sistema, que inclui o hash do binário e sua comparação com uma lista de, talvez, milhares de hashes.

Por padrão, essa funcionalidade permanece desabilitada, mas pode ser habilitada manualmente. Para isso, navegue até o nó Diretivas de Restrição de Software em gpedit.msc e clique duas vezes em Imposição. Depois, selecione o botão de opção Todos os arquivos de software.

Como mencionamos, a diretiva de restrição de software é integrada à maioria dos hosts de script do sistema. Isso inclui cmd, VBScript, Cscript e JScript®. Esses pontos de entrada, bem como os demais, usam a API de imposição da diretiva de restrição de software principal: SaferIdentifyLevel.

A API SaferIdentifyLevel determina se um executável especificado deve ter permissão de execução, procurando as informações de identificação nas diretivas de restrição de software relevantes. Trata-se de uma API documentada publicamente. Os hosts de script de terceiros e os ambientes executáveis podem e devem usá-la na integração com a diretiva de restrição de software de forma que a diretiva possa determinar se uma parte do código executável deve ter permissão de execução.

Executando como um usuário padrão

Um recurso não tão conhecido da diretiva de restrição de software é sua capacidade de filtrar os privilégios de determinados aplicativos quando eles são iniciados. Essa funcionalidade foi introduzida no Windows XP, mas não foi exposta na interface do usuário da diretiva de restrição de software até o Windows Vista.

Dessa forma, ela foi uma precursora da UAC do Windows Vista porque você poderia usá-la na execução de um aplicativo como Usuário Padrão mesmo quando o usuário fosse membro do grupo Administradores. É isso o que acontece quando você cria uma regra e define o Nível de Segurança como Usuário Normal na interface do usuário Regras Adicionais.

A funcionalidade de filtragem de token da UAC e as regras de Usuário Normal das diretivas de restrição de software usufruem uma API subjacente que implementa o mesmo comportamento da API CreateRestrictedToken. No entanto, as diferenças arquitetônicas gerais das tecnologias são bastante significativas. Mas a UAC difere da diretiva de restrição de software de várias formas significativas.

Primeiro, no Windows Vista com a UAC habilitada, por padrão, todos os aplicativos são iniciados com um token de segurança semelhante ao de um membro do grupo Usuários, mesmo quando o usuário é um administrador. Isso é conseguido com a diretiva de restrição de software, embora não haja nenhum modo de iniciar um aplicativo com o token Administrador real do usuário – por exemplo, quando o usuário precisa instalar um aplicativo. A alteração feita no contexto de segurança padrão e a facilidade de acesso ao token de administrador completo de um usuário são os principais benefícios da UAC.

A segunda diferença é que, no caso dos executáveis, o próprio código expressa o nível de privilégio necessário ao funcionamento. Trata-se de uma distinção importante porque ISVs (fornecedores independentes de software) e desenvolvedores compreendem a necessidade do código. Por exemplo, caso precise editar algo que exija privilégio administrativo, um aplicativo de painel de controle pode especificar esse requisito em seu manifesto. Dessa forma, o ISV pode descrever os privilégios exigidos por um aplicativo, em vez de impor um determinado nível de privilégio sem que haja qualquer meio disponível para alterar esse nível.

Por enquanto, você deve evitar usar as regras de Usuário Normal até compreender, de fato, como elas funcionam. A UAC é uma forma excelente de ajudar os usuários de desktop do grupo Administradores, e você deve considerar seriamente deixar a UAC no ambiente corporativo.

Diretivas de restrição de software usadas atualmente

Há várias partes móveis que você precisa levar em conta ao usar a diretiva de restrição de software. Mas não é como você deve pensar e, na verdade, você talvez esteja usando diretivas de restrição de software até mesmo sem perceber. Caso, por exemplo, execute Controles dos Pais em um sistema com Windows Vista, você está usando diretivas de restrição de software para controlar a execução dos aplicativos.

A diretiva de restrição de software foi um desenvolvimento tecnológico importante quando lançado pela primeira vez no Windows XP. Mas o bloqueio do aplicativo só está chamando mesmo a atenção dos profissionais de TI agora.

O recurso da diretiva de restrição de software no Windows Vista ainda tem algumas arestas a serem aparadas, mas está claro que os administradores desejam contar com esse controle maior sobre o que está em execução em seus ambientes. Felizmente para todos nós, essa tecnologia continuará evoluindo e facilitando o gerenciamento dos sistemas em nome dos profissionais de TI, o que reduz o custo da execução do ambiente do Microsoft Windows.

A diretiva de restrição de software básica

Uma aplicação da diretiva de restrição de software é criar uma diretiva que bloqueie o Windows em um modo de quiosque. Na verdade, a Microsoft produz um kit de ferramentas chamado SteadyState™ para a criação desse quiosque. No entanto, caso você esteja interessado apenas em bloquear os aplicativos que possam ser executados, isso pode ser conseguido mais facilmente.

Para permitir que o conjunto mínimo de aplicativos necessários faça logon no Windows Vista, crie uma diretiva que permita a execução de logonui.exe e userinit.exe em %windir%\system32. É provável que a maior parte dos usuários também precisará dos seguintes aplicativos com permissão de execução:

dllhost.exe, rundll32.exe, control.exe (also under %windir%\system32)....

Se quisesse o shell do Windows padrão, você também desejaria adicionar %windir%\explorer.exe.

Você também poderia optar por inicializar diretamente um aplicativo como, por exemplo, o Internet Explorer®. Nesse caso, seria necessário que você listasse iexplore.exe, e não explorer.exe.

Outro aspecto dessa diretiva básica é que os usuários não devem fazer parte do grupo Administradores. Isso é importante para que eles não consigam ignorar a diretiva. No entanto, como eles só podem executar um conjunto muito básico de aplicativos e não têm os privilégios de um Administrador, os usuários não terão os privilégios para instalar aplicativos ou manter o sistema.

Você precisará encontrar alguma forma de fazer isso nessas máquinas. Caso pretenda atualizar e manter essas máquinas fazendo logon localmente com uma conta Administrador, você deve selecionar o botão de opção que aplica a diretiva de restrição de software a todos os usuários, exceto os administradores locais. A diretiva também deve incluir consent.exe e cmd.exe. Isso permitirá ao administrador iniciar qualquer opção administrativa em um prompt de comando de administrador.

Observe que a UAC limita os privilégios do token de segurança do usuário por padrão para que ele seja semelhante ao token que não é membro do grupo Administradores. Mesmo que você defina a configuração acima para não aplicar a diretiva a Administradores, ela continuará sendo aplicada aos usuários. É somente quando você passa pela experiência de elevação da UAC que o Administrador efetivamente recebe os privilégios de administrador completos e a diretiva de restrição de software deixa de ser aplicada.

Chris CorioChris Corio foi membro da equipe de segurança do Windows na Microsoft durante mais de cinco anos. Na Microsoft, a sua atenção estava voltada principalmente para as tecnologias de segurança do aplicativo e de gerenciamento para a proteção do Windows. É possível entrar em contato com Chris pelo email winsecurity@chriscorio.com.

Durga Prasad SayanaDurga Prasad Sayana é engenheiro de criação de software/teste na equipe de segurança básica do Windows. Seus interesses principais são tecnologias de segurança e testes de software. É possível entrar em contato com Durga pelo email durgas@microsoft.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados; é proibida a reprodução parcial ou completa sem autorização..