CAS tem sido notoriamente difícil de usar corretamente. Para os desenvolvedores, existe pouco ou nenhum feedback para avisá-los quando eles aplicam mal os atributos de um bloco de código. Para os administradores, a situação é ainda pior. Políticas CAS para cada permissão devem ser configuradas manualmente, mas os aplicativos raramente listam as permissões que eles precisam. Pior ainda, as políticas CAS devem ser recriadas para cada versão do .NET.
Na prática o CAS revelou-se mais sobre o teatro de segurança do que de segurança. Executáveis por padrão em um compartilhamento de arquivo tinham permissões diferentes de executáveis que foram copiados a partir do compartilhamento de arquivos para o disco local. E se o executável não for gerenciado em seguida, o CAS não se aplicaria a todos.
Com o .NET 4.0, as políticas globais CAS serão desativadas por padrão. Os administradores de sistema são incentivados a utilizar meios mais eficazes, tais como políticas de restrição de software do Windows em vez disso. Se o CAS for realmente necessário, ele pode ser ativado por uma aplicação com base no arquivo app.config definindo a flag runtime/NetFx40_LegacySecurityPolicyenabled como "True".
Códigos que são executados normalmente, terão por padrão confiança total. As permissões são concedidas no nível do domínio de aplicação, acabando com a política de mistura de níveis de segurança dentro de um domínio único aplicativo. O efeito real desta situação é chamar o Assembly.LoadFrom com uma URL que irá agora conceder confiança completa a esse assembly.
Quando o código gerenciado está hospedado, será executado em uma sandbox com as permissões especificadas do Host. Exemplos disto incluem conjuntos gerenciados executando dentro SQLCLR e aplicações ClickOnce, instaladas a partir da Internet. Em um domínio do aplicativo no modo seguro, cada conjunto é executado com confiança, quer parcial ou total. Os complexos sistemas de stack-walking e demandas de link não existem mais.
Sob o novo modelo, quando o domínio de aplicação é criado, a lista de subsídios explícitos para conjuntos parcialmente confiáveis deve ser especificada. Ao mesmo tempo, uma lista de conjuntos, que serão concedidos com confiança total, pode ser inclusa.
Na verdade, existem três níveis que o código pode cair. O mais alto nível "Crítico" é código totalmente confiável que pode fazer qualquer coisa. Código no nível mais baixo, "Transparente", não pode chamar diretamente funcionalidades marcadas como críticas. Atuando como uma ponte o código marcada como "Safe Critical" atua como uma ponte entre os dois. Códigos transparentes e críticos são fáceis de raciocinar, código Transparente é fortemente limitado pela área de segurança e código de critico é totalmente aberto. O único código que realmente tem que se preocupar é o Safe Critical, que deve ser raro e muito atentamente examinado. Muito parecido com o código de gateway entre o kernel e o espaço do usuário, um erro no Safe Critical pode ser terrível.
Se tudo isto soa familiar, deve ser. Este modelo, conhecido como Nível 2 de Transparência de Segurança, foi comprovado com a plataforma Silverlight. Você pode aprender mais sobre o Nível 2 de Transparência de Segurança no MSDN.