Segurança

Novas ACLs aprimoram a segurança do Windows Vista

Jesper Johansson

Visão geral:

• Novidades nas ACLs
• Controles mais rígidos sobre o administrador
• Permissões para instaladores confiáveis
• Usuários e grupos modificados

A estrutura fundamental das ACLs (listas de controle de acesso) não mudou muito no Windows Vista, mas há algumas alterações pequenas, porém importantes que você precisa conhecer. Algumas alterações

eram necessárias porque, no Windows® XP, as ACLs tinham participação em vários problemas. Em primeiro lugar, a maioria dos usuários executa o Windows XP como administrador. Isso significa que usam uma conta pertencente ao grupo interno Administradores. No caso dos usuários domésticos, isso é praticamente uma certeza, pois todas as contas adicionadas durante a instalação tornam-se contas de administrador. Assim, todos os programas que esses usuários executarem serão também executados com privilégios administrativos, com acesso irrestrito ao sistema operacional. Claro que isso é especialmente problemático se os programas não forem recomendáveis.

O segundo problema a ser solucionado era o incômodo causado pelas ACLs padrão das versões anteriores do Windows, que incluíam ACEs (entradas de ACL) para Todos, Usuários Avançados e assim por diante. Por exemplo, a ACL padrão na raiz do volume de inicialização (normalmente C:\) do Windows XP dava acesso de leitura a Todos e concedia permissão para criar pastas a membros do grupo Usuários. Por fim, no Windows XP havia limitações no que era possível fazer com as ACLs. Por exemplo, não havia no Windows XP forma alguma de atribuir permissões ao proprietário atual de um objeto. Era possível atribuir permissões ao proprietário mas, se o proprietário mudasse, essas permissões não eram transferidas. Do mesmo modo, os proprietários sempre tinham direitos implícitos sobre um objeto, independentemente das permissões atribuídas àquele objeto.

Com o Windows Vista™, a Microsoft lançou-se em um projeto para solucionar vários desses problemas e para habilitar o suporte a outros recursos, como o UAC (Controle de Conta de Usuário). Este artigo se concentra nas principais alterações relacionadas ao controle de acesso no Windows Vista. No próximo mês continuarei a análise das ferramentas que você pode usar para gerenciar o controle de acesso.

Usuários e grupos novos e modificados

Há alguns usuários e grupos novos no Windows Vista, e alguns antigos do Windows XP foram removidos. Além disso, a forma como alguns deles funcionam foi modificada. Cada alteração terá algum impacto sobre a forma como você gerencia o controle de acesso.

Administrador — conta desabilitada por padrão A conta interna Administrador, com um RID (identificador relativo) de 500, agora é desabilitada por padrão na maioria dos casos. Ela deveria ser uma conta de emergência, usada para o salvamento do computador quando tudo o mais falhar. Só que com muito mais freqüência passou a ser usada como conta administrativa padrão, violando vários princípios de segurança. O mais notável deles — a responsabilidade — significa que você perde a capacidade de controlar quem está fazendo alterações no seu sistema. Por isso, a conta foi parcialmente preterida. A Microsoft poderá, por fim, preterir completamente a conta, mas agora ela é desabilitada por padrão. Se você não tiver outras contas locais no grupo Administradores, ainda será possível usar o RID 500 no console de recuperação e no modo de segurança, mas ele não pode e não deve ser usado de outra forma.

Observe que existe uma diferença entre a conta interna Administrador e as outras contas do grupo Administradores. Normalmente escrevemos "Administrador" com inicial maiúscula quando nos referimos à conta com o RID 500, para distingui-la de "administrador", que é qualquer outra conta pertencente ao grupo interno Administradores. Os nomes de grupos também são escritos com inicial maiúscula.

No Windows XP, a conta interna Administrador tinha vários direitos especiais e privilégios que não eram concedidos a nenhum outro administrador. Muitos deles foram removidos do Windows Vista, mas há duas exceções dignas de nota: em primeiro lugar, uma conta Administrador desabilitada pode ser usada no console de recuperação se não houver outros administradores locais. Em segundo lugar, o Administrador não está sujeito ao UAC e sempre terá um token administrativo completo. O mesmo vale para o Administrador de Domínio (RID 500 em um domínio).

