Programmatic Security (part 6) - Assembly-Wide Permissions

6. Assembly-Wide Permissions

Instead of type-based or even method-based security configuration, you can declaratively apply security permission attributes to an entire assembly, affecting every component in the assembly. All the permission attributes can be applied at the assembly level as well, although the semantics of the security action taken are different from those for a type or method. In fact, you can't apply the values of the SecurityAction enum shown so far on an assembly, and the compiler enforces that. The SecurityAction enum provides three specific values that can be applied only at the assembly scope, again enforced by the compiler:

    public enum SecurityAction
    {
       //Assembly values:
       RequestMinimum,
       RequestOptional,
       RequestRefuse
       //More type and method values
    }

Even though the compiler provides the required degree of type safety for the SecurityAction enum, it would have been cleaner to factor it into two enums: SecurityActionType and SecurityActionAssembly.

You can use these security action values with an individual permission, such as a request for full access to the C:\Temp directory:

    [assembly : FileIOPermission(SecurityAction.RequestMinimum,
                               ViewAndModify= @"C:\temp")]

You can even use these values with a named permission set:

    [assembly : PermissionSet(SecurityAction.RequestMinimum,Name = "Internet")]


					  

You can apply an assembly permission attribute multiple times:

    [assembly : FileIOPermission(SecurityAction.RequestMinimum,
                               ViewAndModify= @"C:\temp")]
    [assembly : FileIOPermission(SecurityAction.RequestMinimum,
                               ViewAndModify= @"D:\temp")]

The SecurityAction.RequestMinimum value indicates to .NET that this assembly requires the specified permission or permission set to operate. Without it, there is no point in loading the assembly or trying to create the types in it. The SecurityAction.RequestRefuse value is useful when all the types in an assembly require denying a particular permission or permission set, or when you explicitly want to reduce the permissions granted to the assembly—when .NET computes the permissions granted to the assembly, it subtracts the refused permissions from the administratively granted permissions. The SecurityAction.RequestOptional value indicates to .NET what permissions this assembly wants in addition to the minimum permissions requested. Optional permissions also indicate that the assembly can operate without them and that no other permissions are required. Specifying optional and refused permissions can prevent the assembly from being granted permissions it doesn't require. Although not technically necessary, it's always better to refuse any permissions that an assembly is granted but doesn't require. Doing so reduces the chance of abuse by malicious clients and counters luring attacks. The final permissions granted must therefore take into account the assembly attributes and the configured policy.

If no assembly attributes are present, .NET grants the assembly the administratively configured permissions according to the security policies. However, if assembly security attributes are present, .NET follows the following algorithm. First, .NET retrieves the permissions granted by the .NET administrators. It then verifies that the requested minimum set of permissions is a subset of the granted policies. If so, .NET computes the union of the minimum and optional permissions, and intersects the result with the administratively granted permissions. Finally, .NET subtracts the refused permissions from the intersection. Figure 1 summarizes this algorithm by using formal notations.

Figure 1. Computing assembly permissions when assembly permission attributes are provided