Design do Mecanismo de Integridade do Windows

  • Artigo

O mecanismo de integridade do Windows é uma extensão da arquitetura de segurança do Windows, que se baseia no Monitor de Referência de Segurança no kernel. O monitor de referência de segurança impõe o controle de acesso comparando SIDs de usuário e grupo no token de acesso de segurança com permissões de acesso concedidas na ACL do descritor de segurança de um objeto. O mecanismo de integridade adiciona um nível de integridade ao token de acesso de segurança e uma entrada de controle de acesso de rótulo obrigatório à ACL do sistema (SACL) no descritor de segurança.

As principais partes do mecanismo de integridade são:

  • Níveis de integridade predefinidos e sua representação.
  • Políticas de integridade que restringem as permissões de acesso.
  • Nível de integridade atribuído ao token de acesso de segurança.
  • Entrada de controle de acesso de rótulo obrigatório.
  • Rótulos obrigatórios atribuídos a objetos.
  • Restrições de integridade nas APIs AccessCheck e seAccessCheck no modo kernel.

Cada uma dessas partes é descrita mais detalhadamente abaixo. O mecanismo de integridade do Windows está sempre em vigor, independente de outras opções de política de segurança. As verificações de nível de integridade, como as verificações de controle de acesso, não são opcionais. Não há opções de política de segurança para desabilitar verificações no nível de integridade. Embora o mecanismo de integridade dê suporte ao UAC, o mecanismo de integridade permanece em vigor quando o UAC é desabilitado por Política de Grupo de segurança.

Níveis de integridade

O Windows define níveis de integridade usando um SID. Usar um SID para representar um nível de integridade facilita muito a integração do mecanismo de integridade às estruturas de dados de segurança existentes sem a necessidade de alterações de código. OS SIDs de nível de integridade têm o seguinte formato: S-1-16-xxxx. A Tabela 1 mostra os componentes dos SIDs de nível de integridade.

Valores de autoridade do identificador sid no nível de integridade da Tabela 1

Valor Descrição

16

Representa a autoridade de rótulo obrigatória (SECURITY_MANDATORY_LABEL_AUTHORITY).

xxxx

Representa o campo RID (identificador relativo) que é o nível de integridade. RID é um valor hexadecimal que representa o nível de integridade.

Há quatro níveis de integridade principais no Windows Vista com quatro valores correspondentes. Um valor mais baixo indica um nível de integridade inferior ou um nível mais baixo de confiabilidade. Esses valores são definidos no arquivo de cabeçalho, winnt.h. A Tabela 2 mostra os níveis de integridade definidos e seus valores correspondentes.

Tabela 2 Níveis de integridade definidos e valores correspondentes

Valor Descrição Símbolo

0x0000

Nível não confiável

SECURITY_MANDATORY_UNTRUSTED_RID

0x1000

Baixo nível de integridade

SECURITY_MANDATORY_LOW_RID

0x2000

Nível médio de integridade

SECURITY_MANDATORY_MEDIUM_RID

0x3000

Alto nível de integridade

SECURITY_MANDATORY_HIGH_RID

0x4000

Nível de integridade do sistema

SECURITY_MANDATORY_SYSTEM_RID

Um exemplo de sid de nível de integridade médio é esta cadeia de caracteres: S-1-16-8192. O valor RID de 8192 é o equivalente decimal de 0x2000.

Os RIDs são separados por intervalos de 0x1000 para permitir a definição de níveis adicionais no futuro. A separação também permite atribuir um nível de integridade a um processo ligeiramente maior que o médio: por exemplo, para atender a metas específicas de design do sistema.

Os SIDs de nível de integridade definidos têm valores de nome de cadeia de caracteres associados a eles. O uso da API LookupAccountSID retornará nomes de cadeia de caracteres para cada SID de nível de integridade. A Tabela 3 mostra os nomes de cadeia de caracteres para os níveis de integridade.

Nomes de cadeia de caracteres no nível de integridade da Tabela 3

SID no nível de integridade Nome

S-1-16-4096

Rótulo obrigatório\Baixo nível obrigatório

S-1-16-8192

Rótulo obrigatório\nível obrigatório médio

S-1-16-12288

Rótulo obrigatório\Alto nível obrigatório

S-1-16-16384

Rótulo Obrigatório\Nível Obrigatório do Sistema

Os níveis de integridade também são definidos como cadeias de caracteres SID na SDDL (Linguagem de Definição do Descritor de Segurança). O SDDL define o formato de cadeia de caracteres que as funções ConvertSecurityDescriptorToStringSecurityDescriptor e ConvertStringSecurityDescriptorToSecurityDescriptor usam para descrever um descritor de segurança como uma cadeia de caracteres de texto. A linguagem também define elementos de cadeia de caracteres para descrever informações nos componentes de um descritor de segurança. Usar o SDDL para definir os níveis de integridade torna conveniente definir o nível de integridade de um objeto quando o objeto é criado. Para obter mais informações sobre cadeias de caracteres SID para níveis de integridade, consulte Recursos do Mecanismo de Integridade do Windows. O suporte de SDDL para rótulos obrigatórios é descrito no Apêndice A: SDDL para Rótulos Obrigatórios.

O Windows Vista usa SIDs no nível de integridade no token de acesso de segurança para representar o nível de integridade do assunto e usa SIDs de nível de integridade no rótulo obrigatório ACE em um descritor de segurança para representar o nível de integridade do objeto.

Políticas de integridade

O mecanismo de integridade do Windows usa políticas simples para determinar como usar os rótulos obrigatórios em objetos para restringir o nível de acesso disponível para assuntos de menor integridade. Isso significa que as políticas limitam o tipo de acesso que objetos de nível de integridade inferior têm permissão para ter a objetos de nível de integridade mais alto. A Tabela 4 mostra as duas categorias de política.

Categorias de política de integridade da Tabela 4

Categoria Descrição

Políticas obrigatórias de token de acesso

Defina no token de acesso e determine como as políticas obrigatórias se aplicam ao assunto, que é representado no token de acesso.

Políticas de rótulo obrigatórias

Defina no rótulo obrigatório ACE (descrito abaixo) em objetos e determine como restringir o acesso ao objeto.

As políticas de integridade são usadas quando a política obrigatória marcar é executada ao avaliar permissões de acesso em um objeto protegível. As políticas determinam como os direitos de acesso são restritos entre níveis de integridade.

Políticas de token de acesso obrigatório

A Tabela 5 mostra as políticas de token de acesso obrigatórias definidas no Windows Vista.

Tabela 5 Políticas de token de acesso obrigatório no Windows Vista

Política Descrição

TOKEN_MANDATORY_NO_WRITE_UP

A política padrão atribuída a todos os tokens de acesso. A política restringe o acesso de gravação por essa entidade a qualquer objeto em um nível de integridade mais alto.

TOKEN_MANDATORY_NEW_PROCESS_MIN