Permissões de Usuários Avançados removidas O antigo grupo Usuários Avançados foi abolido para todas as finalidades práticas. O grupo ainda existe, mas a maioria das permissões concedidas a ele foi removida. Não era exatamente um segredo que um usuário pertencente ao grupo Usuários Avançados era, na realidade, um administrador que simplesmente ainda não se tornara um administrador. Uma vez assumi o controle de uma máquina com todos os patches, executando Windows XP SP2 (Service Pack 2), em menos de 45 minutos, concedendo a mim mesmo privilégios administrativos. Isso incluiu o reconhecimento, escrever um pequeno programa em C++, fazer logoff e logon novamente para concluir a tomada de controle — com todos esses recursos habilitados, pois eu era membro do grupo Usuários Avançados.

Muitas organizações concederam permissões sofisticadas ao grupo Usuários Avançados e contam com o fato de seus usuários pertencerem a ele. Por isso, não era viável remover o grupo do Windows Vista. No entanto, é provável que a Microsoft remova completamente o grupo Usuários Avançados em uma versão futura do Windows. Seria aconselhável que você começasse a planejar a migração para deixar o grupo Usuários Avançados.

Instalador Confiável O Instalador Confiável é na verdade um serviço, e não um usuário, embora você veja permissões concedidas a ele em todo o sistema de arquivos. O sistema de proteção de serviços permite que cada serviço seja tratado como uma entidade de segurança completa, que pode ter permissões concedidas como qualquer outro usuário. Para obter uma visão geral desse recurso, consulte a edição de janeiro de 2007 da TechNet Magazine. O livro Windows Vista Security (Grimes e Johansson, Wiley Press, 2007) explora detalhes do sistema de proteção de serviços, inclusive de que forma ele é aproveitado por outros recursos, como firewall e IPsec.

Os SIDs de serviço não são emitidos pelas mesmas autoridades de antes, como NT AUTHORITY ou um domínio. O nome completo da conta virtual TrustedInstaller é NT SERVICE\TrustedInstaller e seu SID é:

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

Você pode ver o SID de qualquer serviço, mesmo daqueles que não existem, executando o comando sc showsid, como mostrado na Figura 1.

Figura 1** O comando sc showsid mostra o SID de qualquer serviço, inclusive daqueles que ainda não existem **(Clique na imagem para aumentar a exibição)

Esse SID começa com S-1-5-80. Observe que a primeira subautoridade aqui é 80, que representa SECURITY_SERVICE_ID_BASE_RID, o que significa que esse SID foi emitido pela subautoridade NT SERVICE para um serviço. O mesmo se aplica a qualquer serviço. As subautoridades restantes e os RIDs se baseiam no próprio nome do serviço. Isso permite que um desenvolvedor conceda permissões a seu serviço sem precisar criá-lo e instalá-lo primeiro, uma vez que o nome é determinístico e não irá variar de máquina para máquina.

Caso você não encontre o serviço TrustedInstaller no gerenciador de serviços, seu nome de exibição é "Instalador de Módulos do Windows".

Contas de ajuda e suporte removidas As contas Support_xxxxxx e HelpAssistant foram removidas das instalações limpas do Windows Vista, embora sejam retidas quando é feita a atualização de uma versão anterior do Windows. A conta Support_xxxxxx era usada para executar scripts do centro de suporte. Alguns OEMs que forneciam conteúdo próprio de ajuda talvez fornecessem também suas próprias contas de suporte. Não está claro o que acontecerá com as contas de OEMs, mas é muito provável que eles simplesmente deixem de criá-las. A rigor, não são mais necessárias. Na verdade, do ponto de vista da segurança, não era mesmo uma boa idéia permitir que usuários executassem scripts do centro de ajuda como se fossem outros usuários, então seria melhor se essas contas desaparecessem. O Windows Vista tem um novo mecanismo para realizar essa tarefa.

