O Code Acess Security (CAS) é a "entidade" do .NET responsável por gerenciar as permissões que um assembly possui durante sua execução. Repare que não estamos falando de permissões de usuário...

Podemos pensar nisso como uma camada de segurança a mais entre o usuário e o sistema operacional. Ou seja, antes mesmo de verificar as permissões que um usuário possui no computador, o CAS verifica as permissões que estão relacionadas ao assembly .NET, para somente então repassar a chamada para o sistema operacional. Somente então é o sistema operacional irá verificar o permissionamento do usuário.

Até a versão 4.0, o CAS trabalhava baseado no conceito de Políticas, isto é, dado um determinado conjunto de condições (que era satisfeito pelas Evidências), era localizada a política de segurança para aquele assembly. Desta forma, o CAS sabia qual era o PermissionSet (Conjunto de permissões) que determinava o que poderia ser feito pelo assembly ou não.

As permissões controladas pelo CAS abrangem desde permitir ou não a execução de um programa .NET, até as permissões para outras tarefas como executar código unsafe, reflection, acessar o sistema de arquivos, exibir UI e etc... Existe a mesmo a permissão de "bypassar" o CAS..

Todos os programas em .NET estão sujeitos ao CAS, mas é engraçado que mesmo assim a grande das pessoas que trabalham com .NET nunca se deparou com ele. E é fácil entender porque. Nas políticas default do .NET, todo código que rodava localmente possuia a permissão FullTrust.  Já o código que rodasse via intranet/internet, possuía menos permissões. Só que esse caso era de certa forma raro, pois se os arquivos estivessem no mesmo computador que o servidor web, mesmo no caso de aplicações ASP.NET, o CAS entendia que os assemblies estavam locais (e de fato estavam) e concedia FullTrust.

CAS começava a apitar quando aplicações que estavam em um outro computador da rede fossem executadas, ou por exemplo no uso de NAS...

...e como quem não é visto não é lembrado, o CAS passava batido. Até, para o espanto de todos, algumas empresas de hospedagem não conheciam o CAS e deixavam as permissões default. Dessa forma uma aplicação .NET poderia até mesmo atrapalhar a saúde do servidor, tá louco...

Mas tudo mudou no .NET 4.0. O CAS não morreu, mas foi repaginado. Quem morreu foram as políticas. Alguém percebeu que isso era completamente inútil. A idéia era até boa, imagine, rodar um programa direto da internet (alguém corajoso o suficiente pra isso) e ele seria executado com permissões restritas. Assim ele não poderia fazer dano ao meu computador. Mas um atacante podia também apagar o executável .NET, colocar outro programa não gerenciado e quando o corajoso fosse executar o seu programa, bingo. Infectado..

Falsa segurança é a pior forma de insegurança.

Agora, ao invés do CLR controlar as políticas, ele deixa isso a cargo de cada HOST. Ou seja, o IIS controla as permissões de suas aplicações ASP.NET uma-a-uma, um programa .NET que decidir carregar outra assembly para o seu AppDomain decide as permissões vigentes para o app domain e assim por diante.

O default continua FullTrust pra todo mundo. Mas para configurar as permissões da sua aplicação, não é mais necessário usar dúzias de comandos em um prompt. Com o modelo da Transparência, tudo ficou mais simples. Mas isso fica pra próxima conversa.