Code Groups

for RuBoard

Now that we have covered membership conditions, it is logical to consider how they are used in the bigger picture. This is where code groups come into play. Code groups roughly define bindings between membership conditions and permission sets. If code matches the membership condition in a code group , it is granted a permission set.

From a high-level point of view, code groups are more than a binding between membership conditions and permission sets. They represent the intention of how much trust to grant code. For example, you may want to allow code loaded from your company's Web site to have full use of the network, but not code loaded from any other Web site. Different code groups can be constructed to express these intentions.

To understand code groups in depth, it is necessary to cover the following issues:

  • Code groups are constructed from a membership condition and a policy statement.

  • Code groups were designed to be placed into hierarchies.

  • There are several different types of code groups provided by the .NET Framework.

  • As with membership conditions, code groups are extensible security objects.

Code Group Construction

The base code group class, System.Security.Policy.CodeGroup , has one constructor. Its two arguments are a membership condition and a PolicyStatement . The membership condition argument can be either one of the default membership conditions covered earlier or a custom membership condition. The PolicyStatement is really just a dressed up PermissionSet object. It either contains a PermissionSet alone or a PermissionSet with a PolicyStatementAttribute . The attribute is one of the following values:

  • All

  • Exclusive

  • LevelFinal

  • Nothing

The meaning of the Exclusive and LevelFinal attributes will be covered later in the chapter. All means Exclusive and LevelFinal , and Nothing means neither Exclusive nor LevelFinal .

Some code group classes derived from the CodeGroup class have slightly different constructors. However, they all either have to determine the membership condition and permission set by values from the constructor or from hard-coded values in the code group itself. Also, they all need to deal with PolicyStatementAttribute s in some fashion.

Code Group Hierarchies

Code groups were meant to be made into hierarchies. The reason for this is to allow complex intentions to be expressed by .NET Framework users. If a user only wants to grant certain rights to code from sites in the trusted IE security zone, he or she could create the code group hierarchy illustrated in Figure 8.1. In this example, MyPermissionSet is some user-defined permission set.

Figure 8.1. Example code group hierarchy.

graphics/08fig01.gif

To see what permissions an assembly should be granted from a code group hierarchy, the Common Language Runtime will call Resolve on the root code group object. Note that the root of the example hierarchy in Figure 8.1 matches all code and has an empty permission set. Code from a site in the trusted zone, though, will be granted the permissions in MyPermissionSet . Similarly, code loaded from the local computer will only have the right to execute. This occurs because the root code group will see if the assembly matches any of its children. If it does match a child code group, the child's permission set is added to the parent by unioning it (by calling PermissionSet.Union ). This process continues until no more children code groups match.

Code group hierarchies are where the PolicyStatementAttribute Exclusive comes into play. If a code group has this attribute, any assembly matching the code group should not be evaluated by any other code groups in the hierarchy. The assembly should only be granted the permissions from the exclusive code group. No unions are performed from the different permission sets of matching code group. Figure 8.2 shows an example of this. If a .NET Framework user is browsing to an Internet site that tries to load assembly A from www.goodsite.com and assembly B from www.badsite.com , the following will happen:

  • Assembly A will match the code groups All_Code and Internet_Zone . The resulting permission grant will contain the union of the permission sets Execution and Internet .

  • Assembly B will match the code groups All_Code and Bad_Site . Because the Bad_Site code group is exclusive, the resulting permission grant will only contain the Nothing set. That will prevent the assembly from even loading. If the Bad_Site code group did not have the Exclusive flag, the resulting permission grant would have contained the ability to execute because the All_Code group grants that permission.

Figure 8.2. Example of an exclusive code group in a code group hierarchy.

graphics/08fig02.gif

NOTE

If some assembly matches two different code groups in the same hierarchy that both have the Exclusive flag set, this is considered an error. The Common Language Runtime will throw a System.Security.Policy.PolicyException while trying to load the assembly. The default security policy doesn't ship with any exclusive code groups, so this error condition can only occur via a user or administrator's change to policy.


Code Groups Provided by the .NET Framework

There are a handful of code group classes provided by the .NET Framework. Each one is designed with slightly different semantics for what permission sets are granted or how to deal with child code groups. Table 8.2 lists all of these classes with some details.

