09/05/13

Controle de acesso: Compreendendo as permisses de arquivo e registro do Windows

Controle de acesso: Compreendendo as permisses de arquivo e registro do Windows

Controle de acesso Compreendendo as permisses de arquivo e registro do Windows John R. Michener

Este artigo aborda: Listas de controle de acesso Este artigo usa as seguintes tecnologias: Direitos do usurio Windows Server 2008 Permisses do sistema de arquivos Registro e suas permisses

Descritores de segurana do objeto Noes bsicas do descritor de segurana string_aces Direitos padro e especficos Rtulos de integridade e seu uso Object_guid e inherit_object_guid Interpretando o descritor de segurana string_aces Proteo de Recursos do Windows Definindo permisses seguras do sistema de arquivos Gerenciando o Registro e suas permisses Concluso Sempre que alguma coisa acontece em um sistema, uma entidade de segurana (que poderia ser um processo ou thread agindo em nome de um usurio ou servio) age sobre objetos. Arquivos, diretrios e chaves do Registro so exemplos de objetos muito conhecidos. O mecanismo de segurana bsico do Windows envolve um componente do sistema confivel que verifica permisses e direitos (AccessCheck) antes que uma operao tenha permisso para continuar. Por isso, voc gerencia o comportamento do sistema definindo permisses e direitos. Como no possvel definir permisses apropriadamente sem compreender aquilo que est sendo feito sob a superfcie, comearei descrevendo configuraes de segurana em objetos e como elas so processadas e, em seguida, como definir valores para elas. Antes de me aprofundar nos detalhes tcnicos, quero observar as permisses 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 segurana, clico com o boto direito do mouse em Disco Local (C:) e seleciono Propriedades, vejo que os administradores tm controle total. Se clico em SYSTEM em Nomes de grupo ou de usurio, vejo que SYSTEM tambm tem controle total. Quando clico em Usurios em Nomes de grupo ou de usurio, vejo que a situao da permisso no to simples assim: o grupo de usurios no sistema na Figura 1 tem Ler e Executar, Listar, Ler etc. Clicar no boto
msdn.microsoft.com/pt-br/magazine/cc982153.aspx 1/22

09/05/13

Controle de acesso: Compreendendo as permisses de arquivo e registro do Windows

Avanado proporciona uma viso mais detalhada das permisses associadas ao grupo de usurios (consulte a Figura 2). Figura 1 Direitos do usurio do Disco Local C

Figura 2 Modo de exibio avanado dos direitos de usurio na unidade C (clique na imagem para ampli-la) Aqui, os membros do grupo de usurios tm permisso para criar pastas e acrescentar dados a arquivos na raiz da unidade do sistema. Se clicar no boto Editar, voc ver outra concesso "especial" a subpastas, mostrada na Figura 3. Essa operao requer privilgios de administrador. msdn.microsoft.com/pt-br/magazine/cc982153.aspx

2/22

09/05/13

de administrador.

Controle de acesso: Compreendendo as permisses de arquivo e registro do Windows

Figura 3 Modo de exibio de edio dos direitos especiais de usurio Dessa forma, voc v que usurios normais tm permisso, por padro, para criar subpastas e adicionar contedo a essas pastas na raiz da unidade do sistema no Windows Server 2008. Essa funcionalidade foi fornecida a membros do grupo de usurios no Windows Server 2008 porque h software de terceiros que pressupe a presena dessas permisses, e a Microsoft no gostaria de suspender a compatibilidade do aplicativo. Agora passemos a uma abordagem tcnica desses problemas e como eles funcionam abaixo da interface GUI apresentada ao usurio. Todos os objetos nomeados no Windows tm descritores de segurana, que fornecem informaes sobre seu proprietrio, bem como listam quais usurios e assuntos tm permisses especificadas. Eles tambm podem especificar quais acessos a objeto devem ser registrados no log de eventos do sistema. As informaes sobre o que um assunto (usurio, processo etc.) tem permisso para fazer em um objeto ou recurso so especificadas em uma estrutura de dados conhecida como ACL. As ACLs enumeram aqueles que (qual entidade de segurana) tm determinado tipo de acesso a objetos especficos. Uma DACL (ACL discricionrio) um tipo de ACL em que os proprietrios de objetos tm permisso para alter-los. Sempre que um objeto acesso, o descritor de segurana comparado com as permisses da entidade de segurana para verificar se o acesso solicitado permitido. Observe que o Windows tambm oferece suporte a SACLs (ACLs do sistema) para objetos e usou as configuraes de SACL para estabelecer quais eram os eventos registrados no log de auditoria em muitas verses. Com o Windows Server 2008 e o Windows Vista, a SACL foi estendida para transportar informaes de nvel de integridade. O rtulo de integridade usado para estabelecer o rtulo "low" que marca o processo do Internet Explorer usado em LowRights Internet Explorer. Os rtulos "System" e "high" so usados para proteger os recursos crticos do sistema. A bomba de mensagens do Windows filtra as mensagens com base no nvel de integridade. Por exemplo, processos de nvel mdio no recebem mensagens enviadas de processos de nvel baixo e processos de nvel alto no

msdn.microsoft.com/pt-br/magazine/cc982153.aspx

3/22

09/05/13

no recebem mensagens enviadas de processos de nvel baixo e processos de nvel alto no recebem mensagens de processos de nvel baixo ou mdio. A essa altura, a proteo do nvel de integridade a uma bomba de velocidade, e no uma barreira de segurana efetiva com a qual voc conta para dar garantias de segurana. A altura dessa bomba aumentar significativamente nas verses posteriores, quando ela deve se tornar uma barreira de segurana real. Assim como acontece com outros sistemas operacionais modernos, o Windows depende de DACLs para tomar decises de controle de acesso. Aqui me concentrarei principalmente em DACLs. Para que o sistema determine se uma entidade de segurana tem permisso para realizar uma operao em um objeto, vrias coisas so verificadas: os privilgios da entidade de segurana, o token da entidade de segurana e o descritor de segurana do objeto. O descritor de segurana binrio em um objeto passado para a rotina AccessCheck com o token da entidade de segurana. preparado um vetor de bits da mscara de acesso solicitado, representando os direitos de acesso que devem ser concedidos para que haja xito na verificao de acesso. Ele passado com o descritor de segurana da entidade para a rotina AccessCheck, que examina o token de segurana do usurio e considera os privilgios da entidade de segurana (normalmente baseados em funes ou associao como, por exemplo, administrador) em combinao com o acesso solicitado e a DACL no objeto. Caso o acesso solicitado seja atendido pelos privilgios da entidade de segurana, o acesso concedido. Do contrrio, as ACEs (entradas de controle de acesso) da DACL so examinadas em ordem. To logo consiga mostrar que todos os componentes do acesso solicitado tm permisso ou que algum deles foi negado, o sistema de segurana retorna um xito no primeiro caso e uma falha no segundo. Assim, a lista de DACLs das ACEs deve ser ordenada corretamente. A ordem padro (cannica) colocar primeiro negaes explcitas e, em seguida, permisses explcitas, negaes gerais (grupo) e permisses gerais. Caso a ordem cannica no seja usada, podem ocorrer permisses ou negaes imprevistas.

Controle de acesso: Compreendendo as permisses de arquivo e registro do Windows

Descritores de segurana do objeto Embora seja uma estrutura de dados binria, o descritor de segurana depende do formato da cadeia de caracteres do descritor para fornecer um formato de texto que possa ser lido por humanos. Um descritor de segurana 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: proprietrio (O:), grupo primrio (G:), DACL (D:) e SACL (S:), como ilustra a Figura 4. Figura 4 Descritores de segurana

msdn.microsoft.com/pt-br/magazine/cc982153.aspx

4/22

09/05/13

Controle de acesso: Compreendendo as permisses de arquivo e registro do Windows

Os SIDs (identificadores de segurana) so estruturados para fornecer informaes de anlise e incluem 96 bits de informaes aleatrias (e podem incluir 32 bits de contagem em seqncia) para funcionar como um identificador exclusivo dos proprietrios. As string_aces (ACEs expressadas no formato da cadeia de caracteres) so estruturas que concedem ou negam permisses explicitamente na DACL e definem a diretiva na SACL. Toda string_ace fica entre parnteses e tem a seguinte estrutura: ( a c e _ t y p e ; a c e _ f l a g s ; r i g h t s ; o b j e c t _ g u i d ; i n h e r i t _ o b j e c t _ g u i d ; a c c o u n t _ s i d ) Apenas essas concesses, necessrias ao acesso adequado ao objeto em questo, devem estar presentes. Normalmente, owner_sid e group_sid so omitidos do descritor de segurana. Se no for especificado explicitamente no momento da criao, o campo owner do descritor de segurana definido como o SID da entidade de segurana que invoca a criao do objeto. O campo group definido como o grupo primrio do token de segurana da entidade. Se no for necessrio auditar um objeto ou definir um rtulo de integridade, a SACL no estar

msdn.microsoft.com/pt-br/magazine/cc982153.aspx

5/22

09/05/13

necessrio auditar um objeto ou definir um rtulo de integridade, a SACL no estar presente. Nas string_aces, apenas esses campos necessrios so includos (o conjunto mnimo ace_type, direitos e o assunto, normalmente account_sid). Em geral, object_guid e inherit_object_guid no esto 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 permisses" deve vir antes de "dar permisses". Uma ACL sem ACEs uma DACL vazia. Como uma ACE concede acesso a um assunto especificado para um objeto, ningum pode acessar um objeto com uma DACL vazia. Diz-se que um objeto sem uma DACL tem uma DACL NULL. Objetos com DACLs NULL no foram protegidos e todos tm controle total sobre eles. Por esse motivo, no defina DACLs vazias ou NULL. Agora vale a pena observar como seria um descritor de segurana real. Eis um descritor de segurana 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 substituda por icacls. Infelizmente, icacls no oferece suporte a uma opo de linha de comando para gerar os resultados na Security Descriptor Definition Language, ou SDDL, uma opo que cacls tem o sinalizador /S): C : \ > c a c l sc : // s c : \ " D : P A I ( A ; O I C I ; F A ; ; ; S Y ) ( A ; O I C I ; F A ; ; ; B A ) ( A ; O I C I ; 0 x 1 2 0 0 a 9 ; ; ; B U ) ( A ; C I ; L C ; ; ; B U ) ( A ; C I I O ; D C ; ; ; B U ) ( A ; O I C I I O ; G A ; ; ; C O ) " Com base naquilo que sabemos sobre descritores de segurana, possvel observar a partir do primeiro "D:" que nenhuma propriedade ou associao a um grupo reivindicada e que o descritor uma DACL. A DACL est protegida: o "P" e o sinalizador de herana do Windows NT 5.0 esto definidos. Em seguida, temos algumas ace_strings que precisam ser decifradas.

Controle de acesso: Compreendendo as permisses de arquivo e registro do Windows

Noes bsicas do descritor de segurana string_aces Lembre-se do formato string_aces que mostrei anteriormente. Os ace_types permitidos esto definidos na Figura 5, e os ace_flags permitidos esto definidos na Figura 6. Os ace_flags da herana so os fatores de controle da herana 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 permisses de arquivo e registro do Windows

Figura 6 ace_flags permitidos

Os direitos de ACE so indicados por uma cadeia de caracteres que denota os direitos de acesso controlados pela ACE. A cadeia de caracteres pode ser uma representao da cadeia de caracteres hexadecimal como, por exemplo, "0x7800003F" ou ser uma concatenao das cadeias de caracteres dos Direitos como "CCLCSWLOCRRC", que interpretarei posteriormente. A representao hexadecimal e os valores de bit associados so mostrados na Figura 7 . Figura 7 Mscara de acesso ACL

O sistema usa uma representao de bitmap nico dos direitos de ACE para todos os objetos. Nem todos os bits so significativos para vrios objetos. Apenas os direitos apropriados a um objeto so aplicados. Os direitos padro so aqueles comuns a todos os objetos protegveis. msdn.microsoft.com/pt-br/magazine/cc982153.aspx

7/22

09/05/13

Controle de acesso: Compreendendo as permisses de arquivo e registro do Windows

objeto so aplicados. Os direitos padro so aqueles comuns a todos os objetos protegveis. Direitos genricos so uma forma prtica de especificar direitos de inteno semelhante para vrios objetos. A especificao de direitos genricos mapeada para o conjunto apropriado de direitos especficos. Os rtulos de integridade tambm so codificados usando o campo de direitos de ACE durante a especificao da SACL. Os direitos disponveis de vrios objetos so listados na Figura 8. Figura 8 Direitos genricos

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 declarao de controle total apropriada. KA (Key All) a declarao de controle total apropriada para o Registro. As declaraes genricas costumam ser usadas no lugar das declaraes mais apropriadas, embora sejam mapeadas para o sistema de arquivos apropriado ou para as declaraes da chave do Registro, conforme apropriado. Como as expresses SDDL normalmente misturam esses termos, voc precisa estar atento s equivalncias.

Direitos padro e especficos Muitos objetos podem receber direitos. Alm de arquivos e diretrios, temos chaves do Registro, processos, reas de trabalho etc. Para obter a lista completa, consulte as figuras de A a J. Como abordaremos as permisses no sistema de arquivos e no Registro, os direitos especficos desses objetos so fornecidos nas figuras 9 e 10.
msdn.microsoft.com/pt-br/magazine/cc982153.aspx 8/22

09/05/13

Controle de acesso: Compreendendo as permisses de arquivo e registro do Windows

Figura 9 Direitos de arquivo especficos

Figura 10 Direitos do Registro especficos

Rtulos de integridade e seu uso Conforme j dissemos, os rtulos de integridade, se estiverem presentes, so armazenados na SACL do objeto. Implicitamente, os objetos tm integridade mdia, logo, se no h nenhum rtulo de integridade, a integridade do objeto mdia. Da mesma forma, se no h nenhum rtulo de integridade em um token de segurana, a integridade do dele tambm mdia. O rtulo de baixa integridade usado para identificar processos com direitos limitados como, por exemplo, o Internet Explorer e objetos no confiveis relacionados. Os nveis "high" e "system" so usados para ajudar a isolar esses objetos dos processos medium e low. Os rtulos de integridade so mostrados na Figura 11 . Figura 11 Rtulos de integridade