A conta HelpAssistant era usada durante a assistência remota. Assim como o centro de ajuda, o recurso de assistência remota foi reprojetado para evitar a necessidade da conta HelpAssistant, que conseqüentemente foi removida.

Novos SIDs de locais de rede Os sistemas operacionais baseados em Windows NT® sempre tiveram alguns SIDs baseados em locais de rede, como NETWORK e INTERACTIVE, denotando usuários fazendo logon a partir da rede e interativamente. Há também um SID REMOTE INTERACTIVE LOGON atribuído aos usuários fazendo logon via Serviços de Terminal (observe que os usuários dos Serviços de Terminal na verdade terão REMOTE INTERACTIVE LOGON e INTERACTIVE LOGON em seus tokens). No Windows Vista, são adicionados mais dois: DIALUP e INTERNET. Não são claras as razões exatas da adição de uma conta denotando um logon via dial-up, especialmente porque cada vez mais usuários deixarão de conectar-se caso a única rede disponível seja uma linha telefônica, mas essa conta existe. INTERNET logicamente se destina a indicar qualquer usuário que fez logon fora da rede local. NETWORK, no entanto, ainda designa qualquer usuário que fez logon na rede, incluindo a Internet.

OWNER RIGHTS e direitos do proprietário Existe agora um SID OWNER RIGHTS, que se aplica ao proprietário de um arquivo no momento em que ele for acessado. É usado principalmente para restringir o que o proprietário pode fazer com o arquivo. Há duas alterações dignas de nota na forma como os direitos do proprietário se comparam ao Windows XP. Em primeiro lugar, se você for o proprietário do objeto, mas houver nele uma ACE aplicável a você, os direitos na ACE prevalecerão sobre o fato de você ser o proprietário. Essa é uma alteração importante e exercerá um impacto considerável sobre certos aspectos da administração de sistemas, pois estamos acostumados com o fato de o proprietário ter direitos implícitos. Em segundo lugar, o SID OWNER RIGHTS pode ser usado para restringir ainda mais o que o proprietário pode fazer com um objeto.

Suponhamos que temos uma pasta cujo proprietário é o usuário Jesper, com uma ACL como a mostrada na Figura 2. O usuário, Jesper, tem apenas permissão de leitura sobre a pasta, embora seja o proprietário. Se ele tentar copiar um arquivo para ela, a cópia falhará porque Jesper não tem permissão para gravar na pasta. No entanto, isso não é totalmente intuitivo nas mensagens de erro. Se você tentar copiar um arquivo para uma pasta da qual é proprietário, mas sem permissões de gravação para usar o Windows Explorer®, eis o que acontecerá: primeiro, o Explorer informará que você precisa elevar as permissões para copiar o arquivo e solicitará que você os eleve, mas a cópia do arquivo falhará porque você não tem direitos para copiar nada nessa pasta. Você receberá uma mensagem de erro dizendo "Você precisa de permissão para executar esta ação" e botões para "Tentar novamente" (como se isso pudesse ajudar) e "Cancelar". Isso acontecerá apesar do fato de você ser o proprietário.

Figura 2** Somente o Sistema Local e um outro usuário têm acesso a esta pasta **(Clique na imagem para aumentar a exibição)

Se Jesper tentar alterar a ACL no arquivo, será solicitado que eleve seu token para fazê-lo. Como ele é o proprietário do arquivo, pode fazer isso. O proprietário retém direitos implícitos de ler e alterar a ACL (READ_CONTROL e WRITE_DAC), a menos que haja uma ACE para OWNER RIGHTS especificando o contrário.

Para entender o efeito do SID OWNER RIGHTS, vamos adicioná-lo à ACL acima. Agora temos as permissões mostradas na Figura 3.

Figura 3** Adicionar as permissões de OWNER RIGHTS à pasta altera as permissões de Jesper **(Clique na imagem para aumentar a exibição)

