Summary

for RuBoard

Membership conditions are some of the basic building blocks of .NET Framework security policy. A membership condition object examines the evidence on an assembly and reports whether or not it matches. There are a set of default membership condition classes that look at the different default types of evidence. .NET Framework developers can also write their own membership conditions classes to examine default or custom types of evidence.

Code groups are objects that bind a membership condition to a permission set. When an assembly matches a membership condition, the code group grants the permission set to the assembly. Code groups are formed into hierarchies to express more complicated intentions. If an assembly matches a code group, all of its children are examined, too. For the most common code group class, the UnionCodeGroup , the permission sets from matching children are unioned with the parent's granted permission set. The resulting union of the root code group's permission set and all matching children's code groups is the final permission set to grant the assembly.

There are several default types of code groups. Different code groups handle the permission sets to grant and the merging logic with children differently. As with membership conditions, .NET Framework developers also have the ability to create their own code group classes.

The final piece of security policy we covered is the policy level. A policy level has three pieces ”a permission set list, a code group hierarchy, and a list of assemblies. .NET Framework security policy has four levels ”Enterprise, Machine, User , and AppDomain. Each policy level is controlled by different entities ”network administrators, machine administrators, users, and application developers. As assemblies are loaded, they are resolved against each level to produce a set of granted permissions. The grant set from each level is intersected to produce the grant set for the entire assembly.

for RuBoard