msdn.microsoft.com/pt-br/magazine/cc982153.aspx

9/22

09/05/13

Controle de acesso: Compreendendo as permisses de arquivo e registro do Windows

Object_guid e inherit_object_guid Object_guid e inherit_object_guid so usados na especificao da segurana dos objetos no Active Directory. Eles no so usados durante a proteo do sistema de arquivos ou do Registro. "OA" e "OD" no campo ace_type de uma cadeia de caracteres ACE correspondem a uma permisso de objeto e a uma negao de objeto, respectivamente. Nesse caso, object_guid mantm o GUID do objeto que est recebendo a permisso e inherit_object_guid mantm o GUI do objeto do qual as permisses so herdadas. O campo account_sid na estrutura ACE denota a entidade de segurana que est recebendo a concesso ou a negao 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 notao "SID string" de atalho para uma conta comum. A notao da cadeia de caracteres SID para contas comuns usada sempre que possvel para tornar o sistema mais legvel. Uma tabela das contas comuns ou bem conhecidas e suas cadeias de caracteres SID mostrada na abaixo. A declarao OW de direitos do proprietrio nova no Windows Server 2008 e no Windows Vista. Anteriormente, o CO (criador/proprietrio) de um objeto tinha os direitos padro de RC (controle de leitura) e WD (Write_DAC) nesse objeto, o que permitia ao proprietrio definir a segurana no objeto. Isso cria um problema caso um usurio seja membro de um grupo e crie muitos objetos. Se esse usurio deixasse o grupo, ele ainda teria controle sobre 10/22 msdn.microsoft.com/pt-br/magazine/cc982153.aspx

09/05/13

grupo e crie muitos objetos. Se esse usurio deixasse o grupo, ele ainda teria controle sobre esses objetos por ser o proprietrio deles, o que concederia a eles permisses RC mais Write_DAC. A presena da restrio de ACE do proprietrio OW impede a concesso implcita de RC/WD ao proprietrio, a menos que essas concesses sejam feitas explicitamente ACE do proprietrio de qualquer outra ACE relev ante na ACL. Isso possibilita a atenuao desse problema de segurana.

Controle de acesso: Compreendendo as permisses de arquivo e registro do Windows

Interpretando o descritor de segurana string_aces A sada de calcs na raiz da unidade do sistema foi: " D : P A I ( A ; O I C I ; F A ; ; ; S Y ) ( A ; O I C I ; F A ; ; ; B A ) ( A ; O I C I ; 0 x 1 2 0 0 a 9 ; ; ; B U ) ( A ; C I ; L C ; ; ; B U ) ( A ; C I I O ; D C ; ; ; B U ) ( A ; O I C I I O ; G A ; ; ; C O ) " Analisando a legibilidade disso, voc tem: " D : P A I ( A ; O I C I ; F A ; ; ; S Y ) ( A ; O I C I ; F A ; ; ; B A ) ( A ; O I C I ; 0 x 1 2 0 0 a 9 ; ; ; B U ) ( A ; C I ; L C ; ; ; B U ) ( A ; C I I O ; D C ; ; ; B U ) ( A ; O I C I I O ; G A ; ; ; C O ) " Trata-se de uma DACL protegida com o sinalizador de herana automtica para um conjunto de sistemas de arquivos modernos. O sinalizador protegido significa que as concesses pai herdveis no sero herdadas; a DACL protegida da herana do pai do objeto. Nesse caso, no existe nenhum pai porque ele a raiz. O administrador interno e o sistema recebem File All herdvel tanto nos arquivos (devido herana do objeto) quanto nos diretrios (devido herana do continer, ou CI). Isso significa que essa DACL concede File All recursivamente em todos os arquivos e diretrios abaixo da raiz exceto quando a herana interrompida por uma DACL protegida, quando a concesso na DACL protegida deve ser examinada. CO recebe Generic_All, que mapeado para File All, tanto nos arquivos quanto nos diretrios abaixo do diretrio raiz (devido ao sinalizador somente herana). A concesso para o usurio interno muito mais interessante. A primeira string_ace se aplica tanto a arquivos quanto a diretrios na raiz e abaixo, alm 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 herana), e a terceira string_ace permite AddFile nos diretrios abaixo da raiz. a mesma coisa que voc viu ao explorar essas permisses com a interface grfica ACL do Windows Explorer.

msdn.microsoft.com/pt-br/magazine/cc982153.aspx

11/22

09/05/13

Controle de acesso: Compreendendo as permisses de arquivo e registro do Windows