Com essas permissões, se a conta de Jesper tentar copiar alguma coisa para a pasta, essa ação terá sucesso imediato, pois Jesper é o proprietário e tem os direitos adequados. No entanto, se Jesper tentar alterar a ACL no objeto, a ação falhará! A ACE para OWNER RIGHTS especifica que o proprietário terá apenas o privilégio de modificação, e não a capacidade de modificar a DACL (lista de controle de acesso condicional). Assim, OWNER RIGHTS é usado principalmente para remover do proprietário WRITE_DAC, a capacidade de modificar o descritor de segurança.

Se um administrador alterar o proprietário do objeto, as permissões de OWNER RIGHTS não serão automaticamente transferidas para o novo proprietário. Nesse caso a ACE OWNER RIGHTS é desabilitada, sendo marcada como somente herdada, mas não aplicada a contêineres ou objetos — em outras palavras, não sendo aplicada a nada. Isso é feito para garantir que o objeto não fique completamente bloqueado para os administradores. Para fazer com que a ACE OWNER RIGHTS entre novamente em vigor, o Administrador precisa reabilitá-la manualmente. Para isso, é preciso marcá-la como aplicável à pasta, às subpastas e aos arquivos, conforme desejado.

Há vários cenários interessantes nos quais o SID OWNER RIGHTS pode ser útil. Por exemplo, quando o administrador quer que os usuários sejam capazes de criar arquivos e pastas em um servidor de arquivos, mas não quer que possam alterar as ACLs nessas pastas. Outra situação provável é quando certos usuários criaram objetos em algum momento como membros de um grupo, mas depois, talvez por motivos relativos a empresas, foram removidos do grupo. Agora, eles não devem ser capazes de modificar as configurações dos objetos.

OWNER RIGHTS é usado de forma bastante ampla no sistema de proteção de serviços. Quando um serviço cria um objeto transitório em runtime, o criador do objeto é o SID principal do processo de serviço, geralmente LocalSystem, NetworkService ou LocalService, e não o SID do serviço em si. Isso significa que qualquer outro serviço executado no mesmo contexto de processo poderia modificar o objeto, o que seria quase certamente algo indesejável. Definindo um SID OWNER RIGHTS nesses objetos, o sistema operacional pode impedir que outros serviços tenham acesso a eles.

ACLs padrão

As ACLs padrão do Windows XP eram, na verdade, relativamente boas. Com a exceção de alguns pequenos problemas, como permitir que os usuários colocassem arquivos na raiz do volume de inicialização, eram, de modo geral, sensatas. No entanto, alguns OEMs aparentemente decidiram que tinham uma idéia melhor do que constituiria uma segurança razoável. A tela na Figura 4 mostra uma imagem da ACL no diretório Windows de um computador de um grande OEM executando Windows XP Media Center Edition. Basicamente, o OEM desabilitou a segurança do sistema de arquivos.

Figura 4** Uma ACL configurada por OEM **

A Microsoft fez alguns ajustes nas ACLs do Windows Vista. Em primeiro lugar, se você está acostumado com o Windows XP, sabe que todos os arquivos do sistema operacional são propriedade do grupo Administradores, e que os administradores têm total controle sobre esses arquivos. Como membro do grupo, você tinha acesso irrestrito a esses arquivos. Não é assim no Windows Vista.

Instalador Confiável No Windows Vista, a maioria dos arquivos do sistema operacional tem como proprietário o SID TrustedInstaller, e somente esse SID tem total controle sobre eles. Isso faz parte do trabalho de integridade do sistema empreendido no Windows Vista, e destina-se especificamente a impedir que um processo executado como administrador ou Sistema Local substitua automaticamente os arquivos. Para excluir um arquivo do sistema operacional, você precisa, então, assumir a propriedade do arquivo e adicionar a ele uma ACE que lhe permita excluí-lo. Isso fornece alguma proteção contra processos executados como LocalSystem, com rótulo de integridade do sistema; um processo com integridade inferior não deve ser capaz de elevar-se para alterar a propriedade. Alguns serviços, por exemplo, podem ser executados com integridade média, embora sejam executados como Sistema Local. Tais serviços não podem substituir arquivos do sistema, portanto um explorador que assuma o controle de um deles não poderá substituir arquivos do sistema operacional, dificultando um pouco a instalação de um rootkit ou de outro malware no sistema. Também fica mais difícil que os administradores de sistema incomodados pela simples presença de algum binário de sistema façam sua remoção.

