This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!
Security Issues in Reflection Emit
This section describes the security issues to be aware of when creating dynamic assemblies using the Reflection Emit APIs. Some scenarios require specific permissions. Other scenarios require permissions to be established for generated code. In the description below, 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.
Establishing Permissions for Generated Code
- A caller needs the right file permissions to persist a dynamic assembly.
- Callers with the SecurityPermissionFlag.ControlEvidence permission will be able to supply evidence for the generated code. This evidence will get mapped through policy to determine the granted permissions.
- Any caller may supply null evidence in which case the assembly will pick up 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 will get 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 will always be verified. Specifically, the runtime always verifies code that does not get the SecurityPermissionFlag.SkipVerification permission. Fully trusted callers can opt to skip verification or require the generated code to be verified.