Você está na página 1de 22

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

Controle de acesso

Compreendendo as permissões de arquivo e registro do Windows

John R. Michener

Este artigo aborda:

Listas de controle de acessoe registro do Windows John R. Michener Este artigo aborda: Direitos do usuário Permissões do sistema

Direitos do usuárioR. Michener Este artigo aborda: Listas de controle de acesso Permissões do sistema de arquivos Registro

Permissões do sistema de arquivosaborda: Listas de controle de acesso Direitos do usuário Registro e suas permissões Este artigo usa

Registro e suas permissõesDireitos do usuário Permissões do sistema de arquivos Este artigo usa as seguintes tecnologias: Windows Server

Este artigo usa as seguintes tecnologias:

Windows Server 2008

Descritores de segurança do objeto Noções básicas do descritor de segurança string_aces Direitos padrão e específicos Rótulos de integridade e seu uso Object_guid e inherit_object_guid Interpretando o descritor de segurança string_aces Proteção de Recursos do Windows Definindo permissões seguras do sistema de arquivos Gerenciando o Registro e suas permissões Conclusão

Sempre que alguma coisa acontece em um sistema, uma entidade de segurança (que poderia ser um processo ou thread agindo em nome de um usuário ou serviço) age sobre objetos. Arquivos, diretórios e chaves do Registro são exemplos de objetos muito conhecidos. O mecanismo de segurança básico do Windows envolve um componente do sistema confiável que verifica permissões e direitos (AccessCheck) antes que uma operação tenha permissão para continuar. Por isso, você gerencia o comportamento do sistema definindo permissões e direitos. Como não é possível definir permissões apropriadamente sem compreender aquilo que está sendo feito sob a superfície, começarei descrevendo configurações de segurança em objetos e como elas são processadas e, em seguida, como definir valores para elas.

Antes de me aprofundar nos detalhes técnicos, quero observar as permissões na raiz da unidade do sistema no Windows Server 2008 usando a GUI de ACL (lista de controle de acesso) do Windows. Se abro o Windows Explorer, seleciono a guia de segurança, clico com o botão direito do mouse em Disco Local (C:) e seleciono Propriedades, vejo que os administradores têm controle total. Se clico em SYSTEM em Nomes de grupo ou de usuário, vejo que SYSTEM também tem controle total. Quando clico em Usuários em Nomes de grupo ou de usuário, vejo que a situação da permissão não é tão simples assim: o grupo de usuários no sistema na Figura 1 tem Ler e Executar, Listar, Ler etc. Clicar no botão

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

Avançado proporciona uma visão mais detalhada das permissões associadas ao grupo de usuários (consulte a Figura 2).

associadas ao grupo de usuários (consulte a Figura 2 ). Figura 1 Direitos do usuário do

Figura 1 Direitos do usuário do Disco Local C

Figura 2 ). Figura 1 Direitos do usuário do Disco Local C Figura 2 Modo de

Figura 2 Modo de exibição avançado dos direitos de usuário na unidade C (clique na imagem para ampliá-la)

Aqui, os membros do grupo de usuários têm permissão para criar pastas e acrescentar dados a arquivos na raiz da unidade do sistema. Se clicar no botão Editar, você verá outra concessão "especial" a subpastas, mostrada na Figura 3. Essa operação requer privilégios

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

de administrador.

de arquivo e registro do Windows de administrador. Figura 3 Modo de exibição de edição dos

Figura 3 Modo de exibição de edição dos direitos especiais de usuário

Dessa forma, você vê que usuários normais têm permissão, por padrão, para criar subpastas e adicionar conteúdo a essas pastas na raiz da unidade do sistema no Windows Server 2008. Essa funcionalidade foi fornecida a membros do grupo de usuários no Windows Server 2008 porque há software de terceiros que pressupõe a presença dessas permissões, e a Microsoft não gostaria de suspender a compatibilidade do aplicativo.

Agora passemos a uma abordagem técnica desses problemas e como eles funcionam abaixo da interface GUI apresentada ao usuário. Todos os objetos nomeados no Windows têm descritores de segurança, que fornecem informações sobre seu proprietário, bem como listam quais usuários e assuntos têm permissões especificadas. Eles também podem especificar quais acessos a objeto devem ser registrados no log de eventos do sistema.

As informações sobre o que um assunto (usuário, processo etc.) tem permissão para fazer em um objeto ou recurso são especificadas em uma estrutura de dados conhecida como ACL. As ACLs enumeram aqueles que (qual entidade de segurança) têm determinado tipo de acesso a objetos específicos. Uma DACL (ACL discricionário) é um tipo de ACL em que os proprietários de objetos têm permissão para alterá-los. Sempre que um objeto é acesso, o descritor de segurança é comparado com as permissões da entidade de segurança para verificar se o acesso solicitado é permitido.

