Programming Security Policy (part 3) - Programming the Security Manager

3. Programming the Security Manager

The System.Security.SecurityManager class contains a set of static members that provide access to critical security system functionality and data. Most members of SecurityManager require the caller to have the ControlPolicy permission; ControlPolicy is an element of System.Security.Permissions.SecurityPermission. The SecurityManager functionality protected by ControlPolicy means that ControlPolicy is one of the highest trust permissions you can grant to code; you must have absolute confidence in the source and integrity of the code to which you grant the ControlPolicy permission.

Table 7 summarizes the members of the SecurityManager class. The far right column titled "C" identifies those members that require the ControlPolicy permission.

Table 7. Members of the SecurityManager class

Member	Description	C
Properties
CheckExecutionRights	Controls whether the runtime enforces the Execution permission.	✓
SecurityEnabled	Controls whether the runtime enforces code-access security.	✓
Methods
IsGranted	Checks if the calling code has a specified permission.
LoadPolicyLevelFromFile	Replaces the specified policy level with a policy level loaded from a file; the file must contain an XML representation of the policy level. Use a member of the PolicyLevelType enumeration to identify the current policy level to replace.	✓
LoadPolicyLevelFromString	Like LoadPolicyLevelFromFile but reads the XML definition of the new policy level from a String.	✓
PolicyHierarchy	Provides access to the currently active policy levels via an IEnumerator.	✓
ResolvePolicy	Returns a PermissionSet containing all of the permissions the policy resolution process would grant based on a specified Evidence collection.
ResolvePolicyGroup	Returns an IEnumerator containing a set of CodeGroup objects representing the code groups to which a specified Evidence collection would grant membership.
SavePolicy	Saves the security configuration, including all policy levels.	✓
SavePolicyLevel	Saves the specified policy level to the same location from which it was loaded.	✓

The SecurityEnabled property is critical to the overall operation of the security system. SecurityEnabled is the master switch for code access security. Setting SecurityEnabled to false causes all demands for code-access or identity permissions to succeed; role-based security is not affected. This is effectively the same as giving all code FullTrust but has less overhead, because the runtime bypasses the security system when code makes security demands.

SecurityManager implements one of the most important members of the whole security system. The SecurityEnabled property allows you to turn off all code-access security, meaning that any code can perform any operation regardless of evidence and permissions.

The CheckExecutionRights property controls whether the runtime enforces the Execution permission, which is also an element of the SecurityPermission class. When CheckExecutionRights is false, any code can run regardless of whether it has the Execution permission.

The runtime will not store changes to the SecurityEnabled and CheckExecutionRights properties until you call the SavePolicy method. Even after calling SavePolicy, the effect on the current process is unpredictable, and only new processes will work reliably with the new settings:

# C#

// Turn on security, turn off execution checking, and save the settings
SecurityManager.SecurityEnabled = true;
SecurityManager.CheckExecutionRights = false;
SecurityManager.SavePolicy(  );

# Visual Basic.NET

' Turn on security, turn off execution checking, and save the settings
SecurityManager.SecurityEnabled = True
SecurityManager.CheckExecutionRights = False
SecurityManager.SavePolicy(  )

The reason you are most likely to be tempted to use both SecurityEnabled and CheckExecutionRights is performance. In an environment where security is not required, it makes sense to remove the overhead of runtime security checks, but the performance gains will vary greatly depending on the nature of the application. In addition, you should consider thoroughly what other factors are affecting application performance before you decide to turn off code-access security.

The IsGranted, ResolvePolicy, and ResolvePolicyGroup members are useful for testing and debugging but are not as useful as they might initially seem. IsGranted only determines if the grant set of the calling code contains a specified permission. ResolvePolicy and ResolvePolicyGroup both take an Evidence collection and run it through the policy resolution process. ResolvePolicy returns a grant set based on the evidence provided, and ResolvePolicyGroup returns the code groups to which the evidence qualifies for membership.

Of more use is the PolicyHierarchy method that returns a System.Collections.IEnumerator containing PolicyLevel objects for each of the active policy levels. Stepping through the enumerator, you can obtain a PolicyLevel object representing one of the active policy levels, allowing you to edit its content. Use the PolicyLevel.Label property to identify the desired PolicyLevel:

# C#

// Get the enumeration of policy levels.
IEnumerator e = SecurityManager.PolicyHierarchy(  );

// Step through the PolicyLevel objects, find the User policy
// and display it to the console.
while(e.MoveNext(  )) {

    PolicyLevel p = e.Current as PolicyLevel;

    if (p.Label == "User") {
        Console.WriteLine(p.ToXml(  ).ToString(  ));
    }
}

# Visual Basic .NET

' Get the enumeration of policy levels.
Dim e As IEnumerator =  SecurityManager.PolicyHierarchy(  ) 
 
' Step through the PolicyLevel objects, find the User policy
' and display it to the console.
While e.MoveNext(  )
 
    Dim p As PolicyLevel =  CType(e.Current,PolicyLevel)
 
    If p.Label = "User" Then
        Console.WriteLine(p.ToXml(  ).ToString(  ))
    End If
End While

					  

After editing an active PolicyLevel, you must call SavePolicy or SavePolicyLevel method if you want to save the changes to disk so that they affect future processes. SavePolicy saves all policy levels and policy settings, but SavePolicyLevel saves the configuration of a specified PolicyLevel. SavePolicyLevel saves the specified PolicyLevel back to its source location, which is contained in the PolicyLevel.StoreLocation property.