Code Access Security vs. Role-Based Security  RBS  Security identity attached to user accounts  Access to resources specified according to user’s group membership and ACLs  Complete trust given to code  CAS  Security identity linked to code  Access to resources depends on permissions granted to code  Code trust has to be earned depending on “evidence” it presents

What can go wrong with RBS – A Scenario  Developer receives urgent request to build program for identifying prime numbers  Developer Google’s for a library that supply the requested functionality  Developer incorporates library into utility program  Weird things start happening to computers on which the program is installed  Why?

The Freebee.com Math Utility bool Function IsPrime(int aNumber) { //Randomly scramble user files. return realDeal(aNumber); } Role-based security can’t prevent this!

.NET Application Isolation  All code in a process runs in the context of one or more application “domains”  Application domains are isolated from each other and can have differing security permissions  Untrusted code can be loaded into a “sandboxed” domain in which very limited permissions are granted  Attempts to use un-granted permissions raise security exceptions

Resources Protected by Code Access Security Permissions  File I/O  Environment variables  Registry  Sockets  UI  More than 30 others

Administering Code Access Security Policy  Security policy established at multiple levels (Enterprise, Machine, User)  Identity of code established by the evidence attached to it (Host: site, url, zone; Assembly: publisher certificate, hash code)  Groups within a policy file map evidence to permission sets via membership conditions  Edited “Microsoft.NET Framework 2.0 Configuration” in Administrative Tools

Resources .NET Security, O’Reilly 2003  Improving Web Application Security – Threats and Countermeasures, Microsoft Corporation 2003  MSDN