Прозрачный с точки зрения безопасности код, уровень 2Security-Transparent Code, Level 2

Внимание!

Управление доступом для кода и частично доверенный кодCode Access Security and Partially Trusted Code

Платформа .NET Framework предоставляет механизм для принудительного применения различных уровней доверия к разным частям кода, выполняемым в одном и том же приложении. Этот механизм называется управлением доступом для кода.The .NET Framework provides a mechanism for the enforcement of varying levels of trust on different code running in the same application called Code Access Security (CAS). Управление доступом для кода в .NET Framework не следует использовать в качестве механизма обеспечения границ безопасности на основе происхождения кода или других аспектов, связанных с удостоверениями.Code Access Security in .NET Framework should not be used as a mechanism for enforcing security boundaries based on code origination or other identity aspects. Мы обновляем рекомендации с учетом того, что управление доступом для кода и прозрачный для системы безопасности код не будут поддерживаться в качестве механизма безопасности при работе с частично доверенным кодом, особенно с кодом неизвестного происхождения.We are updating our guidance to reflect that Code Access Security and Security-Transparent Code will not be supported as a security boundary with partially trusted code, especially code of unknown origin. Мы не рекомендуем загружать и выполнять код из неизвестных источников, не предприняв дополнительные меры безопасности.We advise against loading and executing code of unknown origins without putting alternative security measures in place.

Эта политика действует в отношении всех версий платформы .NET Framework, кроме платформы .NET Framework в составе Silverlight.This policy applies to all versions of .NET Framework, but does not apply to the .NET Framework included in Silverlight.

Прозрачность уровня 2 появилась в .NET Framework 4.Level 2 transparency was introduced in the .NET Framework 4. Ключевыми элементами этой модели являются следующие компоненты: прозрачный код, надежный с точки зрения безопасности код и критический с точки зрения безопасности код.The three tenets of this model are transparent code, security-safe-critical code, and security-critical code.

  • Прозрачный код (в том числе код с полным доверием) может вызывать только другой прозрачный или надежный с точки зрения безопасности код.Transparent code, including code that is running as full trust, can call other transparent code or security-safe-critical code only. Прозрачный код может выполнять только действия, разрешенные набором разрешений частичного доверия домена (если он существует).It can only perform actions allowed by the domain’s partial trust permission set (if one exists). Прозрачный код не может выполнять следующие действия:Transparent code cannot do the following:

    • выполнять метод Assert или повышение привилегий;Perform an Assert or elevation of privilege.

    • содержать небезопасный или непроверяемый код;Contain unsafe or unverifiable code.

    • напрямую вызывать критический код;Directly call critical code.

    • вызывать машинный код или код с атрибутом SuppressUnmanagedCodeSecurityAttribute;Call native code or code with the SuppressUnmanagedCodeSecurityAttribute attribute.

    • вызывать член, защищенный с помощью LinkDemand;Call a member that is protected by a LinkDemand.

    • наследовать от критических типов.Inherit from critical types.

    Кроме того, прозрачные методы не могут переопределять критические виртуальные методы или реализовывать критические методы интерфейсов.In addition, transparent methods cannot override critical virtual methods or implement critical interface methods.

  • Надежный с точки зрения безопасности код имеет полное доверие, но может вызываться прозрачным кодом.Safe-critical code is fully trusted but is callable by transparent code. Он предоставляет ограниченный объем кода с полным доверием. В надежном с точки зрения безопасности коде выполняются проверки на правильность и безопасность.It exposes a limited surface area of full-trust code; correctness and security verifications happen in safe-critical code.

  • Критический с точки зрения безопасности код может вызывать любой код, но не может вызываться из прозрачного кода.Security-critical code can call any code and is fully trusted, but it cannot be called by transparent code.

Примеры использования и поведениеUsage Examples and Behaviors

Чтобы указать правила .NET Framework 4 (прозрачность уровня 2), используйте следующую аннотацию для сборки:To specify .NET Framework 4 rules (level 2 transparency), use the following annotation for an assembly:

[assembly: SecurityRules(SecurityRuleSet.Level2)]

Чтобы зафиксировать правила платформы .NET Framework 2.0 (прозрачность уровня 1), используйте следующую заметку:To lock into the .NET Framework 2.0 rules (level 1 transparency), use the following annotation:

[assembly: SecurityRules(SecurityRuleSet.Level1)]

Если сборка не замечается, то по умолчанию используются правила .NET Framework 4.If you do not annotate an assembly, the .NET Framework 4 rules are used by default. Однако рекомендуется использовать атрибут SecurityRulesAttribute, а не в зависимости от значения по умолчанию.However, the recommended best practice is to use the SecurityRulesAttribute attribute instead of depending on the default.

Заметка на уровне сборкиAssembly-wide Annotation

Ниже перечислены правила, которые применяются к использованию атрибутов на уровне сборки.The following rules apply to the use of attributes at the assembly level:

  • Без атрибутов: если атрибуты не указаны, то среда выполнения рассматривает код как критический с точки зрения безопасности за исключением случаев, когда это нарушает правило наследования (например, при переопределении или при реализации прозрачного виртуального метода или метода интерфейса).No attributes: If you do not specify any attributes, the runtime interprets all code as security-critical, except where being security-critical violates an inheritance rule (for example, when overriding or implementing a transparent virtual or interface method). В таких случаях методы являются надежными с точки зрения безопасности.In those cases, the methods are safe-critical. Если атрибут не указан, то определение правил прозрачности выполняется средой CLR.Specifying no attribute causes the common language runtime to determine the transparency rules for you.

  • SecurityTransparent: весь код является прозрачным, а сборка не будет выполнять небезопасных действий или действий, требующих наличия особых привилегий.SecurityTransparent: All code is transparent; the entire assembly will not do anything privileged or unsafe.

  • SecurityCritical: весь код типов в этой сборке является критическим, а остальной код — прозрачным.SecurityCritical: All code that is introduced by types in this assembly is critical; all other code is transparent. Этот случай аналогичен отсутствию атрибутов, но среда CLR не определяет правила прозрачности автоматически.This scenario is similar to not specifying any attributes; however, the common language runtime does not automatically determine the transparency rules. Например, если переопределить виртуальный или абстрактный метод или реализовать метод интерфейса, то такой метод по умолчанию будет прозрачным.For example, if you override a virtual or abstract method or implement an interface method, by default, that method is transparent. Следует явным образом пометить метод как SecurityCritical или SecuritySafeCritical. В противном случае при загрузке возникнет исключение TypeLoadException.You must explicitly annotate the method as SecurityCritical or SecuritySafeCritical; otherwise, a TypeLoadException will be thrown at load time. Это правило также применяется в том случае, если базовый и производный классы находятся в одной сборке.This rule also applies when both the base class and the derived class are in the same assembly.

  • AllowPartiallyTrustedCallers (только уровень 2): весь код по умолчанию является прозрачным.AllowPartiallyTrustedCallers (level 2 only): All code defaults to transparent. Однако отдельные типы и члены могут иметь другие атрибуты.However, individual types and members can have other attributes.

В следующей таблице сравнивается поведение уровня сборки уровня 2 с уровнем 1.The following table compares the assembly level behavior for Level 2 with Level 1.

Assembly - атрибутAssembly attribute Уровень 2Level 2 Уровень 1Level 1
Частично доверенная сборка без атрибутовNo attribute on a partially trusted assembly Типы и члены по умолчанию являются прозрачными, но могут быть критическими или надежными с точки зрения безопасности.Types and members are by default transparent, but can be security-critical or security-safe-critical. Все типы и члены являются прозрачными.All types and members are transparent.
Атрибут не указанNo attribute Если атрибут не указан, то определение правил прозрачности выполняется средой CLR.Specifying no attribute causes the common language runtime to determine the transparency rules for you. Все типы и члены являются критическими с точки зрения безопасности за исключением тех случаев, когда это нарушает правило наследования.All types and members are security-critical, except where being security-critical violates an inheritance rule. В сборке с полным доверием (в глобальном кэше сборок или в сборке, для которой полное доверие указано в домене AppDomain) все типы являются прозрачными, а члены — надежными с точки зрения безопасности.On a fully trusted assembly (in the global assembly cache or identified as full trust in the AppDomain) all types are transparent and all members are security-safe-critical.
SecurityTransparent Все типы и члены являются прозрачными.All types and members are transparent. Все типы и члены являются прозрачными.All types and members are transparent.
SecurityCritical(SecurityCriticalScope.Everything) Неприменимо.Not applicable. Все типы и члены являются прозрачными.All types and members are security-critical.
SecurityCritical Код всех типов в этой сборке является критическим, а остальной код — прозрачным.All code that is introduced by types in this assembly is critical; all other code is transparent. При переопределении виртуального или абстрактного метода или при реализации метода интерфейса следует явным образом пометить этот метод как SecurityCritical или SecuritySafeCritical.If you override a virtual or abstract method or implement an interface method, you must explicitly annotate the method as SecurityCritical or SecuritySafeCritical. Весь код по умолчанию является прозрачным.All code defaults to transparent. Однако отдельные типы и члены могут иметь другие атрибуты.However, individual types and members can have other attributes.