Controla o comportamento de atribuir o nível de integridade a processos filho. Normalmente, um processo filho herda o nível de integridade do processo pai quando o token de acesso do processo pai é atribuído ao filho. Com a política de NEW_PROCESS_MIN, o nível de integridade do processo filho será o nível mínimo de integridade do token de acesso pai ou o nível de integridade do objeto do arquivo executável para o novo processo. Essa política é definida por padrão em todos os tokens de acesso.

A política de NEW_PROCESS_MIN pode ser descrita por um exemplo. Suponha que haja um programa executável chamado lowcalc.exe. O arquivo de programa recebe um rótulo de baixa integridade. Em um prompt de comando, o usuário executa lowcalc.exe. O processo pai, cmd.exe, está em execução em um nível de integridade médio. Como o arquivo de imagem, lowcalc.exe, tem um rótulo de baixa integridade, a política de NEW_PROCESS_MIN define o nível de integridade do novo processo, lowcalc, como baixo. Isso é ilustrado no exemplo abaixo na seção Designing Applications to Run at a Low Integrity Level.

Políticas de rótulo obrigatórias

As políticas de rótulo obrigatório são definidas como sinalizadores (bits) no campo Máscara da entrada de controle de acesso de rótulo obrigatório. Esses sinalizadores de política determinam as restrições de permissões de acesso que se aplicam a assuntos de integridade inferiores. A Tabela 6 mostra as políticas de rótulo obrigatórias definidas no Windows Vista.

Tabela 6 Políticas de rótulo obrigatório no Windows Vista

Política Descrição

SYSTEM_MANDATORY_POLICY_NO_WRITE_UP

A política padrão em todos os rótulos obrigatórios do objeto. O sinalizador é equivalente à política de token de acesso NO_WRITE_UP. A política restringe o acesso de gravação ao objeto por um assunto com um nível de integridade inferior.

SYSTEM_MANDATORY_POLICY_NO_READ_UP

Restringe o acesso de leitura ao objeto por um assunto com um nível de integridade inferior. A política é usada, por exemplo, para restringir o acesso de leitura ao espaço de endereço de memória virtual de um processo.

SYSTEM_MANDATORY_POLICY_NO_EXECUTE_UP

Restringe o acesso de execução ao objeto por um assunto com um nível de integridade inferior. A política é usada, por exemplo, para restringir permissões de ativação de inicialização em uma classe COM por entidades de integridade inferiores.

Essas políticas definidas atendem às metas de design do Windows Vista. A arquitetura do mecanismo de integridade permite uma expansão futura definindo opções de política adicionais que controlam permissões de acesso entre entidades e objetos em diferentes níveis de integridade.

Como as políticas de integridade são mapeadas para direitos genéricos

A política obrigatória marcar ocorre como parte da função de segurança AccessCheck. AccessCheck (e SeAccessCheck no modo kernel) tem como um dos parâmetros de função uma estrutura GENERIC_MAPPING. O mapeamento genérico fornecido pelo chamador mapeia direitos de acesso específicos ao objeto para as categorias genéricas de leitura, gravação e execução. As políticas de rótulo obrigatório implementam restrições ao acesso permitido com base nas categorias genéricas. Para um tipo de objeto específico, o GENERIC_MAPPING se comunica com a política obrigatória marcar quais direitos de acesso específicos são proibidos.

Se a estrutura de GENERIC_MAPPING passada para uma chamada para AccessCheck for todos zeros (0), o mapeamento genérico será indefinido. Quando o mapeamento genérico é indefinido, a política obrigatória marcar restringe todos os direitos de acesso por entidades de integridade inferior. Os gerenciadores de recursos que usam o AccessCheck para segurança de objeto privado e passam uma estrutura GENERIC_MAPPING de todos os zeros verão erros de Acesso Negado . Uma alteração de código no aplicativo gerenciador de recursos é necessária para mapear direitos de acesso específicos do tipo de objeto para os direitos de acesso genéricos que a política obrigatória impõe.

Como os níveis de integridade são atribuídos aos tokens de acesso

O token de acesso de segurança é uma estrutura de dados interna que o kernel usa. O token de acesso de segurança contém valores de informações diferentes que correspondem a privilégios, associação de grupo e outros detalhes relacionados à segurança. A inicialização do token de acesso ocorre quando um usuário faz logon interativamente no Windows ou quando ocorre uma autenticação de rede. Quando o token de acesso é inicializado, o SID do usuário, os SIDs de grupo e os privilégios são adicionados, além de outros valores. O Windows Vista atribui o nível de integridade para o token de acesso quando o token de acesso é inicializado.

O kernel atribui um token de acesso a cada processo e thread. O token de acesso primário do processo contém o nível de integridade associado a esse processo. No mecanismo de integridade do Windows, o nível de integridade do processo é conhecido como o nível de integridade do assunto. Se o token de acesso de um aplicativo contiver o SID de integridade média, o processo do aplicativo será executado em um nível de integridade média. Vários processos de aplicativo em execução na mesma conta de usuário recebem o mesmo token de acesso primário. É assim que cada um dos aplicativos recebe o mesmo nível de integridade.

Os níveis de integridade são atribuídos a tokens de acesso com base em SIDs de grupo específicos presentes na estrutura TOKEN_GROUPS. O kernel do Windows atribui um nível de integridade com base em contas de usuário ou grupo internas específicas. O Windows Vista atribui um token de acesso que tem o SID da conta do Sistema Local presente no nível de integridade do sistema, um token de acesso com o SID do grupo de administradores local presente recebe o nível de integridade alto e um token de acesso para uma conta de usuário padrão recebe o nível de integridade médio.

A Tabela 7 mostra as atribuições de nível de integridade para o token de acesso, com base na presença de SIDs específicos.

Níveis de integridade da Tabela 7 vinculados a SIDs específicos

SID no token de acesso Nível de integridade atribuído

LocalSystem

Sistema

LocalService

Sistema

NetworkService

Sistema

Administradores

Alto

Operadores de cópia

Alto

Operadores de Configuração de Rede

Alto

Operadores criptográficos

Alto

Usuários Autenticados

Médio

Todos (Mundo)

Baixo

Anônima

Untrusted

Os níveis de integridade definem diferentes níveis de confiabilidade para aplicativos em execução em diferentes níveis de acesso. A maioria dos aplicativos no Windows Vista é executada em um nível de usuário padrão de acesso no nível de integridade média. Os aplicativos no nível de integridade média não têm restrições sobre como interagem com outros aplicativos e com dados no nível de integridade média. Tarefas ou aplicativos específicos que exigem direitos administrativos são executados em um nível de integridade alto. Os serviços do sistema são executados no nível de integridade do sistema, pois há restrições na capacidade de interagir com a área de trabalho padrão e geralmente são executados com privilégios avançados do sistema. Alguns aplicativos que foram projetados para serem executados com o menor número possível de direitos, como o modo protegido Explorer internet, podem ser executados com um nível de integridade baixo.