Proteo de Recursos do Windows Comeando com o Windows Server 2008 e o Windows Vista, os componentes declaram suas configuraes de segurana necessrias em seus manifestos, assinados por uma raiz de assinatura de cdigo Microsoft. O manifesto especifica as ACLs e as demais permisses associadas ao arquivo. Por isso, quando instalado, um componente transporta as configuraes de segurana apropriadas. Alm disso, os arquivos do sistema operacional so protegidos contra danos acidentais causados pelo administrador do sistema usando a WRP (Proteo de Recursos do Windows). A WRP depende de uma nova entidade de nvel do sistema, Trusted Installer, para obter e administrar arquivos e pastas do sistema. Um bom recurso para permitir que usurios normais do Windows realizassem instalaes de componentes autorizados foi adicionado ao Windows Vista. Assim, a funo Usurio Avanado deixa de ser obrigatria, e as instncias das ACEs que contm o SID de Usurio Avanado foram removidas. O grupo Usurio Avanado ainda existe, mas os manifestos do componente foram verificados e todas as instncias detectadas de concesses a PU foram excludas. Vejamos um diretrio de sistema para observar as novas permisses. Este tambm um timo exerccio de leitura SDDL: C : \ > c a c l sc : \ w i n d o w s/ s C : \ W i n d o w s" D : P A I ( A ; ; F A ; ; ; S 1 5 8 0 9 5 6 0 0 8 8 8 5 3 4 1 8 5 2 2 6 4 9 1 8 3 1 0 3 8 0 4 4 1 8 5 3 2 9 2 6 3 1 2 2 7 1 4 7 8 4 6 4 ) ( A ; C I I O ; G A ; ; ; S 1 5 8 0 9 5 6 0 0 8 8 8 5 3 4 1 8 5 2 2 6 4 9 1 8 3 1 0 3 8 0 4 4 1 8 5 3 2 9 2 6 3 1 2 2 7 1 4 7 8 4 6 4 ) ( A ; ; 0 x 1 3 0 1 b f ; ; ; S Y } ( A ; O I C I I O ; G A ; ; ; S Y ) ( A ; ; 0 x 1 3 0 1 b f ; ; ; B A ) ( A ; O I C I I O ; G A ; ; ; B A ) ( A ; ; 0 x 1 2 0 0 a 9 ; ; ; B U ) ( A ; O I C I I O ; G X G R ; ; ; B U ) ( A ; O I C I I O ; G A ; ; ; C O ) " O SID de Trusted Installer S-1-5-80-956008885-3418522649-18310380441853292631-2271478464. Usando TI como atalho, encontramos o seguinte: C : \ W i n d o w s" D : P A I ( A ; ; F A ; ; ; T I ) ( A ; C I I O ; G A ; ; ; T I ) ( A ; ; 0 x 1 3 0 1 b f ; ; ; S Y ) ( A ; O I C I I O ; G A ; ; ; S Y ) ( A ; ; 0 x 1 3 0 1 b f ; ; ; B A ) ( A ; O I C I I O ; G A ; ; ; B A ) ( A ; ; 0 x 1 2 0 0 a 9 ; ; ; B U ) ( A ; O I C I I O ; G X G R ; ; ; B U ) ( A ; O I C I I O ; G A ; ; ; C O ) " Interpretando isso, voc o v como uma ACE protegida sendo aplicada a C:\Windows usando o modelo de herana do Windows NT 5.0. Trusted Installer tem controle total sobre C:\Windows e recebe Generic_All em todos os contineres filho em C:\Windows (por ser CI, somente herana). System e admin recebem Read, Write, Append, ReadEA, WriteEA, Execute, ReadAttr,
msdn.microsoft.com/pt-br/magazine/cc982153.aspx 12/22

09/05/13

Controle de acesso: Compreendendo as permisses de arquivo e registro do Windows System e admin recebem Read, Write, Append, ReadEA, WriteEA, Execute, ReadAttr, 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 proprietrio ou a ACL. "BA" e "SY" tm Generic_All nos objetos de diretrio e arquivo filho.

Como o administrador tem o privilgio de apropriar-se, ele ainda pode declarar WriteOwnership e assumir o controle mesmo assim. Administrator e system so equivalentes em termos de segurana. Mas com esse privilgio, um determinado administrador pode contornar os controles ACL da WRP. CO tambm tem Generic_All nos objetos de diretrio e arquivo filho. O usurio interno tem Read, ReadEA, Execute, ReadAttr, RCtl e Sync = GRGX em C:\Windows e GRGX nos subdiretrios e em seus arquivos abaixo de C:\Windows. Todos os arquivos e pastas de sistema tm ACLs protegidas que concedem controle total a Trusted Installer. O controle de arquivos por Trusted Installer no expressado na declarao no diretrio raiz do sistema, e sim nas declaraes separadas dos componentes do Windows.

