Hablando de Code Access Security (CAS)
Estaba hablándole a mi hermano acerca del modelo de seguridad CAS, y pos decidí que tal vez sería lo mejor escribirlo, y postearlo para todos. Luego de explicar, empecé...
Cuando corremos alguna aplicación no administrada este toma los permisos de la cuenta de usuario actual (mediante Role-Based Security, RBS), es así que, para ser más específicos, el código no administrado tomará todos los privilegios de la cuenta de usuario actual. ¿Qué pasa si su cuenta tiene los permisos de adminitrador?, entonces cualquiera malware tomará los derechos de dicha cuenta para hacer lo que quiera con su PC. Antes de seguir debe quedar claro que mediante RBS controlar permisos para cuentas de usuarios, y con CAS para asemblies.
Para tratar este problema y controlar permisos de nuestro código, tenemos a la mano un mecanismo de seguridad para aplicaciones .Net. Esto es, Code Access security (CAS), CAS habilita a los usuarios a restringir de manera muy granular lo que el código administrado podrá hacer, es decir, se puede controlar los permisos individuales para cada aplicación hecha en .NET. Una imagen valen más que mil palabras, así que dejo una imagen que ayudará a entender mejor hasta este punto.
CAS es un sistema de seguridad que permite a los administradores y desarrolladores controlar la autorización de una aplicación, como por ejmplo, permitir a una aplicación que escriba y lea el registro del sistema con un nivel de acceso restringido, como también, no permitir a que una aplicación envie un documento para su impresión. También podemos restringir recursos que no se puede controlar usando RBS, como por ejemplo, restringir si es que una aplicación puede hacer solicitudes DNS o de páginas web. Todos estos permisos lo podemos controlar en varios niveles (mediante Security Policy, manejando niveles Enterprise, Machine, User, Application Domain). Entendido?, espero que si...
Ahora bien, todo sistema de seguridad necesita identificar a los usuarios y determinar qué es lo que puede hacer y que no puede hacer. Por ejmplo, RSB usa los user names, los passwords, etc, para lograr este objetivo. En contraste, CAS identifica a los assemblies de una manera diferente, esto es, usando Evidence. Evidence es la información que identifica a un assembly, como el hash del código del assembly, la URI del assembly, el directorio de la aplicación, Site de donde se descargó el assembly, Strong Name, entre otros.He aquí una imagen para entender mejor la idea.
Asi como en RBS existen los User Groups que agrupan usuarios, en CAS existen los Code Groups que agrupan assemblies. Code Groups (como Internet_Zone, LocalIntranet_zone, Trusted_Zone, etc) son unidad de autorizacion que asocian assemblies con Permission Sets ( es un CAS ACL, una lista de control de permisos). Cada assembly es agregada a un determinado Code Group de acuerdo al tipo de evidencia del mismo, y cada code group es asociado con un Permission Set. Pero todo esto no es un proceso manual, sino, en base a un code group's membership condition (condición para ser miembro de grupo), esta condición es la que sirve para asociar una assembly a un code group. Ver imagen .
Hasta aquí espero que todo esté claro. Como ya dije más arriba, si deseamos flexibilidad en los niveles de configuración de CAS podemos usar Security Policy (es una agrupación lógica de code group y Permission Sets). Existen 4 nivel de políticas de seguridad, y son:
- Enterprise Policy: Es el más alto nivel de seguridad, y describe políticas de seguridad para una empresa entera. Puede ser configurado usando el servicio Active Directory.
- Machine Policy: Describe políticas de seguridad aplicables a nivel de cada maquina.
- User Policy: Define permisos por cada nivel de usuario.
- Application Domain Policy: Define permisos aplicables para cada dominio de la aplicación.
Usando la herramienta de configuración del .NET Framework podemos configurar 19 permisos, como por ejemplo, File Dialog Permission, DNS Permission, Event Log Permission, Performance Counter Permission, File IO Permission, SQL Client Permission, Printing Permission, etc, etc... Por ejemplo, el File Dialog Permission controla si es que un usuario podra o no, hacer prompt con el Open File Dialog o Save File Dialog, el SQL Client Permission controla el acceso a SQL Server, una de las cosas que podemos configurar es, por ejemplo, que la aplicacion nunca pueda conectarse a SQL Server... y asi sucesivamente para el resto de permisos. También nos permite agregar Code Groups, incrementar el nivel de confianza para un assembly, agregar nuevos conjuntos de permisos (Permission Sets), resetear Security Polities, etc. A nivel de lineas de comandos podemos usar la herramienta Caspol, el cual provee una funcionalidad similar.
Creo que hasta aquí es todo, si deseas algo más, revisa este artículo, del cual saqué las imágenes que muestro arriba, y de las cuales me servir para aclarar ciertas ideas.