CoreCLR

Nota: devido à complexidade das definições você vai precisar de algum conhecimento prévio do modelo de segurança CoreCLR ou ler duas vezes para entender o sentido ;-)

Os níveis de segurança

O modelo de segurança CoreCLR divide todo o código em três níveis distintos: transparent, safe-critical e critical. Este modelo é muito mais simples de entender (e aplicar) do que CAS (e.g, sem stack-walk). Com apenas algumas regras podemos descrever grande parte dele.

Transparent

Por padrão todo o código é transparent dentro do modelo CoreCLR

  • O código Transparent é limitado. Especificadamente, não pode chamar diretamente o código critical (e.g. p/ chamar no código não seguro), mas pode chamar o código safe-critical e outros códigos Transparent.

  • Como é padrão, não há necessidade de adicionar um atributo [SecurityTransparent] em todo lugar.

Safe Critical

O código crítico é uma ponte entre o código transparent e o código critical. Como tal representa o código mais arriscado (quanto menos melhor) .

  • Todo código que é interposto entre uma API transparent (segura) e código critical (não necessariamente seguro) deve ser anotado com o atributo [SecuritySafeCritical].

  • O código Safe critical precisa fazer validações extras (pré e/ou pós) entre o transparent e o critical afim de merecer o prefixo safe(seguro).

Critical

O código crítico pode fazer qualquer coisa, como chamar um código nativo e ter acesso a tudo fora do da caixa de areia (sandbox). O plugin em si (no caso do Silverlight) não conseguiria funcionar sem ter código crítico. No entanto as aplicações podem (e devem) funcionar ser ter acesso direto a esse tipo de código.

  • O código crítico, incluindo cada API visível que faz coisas que o código do aplicativo não deve fazer (e.g, acesso a arquivos), devem ser marcados com um atributo [SecurityCritical].

  • Todo código unsafe e declarações p/invoke são critical (mas ainda assim precisam ser marcados como tal).

Categorias dos Códigos

Para tornar isso ainda mais fácil de entender, de um ponto de vista do aplicativo do desenvolvedor, todos os assemblies são divididos em duas categorias: o código da aplicação (ou usuário) e o código da plataforma.

Código da Aplicação

O código da aplicação é executado com confiança limitada. Isso torna possível, juntamente com outros recursos, executar com segurança código não confiável dentro do seu navegador. O código do aplicativo funciona com seguintes regras:

  • Todo o código da aplicação é transparent. Usando atributos para (tentar) mudar isso irá compilar mas será ignorado em tempo de execução.

  • Como transparent ele pode chamar outro código da aplicação (todo transparent) e o código da plataforma que é transparent (padrão) ou anotado com o atributo [ SecuritySafeCritical ].

  • O código da aplicação não pode chamar diretamente métodos/tipos decorados com [SecurityCritical].

Código da Plataforma

Código da plataforma é um subconjunto do código gerenciado fornecido com o plugin. Este código é totalmente confiável. Como tal, não pode expor toda a sua API para o código da aplicação, em vez disso, pode expor seus métodos/tipos usando três níveis de segurança diferentes (veja a próxima seção).

  • O código de plataforma, por padrão, é transparent. Isto significa que a maior parte dele pode ser chamado diretamente do código do aplicativo.

  • O código de plataforma contém código critical - i.e. o código que pode fazer qualquer coisa (como chamar código inseguro). Esse código é implementado com atributos [SecurityCritical] e não pode ser chamado do código da aplicação.

  • Acesso do código transparent para o código critical (e.g. usando a segura, e transparent, implementação de IsolatedStorage que por sua vez código critical da System.IO) é possível através de código implementado com o atributo [SecuritySafeCritical].

A lista de assemblies que constam do Código de Plataforma inclui:

  • mscorlib
  • Microsoft.VisualBasic [1][2]
  • System
  • System.Core
  • System.Net
  • System.Runtime.Serialization
  • System.ServiceModel [1][2]
  • System.ServiceModel.Web [1]
  • System.Windows
  • System.Windows.Browser
  • System.Xml

[1] não contém qualquer atributo [SecurityCritical] ou [SecuritySafeCritical] [2] tem uma chave pública diferente do que em outros assemblies.

Ambos [1] e [2] podem ser considerados códigos de plataforma - mas como eles não fazem uso do [SecurityCritical] e nem do [SecuritySafeCritical], eles são efetivamente código totalmente transparent (como o código da aplicação).

Onde? No Windows/Silverlight 2 os arquivos da plataforma podem ser encontrados em:

  • C:\Program Files\Microsoft Silverlight\2.0.31005.0
  • C:\Program Files\Microsoft SDKs\Silverlight\v2.0\Reference Assemblies

O último só existe se você tiver o Silverlight 2 SDK instalado.

Lembrete para o Desenvolvedor de Aplicações

Apenas lembre-se: sob a CoreCLR uma aplicação pode chamar qualquer coisa (i.e. transparent ou safe-critical), desde que não seja critical.

Considerações Especiais

[InternalsVisibleTo]

São necessários cuidados especiais com código interno já que a maioria das montagens de plataforma inclui atributos [InternalsVisibleTo ] - e sim, os “internos” estão abertos para algumas montagens não-de-plataforma (i.e. o código da aplicação).

Introspecção (Reflection)

A instrospecção é possível, mas tem algumas limitações.

Reflection.Emit

Geração de código é possível (e.g. DLR), mas também tem algumas limitações

Políticas

O modelo de segurança CoreCLR não lida com políticas - suas decisões são verdadeiras ou falsas, PODE ou NÃO PODE. Enquanto isso funciona para a maioria das peças básicas não resolve os casos em que são necessárias regras de acesso mais elaboradas, como por exemplo:

  • Políticas de downloads.
  • Políticas de soquetes.

É necessário (fora do escopo do CoreCLR) ter um cuidado especial para protege-los.

Detalhes da Implementação

Compatibilidade entre Atributos de Segurança

Chamadas do código da aplicação para código de plataforma (fornecido pelo Moonlight) ou funcionam (e.g. chamando o código transparent ou o código [SecuritySafeCritical]) ou falham (e.g. chamando o código [SecurityCritical])

Como não há distinção entre chamar o código *transparent** ou safe critical os usos do atributo [SecuritySafeCritical] no Moonlight não precisam corresponder a implementação Silverlight. No entanto temos de ‘casar’ o uso visível do atributo [SecurityCritical] na API pública ou protegida.

Referências