NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

Analyzing the security settings that apply to an assembly

When an assembly does not seem to run properly it may very well be that it has not been granted sufficient permissions to execute in the way envisioned by the author of the assembly. It is possible to use CASPol to localize problems with an assembly in respect to the policy system. CASPol offers two analysis features: showing the code groups that apply to a particular assembly and showing the permissions that apply to a particular assembly.

Showing the code groups that apply to a particular assembly

Sometimes unintended security settings apply to an assembly because it does (or does not) belong to some unconsidered code group. Such side effects may occur when code groups are added or deleted. In order to make it easier to find such problems in the user and machine code group hierarchy CASPol implements a feature that lists all the code groups an assembly belongs to. The syntax is as follows:

Caspol –resolvegroup assembly-file

Assembly-file is simply the name of the managed code that should be tested for code group membership. The example below shows how you can find the code groups that CASPol itself belongs to (CASPol is itself a managed application)

Caspol –resolvegroup caspol.exe

As all other CASPol options the –resolvegroup option will apply to the default policy level , unless it is explicitly specified whether just the code group matches at the machine policy level (-machine), user policy level (-user) or both (-all) should be shown. In the example below, the code group matches for CASPol at the user policy level are shown.

Caspol –user –resolvegroup caspol.exe 

The below example shows the code group matches for CASPol at both the machine and user policy levels:

Caspol –all –resolvegroup caspol.exe

Showing the permission set that applies to an assembly

Code gets granted a set of permissions based on evidence about the code. Each policy levels grants a set of permissions to code. The effective permission set that the security policy grants to code is determined as the intersection between the permission sets granted by the machine and user policy. CASPol can be used to view the permission set that an assembly would be granted by a particular policy level, CASPol can also be used to view the permission set that results from intersecting the permission set granted by the machine policy to code with the permission set granted by the user policy to code. To show the permission set for a particular assembly the following syntax is used:

Caspol –resolveperm assembly-file

So for instance to show the permissions that apply to CASPol at the user policy level, the following command should be used:

Caspol –user –resolveperm caspol.exe

To show the permission set that is granted to CASPol by the overall (machine and user) policy, simply type:

Caspol –all –resolveperm caspol.exe

Common security policy problems with an assembly and how to fix them

How to analyze problems with an assembly that does not run

There are a wide variety of reasons why an assembly may not run. It may be the case that it does not have sufficient permissions to run properly. In order to find that out, one should first determine what permissions policy grants that assembly:

Caspol –all –resolveperm assembly_file 

The above command can be used to find out the permissions granted to the assembly by the policy system. Check whether the assembly has the right to execute by checking whether the execution flag is set in the SecurityPermission. Furthermore, if the assembly needs to access a protected resource (such as disk access, create windows, write into the registry etc) one should check whether the appropriate permissions are set.

If it turns out that insufficient permissions are set for that assembly, one should check the permissions granted at the machine policy to the assembly and the permissions granted from the user policy level using

caspol –machine –resolveperm assembly-file 

and

caspol –user –resolveperm assembly-file

Note: since the permissions granted from the machine and user policy are intersected, a permission must be set at both levels in order for an assembly to receive it.

If some permissions were insufficient one can try to introduce a new code group using ‘–addgroup’ that grants the assembly the permissions needed. It may also be the case that the assembly should have been covered by a code group whose membership condition is too restrictive, or whose associated permission set does not contain the permissions needed for the assembly to function. To find out which code groups the assembly belongs to type

Caspol –all –resolvegroups assembly-file

One can then attempt to modify either the associated permission set or the membership condition of code groups so that the assembly has the appropriate permissions granted to it. Such modification is done using the ‘–chggroup’ option.

Analyzing an assembly that accesses protected resources or is not supposed to run

If an assembly runs, but it should not, or if an assembly accesses resources (such as creating dialogue windows) but it shouldn’t, then the assembly has probably been granted too many permissions. As in the case above, using ‘–resolveperm’ one should find out what permissions the assembly is granted. Then, using ‘–resolvegroups’ one can find out what code groups it belongs to and change either the membership conditions or associated permission sets of the code groups the assembly belongs to in order to limit the permissions it is granted.