Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Платформа .NET Framework предоставляет три способа выдачи общего промежуточного языка (CIL), каждый из которых имеет собственные проблемы безопасности:
- Динамические сборки
- Анонимные динамические методы
- Динамические методы, связанные с существующими сборками
Независимо от способа создания динамического кода выполнение созданного кода требует всех разрешений, необходимых типам и методам, которые используют созданный код.
Замечание
Разрешения, необходимые для инспектирования и генерации кода, изменились с последующими выпусками .NET Framework. Дополнительные сведения о версиях см. в этой статье.
Динамические сборки
Динамические сборки создаются с помощью перегрузок метода AppDomain.DefineDynamicAssembly. Большинство перегрузок этого метода устарели в .NET Framework 4 из-за ликвидации политики безопасности на уровне компьютера. Остальные перегрузки могут выполняться любым кодом независимо от уровня доверия. Эти перегрузки делятся на две группы: те, которые указывают список атрибутов для применения к динамической сборке при ее создании, и те, которые этого не делают. Если вы не указываете модель прозрачности для сборки, применяя атрибут SecurityRulesAttribute при её создании, модель прозрачности наследуется от излучающей сборки.
Замечание
Атрибуты, применяемые к динамической сборке после его создания, с помощью SetCustomAttribute метода, не вступают в силу, пока сборка не будет сохранена на диске и загружена в память снова.
Код в динамической сборке может получить доступ к видимым типам и элементам в других сборках.
Замечание
Динамические сборки не используют ReflectionPermissionFlag.MemberAccess и ReflectionPermissionFlag.RestrictedMemberAccess флаги, которые позволяют динамическим методам получать доступ к неопубликованным типам и членам.
Временные динамические сборки создаются в памяти и никогда не сохраняются на диске, поэтому им не требуются разрешения на доступ к файлам. Сохранение динамической сборки на диск требует FileIOPermission с установкой соответствующих флагов.
Создание динамических сборок из частично доверенного кода
Рассмотрим условия, в которых сборка с разрешениями Интернета может создать временную динамическую сборку и выполнить его код:
Динамическая сборка использует только общедоступные типы и члены других сборок.
Разрешения, требуемые этими типами и членами, включены в набор разрешений частично доверенной сборки.
Сборка не сохраняется на диск.
Символы отладки не создаются. (
InternetиLocalIntranetнаборы разрешений не включают необходимые разрешения.)
Анонимно размещаемые динамические методы
Анонимные динамические методы создаются с помощью двух DynamicMethod конструкторов, которые не указывают связанный тип или модуль, DynamicMethod(String, Type, Type[]) и DynamicMethod(String, Type, Type[], Boolean). Эти конструкторы размещают динамические методы в системно предоставленной, полностью доверенной, прозрачно безопасной сборке. Разрешения не требуются для использования этих конструкторов или для отправки кода для динамических методов.
Вместо этого при создании анонимно размещенного динамического метода стек вызовов фиксируется. Когда метод создаётся, требования безопасности предъявляются в отношении захваченного стека вызовов.
Замечание
Концептуально, требования предъявляются при создании метода. То есть требования могут предъявляться по мере выдачи каждой инструкции CIL. В текущей реализации все запросы выполняются при вызове метода DynamicMethod.CreateDelegate или при запуске JIT-компилятора, если метод вызван без вызова CreateDelegate.
Если домен приложения разрешает это, анонимные динамические методы могут пропускать проверки видимости JIT при условии следующего ограничения: закрытые типы и члены, к которым обращается анонимный динамический метод, должны находиться в сборках, наборы разрешений которых равны наборам разрешений стека вызовов или являются их подмножествами. Эта ограниченная способность пропускать проверки видимости JIT включается, если домен приложения предоставляет ReflectionPermission с флагом ReflectionPermissionFlag.RestrictedMemberAccess.
Если в методе используются только общедоступные типы и члены, во время строительства разрешения не требуются.
Если указать, что проверки видимости в процессе JIT должны быть пропущены, запрос, формируемый при создании метода, включает ReflectionPermission с ReflectionPermissionFlag.RestrictedMemberAccess флагом, а также набор привилегий сборки, содержащей непубличный член, к которому осуществляется доступ.
Поскольку набор предоставленных непубличных элементов учитывается, код с частичным доверием, которому был предоставлен ReflectionPermissionFlag.RestrictedMemberAccess, не может повысить свои привилегии, выполняя непубличные элементы доверенных сборок.
Как и в случае с любым другим созданным кодом, выполнение динамического метода требует любых разрешений, требуемых методами, которые использует динамический метод.
Системная сборка, на которой анонимно размещаются динамические методы, использует модель прозрачности SecurityRuleSet.Level1, которая использовалась в .NET Framework до версии 4.
Дополнительные сведения см. в DynamicMethod классе.
Создание анонимных динамических методов из частично доверенного кода
Рассмотрим условия, в которых сборка с разрешениями Интернета может создать анонимный динамический метод и выполнить его:
Динамический метод использует только общедоступные типы и члены. Если его набор разрешений включает ReflectionPermissionFlag.RestrictedMemberAccess, он может использовать закрытые типы и члены любой сборки, набор разрешений которой равен набору разрешений сборки, из которой выполняется издание, или является его подмножеством.
Разрешения, необходимые всем типам и членам, используемым динамическим методом, включаются в набор разрешений частично доверенной сборки.
Замечание
Динамические методы не поддерживают отладочные символы.
Динамические методы, ассоциированные с существующими сборками
Чтобы связать динамический метод с типом или модулем в существующей сборке, используйте любой DynamicMethod из конструкторов, указывающих связанный тип или модуль. Разрешения, необходимые для вызова этих конструкторов, различаются, так как связывание динамического метода с существующим типом или модулем предоставляет динамический метод доступа к неопубликованным типам и членам:
Динамический метод, связанный с типом, имеет доступ ко всем элементам этого типа, даже к частным членам, а также ко всем внутренним типам и членам в сборке, содержащей связанный тип.
Динамический метод, связанный с модулем, имеет доступ ко всем типам и членам (
internalв Visual Basic, метаданныеFriendв CLR) в этом модуле.
Кроме того, можно использовать конструктор, указывающий возможность пропуска проверок видимости компилятора JIT. Это дает вашему динамическому методу доступ ко всем типам и элементам во всех сборках независимо от уровня доступа.
Разрешения, которые требует конструктор, зависят от того, сколько доступа вы решили предоставить этому динамическому методу.
Если метод использует только общедоступные типы и члены, и вы связываете его с собственным типом или собственным модулем, разрешения не требуются.
Если указано ReflectionPermission, что проверки видимости JIT должны быть пропущены, конструктор требует флага ReflectionPermissionFlag.MemberAccess.
Если вы связываете динамический метод с другим типом, даже если это другой тип в вашей собственной сборке, конструктор требует ReflectionPermission с флагом ReflectionPermissionFlag.MemberAccess и SecurityPermission с флагом SecurityPermissionFlag.ControlEvidence.
Если вы ассоциируете динамический метод с типом или модулем в другой сборке, конструктор требует двух вещей: ReflectionPermission с флагом ReflectionPermissionFlag.RestrictedMemberAccess и набором разрешений сборки, содержащей другой модуль. То есть стек вызовов должен содержать все разрешения в наборе разрешений целевого модуля, а также ReflectionPermissionFlag.RestrictedMemberAccess.
Замечание
Для обратной совместимости, если запрос на целевой набор грантов вместе с ReflectionPermissionFlag.RestrictedMemberAccess завершается ошибкой, конструктор запрашивает SecurityPermission c флагом SecurityPermissionFlag.ControlEvidence.
Хотя элементы в этом списке описываются с точки зрения набора разрешений исходной сборки, помните, что требования предъявляются к полному стеку вызовов, включая границу домена приложения.
Дополнительные сведения см. в DynamicMethod классе.
Создание динамических методов из частично доверенного кода
Замечание
Рекомендуемый способ создания динамических методов из частично доверенного кода — использовать анонимные динамические методы.
Рассмотрим условия, в которых сборка с разрешениями Интернета может создать динамический метод и выполнить его:
Динамический метод связан с модулем или типом, который его создает, или его набор разрешений включает ReflectionPermissionFlag.RestrictedMemberAccess и связан с модулем в сборке, набор разрешений которой равен или является подмножеством набора разрешений сборки, создающей его.
Динамический метод использует только общедоступные типы и члены. Если его набор разрешений включает ReflectionPermissionFlag.RestrictedMemberAccess и связан с модулем в сборке, набор разрешений которого равен или является подмножеством набора разрешений исходной сборки, он может использовать типы и члены, помеченные
internal(Friendв Visual Basic,assemblyв метаданных среды CLR) в связанном модуле.Разрешения, требуемые всеми типами и элементами, используемыми динамическим методом, включаются в набор разрешений сборки с частичной доверенностью.
Динамический метод не пропускает проверки видимости JIT.
Замечание
Динамические методы не поддерживают отладочные символы.
Сведения о версиях
Начиная с .NET Framework 4 политика безопасности на уровне компьютера устраняется, а прозрачность безопасности становится механизмом принудительного применения по умолчанию.
Начиная с .NET Framework 2.0 с пакетом обновления 1 (SP1) ReflectionPermissionReflectionPermissionFlag.ReflectionEmit флаг больше не требуется при создании динамических сборок и динамических методов. Этот флаг необходим во всех предыдущих версиях .NET Framework.
Замечание
ReflectionPermission
ReflectionPermissionFlag.ReflectionEmit с флагом по умолчанию включается в FullTrust наборы разрешений и LocalIntranet именованные наборы разрешений, но не в Internet наборе разрешений. Поэтому в ранних версиях .NET Framework библиотека может работать с сетевыми разрешениями, только если она выполняет Assert для ReflectionEmit. Для таких библиотек требуется тщательная проверка безопасности, так как ошибки кодирования могут привести к ошибкам безопасности. .NET Framework 2.0 с пакетом обновления 1 (SP1) позволяет создавать код в сценариях частичного доверия без выдачи требований безопасности, так как создание кода по сути не является привилегированной операцией. То есть созданный код не имеет больше разрешений, чем сборка, которая выдает его. Это позволяет библиотекам, которые создают код и являются прозрачными с точки зрения безопасности, и устраняет необходимость утверждения ReflectionEmit, что упрощает задачу написания защищенной библиотеки.
Кроме того, .NET Framework 2.0 SP1 вводит флаг, позволяющий доступ к недоступным типам и членам из частично доверенных динамических методов. В более ранних версиях .NET Framework требуется ReflectionPermissionFlag.MemberAccess флаг для динамических методов, которые обращаются к неопубликованным типам и членам. Это разрешение, которое никогда не должно быть предоставлено частично доверенному коду.
Наконец, .NET Framework 2.0 с пакетом обновления 1 (SP1) представляет анонимно размещенные методы.
Получение сведений о типах и членах
Начиная с .NET Framework 2.0, для получения сведений о неопубликованных типах и членах не требуются разрешения. Отражение используется для получения информации, необходимой для выдачи динамических методов. Например, MethodInfo объекты используются для выдачи вызовов методов. Для более ранних версий .NET Framework требуется использовать ReflectionPermission вместе с флагом ReflectionPermissionFlag.TypeInformation. Дополнительные сведения см. в разделе Соображения безопасности для отражений.