|
1. |
This can indeed become a major concern if it turns out that the code accesses a significant number of protected resources and/or operations, especially if they happen in a long calling chain. The only way to prevent this from happening is to put in a SecurityAction.Assert just before a protected resource or operation is called. This implies that you need a thorough understanding of when a stack walk—or demand—is triggered and on what permission this stack walk will be performed. By just placing an Assert, you create an uncontrolled security hole. What you can do is the following, which can be applied in the situation in which you make a call to a protected resource, but do this from within a loop structure. You can also use it in a situation in which you call a method that makes a number of calls to (different) protected resources or operations that trigger the demand for the same type of permission. The only way to prevent a number of stack walks is to place an imperative assertion on the permission that will be demanded. Now you know that the stack walk will be stopped in its tracks. To close the security hole you just opened, you place an imperative demand for the permission you asserted in front of the assertion. If the demand succeeds, you know that in the other part of the calling chain, everything is okay in regard to this permission. Moreover, because nothing will change if you check a second or third time, you can save yourself a lot of unnecessary stack walks. Think about a 1000-fold loop: You just cleared your code from doing 999 redundant stack walks.
|
|
2. |
First, make sure that you understand the difference in the effect of each. The imperative syntax makes a demand, or override for that matter, on the part of your code. It is executed when the line of code that holds the demand or override is encountered during runtime. The declarative syntax brings these demands and overrides right into the metadata of the assembly. During the load phase of the assembly, the metadata is extracted and interpreted, meaning that the CLR already takes action on this information. If a stack walk takes place, the CLR can handle overrides much quicker than if they occur during execution, thus the imperative way. However, demands should only be made at the point they are really necessary. Most of the time, demands are conditional—think about whether the demand is based on a role-based security check. If you make a demand declarative for a class or method, it will trigger a stack walk every time this class or method is referenced, even if demands turn out to be not needed. To recap: Make overrides declarative and place them in the header of the method, unless all methods in the class need the assertion; then place it in the class declaration. Remember that an assembly cannot have more than one active override type. If you cannot avoid this, you need to use declarative overrides anyway. Make demands imperative and place them just before you have to access a protected resource or operation. |
|
3. |
You need to remember four important issues in building a code group hierarchy:
An assembly cannot be a member of code groups that have conflicting permissions—for example, one with unrestricted FileIOPermission and one with a more restricted FileIOPermission.
The bigger the code group hierarchy, the harder it is to maintain.
The larger the number of permission sets, the harder it is to maintain them.
The harder it is to maintain code groups and permissions sets, the more likely it is that they contain security holes.
The best approach is the largest common denominator. Security demands simplicity with as few exceptions as possible. Before you start creating custom properties sets, convince yourself that this is absolutely necessary. Nine out of 10 times, one of the built-in permission sets suffices. The same goes for code groups—most assemblies will fit nicely in a code group based on their zone identity. If you conclude that this will not do, add only code groups that are more specific than the zone identity, like the publisher identity, but still apply to a large group of assemblies. Use more than one level in the code group hierarchy only if it is absolutely necessary to check on more than one membership condition or identity attribute. Add a permission set to the lowest level of the hierarchy only and apply the Nothing permission set to the parent code groups. Take into account that the CLR will check on all policy levels, so check to see whether you have to modify the code group hierarchy of only one policy level or whether this has to be done on more levels. Remember, the CLR will intersect the actual permission sets of all the policy levels. |