Pesquisa personalizada

Com este artigo estarei iniciando uma série de artigos sobre segurança com o FrameWork .NET, enfocando principalmente o recurso de Code Access Security. Então preparem-se para desvendar este extenso mundo da segurança.

Quando uma aplicação roda no sistema operacional ela abre um processo para realizar sua execução no sistema operacional.

O sistema operacional faz seu controle de segurança, controlando quem faz o que. Então tudo que é feito no sistema operacional precisa de uma identidade de usuário. Por isso todo processo rodando na máquina sempre possui uma identidade de usuário.

Quando o usuário inicia uma aplicação interativamente, esta aplicação assume a própria identidade do usuário. Quando a aplicação inicia-se na forma de serviço, em um servidor onde nenhum usuário se logou, por exemplo, o administrador de rede já atribuiu uma identidade para essa aplicação.

A aplicação, então, utiliza esta identidade para executar as tarefas perante o sistema operacional.

Porém este sistema de segurança, baseado apenas na identidade do usuário, é falho. Imagine que o usuário clique em um link no browser e a partir deste link rode uma aplicação na web. A aplicação, rodando na máquina do usuário, estará utilizando a identidade dele próprio, tendo permissão até mesmo para formatar o HD.

É ai que entram os novos recursos de segurança do .NET, CAS - Code Access Security. O CAS determina que não apenas o usuário precisa ter permissão de fazer algo, mas a aplicação precisa ter permissão de fazer algo.

As permissões da aplicação são fornecidas por requisição da própria aplicação ou com base na identidade da aplicação.

A identidade da aplicação, mais chamada de evidencia, é formada por uma série de informações que são obtidas do assembly no momento do inicio de sua execução. As informações são : Site, URL (é claro que isso pode ser web, intranet, ou até disco), Hash, StrongName e Publisher.Esta evidencia permite a aplicação de permissões, via CAS, ao assembly.

O mais comum de observarmos é a necessidade de diferentes permissões de acordo com o local de origem da aplicação (e o local de origem faz parte da identidade da aplicação).

Por exemplo, uma aplicação que esteja sendo executada diretamente a partir da máquina do usuário vai ter um certo conjunto de permissões, enquanto que uma aplicação executada a partir da rede local terá outro conjunto de permissões e uma aplicação executada a partir da internet, outro conjunto.

Essas permissões são definidas através do painel de controle, Ferramentas Administrativas. Ao ser instalado o Framework adicionou o item Microsoft .NET Framework 1.1 Configuration, que nos permite, entre outras configurações, ajustar as permissões de código, ou seja, o CAS.

Mas vamos imaginar algumas situações um pouco diferentes. Imagine que você produziu um Serviced Component e o instalou dentro do COM+ . Este Serviced Component tem permissões administrativas na máquina e alguns de seus métodos são capazes de eliminar arquivos do disco.

Dispondo de muita habilidade, um hacker poderia conseguir disparar seu Serviced Component remotamente, e provocar um estrago.

Esta primeira opção pode ser evitada pelo COM+, com a checagem da identidade de quem o está disparando. Porém o invasor, especialmente se for um funcionário da empresa, pode conseguir inserir sua aplicação diretamente no HD local do servidor e dai chamar o componente no COM+, podendo, em alguns casos, burlar a segurança do COM+ (não é fácil, muito pelo contrário).

Para que não imaginem esse cenário como algo muito inviável, imaginem que o invasor pode ser um programador da empresa, tentando realizar uma tarefa que normalmente ele não poderia realizar. Ele pode realizar a tarefa através de um componente já em produção que tenha permissão de fazer a tarefa.

Neste ponto entra novamente o CAS para resolver o problema de segurança. Vamos chamar o componente crítico de A. Digamos que este componente A atribui um aumento aos funcionários. Outros componentes não tem permissão de banco para atribuir esse aumento, mas um componente intruso poderia fazer isso através de A. A menos que se faça uso do CAS. Com o CAS, A pode informar ao framework que para que seja executado é necessário que quem o está executando tenha permissão de dar aumento aos funcionários. Isso transmite para o componente chamador a exigência de permissão.

Não quer dizer que o componente chamador possa ir ao banco diretamente e dar aumento, não, de forma alguma. Neste exemplo, poderiamos criar uma classe que represente esta permissão, algo como "DarAumentoPermission". O componente A então exige que os componentes que o chamarem tenham esta permissão, caso contrário não roda.

Isso vale não apenas para o chamador imediato, mas sim para todo o Call Stack, toda a sequencia de componentes chamadores, através de um processo que o framework realiza e que é conhecido como Stack Walks.

Vamos então começar a ver mais detalhes sobre a configuração do CAS. A configuração é feita através do painel de controle, Ferramentas administrativas, .NET Configuration 1.1