Table 8.2. Full List of Default Code Groups Provided by the .NET Framework
Code Group Class Description
CodeGroup This is the abstract, base class that the rest of the code group classes use. Because it is abstract, no code group objects can be instantiated with this type.
UnionCodeGroup This is the "standard" code group used in the .NET Framework. It is constructed from a membership condition and a policy statement. If the membership condition matches an assembly's evidence, it grants that assembly the permission set that is part of the original policy statement. It will union the permission sets of all matching child code groups when determining the permission set grant.
FileCodeGroup The constructor for this code group has a membership condition and a FileIOPermissionAccess value. If the membership condition matches an assembly's evidence, it grants that assembly file access to the assembly's directory of origin. For example, if an assembly is loaded from the directory \\FileServer\Share\Application , a FileCodeGroup will grant that assembly the ability to access files in the directory \\FileServer\Share\Application and all its subdirectories. The type of file access is determined by the FileIOPermissionAccess value. It merges permission sets from matching child code groups in the same manner as the UnionCodeGroup .
FirstMatchCodeGroup This code group is constructed from a membership condition and a policy statement. If the membership condition matches an assembly's evidence, it grants that assembly the permission set that is part of the original policy statement. It will not union the granted permission sets of all child code groups to determine the assembly's permission set grant. Instead, it will only union the permission set of the first matching child code group with its own.
NetCodeGroup The NetCodeGroup 's constructor only takes a membership condition. If the membership condition matches an assembly's evidence, it examines the assembly's evidence to find a piece of Url evidence. If Url evidence is found, the code group grants the assembly a WebPermission that allows network access to the assembly's site of origin using the same network protocol except for http, which allows connecting back to the server via http or https . For example, if an assembly is loaded from http://www.microsoft.com/application/assembly.dll , a NetCodeGroup will grant the assembly the ability to access www.microsoft.com using only the http or https protocol. If the same assembly were loaded from ftp://ftp.microsoft.com/application/assembly.dll , it could only connect to ftp.microsoft.com using the ftp protocol. This code group merges permission sets from matching child code groups in the same manner as the UnionCodeGroup .

NOTE

The .NET Framework security administration tools only fully support the UnionCodeGroup class to create new code groups not in the default security policy. To utilize the other types of code groups, you must construct security policies programmatically, modify the security policy files manually, or deal with raw XML text in the UI administration tool. Default policy files are covered later in this chapter in the section "Working with Policy Levels", and policy administration tools are covered in Chapter 18, "Administering Security Policy Using the .Net Framework Configuration Tool," and Chapter 19, "Administering .NET Framework Security Policy Using Scripts and Security APIs."


Code Group Extensibility

Unlike membership conditions, creating a new type of code group does not require implementing a set of interfaces. Instead, a developer needs to extend the abstract class System.Security.Policy.CodeGroup . The following list of methods and properties must be overridden:

  • Copy ” This method makes a deep copy of a given code group. This means that any children of the target code group should be copied , in addition to any other objects being held by the code group.

  • Resolve ” This is the primary method that the .NET Framework will use when calling the code group. It will get called to determine the granted permissions of every loaded assembly. Its argument is an Evidence object, and its return value is a policy statement. The expected work a code group should perform begins by determining whether the evidence matches it. Presumably, this is done by calling Check on a membership condition passed in the constructor or created by the code group. If the assembly's evidence matches, the code group must construct a permission set to return. That permission set is combined with an optional PolicyStatementAttribute to form the PolicyStatement to return.

  • ResolveMatchingCodeGroups ” This method is used by the .NET Framework to help administrators see which code groups apply to an assembly. See the -resolvegroup option of the tool caspol .exe for an example of how this method is utilized. Its argument is an Evidence object, and it returns a CodeGroup object. This method should work similar to the first half of a Resolve call. If the evidence matches the code group's membership condition, check which child code groups apply. The returned CodeGroup object should include any matching children.

  • AttributeString ” This property returns a string representation of the PolicyStatementAttribute applied to that code group. For example, a code group with the flag PolicyStatementAttribute.Exclusive would return the AttributeString Exclusive . If a code group doesn't use a PolicyStatementAttribute , it should return null .

  • MergeLogic ” This property returns a string representation of the logic used to merge PolicyStatement s of matching child code groups. UnionCodeGroup , FileCodeGroup , and NetCodeGroup return Union . FirstMatchCodeGroup returns First Match . No convention exists for naming merge logic that doesn't follow either of these techniques, although most code group implementers will probably want to follow Union logic.

  • PermissionSetName ” If a code group takes a PolicyStatement or PermissionSet in its constructor, this property returns the name of the permission set (if it has one). If the permission set has no name , it returns a null reference. For code groups that return dynamically computed permission sets (for example, the NetCodeGroup ), a description of the permission set is acceptable.

If a code group is constructed from objects other than a membership condition and a PolicyStatement , all of the following methods need to be overridden. Otherwise, none of them need to be overridden.

  • CreateXml ” This method serves the same purpose as ToXml for membership conditions. However, because ToXml cannot be overridden, this method can be. The CodeGroup implementation of ToXml will call CreateXml .

  • Equals Equals should be overridden so that the .NET Framework understands how to check for equality of two different code group objects of the same type.

  • GetHashCode ” If Equals needs to be overridden, so does GetHashCode . GetHashCode is used to add code groups to data structures like hash tables. If two different code groups return the same hash code, it makes those data structures less efficient.

  • ParseXml ” This method is equivalent to FromXml . However, FromXml cannot be overridden, so classes derived from CodeGroup can only override this method. CodeGroup 's implementation of FromXml will call ParseXml .

for RuBoard


. NET Framework Security
.NET Framework Security
ISBN: 067232184X
EAN: 2147483647
Year: 2000
Pages: 235

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net