.NET Code Access Security

Code Access Security is a CLR security system that is independent of the host system. It bases its security upon code and where the code comes from. Not who is running the code. So, privileges are given to code not users.

It begins with what is called host evidence. When the CLR loader loads an assembly, it gathers evidence about the code’s origin. A security policy takes evidence as input and produces a permission set as output. A permission set is just a collection of permissions.

There are 7 types of host evidence. Four evidence regarding where the code came from. Two evidence regarding who wrote the code. One evidence which is a hash of the assembly.

Evidence Type	Description
URL	The CODEBASE url in its raw format.
Site	The hostname of the http or ftp url.
Zone	The CLR splits the world into five security zones: trusted, untrusted, Internet, intranet and my computer.
Application directory	The host application must specify the base directory for the running application.
Strong name	Assembly public key.
Publisher	X.509 certificate.
Hash	Hash of assembly to identify a particular build of an assembly.

There are four levels of security policy. User level is specific to an individual user. Machine level applies to all users on a specific machine. Enterprise level applies to the machines part of an active directory installation. AppDomain level is specific to a particular application running in an app domain.

All but the AppDomain level can be configured by editing raw configuration files. security.config and enterprisesec.config in CONFIG sub directory for specific .NET install directory.

By combining the four policy levels we get the policy hierarchy. Each policy level grants a permission set. So, the resulting permission set is the set of permission common to all policy levels.

The policy hierarchy and the resulting permission set in green:

By default, full trust permissions are given by the user, enterprise and AppDomain policy levels, regardless of presented evidence. The machine policy level however grants only full trust permission to code loaded from MyComputer security zone that carry the Microsoft or ECMA public keys.

Each policy level has three parts. 1) a list of permission sets. 2) a code group hierarchy. 3) a list of full trust assemblies.

A code group is used to determine which permission sets to give which presented evidence. In order to allow more than one permission set to be applied to an assembly, code groups are laid out hierarchical: with the possibility of child code groups. If a parent node membership conditions are not met, none of the child nodes are considered.

Full trust assemblies are a list of assemblies that would typically contain custom code needed to enforce security (i.e., custom permissions).

Until there is a need for enforcing security, the security policy usually lays dormant. One enforces security by demanding that all callers have been granted some permission.

Contrary to security sandbox in i.e., Java^TM, because of CAS’ extensibility, it can be said that CAS is a system for building sandboxes.