Entre os vários itens que podem ser configurados através desta ferramenta, o CAS pode ser encontrado com o nome de "Runtime Security Policy", isso porque estaremos configurando as policys de execução de código.

Ao abrirmos esta pasta podemos visualizar 3 policys : Enterprise, Machine e User. As Policys são configurações de permissão para determinados assemblys. Essas configurações podem ser feitas a nível de rede local (Enterprise), micro (Machine) ou usuário (User).

Um administrador de rede pode criar Enterprise Policys e desta forma garantir o máximo de permissão que as aplicações poderão ter em cada máquina (nenhuma aplicação poderá ter mais permissão do que as determinadas na enterprise policy). Através da Enterprise Policy pode também determinar se os usuários poderão ou não restringir mais as permissões de aplicações através das machine policies ou user policies.

As Enterprise Policys aparecem como read-only por default, sendo abertas para configuração apenas em um servidor de domínio. Porém a configuração realizada é válida apenas para a máquina em que foi realizada. Para que a configuração seja válida para toda a rede é necessário que seja feita a distribuição das policys. Esta distribuição é feita criando um package de distribuição, .MSI.

Para criar este package devemos clicar com o botão direito em "Runtime Security Policy" e selecionar a opção "Create Deployment Package". O pacote .MSI gerado pode ser executado em qualquer máquina da rede para implantar as configurações de CAS, mas a melhor forma de fazer isso é associar o .MSI a um objeto GPO (Group Policy Object) no Active Directory e o próprio sistema operacional irá reforçar a policy em todos os logons.

Dentro de cada Policy vemos as opções Code Group e Permission Set. Utilizaremos estas duas opções para realizarmos a configuração de permissões para as aplicações.

Os Code Groups representam as aplicações que serão executadas. Por default na Enterprise Policy e na User Policy vemos apenas o Code Group All_Code. Já a machine Policy possui várias sub-divisões em All_Code. Desta forma, as configurações de permissão que atribuirmos para All_Code valerão para todas as aplicações executadas, enquanto que se atribuirmos alguma configuração para algum code Group abaixo de All_Code a configuração valerá apenas para as aplicações deste code Group.

Os Code Groups são montados através de restrições, especialmente com relação aos parâmetros da evidência, que determinam quais assemblys estarão fazendo parte do code Group. Pode observar que por default os code Groups são divididos de acordo com o local de origem dos Assemblys.

Já os permisson Sets são conjuntos de permissões para nos auxiliar na atribuição de permissões para os code Groups. Normalmente vamos desejar atribuir diversas permissões para cada code Group, por isso os permission Sets representam conjuntos das permissões mais básicas no framework.

E o que são essas permissões mais básicas ?

As permissões mais básicas no framework são classes de permissão que são utilizadas no processo de demanda de permissões. As classes do framework, por default, já demandam permissões, então estas permissões mais básicas precisam estar atribuidas a nossa aplicação para que determinadas tarefas sejam realizadas. Assim sendo para cada namespace no framework temos uma classe de permissão que será checada em nossa aplicação. Veja exemplos :

Nas nossas aplicações poderemos criar nossas próprias classes de permissão e fazer com que tais permissões sejam demandadas por nossos componentes. Então, para que nossas permissões possam ser utilizadas nesta ferramenta de configuração do CAS será necessário que nossas classes de permissão sejam instaladas na pasta "policy assemblys".

Entre os permission Sets configurados por default o único que pode ser personalizado é "Everything". Clicando com o botão direito encontramos a opção "Change Permissons". Da lista de permissões que veremos praticamente todas são configuraveis, podemos clicar no botão properties e configurar a permissão.

Por exemplo, a permissão de File IO pode fornecer acesso ilimitado a disco ou acesso restrito a determinado local e determinadas permissões. O mesmo acontece com as demais.

Vamos montar um projeto de exemplo para demonstrarmos os recursos do CAS. Vamos montar uma Windows Application que chamaremos de SmartDados e um ASP.NET WebService que chamaremos de ServidoProdutos

No WebService vamos chamar o arquivo .ASMX de srvProdutos e inserir um DataAdapter e uma Connection. Vamos gerar um DataSet, que chamaremos de DS, e trazer nele os dados da tabela products, do northwind. Veja como fica o webMethod para recuperar os dados :

 <WebMethod()> _
   Public Function ListaProdutos() As DS
              DA.Fill(Ds1)
              Return (Ds1)
   End Function
       

Na aplicação windows, vamos inserir uma datagrid e dois botões. A dataGrid, DG, será utilizada para exibir os dados. 1 dos botões será utilizado para obter os dados do webService, enquanto que o outro será utilizado para gravar as informações no disco local do usuário.