Definindo permisses seguras do sistema de arquivos Agora que voc tem alguma idia de como as ACLs do sistema de arquivos funcionam e como l-las, vejamos sua configurao. Se estiver instalando um aplicativo, voc deve instal-lo no local Arquivos de Programas padro. As ACLs padro desse local do controle total a Administrador e Sistema Local, o que apropriado. Se instalar um aplicativo em outro local ou conceder ao usurio a possibilidade de escolher seu local preferido para um aplicativo, voc ter um problema: as ACLs padro das demais unidades e reas que no sejam do sistema e do aplicativo da unidade de sistema no so seguras o suficiente. Nesses casos, voc deve usar explicitamente ACL nas pastas com as DACLs protegidas apropriadas. A opo mais simples e segura para instalar um aplicativo duplicar as configuraes de segurana na pasta Arquivos de Programa. Se voc optar por no fazer isso, defina a DACL de forma que os no-administradores no possam alterar DACLs ou a propriedade dos executveis, alm de no poderem gravar, acrescentar ou excluir arquivos em diretrios que contenham executveis. A regra bsica caso esteja definindo DACLs que voc no deseja que administradores ou outros usurios executem o cdigo escrito por um usurio. Isso seria especialmente um problema se a pasta em questo fosse presumivelmente confivel, especialmente estando em uma rea confivel (Windows, Arquivos de Programas etc.). Isso permite a EoP (elevao de privilgio) para administrador e aumenta o risco de ataques entre usurios. Por isso, caso um usurio possa gravar arquivos em uma pasta, os demais usurios e os administradores no devem ser capazes de execut-los. primeira vista, pareceria que voc jamais devesse permitir que usurios gravassem em
msdn.microsoft.com/pt-br/magazine/cc982153.aspx 13/22

09/05/13

Controle de acesso: Compreendendo as permisses de arquivo e registro do Windows primeira vista, pareceria que voc jamais devesse permitir que usurios gravassem em pastas no Windows, System, Arquivos de Programas etc. Acontece que existem motivos vlidos para isso. O mais comum registrar dados no log de erros. Se o executvel est em execuo com as credenciais do usurio e precisa registrar um erro no log, ele deve ter acesso gravao/acrscimo na pasta de registro/log de erros. (Se registrasse erros no log de acordo com os locais do usurio em um sistema com vrios usurios, voc teria os dados de registro em log espalhados pelo sistema, e no associados ao executvel. Os aplicativos e os servios costumam ser gravados em uma pasta compartilhada ou chave do Registro.) Voc enfrentar os mesmos problemas no Registro, onde as informaes sobre erros costumam ser armazenadas em chaves do Registro da mquina especficos por um processo em execuo com as permisses do usurio.

No misture arquivos gravveis com arquivos executveis. Use diretrios separados para arquivos que devam ser confiveis (como, por exemplo, executveis) e arquivos que no devam ser confiveis (qualquer coisa possivelmente gravada por um usurio no confivel). Use a ACL nos diretrios apropriadamente controle do administrador sobre os executveis e leitura/execuo do usurio, mas no gravao. 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 usurios em execuo como administrador. Os administradores de servidor sabem que no devem executar cdigos em reas no confiveis do sistema. Ao estabelecer uma conveno de nomenclatura para isolar arquivos de dados dos executveis no sistema, voc fornece ao administrador diretrizes a respeito da confiabilidade do executvel subdiretrios de registro em log no so confiveis; logo, usurios no devem ter a possibilidade de criar ou modificar esses subdiretrios, porque isso os permitiria falsificar regras de nomenclatura. No ambiente do cliente, muito mais fcil levar o usurio administrativo a executar o cdigo. Com administradores ingnuos assim, os diretrios que tenham gravaes de usurio no devem dar ao administrador privilgios de execuo para impedir que um usurio instale um executvel e, em seguida, leve um administrador a execut-lo e comprometer o sistema. Por exemplo, se o aplicativo ou servio precisa armazenar informaes de log a serem gravadas com privilgios de usurio, voc deve criar um subdiretrio de registro em log para manter esses dados. Esse subdiretrio no deve permitir a execuo. Uma forma de fazer isso adicionar uma negao explcita inicial de execuo do arquivo a todos como, por exemplo, D;OI;WP;;;WD. Isso impede ataques entre usurios em diretrios que permitam a gravao ou a modificao de arquivos aos usurios. H muitos casos em que se espera que os usurios compartilhem dados (ainda que no desejemos que os eles compartilhem e executem cdigos em uma rea compartilhada). Por exemplo, um usurio domstico (ou seu aplicativo de visualizao de fotos) deve criar uma pasta como, por exemplo, C:\Fotos. O usurio deve ser capaz de permitir que vrios usurios gravem nessa pasta e editem as vrias fotos nela. As ACLs padro na raiz da unidade do sistema no Windows Vista oferecem suporte a isso. A outra situao de compartilhamento comum uma pasta na qual os usurios colocam dados para que outros leiam. Apenas o criador dos dados tem permisso para excluir ou modificar os dados, mas os outros podem 14/22 msdn.microsoft.com/pt-br/magazine/cc982153.aspx

