| 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 an 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 of code 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 that can be granted to code is the union of all the permission sets from the all groups that 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. 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 I/O permissions to just read, the assembly will have unlimited permissions for everything but file I/O, 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 machine, user, and then 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 using its name . More than one code group can be associated with a named permission set. Administrators can define their own named permission sets, but there are several built-in named permission sets: -
Nothing: no permissions (cannot run). -
Execution: permission only 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 that can be unrestricted. Of the built-in named permission sets, only the Everything set can be modified. You can also define your own custom permission sets as well. 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 [12] \Application Data\Microsoft\CLR Security Config\vx.x.xxxx directory . [12] Of course, the actual user name is to be substituted into this path at this point. 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 provides a friendlier, but more limited, interface to changing these policy configuration files. To use this tool, go to the Control Panel and select Administrative Tools. From the Administrative Tools list, select Microsoft .NET Framework Configuration, and then open the Runtime Security Policy node. Figure 16-18 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 16-18. 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 16-18, on the machine level, no new named permission sets have been created; only the default ones are present. If you select the Internet named permission set and in the right pane select view permissions, you can then select any permission and look at its settings. Figure 16-19 shows the settings for UserInterface permission in the Internet named permission set. Figure 16-19. Permissions for UserInterface permission in machine-level Internet named permission set.  Figure 16-20 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 16-20. 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.  Dim filename As String = "..\read.txt" Try Dim fileWithFullPath As String = _ Path.GetFullPath(filename) Dim File As FileInfo = New FileInfo(filename) Dim sr As StreamReader = File.OpenText() Dim text As String Text = sr.ReadLine() While text <> Nothing Console.WriteLine(text) text = sr.ReadLine() End While sr.Close() Catch e As Exception Console.WriteLine(e.Message) End Try Figure 16-21 shows a permission set named TestStrongName and two new code groups named My_Computer_Zone and TestStrongNameGroup that we will be adding at the user policy level to control security policy for the Policy example assembly just described. Figure 16-21. Revised user policy level for the Policy assembly example.  First, we create the new permission set named TestStrongName using the .NET Admin Tool. You create this new permission set by selecting the PermissionSets node below the level where you want to create it (in this case, under User). Then right-click and select New, and fill in the fields as shown in Figure 16-22. Figure 16-22. Initial Create Permission Set dialog.  Clicking the Next button brings up the dialog in Figure 16-23. Use the Add and Remove buttons to define the permissions that you want to be part of this permission set. Figure 16-23. TestStrongName permission set definition.  To define the permission itself, select the permission and click the Properties button and make the appropriate choices. Figure 16-24 shows the dialog that appears for the UserInterface permission. When you are finished adding permissions, you click Finish. Figure 16-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 seen that each code group maps to one piece of evidence. Figure 16-25 is a diagram of the User Code Level with its three groups. Figure 16-25. Diagram of user level policy groups.  Now we want to create two new code groups named My_Computer_Zone and TestStrongNameGroup before we can associate them with the desired permission sets. To do this, right click on the All_Code node under Code Groups, under User, and then select New. Figure 16-26 shows this for the TestStrongNameGroup group. After entering the fields, click Next three times. The group has now been created. You can then follow the same steps for the other group named My_Computer_Zone. The details on establishing the My_Computer_Zone group will be described shortly. Figure 16-26. Membership condition for TestStrongNameGroup.  After you have added the groups, you can modify them by associating each of them with a particular permission set. For example, to modify the TestStrongNameGroup group, right-click on that node in the .NET Admin Tool and select Properties. You can then select the Permission Set tab and choose the TestStrongName permission set from the PermissionSet combo box. Figure 16-27 shows how it is associated with this permission set. Note that there is no FileIOPermission in this permission set. This will become important when we look at the effect of this group membership on the Policy example, since it does attempt to perform I/O. Figure 16-27. Permissions associated with TestStrongNameGroup from TestStrongName permission set.  Figure 16-28 shows how to make the group's membership condition depend on the assembly's strong name. The Import button can be used to browse to Policy.exe , and the strong name of that digitally signed assembly is automatically entered into the Public Key field. Figure 16-28. Making TestStrongNameGroup.  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. We set its permission set to Nothing so that it grants no rights. To find out how an assembly matches the code groups, its evidence is 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 groups. 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, then 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 that 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 successfully, performing I/O. Now, if you modify the TestStrongNameGroup on its General tab to be exclusive, as shown in Figure 16-29, by checking the indicated checkboxes, 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 successfully. Figure 16-29. Making TestStrongNameGroup exclusive.  | 