Observe que o Windows também oferece suporte a SACLs (ACLs do sistema) para objetos e usou as configurações de SACL para estabelecer quais eram os eventos registrados no log de auditoria em muitas versões. Com o Windows Server 2008 e o Windows Vista, a SACL foi estendida para transportar informações de nível de integridade.

O rótulo de integridade é usado para estabelecer o rótulo "low" que marca o processo do Internet Explorer usado em LowRights Internet Explorer. Os rótulos "System" e "high" são usados para proteger os recursos críticos do sistema. A bomba de mensagens do Windows filtra as mensagens com base no nível de integridade. Por exemplo, processos de nível médio ã

ã

b

i

d

d

d

í

l b

i

d

í

l

l

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

n o rece em mensagens env a as

recebem mensagens de processos de nível baixo ou médio.

e processos

e n ve

a xo e processos

e n ve

a to n

o

A essa altura, a proteção do nível de integridade é a uma bomba de velocidade, e não uma

barreira de segurança efetiva com a qual você conta para dar garantias de segurança. A

altura dessa bomba aumentará significativamente nas versões posteriores, quando ela deve

se tornar uma barreira de segurança real.

Assim como acontece com outros sistemas operacionais modernos, o Windows depende de DACLs para tomar decisões de controle de acesso. Aqui me concentrarei principalmente em DACLs. Para que o sistema determine se uma entidade de segurança tem permissão para realizar uma operação em um objeto, várias coisas são verificadas: os privilégios da entidade de segurança, o token da entidade de segurança e o descritor de segurança do objeto. O descritor de segurança binário em um objeto é passado para a rotina AccessCheck com o token da entidade de segurança. É preparado um vetor de bits da máscara de acesso solicitado, representando os direitos de acesso que devem ser concedidos para que haja êxito na verificação de acesso. Ele é passado com o descritor de segurança da entidade para a rotina AccessCheck, que examina o token de segurança do usuário e considera os privilégios da entidade de segurança (normalmente baseados em funções ou associação como, por exemplo, administrador) em combinação com o acesso solicitado e a DACL no objeto.

Caso o acesso solicitado seja atendido pelos privilégios da entidade de segurança, o acesso é concedido. Do contrário, as ACEs (entradas de controle de acesso) da DACL são examinadas em ordem. Tão logo consiga mostrar que todos os componentes do acesso solicitado têm permissão ou que algum deles foi negado, o sistema de segurança retorna um êxito no primeiro caso e uma falha no segundo.

Assim, a lista de DACLs das ACEs deve ser ordenada corretamente. A ordem padrão (canônica) é colocar primeiro negações explícitas e, em seguida, permissões explícitas, negações gerais (grupo) e permissões gerais. Caso a ordem canônica não seja usada, podem ocorrer permissões ou negações imprevistas.

Descritores de segurança do objeto

Embora seja uma estrutura de dados binária, o descritor de segurança depende do formato da cadeia de caracteres do descritor para fornecer um formato de texto que possa ser lido por humanos. Um descritor de segurança do formato da cadeia de caracteres é representado como uma cadeia de caracteres terminada em nulo com tokens para indicar cada um dos quatro componentes principais: proprietário (O:), grupo primário (G:), DACL (D:) e SACL (S:), como ilustra a Figura 4.

Figura 4 Descritores de segurança

como ilustra a Figura 4 . Figura 4 Descritores de segurança msdn.microsoft.com/pt-br/magazine/cc982153.aspx 4/22

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

as permissões de arquivo e registro do Windows Os SIDs (identificadores de segurança) são estruturados

Os SIDs (identificadores de segurança) são estruturados para fornecer informações de análise e incluem 96 bits de informações aleatórias (e podem incluir 32 bits de contagem em seqüência) para funcionar como um identificador exclusivo dos proprietários. As string_aces (ACEs expressadas no formato da cadeia de caracteres) são estruturas que concedem ou negam permissões explicitamente na DACL e definem a diretiva na SACL. Toda string_ace fica entre parênteses e tem a seguinte estrutura:

(ace_type;ace_flags;rights;object_guid;inherit_

object_guid;account_sid)

Apenas essas concessões, necessárias ao acesso adequado ao objeto em questão, devem estar presentes. Normalmente, owner_sid e group_sid são omitidos do descritor de segurança. Se não for especificado explicitamente no momento da criação, o campo owner do descritor de segurança é definido como o SID da entidade de segurança que invoca a criação do objeto. O campo group é definido como o grupo primário do token de segurança da entidade. Se não for l

á

á

i

di

b

d

fi

i

ó

d

i

id

d

SACL

ã

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

necess r o au presente.

tar

um

o

jeto ou

e

n r

um r

tu o

e

ntegr

a

e,

a

n

o

estar

