Declarative Actions

Declarative Actions

A declarative security attribute has three characteristics: the target, the metadata item to which it is attributed; the permission, a description of the rights that interest the target; and the action, a description of the precise way the target is interested in these rights.

The nine declarative security actions are intended for different targets and take effect at different stages of the application execution. The earliest stage of execution is the initial loading of the assembly’s prime module and analysis of its manifest. Three declarative actions, targeting the assembly, take effect at this stage:

• Request Minimum  This action specifies that the permission is a minimum requirement for the assembly to be executed. If the minimal permissions are not specified, the assembly is granted all rights according to the existing security policy. These rights, however, might be reduced by other already running parts of the application, by means of a Deny or Permit Only action.

• Request Optional  This action specifies that the permission is useful to have but is not vital for the assembly execution.

• Request Refuse  This action specifies that the permission should not be granted even if the security policy is willing to grant it. This action might be used to ensure that the assembly does not have rights it does not need, thus providing a shield against possible bugs in the assembly itself and against malicious code that might try to coerce the assembly to do something it shouldn’t.

The next stage of the application execution is the loading of its classes and their members. Only one declarative action, targeting classes and methods, plays a role at this stage:

• Inheritance Demand  For classes, this action specifies the permission that all classes descending from this one must have. For methods, this action specifies the permission that all methods overriding this one must have. Obviously, this action makes sense for virtual methods only.

After the classes and their members have been loaded, the IL code of the methods is JIT (just-in-time) compiled. The declarative action targeting classes and methods takes effect at this stage:

• Link Demand  This action specifies the permission that all callers of this method must have—or, if the target is a class, the permission that any method of this class must have. For example, if you have a method that formats the system drive, you want to ensure that this method cannot be successfully called from some rogue code that has no right to do so. This action is limited to the immediate caller only. If method A link-demands permission P, and method B calling A has this permission, but method C calling B does not, the call will go through.

The last stage of the application execution is the run time, when the JIT-compiled code is actually executed. The declarative actions taking effect at this last stage and targeting classes and methods are as follows:

• Demand  This action is similar to Link Demand, but it demands that all callers in the call chain have the specified permission.

• Assert  This action specifies the permission that any caller on the call stack must have. If any caller at any level has the specified permission, the security check succeeds. This action obviously weakens the declarative security model and should be applied with caution. You cannot apply this action unless the code has the access permission SecurityPermission, which is discussed later in this chapter.

• Deny  This action specifies the permission that must be disabled for all callers along the call stack for the duration of the called method. If a caller never had the specified permission in the first place, the action has no effect on it.

• Permit Only  This action specifies the permission that must not be disabled for all callers along the call stack, presuming that the rest of the permissions must be disabled. The action seems excessively cruel (to strip the poor callers of all their privileges except one), but you must not forget that the target might have multiple security attributes. Using a series of Permit Only actions, you can create a set of permissions that remain for the callers to enjoy while all other permissions are temporarily revoked. To clarify this, consider the following example. If the called method has security attributes Deny P and Deny Q, all callers will have their permissions P and Q suspended. If the called method has security attributes Permit Only P and Permit Only Q, all permissions except P and Q of all callers will be suspended.

And now, let’s see what these Ps and Qs stand for.