Determinados privilégios administrativos do Windows podem ser atribuídos a um token de acesso somente com pelo menos um alto nível de integridade. Se o nível de integridade do token de acesso for menor que alto, os privilégios administrativos específicos não serão permitidos e serão removidos do token de acesso. Os privilégios administrativos associados a um alto nível de integridade são:

  • SE_CREATE_TOKEN_PRIVILEGE
  • SE_TCB_PRIVILEGE
  • SE_TAKE_OWNERSHIP_PRIVILEGE
  • SE_BACKUP_PRIVILEGE
  • SE_RESTORE_PRIVILEGE
  • SE_DEBUG_PRIVILEGE
  • SE_IMPERSONATE_PRIVILEGE
  • SE_RELABEL_PRIVILEGE
  • SE_LOAD_DRIVER_PRIVILEGE

Os aplicativos podem atribuir um nível de integridade baixo a um token de acesso duplicado ao criar um processo filho. O Windows poderá executar um processo de aplicativo com um nível de integridade baixo se o arquivo de imagem do programa executável tiver um rótulo baixo obrigatório. Esses recursos são descritos posteriormente neste artigo.

Como obter o nível de integridade de um token de acesso

O nível de integridade é armazenado no token de acesso usando o campo TOKEN_GROUPS. A estrutura TOKEN_GROUPS é uma lista de SIDs e atributos que identifica as associações de grupo para essa conta de usuário. O nível de integridade do token de acesso também é identificado na lista de grupos usando um atributo SID. A estrutura SID_AND_ATTRIBUTES contém o SID de nível de integridade e o nível de integridade é identificado usando os atributos SE_GROUP_INTEGRITY e SE_GROUP_INTEGRITY_ENABLED.

Você pode recuperar o nível de integridade do token de acesso do token de acesso usando a API GetTokenInformation. GetTokenInformation tem um parâmetro para indicar qual classe de informações de token de acesso recuperar. O parâmetro TOKEN_INFORMATION_CLASS tem um valor definido para o nível de integridade, TokenIntegrityLevel. A estrutura de dados retornada é um tipo de TOKEN_MANDATORY_LABEL.

Para determinar o nível de integridade de um processo

  1. Abra um identificador para o token de acesso do processo.

  2. Obtenha o nível de integridade do token de acesso.

  3. Compare o SID de nível de integridade com as RIDs de nível de integridade definidas pelo sistema.

O código de exemplo para obter o nível de integridade do token de acesso é mostrado no Apêndice D.

Como exibir o nível de integridade de um token de acesso

O nível de integridade no token de acesso de segurança de um processo pode ser exibido usando ferramentas que expõem os detalhes de segurança de um processo, como Processar Explorer de SysInternals.com. As imagens a seguir mostram a exibição de Process Explorer com a coluna Nível de Integridade adicionada à exibição (à direita).

Figura 1 Nível de integridade no Explorer de processo

Se examinarmos as propriedades de segurança de um processo específico, como explorer.exe, Process Explorer mostrará o nível de integridade na lista de grupos definidos no token de acesso de segurança do processo. A imagem a seguir mostra o Rótulo Obrigatório/Nível Médio Obrigatório atribuído ao token de acesso para o processo, explorer.exe.

Figura 2 Explorer.exe como um processo de nível de integridade médio

Como definir o nível de integridade de um token de acesso

Os aplicativos geralmente não precisam alterar o valor do nível de integridade do processo. Os aplicativos normalmente não precisam fazer alterações em nenhum dos valores no token de acesso de segurança. No entanto, em algumas circunstâncias, os serviços que dão suporte a clientes locais em diferentes níveis de integridade podem optar por realizar tarefas em um nível de integridade mais baixo. A representação é uma maneira pela qual um thread de serviço pode estar em execução em um nível de integridade mais baixo. Quando um thread de serviço representa um cliente local, o thread de representação tem o contexto de segurança do cliente, que inclui o nível de integridade do cliente se o cliente estiver em execução no mesmo computador local.

Outra maneira de um aplicativo realizar uma operação, como a criação de um conjunto de arquivos e chaves do Registro, em um nível de integridade inferior é definir o TokenIntegrityLevel para o token de acesso de thread atual. O novo nível de integridade não pode ser maior do que o nível de integridade no token de acesso primário do processo.

Para definir o valor de um nível de integridade do token de acesso em um thread

  1. Chame OpenThreadToken para obter um identificador para o token de acesso.

  2. Chame GetTokenInformation com o valor do parâmetro TOKEN_INFORMATION_CLASS de TokenIntegrityLevel para salvar o nível de integridade do thread atual.

  3. Chame SetTokenInformation com o valor do parâmetro TOKEN_INFORMATION_CLASS de TokenIntegrityLevel.

Como não há limite de segurança em um espaço de endereço de processo entre threads em diferentes níveis de integridade, os designers de aplicativos devem considerar os riscos potenciais de segurança de ter código em execução em um thread com menor integridade em execução em um processo de integridade mais alta. A maioria dos aplicativos pode achar mais simples criar um processo separado em execução no nível de integridade inferior para executar tarefas de menor integridade.

Um exemplo de como definir o TokenIntegrityLevel e criar um processo em um nível de integridade inferior é mostrado em Como definir o nível de integridade de um token de acesso.

ACE de rótulo obrigatório

O mecanismo de integridade do Windows define um novo tipo ACE, o ace de rótulo obrigatório do sistema. O ACE de rótulo obrigatório é usado para representar o rótulo obrigatório de um objeto no descritor de segurança do objeto. O rótulo obrigatório contém o nível de integridade e a política de integridade associada. Um ACE de rótulo obrigatório é usado apenas na ACL do sistema, ou SACL, do descritor de segurança. O SACL é um campo separado no descritor de segurança da ACL discricionária (DACL).

Figura 3 Campos do descritor de segurança

A ACL discricionária contém permissões de acesso de usuário e grupo ao objeto . Qualquer usuário ou grupo pode fazer atualizações na DACL com permissões de acesso WRITE_DAC objeto. As ACLs discricionárias podem ser atualizadas com mais frequência e por usuários diferentes. Uma das metas de design do mecanismo de integridade é que o sistema de segurança deve manter o rótulo com um objeto depois que um rótulo obrigatório é aplicado ao objeto . A imposição do rótulo obrigatório apropriado no descritor de segurança do objeto, com pouco ou nenhum impacto para aplicativos projetados para gerenciar ACLs, é realizada colocando o rótulo obrigatório na ACL do sistema, em que está principalmente sob o controle do sistema de segurança. O rótulo obrigatório é logicamente separado das entradas de auditoria do sistema no SACL. Não há nenhuma ordem necessária para que o rótulo obrigatório preceda ou siga as entradas de auditoria do sistema no SACL.

O ACE de rótulo obrigatório é semelhante a um ACE permitido de acesso, pois contém um cabeçalho ACE, uma máscara de acesso e um SID. A parte SID do rótulo obrigatório ACE contém o SID de nível de integridade. A Tabela 8 mostra os campos no cabeçalho ACE.

Campos da Tabela 8 contidos no cabeçalho ACE