ACEs de negação Você descobrirá que vários objetos do sistema de arquivos têm ACEs de negação para Todos, o que tem causado o descontentamento de muitos administradores. Se você ativar a opção "Mostrar arquivos ocultos", verá o familiar diretório Documents and Settings (Documentos e Configurações). Mas, se você clicar nele, obterá um erro de "Acesso negado". Para entender o que está acontecendo com Documents and Settings, dê uma olhada na lista de diretórios na Figura 5.

Figura 5** Documents and Settings é um ponto de junção, e não um diretório **(Clique na imagem para aumentar a exibição)

Documents and Settings, na verdade, não é um diretório, mas sim um ponto de junção! Lembre-se de que os pontos de junção são semelhantes a links simbólicos que simplesmente redirecionam o acesso a algum outro lugar. Nesse caso, a junção vai para um diretório chamado C:\Users. Na verdade, a Microsoft modificou consideravelmente o namespace do sistema de arquivos no Windows Vista, e agora os dados do usuário são movidos para C:\Users. Outros elementos sob o antigo namespace "C:\Documents and Settings\<Nome_Usuário>" também foram movidos. Por exemplo, "C:\Documents and Settings\<Nome_Usuário>\Application Data" foi movido para C:\Users\<nome_usuário>\appdata\roaming. Você poderá ver claramente as alterações se entrar em uma linha de comando e usar o comando dir /a como usei na Figura 5. O motivo de alterações tão drásticas no namespace é torná-lo mais intuitivo para os usuários e gerar uma separação mais clara entre documentos e dados. Em vez de armazenar todos os arquivos de dados na pasta Meus Documentos, os desenvolvedores agora podem criar pastas próprias no perfil do usuário, que as verá ali. Os dados de aplicativos de todos os usuários agora ficam em uma pasta oculta chamada de %systemroot%\ProgramData, e não em Documents and Settings\All Users\Dados de Aplicativos.

A Microsoft não removeu o namespace "C:\Documents and Settings" porque pode haver aplicativos antigos codificados para usar esse nome em vez das variáveis de ambiente preferenciais, como %USERPROFILE%. Esses aplicativos teriam seu funcionamento interrompido se "C:\Documents and Settings" desaparecesse. Em vez disso, agora é representado por pontos de junção ou links simbólicos, para compatibilidade retroativa. Ainda assim, os aplicativos que têm esses caminhos codificados podem deixar de funcionar, dependendo da forma como acessam os dados contidos neles, mas já não funcionam nas versões do Windows em idiomas diferentes do inglês. Isso é realmente fundamental. Quando uma atualização do Windows, como o Windows XP SP2 ou o Windows Vista, interrompe o funcionamento de programas de terceiros, isso quase sempre acontece porque os desenvolvedores desses programas fizeram suposições inválidas ou usaram o Windows de forma inadequada.

Por exemplo, se você tentasse abrir um arquivo digitando "C:\Documents and Settings\<Nome_Usuário>\Meus Documentos\foo.txt", provavelmente funcionaria, desde que você tivesse um arquivo denominado foo.txt nesse local. No entanto, se você tentar navegar até "C:\Documents and Settings\<Nome_Usuário>\Meus Documentos", obterá a mensagem de erro "Acesso negado". Para entender o que está acontecendo, dê uma olhada na ACL na Figura 6.

Figura 6** Há uma ACE de negação em Documents and Settings **(Clique na imagem para aumentar a exibição)