Nas string_aces, apenas esses campos necessários são incluídos (o conjunto mínimo é ace_type, direitos e o assunto, normalmente account_sid). Em geral, object_guid e inherit_object_guid não estão presentes. O sistema analisa as ACEs na ordem, da primeira à última, até que o acesso seja concedido ou negado. Por isso, a ordem das ACEs é importante. "Negar permissões" deve vir antes de "dar permissões".

Uma ACL sem ACEs é uma DACL vazia. Como uma ACE concede acesso a um assunto especificado para um objeto, ninguém pode acessar um objeto com uma DACL vazia. Diz-se que um objeto sem uma DACL tem uma DACL NULL. Objetos com DACLs NULL não foram protegidos e todos têm controle total sobre eles. Por esse motivo, não defina DACLs vazias ou NULL.

Agora vale a pena observar como seria um descritor de segurança real. Eis um descritor de segurança para a raiz da unidade de sistema do Windows Server 2008 (observe que calcs é uma rotina de linha de comando herdada para investigar e definir ACLs que está sendo substituída por icacls. Infelizmente, icacls não oferece suporte a uma opção de linha de comando para gerar os resultados na Security Descriptor Definition Language, ou SDDL, uma opção que cacls tem – o sinalizador /S):

C:\>caclsc://s

c:\"D:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a9;;;BU)

(A;CI;LC;;;BU)(A;CIIO;DC;;;BU)(A;OICIIO;GA;;;CO)"

Com base naquilo que sabemos sobre descritores de segurança, é possível observar a partir do primeiro "D:" que nenhuma propriedade ou associação a um grupo é reivindicada e que o descritor é uma DACL. A DACL está protegida: o "P" e o sinalizador de herança do Windows NT 5.0 estão definidos. Em seguida, temos algumas ace_strings que precisam ser decifradas.

Noções básicas do descritor de segurança string_aces

Lembre-se do formato string_aces que mostrei anteriormente. Os ace_types permitidos estão definidos na Figura 5, e os ace_flags permitidos estão definidos na Figura 6. Os ace_flags da herança são os fatores de controle da herança das ACEs.

Figura 5 ace_types permitidos

de controle da herança das ACEs. Figura 5 ace_types permitidos msdn.microsoft.com/pt-br/magazine/cc982153.aspx 6/22

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

as permissões de arquivo e registro do Windows Figura 6 ace_flags permitidos Os direitos de ACE

Figura 6 ace_flags permitidos

arquivo e registro do Windows Figura 6 ace_flags permitidos Os direitos de ACE são indicados por

Os direitos de ACE são indicados por uma cadeia de caracteres que denota os direitos de acesso controlados pela ACE. A cadeia de caracteres pode ser uma representação da cadeia de caracteres hexadecimal como, por exemplo, "0x7800003F" ou ser uma concatenação das cadeias de caracteres dos Direitos como "CCLCSWLOCRRC", que interpretarei posteriormente. A representação hexadecimal e os valores de bit associados são mostrados na Figura 7.

Figura 7 Máscara de acesso ACL

mostrados na Figura 7 . Figura 7 Máscara de acesso ACL O sistema usa uma representação

O sistema usa uma representação de bitmap único dos direitos de ACE para todos os objetos. Nem todos os bits são significativos para vários objetos. Apenas os direitos apropriados a um

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

objeto são aplicados. Os direitos padrão são aqueles comuns a todos os objetos protegíveis. Direitos genéricos são uma forma prática de especificar direitos de intenção semelhante para vários objetos. A especificação de direitos genéricos é mapeada para o conjunto apropriado de direitos específicos. Os rótulos de integridade também são codificados usando o campo de direitos de ACE durante a especificação da SACL. Os direitos disponíveis de vários objetos são listados na Figura 8.

Figura 8 Direitos genéricos

são listados na Figura 8 . Figura 8 Direitos genéricos Existem muitos mapeamentos de direitos, em

Existem muitos mapeamentos de direitos, em grande parte equivalentes, usados indiscriminadamente. FC (Full Control) é o equivalente a GA (Generic_All). Para o sistema de arquivos, FA (File All) é a declaração de controle total apropriada. KA (Key All) é a declaração de controle total apropriada para o Registro. As declarações genéricas costumam ser usadas no lugar das declarações mais apropriadas, embora sejam mapeadas para o sistema de arquivos apropriado ou para as declarações da chave do Registro, conforme apropriado. Como as expressões SDDL normalmente misturam esses termos, você precisa estar atento às equivalências.

Direitos padrão e específicos

Muitos objetos podem receber direitos. Além de arquivos e diretórios, temos chaves do Registro, processos, áreas de trabalho etc. Para obter a lista completa, consulte as figuras de A a J. Como abordaremos as permissões no sistema de arquivos e no Registro, os direitos específicos desses objetos são fornecidos nas figuras 9 e 10.

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

Figura 9 Direitos de arquivo específicos

do Windows Figura 9 Direitos de arquivo específicos Figura 10 Direitos do Registro específicos Rótulos de

Figura 10 Direitos do Registro específicos

específicos Figura 10 Direitos do Registro específicos Rótulos de integridade e seu uso Conforme já dissemos,

Rótulos de integridade e seu uso

Conforme já dissemos, os rótulos de integridade, se estiverem presentes, são armazenados na SACL do objeto. Implicitamente, os objetos têm integridade média, logo, se não há nenhum rótulo de integridade, a integridade do objeto é média. Da mesma forma, se não há nenhum rótulo de integridade em um token de segurança, a integridade do dele também é média. O rótulo de baixa integridade é usado para identificar processos com direitos limitados como, por exemplo, o Internet Explorer e objetos não confiáveis relacionados. Os níveis "high" e "system" são usados para ajudar a isolar esses objetos dos processos medium e low. Os rótulos de integridade são mostrados na Figura 11.

Figura 11 Rótulos de integridade

são mostrados na Figura 11 . Figura 11 Rótulos de integridade msdn.microsoft.com/pt-br/magazine/cc982153.aspx 9/22

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

as permissões de arquivo e registro do Windows Object_guid e inherit_object_guid Object_guid e

Object_guid e inherit_object_guid

Object_guid e inherit_object_guid são usados na especificação da segurança dos objetos no Active Directory. Eles não são usados durante a proteção do sistema de arquivos ou do Registro. "OA" e "OD" no campo ace_type de uma cadeia de caracteres ACE correspondem a uma permissão de objeto e a uma negação de objeto, respectivamente. Nesse caso, object_guid mantém o GUID do objeto que está recebendo a permissão e inherit_object_guid mantém o GUI do objeto do qual as permissões são herdadas.

O campo account_sid na estrutura ACE denota a entidade de segurança que está recebendo

a concessão ou a negação dos direitos de acesso especificados na ACE. O campo account_sid pode manter um SID, que é um identificador estruturado longo, basicamente sem significado para uma pessoa, ou uma notação "SID string" de atalho para uma conta comum. A notação da cadeia de caracteres SID para contas comuns é usada sempre que possível para tornar o sistema mais legível. Uma tabela das contas comuns ou bem conhecidas e suas cadeias de caracteres SID é mostrada na abaixo.

A declaração OW de direitos do proprietário é nova no Windows Server 2008 e no Windows

Vista. Anteriormente, o CO (criador/proprietário) de um objeto tinha os direitos padrão de RC (controle de leitura) e WD (Write_DAC) nesse objeto, o que permitia ao proprietário

definir a segurança no objeto. Isso cria um problema caso um usuário seja membro de um

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

grupo e crie muitos objetos. Se esse usuário deixasse o grupo, ele ainda teria controle sobre esses objetos por ser o proprietário deles, o que concederia a eles permissões RC mais Write_DAC. A presença da restrição de ACE do proprietário OW impede a concessão implícita de RC/WD ao proprietário, a menos que essas concessões sejam feitas explicitamente à ACE do proprietário de qualquer outra ACE relevante na ACL. Isso possibilita a atenuação desse problema de segurança.

Interpretando o descritor de segurança string_aces

A saída de calcs na raiz da unidade do sistema foi:

"D:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a9;;;BU)(A;

CI;LC;;;BU)(A;CIIO;DC;;;BU)

(A;OICIIO;GA;;;CO)"

Analisando a legibilidade disso, você tem:

"D:PAI (A;OICI;FA;;;SY) (A;OICI;FA;;;BA)

(A;OICI;0x1200a9;;;BU)(A;CI;LC;;;BU)(A;CIIO;DC;;;BU)

(A;OICIIO;GA;;;CO)"

Trata-se de uma DACL protegida com o sinalizador de herança automática para um conjunto de sistemas de arquivos modernos. O sinalizador protegido significa que as concessões pai herdáveis não serão herdadas; a DACL é protegida da herança do pai do objeto. Nesse caso, não existe nenhum pai porque ele é a raiz.

O administrador interno e o sistema recebem File All herdável tanto nos arquivos (devido à

herança do objeto) quanto nos diretórios (devido à herança do contêiner, ou CI). Isso significa

que essa DACL concede File All recursivamente em todos os arquivos e diretórios abaixo da raiz – exceto quando a herança é interrompida por uma DACL protegida, quando a concessão na DACL protegida deve ser examinada. CO recebe Generic_All, que é mapeado para File All, tanto nos arquivos quanto nos diretórios abaixo do diretório raiz (devido ao sinalizador somente herança).

A concessão para o usuário interno é muito mais interessante. A primeira string_ace se aplica tanto a arquivos quanto a diretórios na raiz e abaixo, além de permitir List, Read, ReadEA, Traverse, Execute, ReadAttr, ReadControl e Sync. A segunda string_ace permite AddSubDir na raiz e abaixo (devido ao sinalizador IO – somente herança), e a terceira string_ace permite AddFile nos diretórios abaixo da raiz. É a mesma coisa que você viu ao explorar essas permissões com a interface gráfica ACL do Windows Explorer.

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