Campo de cabeçalho ACE Valor

AceType

SYSTEM_MANDATORY_LABEL_ACE_TYPE

AceFlags

Sinalizadores de controle que definem a herança do tipo ACE de rótulo obrigatório

AceSize

Tamanho do rótulo obrigatório ACE

O ace de rótulo obrigatório contém um campo Máscara . A máscara é usada para definir as políticas obrigatórias que determinam restrições nas permissões de acesso que se aplicam a processos (ou entidades) com um nível de integridade inferior. Uma política de exemplo amplamente usada no Windows Vista é a política de NO_WRITE_UP. O sinalizador de política de NO_WRITE_UP na máscara ACE de rótulo obrigatório significa que os sujeitos com um nível de integridade mais baixo (no token de acesso) do que o SID de nível de integridade no rótulo obrigatório no objeto são impedidos de obter acesso de gravação genérico ao objeto.

Há apenas um rótulo obrigatório efetivo em um objeto . Se um descritor de segurança receber mais de um rótulo obrigatório no SACL, o primeiro ACE de rótulo obrigatório no SACL será o rótulo efetivo do objeto.

Para obter mais informações sobre o ace de rótulo obrigatório, consulte Recursos do Mecanismo de Integridade do Windows.

Lendo o RÓTULO ACE obrigatório

O Windows Vista usa a função de segurança GetSecurityInfo para ler as informações de rótulo obrigatórias de um objeto. GetSecurityInfo obtém as informações de proprietário, grupo, DACL ou SACL de um objeto . O parâmetro SECURITY_INFORMATION para GetSecurityInfo determina qual parte do descritor de segurança é retornada. O Windows Vista define um novo valor de informações de segurança, LABEL_SECURITY_INFORMATION, que é usado para retornar o ace de rótulo obrigatório do SACL. Se a chamada para GetSecurityInfo especificar SACL_SECURITY_INFORMATION, somente os ACEs de auditoria do sistema no SACL serão retornados, não o rótulo obrigatório ACE.

A permissão de acesso necessária para ler o RÓTULO ACE obrigatório em um objeto é o direito de acesso padrão READ_CONTROL. Normalmente, o direito de acesso ACCESS_SYSTEM_SECURITY é necessário para obter ou definir informações no SACL. ACCESS_SYSTEM_SECURITY será concedido somente se o privilégio SE_SECURITY_NAME estiver habilitado no token de acesso. Ler o rótulo obrigatório da SACL não requer privilégio SE_SECURITY_NAME ou o direito de acesso ACCESS_SYSTEM_SECURITY.

Definindo o rótulo obrigatório ACE

O Windows Vista usa a função de segurança SetSecurityInfo para alterar as informações de rótulo obrigatórias em um objeto. O rótulo obrigatório do objeto é definido pelo subsistema de segurança quando o objeto é criado. O parâmetro SECURITY_INFORMATION para SetSecurityInfo deve incluir LABEL_SECURITY_INFORMATION para alterar o rótulo obrigatório no descritor de segurança.

O rótulo obrigatório atribuído na criação de objeto geralmente é o nível de integridade correto para um objeto e não há necessidade de alterar o rótulo obrigatório. No entanto, pode haver requisitos de design de aplicativo para alterar o nível de integridade de um objeto quando o aplicativo for projetado para dar suporte a vários processos de cliente em diferentes níveis de integridade.

As permissões necessárias para alterar o ace de rótulo obrigatório no SACL de um descritor de segurança são WRITE_OWNER. Gravar o rótulo obrigatório no SACL não requer privilégio SE_SECURITY_NAME ou o direito de acesso ACCESS_SYSTEM_SECURITY. O nível de integridade no rótulo obrigatório pode ser definido como um valor menor ou igual ao nível de integridade da entidade.

A alteração mais comum é reduzir o nível de integridade de um objeto para permitir que um processo de aplicativo de integridade inferior tenha acesso modificado. Por exemplo, um aplicativo no nível de integridade média precisa ser sincronizado com outro processo de aplicativo em execução em baixo nível de integridade. O processo de integridade média cria um objeto mutex nomeado e atribui a ele um rótulo obrigatório em baixo para permitir que um processo de integridade inferior abra o mutex para sinalizar eventos.

Privilégio de relançamento

O mecanismo de integridade do Windows define um novo privilégio de segurança do Windows, SE_RELABEL_NAME. Quando habilitado em um token de acesso de segurança, o privilégio de segurança de nova rotulagem permite que o sujeito defina o rótulo obrigatório de um objeto como um nível de integridade mais alto do que o nível de integridade no token de acesso da entidade. A política de segurança padrão do Windows Vista não atribui esse privilégio a nenhum usuário ou grupo. O privilégio foi projetado para resolver cenários em que um processo de Administrador em execução em um alto nível de integridade precisa alterar ou atribuir o rótulo obrigatório para objetos no nível de integridade do sistema. O Windows Vista não tem nenhuma tarefa que exija ou use o privilégio de relançamento.

Como o Windows atribui um rótulo obrigatório a objetos

O Windows atribui um rótulo obrigatório a um objeto protegível quando o descritor de segurança do objeto é criado. O nível de integridade em um novo objeto é atribuído de uma das três maneiras:

  • O subsistema de segurança atribui ao objeto um rótulo obrigatório quando o descritor de segurança é criado para o objeto .
  • O processo de criação especifica um rótulo obrigatório explícito como atributos de segurança ao criar o objeto usando uma função, como CreateFile.
  • O contêiner pai define uma ACE de rótulo obrigatório herdável que se aplica a objetos filho criados no contêiner.

A maneira mais fácil de entender como os níveis de integridade do objeto são atribuídos é assumir que cada objeto recebe um rótulo obrigatório com o mesmo nível de integridade que o nível de integridade do assunto do processo de criação (ou thread). No entanto, há exceções à ideia geral com base no tipo de objeto e no nível de integridade do assunto. As exceções são o resultado de opções de design necessárias para dar suporte a outros requisitos do sistema para uma experiência de usuário consistente quando várias políticas de segurança, como o UAC, estão habilitadas ou desabilitadas.

Os rótulos obrigatórios podem ser aplicados a todos os objetos protegíveis que têm controle de acesso com base no descritor de segurança. Há muitos tipos de objetos protegíveis, incluindo objetos de processo e thread, objetos nomeados e objetos persistentes, como arquivos ou chaves do Registro. O Windows Vista não atribui rótulos obrigatórios explícitos a todos os tipos de objeto quando objetos são criados. Os tipos de objeto aos quais o subsistema de segurança atribui rótulos obrigatórios na criação do objeto são:

  • Processar
  • Thread
  • Token de acesso
  • Trabalho

Todos os outros tipos de objeto têm um padrão implícito ou um rótulo obrigatório herdado. Lembre-se de que, durante a inicialização do token de acesso, um nível de integridade é atribuído ao token de acesso de segurança criado durante um logon interativo. O primeiro processo iniciado em nome de um logon de usuário é userinit.exe, que inicia o processo de shell, explorer.exe. Userinit.exe é iniciado por um serviço do sistema (Winlogon) que usa uma chamada para CreateProcessAsUser e passa o token de acesso para o usuário de logon interativo.