09/05/13

criador dos dados tem permisso para excluir ou modificar os dados, mas os outros podem copi-los e, em seguida, editar a cpia. Trata-se de um cenrio de leitura compartilhada, sendo o padro na unidade de sistema no Windows Server 2008. Considere o caso em que seja possvel bloquear o compartilhamento da unidade do sistema e, mais especificamente, das pastas ACL. Voc precisa escolher as ACLs apropriadas para esses dois cenrios bem comuns. Queremos que os administradores sejam capazes de gerenciar os objetos, mas queremos evitar problemas associados execuo de cdigo nessas pastas (observe que as ACEs aqui impedem at mesmo o proprietrio de executar cdigo nessas pastas). Eis uma ACE de leitura compartilhada: D : P ( D ; O I ; W P ; ; ; W D ) ( A ; O I C I ; F A ; ; ; B A ) ( A ; O I C I ; F A ; ; ; S Y ) ( A ; O I C I ; F A ; ; ; C O ) ( A ; C I ; 0 x 1 2 0 0 a f ; ; ; A U ) ( A ; O I ; G R ; ; ; A U ) E aqui uma ACE de colaborao: D : P ( D ; O I ; W P ; ; ; W D ) ( A ; O I C I ; F A ; ; ; B A ) ( A ; O I C I ; F A ; ; ; S Y ) ( A ; O I C I ; F A ; ; ; C O ) ( A ; O I C I ; S D G R G W ; ; ; A U ) Observe que ambas as ACLs comeam com uma ACE de execuo de negao para todos, herana de objeto (a ser aplicada aos arquivos) para impedir ataques do sistema de usurio e entre usurios. Em seguida, administrator, system (na verdade, system no precisa) e CO recebem controle total = File All. No cenrio de leitura compartilhada, um usurio autenticado recebe List, AddFile, AddSubDir, ReadEA, Traverse, ReadAttr, RCtl e Sync devido restrio dessa concesso a CI e, assim, a diretrios, recebendo a leitura genrica separadamente para todos os arquivos. Para o cenrio de colaborao, um usurio autenticado recebe Delete, Generic Read e Generic Write em arquivos e diretrios.

Controle de acesso: Compreendendo as permisses de arquivo e registro do Windows

Gerenciando o Registro e suas permisses O Windows armazena grande parte das informaes de estado no Registro. Os repositrios de dados do Registro so conhecidos como hives, nos quais os dados so armazenados em chaves e subchaves, ambas exibidas como contineres (subchaves no so exibidas como objetos). Os dados especficos do usurio so armazenados na seo do usurio apropriada de Hive Key Users (HKEY_USERS). Como seria de se esperar, grande parte desses dados pode ser gravada pelo usurio. Em uma sesso, HKey_Current_User (HKCU) aponta para a seo apropriada de HKEY_USERS. As informaes do sistema e da mquina so armazenadas no hive HKEY_LOCAL_MACHINE (HKLM). Includas no HKLM esto as informaes de todos os 15/22 msdn.microsoft.com/pt-br/magazine/cc982153.aspx

09/05/13

Controle de acesso: Compreendendo as permisses de arquivo e registro do Windows

HKEY_LOCAL_MACHINE (HKLM). Includas no HKLM esto as informaes de todos os vrios servios do sistema, a maioria dos quais agora executada com permisses limitadas nos vrios grupos Servio Local ou Servio de Rede. Os servios e os aplicativos podem armazenar informaes de estado em suas chaves do Registro. Essas informaes devem ser armazenadas em subchaves, na chave do servio ou em uma chave sob a chave do servio. A chave do servio no deve usar uma ACL para permitir que o servio tenha SetKey em sua prpria chave de servio (ou WDac ou WOwn, que, assim, permitiriam um ataque), porque isso permite ao servio apontar para um executvel diferente. Um erro desse tipo introduz uma EoP no host do servio, porque o Gerenciador de Controle de Servios carregar o executvel para o qual est apontado quando o sistema for carregado. As diretrizes gerais quanto a DACLs de HKLM que elas no devem permitir aos usurios gravar ou modificar esses dados ou as ACLs associadas e sua propriedade. Assim como acontece com a diretriz para configurao das DACLs do sistema de arquivos em reas do sistema, h excees no registro em log de erros quando um aplicativo ou um servio em execuo em um contexto de usurio ou limitado precisa registrar informaes do erro. A diretriz nessas situaes semelhante a problemas equivalentes no sistema de arquivos criar chaves separadas para essas informaes e usar a ACL nelas corretamente. Por isso, as informaes podem ter a ACL para assuntos confiveis (administrador, sistema etc.) e os dados de registro em log podem ser gravveis, conforme necessrio. A situao que voc est tentando evitar um usurio modificando parmetros confiveis (como, por exemplo, desativar o antivrus o servio de antimalware) ou adulterando uma ferramenta usada por usurios ou administradores. Suponhamos que, quando o Bloco de Notas seja invocado, ele carregue C:\windows\notepad.exe. A ACL padro em C:\windows no permite a um invasor modificar o executvel. Caso consiga reescrever esse link do cone do Bloco de Notas para seu executvel, 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 usurio no tivesse cincia do comprometimento. Caso o invasor consiga controlar o link no Registro, as ACLs de proteo no sistema de arquivos so incuas. Voc est preocupado com ataques de servios do sistema limitados em outros servios do sistema. No Windows Vista e no Windows Server 2008, os servios so separados em grupos pelos privilgios necessrios. As protees de defesa aprofundada oferecidas por esse isolamento do servio exigem a configurao das permisses do servio de forma que os servios no possam se adulterar, especialmente em grupos. Assim como estamos preocupados em impedir os usurios de adicionar ou vincular executveis mal-intencionados, tambm devemos impedir que os servios tenham a possibilidade de alterar suas permisses e recursos. O privilgio ChangeConf nos servios devem ser restritos a administrador, sistema ou Trusted Installer porque esse privilgio permite ao detentor alterar as permisses no servio.

