The NGWS runtime includes an extensible code access security (CAS) model. The goal of code access security (CAS) is to prevent code from accessing protected resources it has no right to access (such as undesired access to files or the registry). In order to satisfy this goal the CAS policy system grants code specific amounts of trust based on evidence about the code. A CAS policy is expressed as a tree-hierarchy of code groups (see diagram below). Each code group is defined by one and only one membership condition as well as an associated permission set. A membership condition ascertains whether some piece of code has the necessary credentials (evidence) to belong to the respective code group. We support the following types of standard membership conditions: Zone, Site, Strong name, Publisher, URL, Hash value, Skip Verification, code’s application directory and the all code membership condition (see NGWS Runtime Security Policy specification). For instance, in the diagram below the leftmost code group in the bottom row has the membership condition that code should possess the strong name MS.office.
Each code group has a named set of permissions associated with it. A named permission set contains at least one permission and a name and description for the permission set. Each permission expresses a specific amount of trust to access a particular protected resource. We support permissions for FileIO, UI access, registry access, Reflection, File Dialogue access, Isolated Storage, Security related settings, and access to environment variables (see permissions specification). We also allow developers to define their own permissions. A named permission set therefore represents an expression of trust to access some protected resources. In the example below the code group defined by the site evidence ‘localweb’ has the ‘MyPermissions’ permission set associated with it. This means that all code to which this code group applies will get trust to read and write to c:\temp and do registry operations.
As mentioned before, code groups are hierarchically arranged allowing for ever-decreasing sub-divisions among code groups. For instance, in the code group hierarchy diagram above the code group defined by the membership condition Zone:intranet, has the child code groups defined by Site:localweb and publisher:corpadmin. Each of these code groups has a named permission set associated with it. This means that a piece of code that comes from the intranet zone will get the permissions granted that are part of the permission set associated with the intranet zone code group. If that same piece of code also comes from the site local web, then it also gets the permissions that are part of the permission set associated with the site:localweb code group. In general, if code belongs to more than one code group, all permissions that are part of the permission sets of the code groups the code belongs to, are unioned together. This yields the effective permissions granted to code.
There are currently two tiers of policy we support - the machine policy and the user policy. The machine policy is the code group hierarchy that applies to the whole machine and it is typically set by the machine admin. A user policy is a code group hierarchy that represents the per-user security settings, it may be modified by the user. The overall policy applying to a specific piece of code is determined by the policy at each of the two tiers. The permissions granted to code by the machine policy setting are intersected with the permissions granted by the user level policy settings. This means that the machine policy represents a “high water mark” for the user policy. For instance, suppose the machine policy for some code only grants code read access to c:\temp but the user level policy grants both read and write access to that directory. In this case the effective permissions the code receives is just read access to c:\temp, which represents the intersection between the permissions granted by machine and user level policy.
For more in-depth information concerning the policy system, please refer to the NGWS Runtime Security Policy specification.
In the following section it will be shown how code access security gets administered using the CASPol tool.