Faltam -1 dias! Inscreva-se agora! O maior encontro de profissionais web da américa latina.

Vimos na matéria anterior os conceitos sobre segurança com .NET. Dando continuidade ao assunto, falaremos sobre Security Police.

O processo de “Atribuição” de permissão para o assembly, passa por três fases:

- Obtenção da evidência
- Apresentação da evidência para o Security Policy e a conseqüente obtenção do Conjunto de Permissões (Permission Set)
- Ajuste do conjunto de permissões baseados nos requerimentos do assembly

Vamos avaliar o mecanismo Security Policy

Após o CLR (Common Language Runtime) obter todas as evidências, elas são submetidas ao Security Policy como um conjunto de objetos encapsulados em uma coleção do tipo Evidence.

Cada nível do Security Policy contém grupos de códigos (Code Group) que são compostos por uma questão proposta para o assembly e um conjunto de permissões que serão garantidas para o assembly caso a evidência satisfaça a questão. Cada questão proposta é chamada tecnicamente de Membership Condition. Veja na figura abaixo, os grupos de códigos e os conjuntos de permissões para o nível Machine.

Os grupos de códigos e conjunto de permissões acima, já vem com uma configuração padrão, por exemplo, o grupo de código My_Computer_Zone, tem um conjunto de permissões FullTrust, ou seja, se o código estiver instalado localmente, ele terá permissões para executar qualquer ação. Mais adiante faremos uma configuração completa para rodar um aplicativo em rede.

O gráfico abaixo sintetiza a relação entre os grupos de código e os conjuntos de permissões:

Ao analisar os grupos de código de um determinado nível, as permissões parciais garantidas para o este assembly será a união das permissões de todos os grupos de código desse nível.

Esse gráfico mostra que todo código baixado pela Internet e originado de um parceiro iMasters terá o conjunto de permissões (Named Permission): LocalIntranet + Internet. Note que esse esquema é para cada nível. O resultado das permissões garantidas para o assembly será a intercessão dos resultados de todos os níveis, como mostra a imagem abaixo:

Só para constar, a fórmula é: G = M + (O?P) – R

G: Permissões Garantidas
M: Requisições mínimas
O: Requisições opcionais
P: Permissões garantidas pelo Security Policy
R: Permissões negadas

Vamos agora fazer um exemplo de configuração para que você possa rodar um aplicativo em rede, ou seja, que possa ser executado com um atalho para o arquivo “.exe” localizado no servidor.

01. Crie um programa simples que tenha as seguintes características: interface com o usuário e acesso ao file system (E/S);

02. Coloque-o em uma pasta compartilhada no seu servidor, e crie um atalho para ele na sua estação;

03. Tente acessar o seu programa e usar o recurso de acesso ao File Sytem por exemplo. Você perceberá que será disparado um SecurityException. Para resolver isso, vamos configurar as políticas de segurança na sua máquina.

04. Abra a ferramenta de configuração mscorcfg.msc (Painel de controle -> Ferramentas Administrativas -> Microsoft .NET Framework 1.1 Configuration) e acesse o nível Machine.

05. Faça uma cópia do grupo de código LocalIntranet_Zone (Botão direito -> Duplicar). Poderia ser de qualquer grupo.

Acesse as propriedades do grupo “Cópia de Intranet_Zone” e vá na guia “Condição de Membro” ou “Membership Condition”, e escolha a condição Zona. Em “Zona:” escolha Intranet Local.

Agora vá na guia “Conjunto de Permissões” ou “Permission Set”, e escolha o conjunto de permissão FullTrust.

Finalize, com ok e renomeie se quiser o seu grupo de código. Agora tente rodar novamente seu programa e verá que tudo funcionará perfeitamente.

Obs: A configuração que eu fiz agora foi muito simples e generalista. Poderia refinar de modo a ficar mais restrita a permissão exclusiva ao meu assembly.

Apenas como curiosidade, podemos fazer essa configuração acessando diretamente o arquivo .config. Veja a localização:

Enterprise: %Systemroot%Microsoft.NETFrameworkversionConfigenterprise.config
Machine: %Systemroot%Microsoft.NETFrameworkversionConfigsecurity.config
User: %UserProfile%Application DataMicrosoftCLR Security Configversionsecurity.config

Aconselho também o estudo da ferramenta CASPOL (Code Access Security Policy). Com ela você pode editar e visualizar as configurações de segurança do assembly.

Teste os exemplos abaixo:

Caspol –a –listgroups
Caspol –a –resolvegroup PathAssembly
Caspol –a –resolveperm PathAssembly

Você verá como saída para a primeira linha a lista de grupos de códigos para os níveis Machine e User. Na segunda linha, aparecerá a lista de grupos de código para assembly específico, e na terceira aparecerá a lista de permissões para o assembly.

Bem, vou ficando por aqui. Na próxima e última matéria sobre segurança mostrarei exemplos práticos e simulações de situações reais para utilização dos mecanismos de segurança do .NET.

Qualquer dúvida, estarei a disposição através do e-mail lblima_net@hotmail.com

Até a próxima!