Veja como fica o código dos dois botões :

   Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
         Dim obj As New produtos.srvProdutos
         dados = obj.ListaProdutos
         DG.DataSource = dados.Products
   End Sub

   Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click
          Dim SFD As New System.Windows.Forms.SaveFileDialog
          Dim arq As String
          SFD.Title = "Salvar Dados"
          If SFD.ShowDialog = DialogResult.OK Then
              arq = SFD.FileName
              dados.WriteXml(arq)
          End If
   End Sub
       

Para testar as funcionalidades do CAS vamos distribuir esses dois projetos em máquinas diferentes. Vamos publicar o webService em um servidor web, que aqui identificaremos pelo IP, 192.168.1.200, e vamos disponibilizar a aplicação Windows em outro servidor web, também identificado pelo IP, 192.168.0.1.

Vamos acessar a aplicação windows na forma de Smart Client, acessando através de uma chamada HTTP. Acessaremos então, via browser, o endereço http://192.168.0.1/SmartDados.exe . Desta forma poderemos observar o impacto do CAS : O Windows form, rodando na forma de smart client, será identificado como uma aplicação vinda da intranet local e portanto o CAS aplicará a policy LocalIntranet.

O efeito disso é que apesar de ter permissão para executar, a aplicação não tem permissão nem para acessar o serviço nem para fazer gravação no disco local. Por isso ao clicar em qualquer dos dois botões veremos mensagens de erro informando a falta de permissão para executar essas tarefas.

As mensagens de erro não tratadas são muito desagradáveis. Podemos fazer pequenos ajustes na aplicação para tratarmos isso. Podemos considerar que para a execução as permissões mínimas que a aplicação precisa são as permissões para o acesso ao webService. A permissão de acesso a arquivos pode ser considerada como um adicional. Então se existir a aplicação permite a gravação, se não existir, não permite.

Então o primeiro passo é configurarmos a aplicação para que a aplicação exija o acesso a web como permissão mínima para seu funcionamento. Vamos inserir a seguinte instrução dentro do AssemblyInfo :

<Assembly: System.Net.WebPermission(Security.Permissions.SecurityAction.RequestMinimum, unrestricted:=True)> 

Desta forma estamos determinando que nosso assembly precisa, no mínimo, da permissão de acesso a web (com direitos irrestritos) para funcionar.

Ao testar a aplicação novamente ao invés de ser executada e falhar quando ocorrer o clique do botão a aplicação não será executada, já avisando de imediato sobre o problema de permissões.

O próximo passo é configurarmos as permissões para a aplicação. Para fazermos isso devemos utilizar a interface de configuração do .NET framework que pode ser encontrada no painel de controle.

Vimos logo acima as definições de permissionSets e CodeGroups, então fica mais fácil entender o que precisamos fazer :

1) Vamos criar um novo permissionSet chamado PermissoesIntranet . Nesse permissionSet vamos adicionar webPermission com fullControl.

2) Vamos criar um novo code Group abaixo da local intranet. Iremos identificar o novo code Group com base no site de origem, 192.168.0.1 e iremos ligar a este code Group o permissionSet permissoesIntranet

Pronto. Ao rodarmos novamente a aplicação esta já terá as permissões de acesso a web necessárias para poder ser executada sem problemas.

Agora temos que controlar a necessidade da permissão de acesso a dadas. Podemos testar, via código, se a permissão de acesso a dados existe ou não. Se não existe, não permitimos que o usuário tenha acesso a essas funcionalidades. Podemos fazer isso no form_load, veja como fica o código :

 Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
       Dim p As New System.Security.Permissions.FileIOPermission(Security.Permissions.PermissionState.Unrestricted)
       Try
            p.Demand()
       Catch ex As Exception
            Button2.Enabled = False
       End Try
 End Sub

O método Demand, existente em objetos permission, faz com que seja feito um teste em todo o callStack para ver se essa permissão está atribuida para a aplicação. Em caso de falha, desabilitamos o botão.

Esse é apenas o começo. A CAS - Code Access Security - fornece inúmeras possibilidades a serem exploradas.

Dennes Torres
MCAD,MCSD,MCSE,MCDBA
Blog: http://br.thespoke.net/myblog/dennes/myblog.aspx

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Conheça mais sobre o nosso site :

• Visite nossa área de artigos técnicos
• Conheça nossas dicas técnicas (mais de 300 dicas)
• Conheça nosso fórum de discussões
• Conheça nossa área de download com muitos componentes e códigos úteis
• Conheça nosso treinamento de lógica de programação on-line
• Conheça nossa prova de certificação em VB (oferecemos certificado aos aprovados)

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::