msdn.microsoft.com/pt-br/magazine/cc982153.aspx

Concluso

16/22

09/05/13

Controle de acesso: Compreendendo as permisses de arquivo e registro do Windows

Concluso O Windows fornece um conjunto muito avanado de controles de permisso que podem ser usados para permitir operaes, bloque-las e fornecer uma defesa aprofundada contra novas ameaas. Inevitavelmente associado a essa possibilidade avanada de controlar o acesso est o problema da complexidade. Seguir algumas diretrizes gerais ajudar voc a evitar problemas. Por exemplo, os padres do sistema so comprometimentos razoveis. 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 padres como, por exemplo, concesses padro a usurios em unidades, mas no se esquea 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 no devem executar cdigo ou seguir ponteiros para um cdigo que possa ser escrito ou modificado por um usurio. E to importante quanto que usurios no executem cdigo ou sigam ponteiros para um cdigo que outro usurio possa ter escrito ou modificado. Essas diretrizes abordam todos os problemas de segurana discutidos aqui. Se qualquer alterao feita por voc seguir essas diretrizes, voc ter evitado grande parte dos problemas de segurana mais srios. Para obter mais informaes sobre componentes de controle de acesso, consulte "Componentes de controle de acesso" no MSDN. Mais informaes sobre os componentes da mscara de acesso ace_string podem ser encontradas no artigo do MSDN "ACCESS_MASK", que inclui ponteiros para direitos especficos de arquivos, diretrios, chaves do Registro e sees compartilhadas. Informaes adicionais sobre SIDs restritos podem ser encontradas no artigo do 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 permisses de arquivo e registro do Windows

Figura B Direitos de arquivos e diretrios especficos

Figura C Direitos de mapa de arquivo e Registro especficos

Figura D Direitos do Gerenciador de Controle de Servios e de servios especficos

msdn.microsoft.com/pt-br/magazine/cc982153.aspx 18/22

09/05/13

Controle de acesso: Compreendendo as permisses de arquivo e registro do Windows

Figura E Direitos de processos e threads especficos

Figura F Direitos de estaes Windows e reas de trabalho especficos

msdn.microsoft.com/pt-br/magazine/cc982153.aspx

19/22

09/05/13

Controle de acesso: Compreendendo as permisses de arquivo e registro do Windows

Figura G Direitos de links simblicos e eventos especficos

Figura H Direitos especficos de semforos e excluses mtuas

Figura I Direitos de pipes e tokens especficos

Figura J Contas 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 permisses de arquivo e registro do Windows

msdn.microsoft.com/pt-br/magazine/cc982153.aspx

21/22

09/05/13

Controle de acesso: Compreendendo as permisses de arquivo e registro do Windows

John R. Michener gerente de programa de segurana snior na Microsoft. Ele ingressou na Segurana do Windows na Microsoft h cinco anos. John tem mais de 20 anos de experincia em segurana de sistema e participou de trs inicializaes de segurana. Ele o especialista em criptografia e permisses da equipe Windows Software Assurance. Voc pode entrar em contato com ele pelo email jmichene@microsoft.com.

msdn.microsoft.com

h t t p : / / m s d n . m i c r o s o f t . c o m / p t b r / m a g a z i n e / c c 9 8 2 1 5 3 . a s p x h t t p : / / g o o . g l / f f g S

msdn.microsoft.com/pt-br/magazine/cc982153.aspx

22/22