Security Policy

for RuBoard

Now that we understand evidence, and how the evidence about an assembly is gathered, we can discuss security policy. Based on the evidence for an assembly, the assembly is assigned to a code group. Associated with each code group is a set of permissions that represent what code associated with that code group can do.

Security Policy Levels

Security policy is set at several levels. The permissions allowed are defined by the intersection of the policy levels. These levels are enterprise, machine, application domain, and user . If there is a conflict between permissions assigned from a particular level, the more restrictive version overrides . So enterprise policy can override all the machines in the enterprise, and machine policy can override all policies for a application domain or a particular user.

Code Groups

The enterprise, machine, and user policy levels are a hierarchy of code groups. Associated with each code group is a set of permissions. Code that meets a specified set of conditions belongs to a particular code group.

The root node is referred to as "All_Code." Below this level is a set of child nodes, and each of these children can have children. Each node represents a code group. If code belongs to a code group, it might be a member of one of its children. If it does not belong to a given code group it cannot belong to any of its children.

By evaluating the evidence you assign code a group. By assignment to a group you get an associated set of permissions. This set of conditions corresponds to a named permission set. Since code can belong to more than one group, the set of permissions which can be granted to code is the union of all the permission sets from the all groups it belongs to.

Therefore code policy is determined in two steps. For each level, the permissions for an assembly are determined by the union of all the permission sets to which it belongs. Each level then effectively has one permission set. Then each of these permission sets is intersected so that the most restrictive of each permission setting is the final value. For example, if the machine level gives all access to an assembly, but the user level restricts the file IO permissions to just read, the assembly will have unlimited permissions for everything but file IO, where it will just have the read permission.

Code groups can have two attributes. The exclusive attribute dictates that code will never be allowed more permissions than associated with the exclusive group. Obviously, code can belong to only one group marked exclusive. The level final attribute indicates that no policy levels below this one are considered when calculating code group membership. The order of levels is enterprise, machine, user, application domain.

Named Permission Sets

A named permission set consists of one or more code access permissions that have a name. An administrator can associate a code group with this permission set by means of this name . More than one code group can be associated with a named permission set. Administrators can define their own named permission sets, but several are built in:

• Nothing: no permissions (cannot run).

• Execution: only permission to run, but no permissions that allow use of protected resources.

• Internet: the default policy permission set suitable for content from unknown origin.

• LocalIntranet: the default policy permission set for within an enterprise.

• Everything: all standard (i.e., built-in) permissions except permission to skip verification.

• FullTrust: full access to all resources protected by permissions.

Of the built-in named permission sets only the Everything set can be modified. You can define custom permission sets.

Altering Security Policy

Security policy is stored in several XML-based configuration files. Machine security configuration is in the security.config file that is stored in the \WINNT\Microsoft.NET\Framework\vx.x.xxxx\CONFIG directory. User security configuration is in the security.config file that is stored in the \Documents and Settings\UserName\Application Data\Microsoft\CLR Security Config\vx.x.xxxx directory.

It is not recommended that you edit these XML files directly. The Code Access Security Policy tool ( caspol .exe ) is a command-line tool that can be used to modify enterprise, machine, and user policy levels.

The .NET Admin Tool introduced in Chapter 7 provides a more friendly interface to changing policy. Figure 12-17 shows the code groups and permission sets defined for the machine and the current user security policy levels as they appear in the left pane in the .NET Admin Tool.

Figure 12-17. Permission sets and groups for machine and user policy.

Let us use this tool to examine the current policies in the machine level. First let us look at the named permission sets. As you can see from Figure 12-18, on the machine level no new named permission sets have been created; only the default ones are present. If you select the Internet permission set and in the right pane select view permissions, you can then select any permission and look at its settings. Figure 12-18 shows the settings for User Interface permission in the Internet named permission set.

Figure 12-18. Permissions for User Interface permission in machine-level Internet named permission set.

Figure 12-19 shows the properties for the Internet Zone code group on the machine policy level. You can see that Zone identity permission is chosen for this group, and the value associated with it is the Internet zone. On the permission set tab, you can view or select the named permission set associated with the Internet zone.