Veja a primeira ACE da lista. É uma ACE de negação para Todos para listar o conteúdo da pasta. Programas podem atravessar os pontos de junção e abrir documentos com caminhos absolutos, pois Todos têm o privilégio "Ignorar a verificação completa" (também conhecido como SeChangeNotifyPrivilege). As tentativas de enumerar os diretórios que eles representam, por parte de um usuário ou processo, falharão devido à ACE de negação. É por isso que, na verdade, você não pode ver o que há dentro de C:\Documents and Settings, nem excluir o "diretório". O motivo principal da existência dessa ACE de negação é impedir que os usuários excluam a junção e interrompam o funcionamento de aplicativos antigos. Isso serve também para lembrar aos desenvolvedores que não devem codificar aplicativos para usar o namespace antigo. Em vez disso, devem começar a usar variáveis de ambiente ou cadeias de caracteres do Registro para isolar o aplicativo de alterações futuras e diferenças de idioma.

Observe que todos esses pontos de junção ficam ocultos por padrão, então a grande maioria dos usuários jamais os verá. Para impedir aqueles que os vêem de excluí-los, a Microsoft incluiu uma ACE de negação para "Listar pastas".

Ignorar a verificação completa O motivo pelo qual os usuários podem acessar arquivos sobre os quais têm direitos dentro de pastas (ou pontos de junção) sobre os quais não têm direitos é que todos têm o privilégio "Ignorar a verificação completa". "Ignorar a verificação completa" ou SeChangeNotifyPrivilege é, na verdade, o privilégio mais básico do Windows, sendo concedido a um processo que teve todos os outros privilégios removidos, a menos que o processo solicite especificamente que ele também seja removido. É isso o que acontece quando você inicia um processo usando a linha runas /trustlevel:0x10000 < no Windows Vista. O programa especificado em <command> será executado com um token restrito e todos os privilégios, exceto SeChangeNotifyPrivilege, serão removidos do token do processo.

Como ponto de interesse, trustlevel 0x20000 fornece um token com o conjunto normal de SIDs, mas com privilégios removidos. 0x40000 fornece um token completamente normal.

Permissões padrão

As permissões padrão no sistema de arquivos do Windows Vista foram um pouco alteradas em relação ao Windows XP. Se você examinar a ACL em %systemdrive% (normalmente a unidade C: — o volume de inicialização), no Windows XP ou no Windows Server® 2003, verá isto (ou algo muito semelhante nas versões mais antigas do Windows XP):

D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU) 

Eis aqui a mesma ACL no mesmo diretório do Windows Vista:

D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU) 

Há algumas diferenças dignas de nota. Em primeiro lugar, agora há duas ACEs para BA (BUILTIN\Administrators), em vez de apenas uma. Contudo, o resultado é o mesmo. No Windows Vista, uma ACE não é herdada e concede acesso total à raiz; a outra é uma ACE IO (somente herdada), herdada por contêineres e objetos, que concede GA (todos genéricos) ou controle total. O mesmo se aplica no caso da substituição da ACE para SY (LocalSystem) por duas no Windows Vista. No Windows XP, a única ACE concedia acesso total e era herdada por objetos e contêineres. Mais uma vez, não há alteração no resultado. A ACL foi alterada principalmente para esclarecer e separar os privilégios, tornando-a mais fácil de gerenciar e, potencialmente, de restaurar.

O mais interessante é que a ACE para CO (Proprietário/Criador) deixou de existir. Isso significa que, se um usuário criar um objeto na raiz do sistema de arquivos, não haverá mais permissões especiais acumuladas para o criador.

Você pode ver também que a ACE para WD (Todos) foi removida. Muitas pessoas interessadas em segurança, embora talvez não tivessem total entendimento das implicações de suas ações, se preocupavam indevidamente com essa ACE. A Microsoft tentou em vão, durante anos, explicar que Todos tinha a mesma função do grupo interno Usuários, mas parece que finalmente desistiu e removeu totalmente a ACE. Como existe uma ACE idêntica para BU (BUILTIN\Users), que também é herdada por contêineres e objetos, o resultado é que nada mudou.