CreateProcessAsUser cria um objeto de processo e um thread inicial, entre outras coisas. Quando o objeto de processo é criado, o descritor de segurança para esse processo recebe o nível de integridade do token de acesso atribuído como o token de acesso primário ao novo processo. Quando userinit.exe chama CreateProcess para iniciar o shell, o objeto de processo para explorer.exe é inicializado. O objeto de processo inclui um descritor de segurança e um token de acesso primário. O rótulo obrigatório no processo de explorer.exe é definido como o nível de integridade do processo de criação, userinit.exe, que é médio. O token de acesso primário para explorer.exe é herdado do processo pai de criação, userinit.exe e tem um nível de integridade médio. Quando o processo de explorer.exe cria um novo thread, o objeto thread recebe um descritor de segurança e o subsistema de segurança atribui um nível de integridade ao objeto thread com base no nível de integridade do processo de criação. Os objetos de thread dentro do processo de explorer.exe são atribuídos a um nível de integridade médio, que é o nível de integridade do token de acesso primário do processo de criação.

Observação

Um objeto de token de acesso é um objeto protegível com seu próprio descritor de segurança. O descritor de segurança do token é usado para determinar o acesso permitido durante as funções OpenProcessToken ou OpenThreadToken. O objeto de token de acesso tem um rótulo obrigatório no descritor de segurança no objeto de token de acesso. O token de acesso também contém um SID no nível de integridade na lista de grupos de tokens de acesso que representa o nível de integridade do assunto.

Ao sempre atribuir rótulos obrigatórios para processar, thread, token e objetos de trabalho, o mecanismo de integridade impede que processos para o mesmo usuário em níveis de integridade inferiores acessem esses tipos de objeto e modifiquem seu conteúdo ou comportamento, como injetar uma DLL ou representar um token de acesso de nível superior.

Nível de integridade padrão

Nem todos os tipos de objeto recebem uma ACE de rótulo obrigatório no descritor de segurança. Se um rótulo obrigatório ACE estiver presente no descritor de segurança, isso será chamado de rótulo obrigatório explícito. Se nenhuma ACE de rótulo obrigatório estiver presente, o subsistema de segurança usará um rótulo obrigatório padrão implícito para esse objeto durante a política obrigatória marcar. O rótulo obrigatório padrão atribui um nível de integridade médio para todos os objetos protegíveis. Se um rótulo obrigatório não for definido no descritor de segurança, o rótulo obrigatório padrão implícito se aplicará a todos os tipos de objeto.

O nível de integridade do objeto padrão de médio, combinado com a política obrigatória padrão de NO_WRITE_UP, restringe a modificação do acesso a todos os objetos por processos com um nível de integridade do assunto menor que médio. O rótulo e a política obrigatórios padrão impedem que processos não confiáveis com baixa integridade modifiquem arquivos de usuário ou sistema ou chaves do Registro no sistema que, de outra forma, podem permitir acesso de gravação discricionário na DACL.

Os objetos do sistema de arquivos NTFS e as chaves do Registro não são rotulados automaticamente quando são criados. Esses objetos não têm rótulos obrigatórios após a atualização de uma versão anterior do Windows para o Windows Vista. Arquivos em sistemas de arquivos não NTFS (CDFS ou FAT32) que não têm descritores de segurança não são objetos protegíveis e não têm um nível de integridade. Cada descritor de segurança deve ter um rótulo obrigatório implícito.

Processos com um nível de integridade do assunto no ou acima de arquivos de criação médio e chaves do Registro sem um rótulo explícito. Como consequência, o sistema de arquivos e os objetos do Registro criados por um processo de nível de integridade do sistema ou alto têm um rótulo médio implícito. Aplicativos que usam rótulos obrigatórios podem definir rótulos explícitos ao criar objetos. No entanto, o Windows Vista não atribui rótulos superiores ao nível de integridade médio ao sistema de arquivos ou ao registro por padrão. Isso não significa que esses objetos estejam necessariamente abertos à modificação por processos de integridade inferior. A lista de controle de acesso discricionário herdada (ou padrão) no sistema de arquivos ou objetos do Registro que foram criados por um processo de alto ou nível do sistema concede acesso de gravação somente a membros do grupo Administradores ou a contas de serviço ou sistema locais.

Uma série de restrições de design necessárias usando o rótulo obrigatório implícito padrão de média, em vez de atribuir um rótulo obrigatório explícito com base no nível de integridade do assunto para a maioria dos tipos de objeto. Um exemplo específico baseia-se na capacidade de habilitar ou desabilitar o Controle de Conta de Usuário usando a política de segurança local. Quando o UAC está desabilitado, um usuário que é membro do grupo administradores local tem todos os processos em execução com um token de acesso de privilégio completo em um nível de integridade alto. Se todos os objetos forem explicitamente rotulados no nível de integridade do assunto, todos os arquivos, como documentos e planilhas que o usuário cria, receberão um alto nível de integridade. O rótulo alto parece apropriado, embora as permissões DACL herdadas para o perfil de usuário forneçam controle de acesso suficiente para o acesso do usuário. No entanto, se o UAC estiver habilitado por computador local ou Política de Grupo, a maioria dos processos executados pelo mesmo usuário receberá um token de acesso de segurança filtrado em um nível de integridade médio. Depois que o UAC estiver habilitado, o usuário não poderá abrir arquivos que foram criados quando o UAC foi desabilitado. Um aplicativo de integridade média que tentou abrir os documentos de alta integridade do usuário receberia um erro acesso negado.

Se um processo estiver em execução com um nível de integridade do assunto menor que o nível de integridade padrão de média, esse processo terá permissões de acesso restritas a todos os objetos que têm um nível implícito de integridade média. Os processos com baixo nível de integridade não poderão modificar nenhum objeto com um nível de integridade explícito ou implícito de médio ou superior, independentemente dos direitos de acesso concedidos na DACL à entidade de segurança. Portanto, todos os objetos criados por um processo com um nível de integridade do assunto menor que o nível padrão (médio) são explicitamente rotulados pelo subsistema de segurança. Restrições de acesso em processos de baixa integridade são possíveis no Windows Vista porque todos os aplicativos geralmente são executados no nível de integridade média e os problemas de compatibilidade do aplicativo são mínimos. Os aplicativos executados corretamente com baixa integridade geralmente exigem alterações de design específicas para funcionar corretamente com acesso restrito. As alterações de design são discutidas na seção abaixo sobre Como criar aplicativos para serem executados em um nível de integridade baixo.

Rotulando objetos criados por assuntos baixos