Proteção de Recursos do Windows

Começando com o Windows Server 2008 e o Windows Vista, os componentes declaram suas configurações de segurança necessárias em seus manifestos, assinados por uma raiz de assinatura de código Microsoft. O manifesto especifica as ACLs e as demais permissões associadas ao arquivo. Por isso, quando é instalado, um componente transporta as configurações de segurança apropriadas. Além disso, os arquivos do sistema operacional são protegidos contra danos acidentais causados pelo administrador do sistema usando a WRP (Proteção de Recursos do Windows). A WRP depende de uma nova entidade de nível do sistema, Trusted Installer, para obter e administrar arquivos e pastas do sistema.

Um bom recurso para permitir que usuários normais do Windows realizassem instalações de

componentes autorizados foi adicionado ao Windows Vista. Assim, a função Usuário Avançado deixa de ser obrigatória, e as instâncias das ACEs que contêm o SID de Usuário Avançado foram removidas. O grupo Usuário Avançado ainda existe, mas os manifestos do componente foram verificados e todas as instâncias detectadas de concessões a PU foram excluídas.

Vejamos um diretório de sistema para observar as novas permissões. Este também é um ótimo exercício de leitura SDDL:

C:\>caclsc:\windows/s

C:\Windows"D:PAI(A;;FA;;;S-1-5-80-956008885-3418522649-18310

38044-1853292631-2271478464)(A;CIIO;GA;;;S-1-5-80-956008885-3

418522649-1831038044-1853292631-2271478464)(A;;0x1301bf;;;SY}

(A;OICIIO;GA;;;SY)(A;;0x1301bf;;;BA)(A;OICIIO;GA;;;BA)(A;;0x120

0a9;;;BU)

(A;OICIIO;GXGR;;;BU)(A;OICIIO;GA;;;CO)"

O SID

1853292631-2271478464. Usando TI como atalho, encontramos o seguinte:

de

Trusted

Installer

é

S-1-5-80-956008885-3418522649-1831038044-

C:\Windows"D:PAI (A;;FA;;;TI)(A;CIIO;GA;;;TI)

(A;;0x1301bf;;;SY)(A;OICIIO;GA;;;SY)

(A;;0x1301bf;;;BA)(A;OICIIO;GA;;;BA)

(A;;0x1200a9;;;BU)(A;OICIIO;GXGR;;;BU)

(A;OICIIO;GA;;;CO)"

Interpretando isso, você o vê como uma ACE protegida sendo aplicada a C:\Windows usando o modelo de herança do Windows NT 5.0.

Trusted Installer tem controle total sobre C:\Windows e recebe Generic_All em todos os contêineres filho em C:\Windows (por ser CI, somente herança).

System e admin recebem Read

Write

Append

ReadEA

WriteEA

Execute

ReadAttr

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

, WriteAttr, Del, RCtl e Sync = SDGRGWGX em C:\Windows. Isso é Generic_All menos Write_Owner e Write_DAC; Admin e System recebem tudo exceto a possibilidade de alterar o proprietário ou a ACL. "BA" e "SY" têm Generic_All nos objetos de diretório e arquivo filho.

,

,

,

,

,

Como o administrador tem o privilégio de apropriar-se, ele ainda pode declarar WriteOwnership e assumir o controle mesmo assim. Administrator e system são equivalentes em termos de segurança. Mas com esse privilégio, um determinado administrador pode contornar os controles ACL da WRP.

CO também tem Generic_All nos objetos de diretório e arquivo filho. O usuário interno tem Read, ReadEA, Execute, ReadAttr, RCtl e Sync = GRGX em C:\Windows e GRGX nos subdiretórios e em seus arquivos abaixo de C:\Windows.

Todos os arquivos e pastas de sistema têm ACLs protegidas que concedem controle total a Trusted Installer. O controle de arquivos por Trusted Installer não é expressado na declaração no diretório raiz do sistema, e sim nas declarações separadas dos componentes do Windows.

Definindo permissões seguras do sistema de arquivos

Agora que você tem alguma idéia de como as ACLs do sistema de arquivos funcionam e como lê-las, vejamos sua configuração. Se estiver instalando um aplicativo, você deve instalá-lo no local Arquivos de Programas padrão. As ACLs padrão desse local dão controle total a Administrador e Sistema Local, o que é apropriado.

Se instalar um aplicativo em outro local ou conceder ao usuário a possibilidade de escolher seu local preferido para um aplicativo, você terá um problema: as ACLs padrão das demais unidades e áreas que não sejam do sistema e do aplicativo da unidade de sistema não são seguras o suficiente. Nesses casos, você deve usar explicitamente ACL nas pastas com as DACLs protegidas apropriadas. A opção mais simples e segura para instalar um aplicativo é duplicar as configurações de segurança na pasta Arquivos de Programa. Se você optar por não fazer isso, defina a DACL de forma que os não-administradores não possam alterar DACLs ou a propriedade dos executáveis, além de não poderem gravar, acrescentar ou excluir arquivos em diretórios que contenham executáveis.

A regra básica caso esteja definindo DACLs é que você não deseja que administradores ou

outros usuários executem o código escrito por um usuário. Isso seria especialmente um problema se a pasta em questão fosse presumivelmente confiável, especialmente estando em uma área confiável (Windows, Arquivos de Programas etc.). Isso permite a EoP (elevação de privilégio) para administrador e aumenta o risco de ataques entre usuários. Por isso, caso um usuário possa gravar arquivos em uma pasta, os demais usuários e os administradores não devem ser capazes de executá-los.

À primeira vista

pareceria que você jamais devesse permitir que usuários gravassem em

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

,

pastas no Windows, System, Arquivos de Programas etc. Acontece que existem motivos válidos para isso. O mais comum é registrar dados no log de erros. Se o executável está em execução com as credenciais do usuário e precisa registrar um erro no log, ele deve ter acesso gravação/acréscimo na pasta de registro/log de erros. (Se registrasse erros no log de acordo com os locais do usuário em um sistema com vários usuários, você teria os dados de registro em log espalhados pelo sistema, e não associados ao executável. Os aplicativos e os serviços costumam ser gravados em uma pasta compartilhada ou chave do Registro.) Você enfrentará os mesmos problemas no Registro, onde as informações sobre erros costumam ser armazenadas em chaves do Registro da máquina específicos por um processo em execução com as permissões do usuário.

Não misture arquivos graváveis com arquivos executáveis. Use diretórios separados para arquivos que devam ser confiáveis (como, por exemplo, executáveis) e arquivos que não devam ser confiáveis (qualquer coisa possivelmente gravada por um usuário não confiável). Use a ACL nos diretórios apropriadamente – controle do administrador sobre os executáveis e leitura/execução do usuário, mas não gravação. A mesma diretriz se aplica a chaves do Registro e subchaves.

Cliente e servidor diferem aqui: administradores de servidor devem ser muito mais influentes do que usuários em execução como administrador. Os administradores de servidor sabem que não devem executar códigos em áreas não confiáveis do sistema. Ao estabelecer uma convenção de nomenclatura para isolar arquivos de dados dos executáveis no sistema, você fornece ao administrador diretrizes a respeito da confiabilidade do executável – subdiretórios de registro em log não são confiáveis; logo, usuários não devem ter a possibilidade de criar ou modificar esses subdiretórios, porque isso os permitiria falsificar regras de nomenclatura.

No ambiente do cliente, é muito mais fácil levar o usuário administrativo a executar o código. Com administradores ingênuos assim, os diretórios que tenham gravações de usuário não devem dar ao administrador privilégios de execução para impedir que um usuário instale um executável e, em seguida, leve um administrador a executá-lo e comprometer o sistema. Por exemplo, se o aplicativo ou serviço precisa armazenar informações de log a serem gravadas com privilégios de usuário, você deve criar um subdiretório de registro em log para manter esses dados. Esse subdiretório não deve permitir a execução. Uma forma de fazer isso é adicionar uma negação explícita inicial de execução do arquivo a todos como, por exemplo, D;OI;WP;;;WD. Isso impede ataques entre usuários em diretórios que permitam a gravação ou a modificação de arquivos aos usuários.

Há muitos casos em que se espera que os usuários compartilhem dados (ainda que não desejemos que os eles compartilhem e executem códigos em uma área compartilhada). Por exemplo, um usuário doméstico (ou seu aplicativo de visualização de fotos) deve criar uma pasta como, por exemplo, C:\Fotos. O usuário deve ser capaz de permitir que vários usuários gravem nessa pasta e editem as várias fotos nela. As ACLs padrão na raiz da unidade do sistema no Windows Vista oferecem suporte a isso. A outra situação de compartilhamento comum é uma pasta na qual os usuários colocam dados para que outros leiam. Apenas o

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

criador dos dados tem permissão para excluir ou modificar os dados, mas os outros podem copiá-los e, em seguida, editar a cópia. Trata-se de um cenário de leitura compartilhada, sendo o padrão na unidade de sistema no Windows Server 2008.

Considere o caso em que seja possível bloquear o compartilhamento da unidade do sistema e, mais especificamente, das pastas ACL. Você precisa escolher as ACLs apropriadas para esses dois cenários bem comuns. Queremos que os administradores sejam capazes de gerenciar os objetos, mas queremos evitar problemas associados à execução de código nessas pastas (observe que as ACEs aqui impedem até mesmo o proprietário de executar código nessas pastas).

Eis uma ACE de leitura compartilhada:

D:P(D;OI;WP;;;WD)(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;OICI;FA;;;C

O)(A;CI;0x1200af;;;AU)(A;OI;GR;;;AU)

E aqui uma ACE de colaboração:

D:P(D;OI;WP;;;WD)(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;OICI;FA;;;C

O)(A;OICI;SDGRGW;;;AU)

Observe que ambas as ACLs começam com uma ACE de execução de negação para todos, herança de objeto (a ser aplicada aos arquivos) para impedir ataques do sistema de usuário e entre usuários. Em seguida, administrator, system (na verdade, system não precisa) e CO recebem controle total = File All.

No cenário de leitura compartilhada, um usuário autenticado recebe List, AddFile,

AddSubDir, ReadEA, Traverse, ReadAttr, RCtl e Sync devido à restrição dessa concessão a

CI e, assim, a diretórios, recebendo a leitura genérica separadamente para todos os arquivos.

Para o cenário de colaboração, um usuário autenticado recebe Delete, Generic Read e

Generic Write em arquivos e diretórios.

Gerenciando o Registro e suas permissões

O Windows armazena grande parte das informações de estado no Registro. Os repositórios

de dados do Registro são conhecidos como hives, nos quais os dados são armazenados em

chaves e subchaves, ambas exibidas como contêineres (subchaves não são exibidas como

objetos).

Os dados específicos do usuário são armazenados na seção do usuário apropriada de Hive Key Users (HKEY_USERS). Como seria de se esperar, grande parte desses dados pode ser gravada pelo usuário. Em uma sessão, HKey_Current_User (HKCU) aponta para a seção apropriada de HKEY_USERS.

As

informações

do

sistema

e

da

máquina

são

armazenadas

no

hive

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

HKEY_LOCAL_MACHINE (HKLM). Incluídas no HKLM estão as informações de todos os vários serviços do sistema, a maioria dos quais agora executada com permissões limitadas nos vários grupos Serviço Local ou Serviço de Rede. Os serviços e os aplicativos podem armazenar informações de estado em suas chaves do Registro. Essas informações devem ser armazenadas em subchaves, na chave do serviço ou em uma chave sob a chave do serviço. A chave do serviço não deve usar uma ACL para permitir que o serviço tenha SetKey em sua própria chave de serviço (ou WDac ou WOwn, que, assim, permitiriam um ataque), porque isso permite ao serviço apontar para um executável diferente. Um erro desse tipo introduz uma EoP no host do serviço, porque o Gerenciador de Controle de Serviços carregará o executável para o qual está apontado quando o sistema for carregado.

As diretrizes gerais quanto a DACLs de HKLM é que elas não devem permitir aos usuários gravar ou modificar esses dados ou as ACLs associadas e sua propriedade. Assim como acontece com a diretriz para configuração das DACLs do sistema de arquivos em áreas do sistema, há exceções no registro em log de erros quando um aplicativo ou um serviço em execução em um contexto de usuário ou limitado precisa registrar informações do erro. A diretriz nessas situações é semelhante a problemas equivalentes no sistema de arquivos – criar chaves separadas para essas informações e usar a ACL nelas corretamente. Por isso, as informações podem ter a ACL para assuntos confiáveis (administrador, sistema etc.) e os dados de registro em log podem ser graváveis, conforme necessário.

A situação que você está tentando evitar é um usuário modificando parâmetros confiáveis (como, por exemplo, desativar o antivírus o serviço de antimalware) ou adulterando uma ferramenta usada por usuários ou administradores. Suponhamos que, quando o Bloco de Notas seja invocado, ele carregue C:\windows\notepad.exe. A ACL padrão em C:\windows não permite a um invasor modificar o executável. Caso consiga reescrever esse link do ícone do Bloco de Notas para seu executável, o invasor pode fazer com que um arquivo diferente, digamos, C:\tools\load_rootkit.exe seja carregado. Isso poderia carregar um rootkit e, em seguida, carregar o Bloco de Notas de forma que o usuário não tivesse ciência do comprometimento.

Caso o invasor consiga controlar o link no Registro, as ACLs de proteção no sistema de arquivos são inócuas. Você está preocupado com ataques de serviços do sistema limitados em outros serviços do sistema. No Windows Vista e no Windows Server 2008, os serviços são separados em grupos pelos privilégios necessários. As proteções de defesa aprofundada oferecidas por esse isolamento do serviço exigem a configuração das permissões do serviço de forma que os serviços não possam se adulterar, especialmente em grupos.

Assim como estamos preocupados em impedir os usuários de adicionar ou vincular executáveis mal-intencionados, também devemos impedir que os serviços tenham a possibilidade de alterar suas permissões e recursos. O privilégio ChangeConf nos serviços devem ser restritos a administrador, sistema ou Trusted Installer porque esse privilégio permite ao detentor alterar as permissões no serviço.

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

Conclusão

O Windows fornece um conjunto muito avançado de controles de permissão que podem ser