Além disso, duas das ACEs para BU (grupo interno Usuários) foram substituídas por ACEs para AU (Usuários Autenticados). O motivo para isso é que a conta Convidado é membro do grupo interno Usuários (devido ao fato de que INTERACTIVE é membro do grupo interno Usuários), mas não de Usuários Autenticados. Para permitir que a conta Convidado leia e execute arquivos, a ACE 0x1200a9 (efetivamente, leitura e execução) permanece concedida a BU. No entanto, as ACEs que concedem permissões para criar arquivos e pastas são concedidas a Usuários Autenticados. Essa é uma divergência em relação ao Windows XP. No Windows XP, um Convidado podia criar arquivos na raiz. No Windows Vista, um Convidado não pode criar esse tipo de arquivo. Lembre-se, contudo, de que isso não faz muito sentido, a menos que a conta Convidado seja habilitada e os convidados tenham acesso à raiz do volume de inicialização. A conta Convidado é desabilitada por padrão.

Deixando o melhor para o final, há algumas ACEs muito interessantes e aparentemente problemáticas nas duas listas acima. No Windows XP, há uma ACE herdada por contêineres, especificando 0x100004 para o grupo interno Usuários. Essa ACE concede aos Usuários o direito de criar subpastas, subsubpastas e assim por diante, por ser herdada pelos contêineres. Há também uma ACE somente herdada que é herdada por subpastas para 0x100002. Essa ACE concede aos usuários o direito de criar arquivos e subpastas em pastas que criarem na raiz. Em outras palavras, essas duas ACEs permitem que os usuários, inclusive Convidados, criem arquivos e pastas na raiz, como já mencionei.

No Windows Vista, as ACEs correspondentes são somente herdadas, sendo herdadas tanto por contêineres quanto por arquivos, concedendo GR (leitura genérica), GX (execução genérica) e GW (gravação genérica), juntamente com o SD (descritor de segurança de leitura) e com uma ACE que se aplica somente à raiz em si, concedendo o privilégio LC. LC é na verdade um termo de atalho, pertencente às ACEs do Active Directory®. No Active Directory, isso significa que um usuário pode listar objetos filho. No entanto, o valor hexadecimal de LC é 0x4. Aplicado a um diretório, 0x4 significa FILE_ ADD_SUBDIRECTORY, o que funcionalmente equivale a 0x100004, como já temos 0x100000 (a capacidade de usar o objeto para sincronização) na ACE 0x1200a9. Em outras palavras, gera exatamente o mesmo efeito que no Windows XP — os usuários podem criar subdiretórios na raiz.

De onde vêm os valores hexadecimais? E o que são, afinal? Como você já deve ter percebido, o controle de acesso está repleto de números hexadecimais (base16), como 0x1200a9. São, na verdade, representações de máscara de bits dos bits em uma máscara de acesso definidos como "ativados"; isso significa que são usados em uma ACE específica. Quando você usa uma ferramenta como icacls, sc ou secedit para listar uma ACL, as máscaras de bits são representadas por cadeias de caracteres de texto muito mais amigáveis, se houver uma correspondência de 1:1.

Portanto, para determinar o que LC significa, basta que você vá ao site do MSDN®, encontre a cadeia de caracteres LC e procure na coluna "Access right value" (Valor de direito de acesso) para encontrar ADS_RIGHT_ACTRL_DS_LIST. Se você abrir o arquivo de cabeçalho Iads.h e procurar essa cadeia de caracteres, descobrirá que corresponde a 0x4. No caso de cadeias de caracteres que não são do Active Directory (não precedidas por "ADS_RIGHT"), geralmente você encontrará o valor hexadecimal em AccCtrl.h. Após obter o valor hexadecimal, será uma tarefa fácil procurá-lo na máscara de acesso em WinNt.h ou AccCtrl.h para ver o que realmente significa.

Se precisar de ajuda para fazer isso, talvez seja bom obter um exemplar do livro Protect Your Windows Network (Proteja sua rede Windows), de Jesper Johansson e Steve Riley, Addison-Wesley, 2005. O capítulo 17 explica em profundidade como analisar cadeias de caracteres SDDL (linguagem de definição do descritor de segurança) e ACEs.

