.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 TypeDescription
URLThe CODEBASE url in its raw format.
SiteThe hostname of the http or ftp url.
ZoneThe CLR splits the world into five security zones: trusted, untrusted, Internet, intranet and my computer.
Application directoryThe host application must specify the base directory for the running application.
Strong nameAssembly public key.
PublisherX.509 certificate.
HashHash 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., JavaTM, because of CAS’ extensibility, it can be said that CAS is a system for building sandboxes.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: