Guidelines for elevating CAS permissions

• Elevate permissions at the lowest level in the code, which is the closest point in the call stack that fails if the permission is not elevated.
• Elevate permissions only in the code specific to rule execution. If elevation is required at a lower level, move up in the call stack to the nearest call that is specific to rules.
• Elevate permissions on methods, and perhaps on classes, but not on the whole assembly.
• Be restrictive and specific. For example, if the code needs to read one registry key, elevate permission only for this key, not the whole registry.
• Use .NET attributes, not procedural code to elevate permissions. .NET attributes limit the scope of elevation to one method call or one class. In procedural code, you can forget to reset elevated permissions, and they can stay on. However, this sets a limit on how restrictive and specific you can be when you elevate permissions on methods or classes. For example, to limit the IO permission to one file, you must specify the complete path, which is known only at runtime, so this is impossible to do with an attribute.
• Add comments to each elevation explaining why it was necessary, and list the use case, unit test, or code path that requires that permission.