Заметки для типов и членовType and Member Annotation

Атрибуты безопасности, которые применяются к типу, также применяются и к членам, которые представлены этим типом.The security attributes that are applied to a type also apply to the members that are introduced by the type. Однако они не применяются к виртуальным или абстрактным переопределениям базового класса, а также к реализациям интерфейса.However, they do not apply to virtual or abstract overrides of the base class or interface implementations. Ниже перечислены правила, которые применяются к использованию атрибутов на уровне типов и членов.The following rules apply to the use of attributes at the type and member level:

  • SecurityCritical: тип или член является критическим и может быть вызван только кодом с полным доверием.SecurityCritical: The type or member is critical and can be called only by full-trust code. Методы, представленные в критическом с точки зрения безопасности коде, также являются критическими.Methods that are introduced in a security-critical type are critical.

    Важно!

    Виртуальные и абстрактные методы, представленные в базовых классах или интерфейсах и переопределяемые или реализуемые в критическом с точки зрения безопасности классе, по умолчанию являются прозрачными.Virtual and abstract methods that are introduced in base classes or interfaces, and overridden or implemented in a security-critical class are transparent by default. Их следует пометить как SecuritySafeCritical или SecurityCritical.They must be identified as either SecuritySafeCritical or SecurityCritical.

  • SecuritySafeCritical: тип или член является надежным с точки зрения безопасности.SecuritySafeCritical: The type or member is safe-critical. В то же время этот тип или член может вызываться из прозрачного кода (с частичным доверием) и имеет те же возможности, что и любой другой критический код.However, the type or member can be called from transparent (partially trusted) code and is as capable as any other critical code. Код необходимо проверить на безопасность.The code must be audited for security.

Схемы переопределенияOverride Patterns

В таблице ниже представлены разрешенные переопределения метода для прозрачности уровня 2.The following table shows the method overrides allowed for level 2 transparency.

Базовый виртуальный член или член интерфейсаBase virtual/interface member Переопределение или интерфейсOverride/interface
Transparent Transparent
Transparent SafeCritical
SafeCritical Transparent
SafeCritical SafeCritical
Critical Critical

Правила наследованияInheritance Rules

В этом разделе коду Transparent, Critical и SafeCritical в зависимости от доступа и возможностей присваивается следующий порядок:In this section, the following order is assigned to Transparent, Critical, and SafeCritical code based on access and capabilities:

Transparent < SafeCritical < Critical

  • Правила для типов: по мере движения слева направо доступ становится более ограниченным.Rules for types: Going from left to right, access becomes more restrictive. Производные типы должны иметь как минимум те же ограничения, что и базовый тип.Derived types must be at least as restrictive as the base type.

  • Правила для методов: производные методы не могут изменять доступность из базового метода.Rules for methods: Derived methods cannot change accessibility from the base method. По умолчанию все производные методы без заметок являются методами Transparent.For default behavior, all derived methods that are not annotated are Transparent. Типы, производные от критических, вызывают возникновение исключения, если переопределенный метод явным образом не помечен как SecurityCritical.Derivatives of critical types cause an exception to be thrown if the overridden method is not explicitly annotated as SecurityCritical.

В таблице ниже показаны разрешенные схемы наследования типов.The following table shows the allowed type inheritance patterns.

Базовый классBase class Производный класс может бытьDerived class can be
Transparent Transparent
Transparent SafeCritical
Transparent Critical
SafeCritical SafeCritical
SafeCritical Critical
Critical Critical

В таблице ниже показаны запрещенные схемы наследования типов.The following table shows the disallowed type inheritance patterns.

Базовый классBase class Производный класс не может бытьDerived class cannot be
SafeCritical Transparent
Critical Transparent
Critical SafeCritical

В таблице ниже показаны разрешенные схемы наследования методов.The following table shows the allowed method inheritance patterns.