usados para permitir operações, bloqueá-las e fornecer uma defesa aprofundada contra novas ameaças. Inevitavelmente associado a essa possibilidade avançada de controlar o acesso está o problema da complexidade.

Seguir algumas diretrizes gerais ajudará você a evitar problemas. Por exemplo, os padrões do sistema são comprometimentos razoáveis. Você deve usá-los. Se estiver instalando um aplicativo fora dos arquivos de programa, use as ACLs dos arquivos de programa. Em alguns casos, você talvez queira apertar um pouco mais os padrões como, por exemplo, concessões padrão a usuários em unidades, mas não se esqueça de que, se pretende fazer isso, você deve estar preparado para procurar e lidar com problemas de compatibilidade do aplicativo potenciais.

A diretriz mais importante é que administradores ou contas do sistema não devem executar

código ou seguir ponteiros para um código que possa ser escrito ou modificado por um usuário. E tão importante quanto é que usuários não executem código ou sigam ponteiros para um código que outro usuário possa ter escrito ou modificado. Essas diretrizes abordam todos os problemas de segurança discutidos aqui. Se qualquer alteração feita por você seguir essas diretrizes, você terá evitado grande parte dos problemas de segurança mais sérios.

Para obter mais informações sobre componentes de controle de acesso, consulte "Componentes de controle de acesso" no MSDN. Mais informações sobre os componentes da máscara de acesso ace_string podem ser encontradas no artigo do MSDN "ACCESS_MASK", que inclui ponteiros para direitos específicos de arquivos, diretórios, chaves do Registro e seções compartilhadas. Informações adicionais sobre SIDs restritos podem ser encontradas no artigo do MSDN "Tokens restritos".

A lista completa de direitos

MSDN "Tokens restritos" . A lista completa de direitos msdn.microsoft.com/pt-br/magazine/cc982153.aspx 17/22

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

as permissões de arquivo e registro do Windows Figura B Direitos de arquivos e diretórios específicos

Figura B Direitos de arquivos e diretórios específicos

Figura B Direitos de arquivos e diretórios específicos Figura C Direitos de mapa de arquivo e

Figura C Direitos de mapa de arquivo e Registro específicos

C Direitos de mapa de arquivo e Registro específicos Figura específicos D Direitos do Gerenciador de

Figura

específicos

D Direitos

do

Gerenciador

de

Controle

de

Serviços

e

de

serviços

D Direitos do Gerenciador de Controle de Serviços e de serviços msdn.microsoft.com/pt-br/magazine/cc982153.aspx 18/22

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

as permissões de arquivo e registro do Windows Figura E Direitos de processos e threads específicos

Figura E Direitos de processos e threads específicos

Figura E Direitos de processos e threads específicos Figura F Direitos de estações Windows e áreas

Figura F Direitos de estações Windows e áreas de trabalho específicos

Direitos de estações Windows e áreas de trabalho específicos msdn.microsoft.com/pt-br/magazine/cc982153.aspx 19/22

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

as permissões de arquivo e registro do Windows Figura G Direitos de links simbólicos e eventos

Figura G Direitos de links simbólicos e eventos específicos

G Direitos de links simbólicos e eventos específicos Figura H Direitos específicos de semáforos e exclusões

Figura H Direitos específicos de semáforos e exclusões mútuas

H Direitos específicos de semáforos e exclusões mútuas Figura I Direitos de pipes e tokens específicos

Figura I Direitos de pipes e tokens específicos

mútuas Figura I Direitos de pipes e tokens específicos Figura J Contas comuns ou bem conhecidas

Figura J Contas comuns ou bem conhecidas e suas cadeias de caracteres de SID

comuns ou bem conhecidas e suas cadeias de caracteres de SID msdn.microsoft.com/pt-br/magazine/cc982153.aspx 20/22

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

Compreendendo as permissões de arquivo e registro do Windows msdn.microsoft.com/pt-br/magazine/cc982153.aspx 21/22

09/05/13

Controle de acesso: Compreendendo as permissões de arquivo e registro do Windows

as permissões de arquivo e registro do Windows John R. Michener é gerente de programa de

John R. Michener é gerente de programa de segurança sênior na Microsoft. Ele ingressou na Segurança do Windows na Microsoft há cinco anos. John tem mais de 20 anos de experiência em segurança de sistema e participou de três inicializações de segurança. Ele é o especialista em criptografia e permissões da equipe Windows Software Assurance. Você pode entrar em contato com ele pelo email jmichene@microsoft.com.

msdn.microsoft.comhttp://msdn.microsoft.com/pt-br/magazine/cc98 2153.aspx http://goo.gl/ffgS

msdn.microsoft.com

http://msdn.microsoft.com/pt-br/magazine/cc98msdn.microsoft.com 2153.aspx http://goo.gl/ffgS

2153.aspx

http://goo.gl/ffgS

http://goo.gl/ffgS