As permissões concedidas para esses subdiretórios são regidas exclusivamente pela ACE (A;OICIIO;SDGXGWGR;;;AU) no Windows Vista, sendo essa a maior diferença entre ele e o Windows XP. Em vez de conceder controle total ao criador dos subdiretórios, como no Windows XP, no Windows Vista as concessões modificam os privilégios dos usuários autenticados.

O resultado dessa nova ACL é que o criador de um objeto não tem mais direitos especiais e que as coisas ficaram um pouco mais claras. Talvez a maior mudança seja que os Usuários Autenticados têm privilégios de modificação até mesmo em subpastas criadas pelos administradores, o que é muito diferente do Windows XP. No Windows XP, Usuários e Usuários Autenticados não têm direitos sobre objetos criados por administradores na raiz. No entanto, de forma geral, embora essas ACEs possam parecer problemáticas, o efeito não é tão diferente do Windows XP.

Resumindo, no Windows Vista todos, inclusive o usuário Convidado, podem ler e executar arquivos na raiz. Somente usuários autenticados podem criar novos arquivos e pastas e, quando o fazem, obtêm permissões de modificação sobre esses arquivos e pastas. Em outras palavras, as permissões são relativamente mais rígidas no Windows Vista do que no Windows XP, embora seja digno de nota que a conta Convidado é desabilitada por padrão.

Alterações em tokens

Quando um usuário membro do grupo Administradores no Windows XP faz logon, seu token contém o SID do grupo Administradores e ele pode fazer qualquer coisa que o grupo Administradores pode fazer. Por outro lado, no Windows Vista, devido ao Controle de Conta de Usuário, esse não é mais o caso. O SID Administradores ainda está presente no token, mas é definido somente para negação, conforme ilustrado na captura de tela do Process Explorer na Figura 7.

Figura 7** Com o UAC, o SID Administradores é usado somente para negar acesso, a menos que você o eleve **(Clique na imagem para aumentar a exibição)

Ao realizar o controle de acesso, essa entrada no token é usada somente para negar acesso — em outras palavras, para a correspondências com as ACEs DENY. As ACEs de permissão para esse SID são ignoradas. Isso significa que você não é realmente um administrador o tempo todo, mesmo se fizer logon no sistema como tal.

Nível de integridade

Agora o Windows oferece suporte à rotulagem de processos e objetos com níveis de integridade. Esses níveis de integridade são, na verdade, representados também por ACEs, mas não na DACL. Em vez disso, fazem parte da SACL (lista de controle de acesso do sistema), com alguns sinalizadores especiais. O sinalizador NW, por exemplo, é usado para denotar o bloqueio de um processo com um nível inferior de integridade para a gravação de objetos em um nível superior de integridade (SDDL_NO_WRITE_UP). Mark Russinovich aborda esse assunto em detalhes em seu artigo "Por dentro do UAC (Controle de Conta de Usuário) do Windows Vista", nesta edição da TechNet Magazine.

Conclusão

Embora não haja uma modificação revolucionária no controle de acesso do Windows Vista, como havia no Windows 2000, há várias pequenas alterações. Podem não parecer muito importantes individualmente, mas, em conjunto, significam que é preciso repensar várias atitudes adotadas no gerenciamento do sistema. Além disso, essas alterações dão suporte a diversas outras iniciativas, especialmente o UAC e o sistema de proteção de serviços. Talvez alguns administradores fiquem bastante frustrados quando começarem a usar o Windows Vista. Já ouvi comentários sobre "sistemas operacionais tirânicos", que restringem a capacidade de excluir partes do sistema operacional que, por um ou outro motivo, parecem ofensivas. Contudo, existem motivos concretos para todas as alterações e, provavelmente, se você dedicar algum tempo à análise do que foi feito, entenderá o porquê.

Jesper Johansson é arquiteto de segurança de uma grande empresa de comércio eletrônico, responsável por uma estratégia de segurança de aplicativos que engloba todas as propriedades e serviços. Ele trabalha há 20 anos na área de segurança, sendo autor de vários artigos e de dois livros sobre o assunto. Quando não está trabalhando com segurança da informação, é professor de mergulho submarino.

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