Os aplicativos podem ser iniciados usando a função CreateProcessAsUser em um nível de integridade baixo. Um processo baixo é inicializado por CreateProcessAsUser com as seguintes informações de nível de integridade:

  • O novo objeto de processo é criado com um descritor de segurança que contém um rótulo obrigatório com baixa integridade.
  • Um novo objeto thread é criado para esse processo e com um descritor de segurança que contém um rótulo obrigatório com baixa integridade.
  • Um token de acesso primário é atribuído ao novo processo. O objeto de token de acesso tem um descritor de segurança com um rótulo obrigatório em baixa e o token de acesso contém um TokenIntegrityLevel com um SID de baixa integridade que representa o nível de integridade do assunto.

Suponha que o processo de baixa integridade esteja em execução e que ele queira criar um thread. Para criar um thread, ele deve abrir seu próprio objeto de processo para acesso de gravação para criar um novo objeto de thread. Se o rótulo obrigatório no objeto de processo fosse médio, a entidade baixa não abriria o processo e não seria capaz de criar um novo thread. Como o objeto de processo também é rotulado com baixa integridade, o assunto baixo tem permissão para abrir o processo de acesso de gravação e criar um novo objeto de thread. O exemplo mostra por que é importante que os rótulos obrigatórios no objeto de processo, objetos de thread e token de acesso de segurança sejam consistentes no mesmo nível de integridade.

Observação

Isso se aplica a todos os níveis de integridade, não apenas a assuntos baixos.

Suponha que o processo baixo crie um arquivo temporário. O aplicativo chama CreateFile para criar um novo arquivo, gravar alguns dados e fechar o arquivo. Posteriormente, o processo baixo deseja reabrir o mesmo arquivo para acrescentar dados. Se o arquivo temporário tiver um rótulo obrigatório padrão implícito no nível de integridade média, o processo baixo não poderá reabrir o arquivo criado anteriormente para modificar o acesso. O mesmo problema pode surgir para qualquer objeto protegível que um assunto com um nível de integridade abaixo do nível padrão de média cria. Portanto, todos os objetos protegíveis criados por um assunto com um nível de integridade abaixo do nível padrão recebem automaticamente um rótulo obrigatório explícito. Em outras palavras, todos os objetos de kernel, chaves do Registro e objetos do sistema de arquivos são explicitamente rotulados como baixos quando o nível de integridade do assunto é baixo.

Como criar um objeto com um rótulo obrigatório específico

A maioria dos aplicativos do Windows não precisa ter "reconhecimento de integridade". O subsistema de segurança cria automaticamente objetos e atribui a eles um rótulo obrigatório. Como a maioria dos aplicativos é executada em um nível de integridade médio e o nível de integridade do objeto padrão é médio, a política de integridade não altera o controle de acesso permitido para a maioria dos aplicativos. No entanto, alguns aplicativos, como serviços, foram projetados para dar suporte a aplicativos cliente em diferentes níveis de integridade. O serviço pode estar em execução em um nível de integridade mais alto do que o cliente e talvez queira rotular novos objetos criados em nome do cliente explicitamente em um nível de integridade inferior. O nível de integridade do objeto pode ser definido pelo processo de criação. A restrição é que o nível de integridade no novo objeto deve ser menor ou igual ao nível de integridade do processo de criação.

Para criar um objeto com um rótulo obrigatório específico
  1. Crie um descritor de segurança SDDL que define um rótulo obrigatório baixo, por exemplo:
    #define LOW_INTEGRITY_SDDL_SACL_W L"S:(ML;;NW;;;LW)"
  2. Converta a cadeia de caracteres SDDL em um descritor de segurança usando ConvertStringSecurityDescriptorToSecurityDescriptor.
  3. Atribua o descritor de segurança com o rótulo de baixa obrigatória a uma estrutura de atributos de segurança.
  4. Passe o parâmetro de atributos de segurança para a chamada para criar um objeto, como CreateFile.

Herança de rótulo obrigatória

O Windows Vista não rotula explicitamente arquivos e diretórios no sistema de arquivos NTFS. Conforme mencionado anteriormente, o subsistema de segurança usa um rótulo obrigatório implícito com um nível padrão de médio para objetos que não têm um rótulo obrigatório no descritor de segurança.

Os aplicativos podem ser projetados para serem executados em um nível de integridade baixo. O modo protegido internet Explorer é um exemplo de um aplicativo do Windows Vista que foi projetado para ser executado com baixa integridade. Aplicativos com baixa integridade podem precisar de pastas no sistema de arquivos em que podem gravar arquivos temporários ou dados de aplicativo. No caso do modo protegido internet Explorer, a pasta Arquivo temporário da Internet no perfil do usuário é usada. Como um aplicativo baixo pode gravar em uma pasta do sistema de arquivos? A pasta deve receber um rótulo obrigatório explícito que permita o acesso de gravação de um processo de baixa integridade.

Dependendo do design do aplicativo, pode haver outros processos de cooperação que adicionam arquivos à pasta usada pelo aplicativo de baixa integridade. Se os outros processos também estiverem em execução com baixa integridade, os arquivos criados por esses processos receberão automaticamente um rótulo de baixa obrigatória. No entanto, se o outro processo de parceiro tiver uma integridade mais alta, o processo do parceiro (um serviço de sincronização de arquivos ou agente de usuário) poderá criar arquivos na pasta baixa que não são rotulados automaticamente como baixo. O processo de parceiro cria um arquivo médio na pasta usada pelo aplicativo baixo, que o aplicativo baixo não pode modificar ou excluir.

O mecanismo de integridade permite que uma pasta com um rótulo baixo obrigatório tenha objetos filho, arquivos e subpastas, cada um com um rótulo obrigatório diferente e mais alto porque cada objeto do sistema de arquivos tem um descritor de segurança exclusivo. Há muitos cenários em que a intenção é que, para uma pasta que recebe um rótulo obrigatório baixo, todos os arquivos na pasta devem receber um rótulo baixo obrigatório para que um processo baixo possa modificá-los. O mecanismo de integridade dá suporte a isso, permitindo que ACEs de rótulo obrigatórios sejam herdáveis do contêiner pai para subcontêneros e objetos filho.

A estrutura de dados de tipo ACE de rótulo obrigatório contém um cabeçalho ACE com um campo AceFlags. O campo AceFlags é usado para definir sinalizadores de herança para o tipo ACE que são iguais aos sinalizadores de herança para outros tipos ace, como o tipo ACE de acesso permitido que é usado para acesso discricionário. AcEs de rótulo obrigatório podem ser definidos como herdáveis, para CI (herdado de contêiner) e/ou OI (herdado de objeto). ACEs de rótulo obrigatório não podem ser inherit_only (E/S). Se houver uma ACE de rótulo obrigatório herdável atribuída a um contêiner, o rótulo obrigatório se aplicará ao próprio contêiner e aos objetos filho aos quais a herança se aplica.

