Security Issues in Reflection EmitÂ
This topic describes the security issues to be aware of when creating dynamic assemblies using reflection emit. Some scenarios require specific permissions. Other scenarios require permissions to be established for generated code. In the following description, the term caller refers to the creator of the dynamic assemblies and/or dynamic modules.
Scenarios Requiring Specific Permissions
The runtime requires the authoring assembly to have the ReflectionPermissionFlag.ReflectionEmit permission for invoking certain operations on AssemblyBuilder objects and ModuleBuilder objects. Because reflection emit uses Reflection, the authoring assembly can also require permission to use Reflection.
Establishing Permissions for Generated Code
A caller needs the appropriate file permissions to persist a dynamic assembly.
Callers with the SecurityPermissionFlag.ControlEvidence permission can supply evidence for the generated code. This evidence is mapped through policy to determine the granted permissions.
Any caller can supply null evidence, in which case the assembly gets the permission set of the caller. This ensures that the generated code does not have more permissions than its caller.
After a dynamic assembly has been persisted to disk, subsequent loads obtain grants based on policies associated with the location where the assembly was persisted. That is, the assembly is treated like any other assembly that is loaded from disk.
Code generated by semi-trusted callers is always verified. Specifically, the runtime always verifies code that does not have the SecurityPermissionFlag.SkipVerification permission. Fully trusted callers can either skip verification or require the generated code to be verified.