Figure 12-19. Properties dialog for Internet zone, machine policy level.

To illustrate how security policy affects running code we use a slightly modified version of the Evidence example. Besides writing out the associated evidence, the Policy example also prints out the contents of a file.

 string filename = ".\read.txt";  try  {    string fileWithFullPath = Path.GetFullPath(filename);    FileInfo file = new FileInfo(filename);    StreamReader sr = file.OpenText();    string text;    text = sr.ReadLine();    while (text != null)    {      Console.WriteLine(text);      text = sr.ReadLine();    }    sr.Close();  }   catch(Exception e)  {    Console.WriteLine(e.Message);  } 

Figure 12-20 shows the two new code groups and the one permission set we will define at the user policy level to control security policy for this assembly.

Figure 12-20. Revised user policy level for Policy example.

We will define a new permission set called TestStrongName and two new code groups, TestStrongNameGroup and My_Computer_Zone. The new permission set definition is in Figure 12-21.

Figure 12-21. TestStrongName permission set definition.

This new permission set is created by selecting the Permission Sets node below the level in which you want to create it (in this case User). Right-mouse-click and select New. The initial Create Permission Set dialog comes up and can be filled in as in Figure 12-22.

Figure 12-22. Initial Create Permission Set dialog.

Clicking the Next button brings up the dialog in Figure 12-23. Use the Add and Remove buttons to define the permissions you want to include in this permission set.

Figure 12-23. PermissionSet definition dialog.

To define the permission itself, select the permission, click the properties dialog, and make the appropriate choices. Figure 12-24 shows the dialog that appears for the User Interface permission. To modify an existing permission set, select it, right-mouse-click, and select the Change Permissions item. A dialog similar to Figure 12-24 will appear.

Figure 12-24. Permission modification dialog.

Now this permission has to be associated with a code group. How do assemblies get assigned to code groups? We have already explained that each code group maps to one piece of evidence. Figure 12-25 is a diagram of the User Code Level with its three groups.

Figure 12-25. Diagram of user-level policy groups.

Figure 12-26 shows that the TestStrongNameGroup is defined to be the strong name associated with the policy.exe assembly. Figure 12-27 shows the TestStrongName permission set associated with the TestStrongNameGroup. Note that there is no FileIOPermission. This code group was created by selecting the parent group (in this case All_Code) and selecting New from its context menu and filling in the information asked for by the wizard. Dialogs similar to Figures 12-26 and 12-27 will appear.

Figure 12-26. Membership condition for TestStrongNameGroup.

Figure 12-27. Permissions associated with TestStrongNameGroup from TestStrongName permission set.

The My_Computer_Zone group is defined to encompass all code on this computer. It is defined in a similar fashion as the TestStrongNameGroup. The membership condition is Zone, and the MyComputer zone is picked as the associated value. FullTrust is selected for its associated permission set. The All_Code group encompasses all code on the machine. It grants no rights to any code. It already existed by default, and we changed its permission set to Nothing . It grants no rights.

To find out how an assembly matches the code groups, its evidence its compared with the membership conditions for the group. All code that resides on the current machine (as opposed to another machine on the network or the Internet) matches the All_Code and My_Computer_Zone group. Only policy.exe matches the membership condition for the TestStrongNameGroup. The tree is walked from parent to child node; if a parent node does not match, no further navigation down the tree is done. On a given level the rights assigned to the assembly are the union of all the groups that it matches. In this case, even though policy.exe matches a group that does not give it the FileIOPermission, it gets that permission from the My_Computer_Zone group which grants FullTrust to code.

A similar analysis of the enterprise and machine levels reveals that they also grant code from this machine FullTrust. So if you run policy.exe , it will run.

Now modify the TestStrongNameGroup on its General tab to be exclusive, as indicated in Figure 12-28. This will cause any code that belongs to this group to get its rights from only this group. Since policy is determined by the intersection of all the three levels, policy.exe will not have the FileIOPermission. If you try to run it, you will see that it cannot read the file.

Figure 12-28. Making TestStrongNameGroup.

for RuBoard