Um exemplo de um rótulo obrigatório herdável é o rótulo baixo obrigatório em uma das pastas criadas em cada perfil de usuário: %USERPROFILE%\AppData\LocalLow. Essa pasta recebe um rótulo baixo obrigatório quando o perfil é inicializado e se destina como a pasta de nível superior que é gravável por padrão por aplicativos de baixa integridade. A imagem a seguir mostra o rótulo obrigatório herdável na pasta AppData\LocalLow exibida usando o comando Icacls. Para obter mais informações sobre como o Icacls dá suporte a rótulos obrigatórios, consulte Apêndice B: Icacls e Níveis de Integridade de Arquivo.

Os sinalizadores de herança no rótulo obrigatório indicam que o ACE é (OI) e (CI) ACE com uma política obrigatória de NO_WRITE_UP (NW). Todas as subpastas criadas na pasta AppData\LocalLow herdarão o rótulo herdável.

Figura 4 Rótulo herdável baixo obrigatório

Quando um novo arquivo ou subpasta é criado a partir de um processo médio, o novo objeto herda o rótulo baixo obrigatório. No exemplo a seguir, o prompt de comando está em execução em processo com nível de integridade médio. Um arquivo, newfile.txt e uma nova pasta, Temp, é criado na pasta LocalLow e ambos os objetos herdam o rótulo de baixa obrigatória do contêiner pai. Icacls indica que o rótulo obrigatório é herdado com a designação (I).

Figura 5 Herdando um rótulo obrigatório em um objeto filho

A herança de rótulos obrigatórios garante a consistência no nível de integridade dos objetos criados em uma parte do namespace do sistema de arquivos.

Herança e rótulos explícitos

Objetos criados em um contêiner que tem um rótulo obrigatório herdável herdam o rótulo obrigatório do contêiner. No entanto, o processo que cria um novo objeto, como um arquivo, pode fornecer um rótulo obrigatório explícito no parâmetro de atributos de segurança para a função create, como CreateFile.

Se o processo de criação fornecer um rótulo explícito como um parâmetro para a função de criação de objeto, o novo objeto receberá o rótulo obrigatório explícito fornecido pelo chamador e não herdará do contêiner pai. O rótulo obrigatório explícito pode ter um nível de integridade não superior ao processo de assunto que cria o objeto. O nível de integridade no rótulo obrigatório explícito fornecido pela entidade pode ser maior do que o nível de integridade no rótulo obrigatório herdável do contêiner pai.

Restrição somente herdada

E/S (herdar somente) é um sinalizador em uma entrada de controle de acesso que indica que a ACE não controla o acesso ao objeto ao qual ele está anexado. AcEs somente herdados geralmente são atribuídos a objetos de contêiner. O ACE somente herdado não é eficaz no próprio contêiner; em vez disso, aplica-se a objetos filho do contêiner. Há uma restrição em assuntos com um nível de integridade menor que o padrão para definir rótulos de INHERIT_ONLY em novos objetos. Se o rótulo explícito passado para um novo objeto de contêiner for um rótulo INHERIT_ONLY com um nível menor que o padrão, o rótulo será considerado inválido e ignorado. A lógica para essa restrição é que um assunto baixo cria um contêiner e tenta definir um rótulo de INHERIT_ONLY no contêiner em baixo. Se o rótulo INHERIT_ONLY fosse aceito, o nível de integridade efetivo para o contêiner seria o nível padrão implícito de média.

Além disso, os sujeitos não podem definir um rótulo INHERIT_ONLY com um nível de integridade superior ao nível de integridade da entidade. Por exemplo, um assunto médio não pode definir um rótulo INHERIT_ONLY com um nível de integridade alto.

SACL protegida e herança de rótulo

O SDDL dá suporte à definição de uma SACL protegida, que pode incluir um rótulo obrigatório explícito. A SACL protegida define o sinalizador SE_SACL_PROTECTED no campo SECURITY_DESCRIPTOR_CONTROL do descritor de segurança. A separação lógica de LABEL_SECURITY_INFORMATION e SACL_SECURITY_INFORMATION em relação aos direitos de acesso não é completa em relação a como uma SACL protegida se comporta. Os rótulos obrigatórios são armazenados na SACL. Uma SACL protegida implica que o rótulo obrigatório também está protegido.

Se o sinalizador SE_SACL_PROTECTED estiver definido no SECURITY_DESCRIPTOR_CONTROL, o rótulo obrigatório também será protegido.

  • Se não houver nenhuma ACE de rótulo obrigatório na SACL protegida, uma ACE de rótulo obrigatório herdável do contêiner não será aplicada (o novo objeto tem um rótulo obrigatório padrão implícito).
  • Se houver uma ACE de rótulo obrigatório na SACL protegida, as alterações no rótulo herdável ACE no contêiner não afetarão esse objeto.

Para obter mais informações sobre o SDDL, consulte Apêndice A: SDDL para rótulos obrigatórios ou Recursos do Mecanismo de Integridade do Windows.

Como as verificações de acesso funcionam com a política obrigatória

A função AccessCheck impõe a política obrigatória. O AccessCheck compara o descritor de segurança especificado com o token de acesso especificado e indica, no parâmetro AccessStatus , se o acesso é concedido ou negado. A função AccessCheck primeiro compara o nível de integridade no ClientToken com o rótulo obrigatório na SACL do pSecurityDescriptor para determinar quais direitos de acesso não estão disponíveis, com base na política obrigatória. Depois que a política obrigatória marcar, o AccessCheck compara o acesso desejado com os direitos de acesso concedidos na DACL.

A política obrigatória padrão impede que processos de integridade inferior obtenham acesso genérico de gravação a objetos de integridade mais alta. Por exemplo, por padrão, um processo de baixa integridade tem acesso de gravação genérico negado a um objeto com um nível de integridade mais alto. Se pSecurityDescriptor não contiver uma ACE obrigatória, uma ACE obrigatória implícita será assumida que atribui ao objeto um nível de integridade médio. O parâmetro GenericMapping determina quais direitos de acesso estão associados ao acesso de gravação genérico. Se o parâmetro GenericMapping for todos zeros, a integridade marcar não concederá direitos de acesso específicos a um ClientToken de integridade inferior. Depois que a integridade marcar determina os direitos de acesso genéricos que estão disponíveis para o chamador com base na política obrigatória, a DACL do descritor de segurança é comparada com ClientToken para determinar os direitos de acesso concedidos restantes.

Isolamento de privilégios de interface do usuário (UIPI) e integridade

O UIPI (Isolamento de Privilégios de Interface do Usuário) implementa restrições no subsistema windows que impedem que aplicativos com privilégios inferiores enviem mensagens de janela ou instalem ganchos em processos de privilégios mais altos. Aplicativos com privilégios mais altos têm permissão para enviar mensagens de janela para processos de privilégios inferiores. As restrições são implementadas nas funções de mensagem de janela SendMessage e relacionadas. Nem todas as mensagens de janela enviadas de um processo de privilégios inferiores para um processo de privilégios mais altos são bloqueadas. Geralmente, mensagens de tipo "leitura", por exemplo WM_GETTEXT, podem ser enviadas de um privilégio inferior para uma janela de privilégios mais altos. No entanto, mensagens de tipo de gravação, como WM_SETTEXT, são bloqueadas.

O nível de privilégio da interface do usuário está no nível do processo e se aplica a todas as janelas criadas pelo processo. O subsistema USER inicializa quando o processo faz a primeira chamada para a GDI (interface de dispositivo gráfico) do Windows. Durante a inicialização do processo, o subsistema USER chama o subsistema de segurança para determinar o nível de integridade atribuído no token de acesso de segurança primário do processo. Depois que o subsistema USER define o nível de privilégio da interface do usuário durante a inicialização do processo, ele não é alterado. Definir o TokenIntegrityLevel para um thread com um valor mais baixo não afeta o nível de privilégio da interface do usuário do processo ou as janelas abertas por esse processo ou thread.

A UIPI não interfere nem altera o comportamento do sistema de mensagens de janela entre aplicativos no mesmo nível de privilégio (ou integridade). A UIPI impede que processos com privilégios inferiores acessem processos de privilégios mais altos bloqueando o comportamento a seguir. Um processo de privilégios inferiores não pode:

  • Execute uma validação de identificador de janela de um processo em execução com direitos mais altos.
  • Use SendMessage ou PostMessage para janelas de aplicativos em execução com direitos mais altos. Essas APIs retornam êxito, mas soltam silenciosamente a mensagem da janela.
  • Use ganchos de thread para anexar a um processo em execução com direitos mais altos.
  • Use ganchos de diário para monitorar um processo em execução com direitos mais altos.
  • Execute a injeção de DLL (biblioteca de vínculo dinâmico) em um processo em execução com direitos mais altos.

Com a UIPI habilitada, os seguintes recursos de USUÁRIO compartilhados ainda são compartilhados entre processos em diferentes níveis de privilégio.

  • Janela da área de trabalho, que na verdade possui a superfície da tela
  • Memória compartilhada somente leitura do heap da área de trabalho
  • Tabela atom global
  • Área de Transferência

Pintar na tela é outra ação que não está bloqueada pela UIPI. O modelo de GDI (interface do dispositivo user/graphics) não permite o controle sobre superfícies de pintura. Portanto, é possível que um aplicativo em execução com menos direitos pinte sobre a superfície da janela do aplicativo para um aplicativo em execução com direitos mais altos.

UIAccess para aplicativos de automação da interface do usuário

A automação da interface do usuário da Microsoft é o modelo do Windows Vista para dar suporte aos requisitos de acessibilidade com melhorias em relação ao modelo anterior, conhecido como MSAA (Microsoft Active Accessibility). Aplicativos projetados para dar suporte à experiência do usuário acessível controlam o comportamento de outros aplicativos do Windows em nome do usuário. Quando todos os aplicativos (o cliente e o servidor de automação) estão em execução como um usuário padrão, ou seja, em um nível de integridade média, as restrições de UIPI não interferem no modelo de automação da interface do usuário.

No entanto, pode haver momentos em que um usuário administrativo executa um aplicativo com privilégios elevados com base no UAC no modo de aprovação Administração. O programa de automação da interface do usuário não poderá conduzir a interface do usuário de gráficos de aplicativos elevados na área de trabalho sem a capacidade de ignorar as restrições implementadas pela UIPI. A capacidade de ignorar restrições de UIPI em SendMessage entre níveis de privilégio está disponível para programas de automação da interface do usuário usando um atributo de segurança especial no manifesto do aplicativo do programa, conhecido como UIAccess.

Veja a seguir um exemplo de uma entrada de manifesto do aplicativo para um programa UIAccess.

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> 
  <security> 
    <requestedPrivileges> 
    <requestedExecutionLevel 
      level="asInvoker" 
      UIAccess="true" /> 
    </requestedPrivileges> 
  </security> 
</trustInfo>

Ao especificar UIAccess="true" no atributo requestedPrivileges, o aplicativo está declarando um requisito para ignorar restrições de UIPI ao enviar mensagens de janela entre níveis de privilégio. O Windows Vista implementa as verificações de política a seguir antes de iniciar um aplicativo com o privilégio UIAccess.

  • O aplicativo deve ter uma assinatura digital que possa ser verificada usando um certificado digital que se encadeia a uma raiz confiável no repositório de certificados autoridades de certificação raiz confiáveis do computador local.
  • O aplicativo deve ser instalado em um diretório de aplicativo de pasta local que seja gravável somente por administradores, como o diretório Arquivos de Programas. Os diretórios permitidos para aplicativos de automação de interface do usuário são:
    • %ProgramFiles% e seus subdiretórios.
    • %WinDir% e seus subdiretórios, exceto alguns subdiretórios que serão excluídos porque os usuários padrão têm acesso de gravação.

Os subdiretórios %WinDir% excluídos incluem:

  • \Depurar
  • \PCHealth
  • \Registo
  • \System32\ccm
  • \System32\com
  • \System32\FxsTmp
  • \System32\Spool
  • \System32\Tasks

O Windows Vista fornece uma configuração de segurança para a política de computador local e para Política de Grupo ajustar o requisito de que os programas UIAccess devem ser iniciados de locais seguros. A configuração é definida nas Opções de Segurança nas Políticas Locais para as Políticas de Segurança Local. A política de segurança é a seguinte:

Controle de Conta de Usuário: eleve apenas aplicativos UIAccess que estejam instalados em locais seguros

Essa configuração é habilitada por padrão. No entanto, um administrador poderá desabilitá-lo se houver situações em que os aplicativos UIAccess (Tecnologia Acessível) que devem ser iniciados de pastas não são protegidos pelo acesso de gravação somente para administradores.

Se o aplicativo de automação da interface do usuário que solicita UIAccess atender aos requisitos de configuração do UIAccess, o Windows Vista iniciará o aplicativo com a capacidade de ignorar a maioria das restrições de UIPI. Se o aplicativo de automação da interface do usuário não atender às restrições de segurança, o aplicativo será iniciado sem direitos de UIAccess e poderá interagir apenas com aplicativos no mesmo nível de privilégio ou inferior.

Um processo que é iniciado com direitos UIAccess:

  • Tem a capacidade de definir a janela em primeiro plano.
  • Pode conduzir qualquer janela do aplicativo usando a função SendInput.
  • Tem entrada de leitura para todos os níveis de integridade usando ganchos de baixo nível, entrada bruta, GetKeyState, GetAsyncKeyState e GetKeyboardInput.
  • Pode definir ganchos de diário.
  • Usa AttachThreadInput para anexar um thread a uma fila de entrada de integridade mais alta

Os aplicativos iniciados com direitos UIAccess para um usuário padrão recebem um valor de nível de integridade ligeiramente maior no token de acesso. O nível de integridade do token de acesso para o aplicativo UIAccess para um usuário padrão é o valor do nível de integridade médio, além de um incremento de 0x10. O nível de integridade mais alto para aplicativos UIAccess impede que outros processos na mesma área de trabalho no nível de integridade média abram o objeto de processo UIAccess.