Базовый методBase method Производный метод может бытьDerived method can be
Transparent Transparent
Transparent SafeCritical
SafeCritical Transparent
SafeCritical SafeCritical
Critical Critical

В таблице ниже показаны запрещенные схемы наследования методов.The following table shows the disallowed method inheritance patterns.

Базовый методBase method Производный метод не может бытьDerived method cannot be
Transparent Critical
SafeCritical Critical
Critical Transparent
Critical SafeCritical

Примечание

Эти правила наследования применяются к типам и членам уровня 2.These inheritance rules apply to level 2 types and members. Типы в сборках уровня 1 могут наследоваться от критических с точки зрения безопасности типов и членов уровня 2.Types in level 1 assemblies can inherit from level 2 security-critical types and members. Таким образом, типы и члены уровня 2 должны иметь различные требования к наследованию для наследуемых типов и членов уровня 1.Therefore, level 2 types and members must have separate inheritance demands for level 1 inheritors.

Дополнительные сведения и правилаAdditional Information and Rules

Поддержка LinkDemandLinkDemand Support

Модель прозрачности уровня 2 заменяет LinkDemand атрибутом SecurityCriticalAttribute.The level 2 transparency model replaces the LinkDemand with the SecurityCriticalAttribute attribute. В устаревшем коде (уровень 1) LinkDemand автоматически рассматривается как Demand.In legacy (level 1) code, a LinkDemand is automatically treated as a Demand.

ОтражениеReflection

Вызов критического метода или чтение критического поля вызывает требование полного доверия (как при вызове закрытого метода или поля).Invoking a critical method or reading a critical field triggers a demand for full trust (just as if you were invoking a private method or field). Таким образом, критический метод может вызываться только в коде с полным доверием, а не в коде с частичным доверием.Therefore, full-trust code can invoke a critical method, whereas partial-trust code cannot.

В пространство имен System.Reflection добавлены следующие свойства, позволяющие определить, является ли тип, метод или поле SecurityCritical, SecuritySafeCritical или SecurityTransparent: IsSecurityCritical, IsSecuritySafeCritical и IsSecurityTransparent.The following properties have been added to the System.Reflection namespace to determine whether the type, method, or field is SecurityCritical, SecuritySafeCritical, or SecurityTransparent: IsSecurityCritical, IsSecuritySafeCritical, and IsSecurityTransparent. Используйте эти свойства, чтобы определить прозрачность с помощью отражения, вместо проверки присутствия атрибута.Use these properties to determine transparency by using reflection instead of checking for the presence of the attribute. Правила прозрачности достаточно сложны, и проверки существования атрибута может быть недостаточно.The transparency rules are complex, and checking for the attribute may not be sufficient.

Примечание

Метод SafeCritical возвращает true как для IsSecurityCritical, так и для IsSecuritySafeCritical, так как SafeCritical действительно является критически важным (он имеет те же возможности, что и важный код, но он может быть вызван из прозрачного кода).A SafeCritical method returns true for both IsSecurityCritical and IsSecuritySafeCritical, because SafeCritical is indeed critical (it has the same capabilities as critical code, but it can be called from transparent code).

Динамические методы наследуют прозрачность модулей, к которым они присоединены. Они не наследуют прозрачность типа (если они присоединены к типу).Dynamic methods inherit the transparency of the modules they are attached to; they do not inherit the transparency of the type (if they are attached to a type).

Пропуск проверки при полном доверииSkip Verification in Full Trust

Для прозрачных сборок с полным доверием проверку можно пропустить, установив свойство SkipVerificationInFullTrust равным true в атрибуте SecurityRulesAttribute:You can skip verification for fully trusted transparent assemblies by setting the SkipVerificationInFullTrust property to true in the SecurityRulesAttribute attribute:

[assembly: SecurityRules(SecurityRuleSet.Level2, SkipVerificationInFullTrust = true)]

Свойство SkipVerificationInFullTrust по умолчанию равно false, поэтому для пропуска проверки его нужно установить равным true.The SkipVerificationInFullTrust property is false by default, so the property must be set to true to skip verification. Это следует делать только в целях оптимизации.This should be done for optimization purposes only. Необходимо убедиться, что прозрачный код в сборке является проверяемым с помощью параметра transparent в средстве PEVerify.You should ensure that the transparent code in the assembly is verifiable by using the transparent option in the PEVerify tool.

См. такжеSee also