Skip to main content
Перейти к основному контенту
Hardware Dev Center
Security-Transparent Code, Level 2
 

Прозрачность уровня 2 появилась в версии .NET Framework 4. Ключевыми элементами этой модели являются следующие компоненты: прозрачный код, надежный с точки зрения безопасности код и критический с точки зрения безопасности код.

  • Прозрачный код (в том числе код с полным доверием) может вызывать только другой прозрачный или надежный с точки зрения безопасности код. Прозрачный код может выполнять только действия, разрешенные набором разрешений частичного доверия домена (если он существует). Прозрачный код не может выполнять следующие действия:

    • выполнять метод Assert или повышение привилегий;

    • содержать небезопасный или непроверяемый код;

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

    • вызывать машинный код или код с атрибутом SuppressUnmanagedCodeSecurityAttribute;

    • вызывать член, защищенный с помощью LinkDemand;

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

    Кроме того, прозрачные методы не могут переопределять критические виртуальные методы или реализовывать критические методы интерфейсов.

  • Надежный с точки зрения безопасности код имеет полное доверие, но может вызываться прозрачным кодом. Он предоставляет ограниченный объем кода с полным доверием. В надежном с точки зрения безопасности коде выполняются проверки на правильность и безопасность.

  • Критический с точки зрения безопасности код может вызывать любой код, но не может вызываться из прозрачного кода.

System_CAPS_ICON_caution.jpg Внимание!

Управление доступом для кода и частично доверенный код

Платформа .NET Framework предоставляет механизм для принудительного применения различных уровней доверия к разным частям кода, выполняемым в одном и том же приложении. Этот механизм называется управлением доступом для кода. Управление доступом для кода в .NET Framework не следует использовать в качестве средства безопасности при работе с частично доверенным кодом, особенно кодом неизвестного происхождения. Мы не рекомендуем загружать и выполнять код из неизвестных источников, не предприняв дополнительные меры безопасности.

Эта политика действует в отношении всех версий платформы .NET Framework, кроме платформы .NET Framework в составе Silverlight.

В этом разделе содержатся следующие подразделы.

  • Примеры использования и поведение

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

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

  • Дополнительные сведения и правила

Чтобы указать правила .NET Framework 4 (прозрачность уровня 2), используйте для сборки следующую заметку:

[assembly: SecurityRules(SecurityRuleSet.Level2)]  

Чтобы зафиксировать правила платформы .NET Framework 2.0 (прозрачность уровня 1), используйте следующую заметку:

[assembly: SecurityRules(SecurityRuleSet.Level1)]  

Если сборка не содержит заметок, то по умолчанию используются правила .NET Framework 4. В то же время рекомендуется использовать атрибут SecurityRulesAttribute вместо зависимостей по умолчанию.

Заметка на уровне сборки

Ниже перечислены правила, которые применяются к использованию атрибутов на уровне сборки.

  • Без атрибутов: если атрибуты не указаны, то среда выполнения рассматривает код как критический с точки зрения безопасности за исключением случаев, когда это нарушает правило наследования (например, при переопределении или при реализации прозрачного виртуального метода или метода интерфейса). В таких случаях методы являются надежными с точки зрения безопасности. Если атрибут не указан, то определение правил прозрачности выполняется средой CLR.

  • SecurityTransparent: весь код является прозрачным, а сборка не будет выполнять небезопасных действий или действий, требующих наличия особых привилегий.

  • SecurityCritical: весь код типов в этой сборке является критическим, а остальной код — прозрачным. Этот случай аналогичен отсутствию атрибутов, но среда CLR не определяет правила прозрачности автоматически. Например, если переопределить виртуальный или абстрактный метод или реализовать метод интерфейса, то такой метод по умолчанию будет прозрачным. Следует явным образом пометить метод как SecurityCritical или SecuritySafeCritical. В противном случае при загрузке возникнет исключение TypeLoadException. Это правило также применяется в том случае, если базовый и производный классы находятся в одной сборке.

  • AllowPartiallyTrustedCallers (только уровень 2): весь код по умолчанию является прозрачным. Однако отдельные типы и члены могут иметь другие атрибуты.

В таблице ниже сравнивается поведение сборки уровня 2 и уровня 1.

Assembly - атрибутУровень 2Уровень 1
Частично доверенная сборка без атрибутовТипы и члены по умолчанию являются прозрачными, но могут быть критическими или надежными с точки зрения безопасности.Все типы и члены являются прозрачными.
Атрибут не указанЕсли атрибут не указан, то определение правил прозрачности выполняется средой CLR. Все типы и члены являются критическими с точки зрения безопасности за исключением тех случаев, когда это нарушает правило наследования.В сборке с полным доверием (в глобальном кэше сборок или в сборке, для которой полное доверие указано в домене AppDomain) все типы являются прозрачными, а члены — надежными с точки зрения безопасности.
SecurityTransparentВсе типы и члены являются прозрачными.Все типы и члены являются прозрачными.
SecurityCritical(SecurityCriticalScope.Everything)Неприменимо.Все типы и члены являются прозрачными.
SecurityCriticalКод всех типов в этой сборке является критическим, а остальной код — прозрачным. При переопределении виртуального или абстрактного метода или при реализации метода интерфейса следует явным образом пометить этот метод как SecurityCritical или SecuritySafeCritical.Весь код по умолчанию является прозрачным. Однако отдельные типы и члены могут иметь другие атрибуты.

Заметки для типов и членов

Атрибуты безопасности, которые применяются к типу, также применяются и к членам, которые представлены этим типом. Однако они не применяются к виртуальным или абстрактным переопределениям базового класса, а также к реализациям интерфейса. Ниже перечислены правила, которые применяются к использованию атрибутов на уровне типов и членов.

  • SecurityCritical: тип или член является критическим и может быть вызван только кодом с полным доверием. Методы, представленные в критическом с точки зрения безопасности коде, также являются критическими.

    System_CAPS_ICON_important.jpg Важно

    Виртуальные и абстрактные методы, представленные в базовых классах или интерфейсах и переопределяемые или реализуемые в критическом с точки зрения безопасности классе, по умолчанию являются прозрачными. Их следует пометить как SecuritySafeCritical или SecurityCritical.

  • SecuritySafeCritical: тип или член является надежным с точки зрения безопасности. В то же время этот тип или член может вызываться из прозрачного кода (с частичным доверием) и имеет те же возможности, что и любой другой критический код. Код необходимо проверить на безопасность.

К началу

В таблице ниже представлены разрешенные переопределения метода для прозрачности уровня 2.

Базовый виртуальный член или член интерфейсаПереопределение или интерфейс
TransparentTransparent
TransparentSafeCritical
SafeCriticalTransparent
SafeCriticalSafeCritical
CriticalCritical

К началу

В этом разделе коду Transparent, Critical и SafeCritical в зависимости от доступа и возможностей присваивается следующий порядок:

Transparent < SafeCritical < Critical

  • Правила для типов: по мере движения слева направо доступ становится более ограниченным. Производные типы должны иметь как минимум те же ограничения, что и базовый тип.

  • Правила для методов: производные методы не могут изменять доступность из базового метода. По умолчанию все производные методы без заметок являются методами Transparent. Типы, производные от критических, вызывают возникновение исключения, если переопределенный метод явным образом не помечен как SecurityCritical.

В таблице ниже показаны разрешенные схемы наследования типов.

Базовый классПроизводный класс может быть
TransparentTransparent
TransparentSafeCritical
TransparentCritical
SafeCriticalSafeCritical
SafeCriticalCritical
CriticalCritical

В таблице ниже показаны запрещенные схемы наследования типов.

Базовый классПроизводный класс не может быть
SafeCriticalTransparent
CriticalTransparent
CriticalSafeCritical

В таблице ниже показаны разрешенные схемы наследования методов.

Базовый методПроизводный метод может быть
TransparentTransparent
TransparentSafeCritical
SafeCriticalTransparent
SafeCriticalSafeCritical
CriticalCritical

В таблице ниже показаны запрещенные схемы наследования методов.

Базовый методПроизводный метод не может быть
TransparentCritical
SafeCriticalCritical
CriticalTransparent
CriticalSafeCritical
System_CAPS_ICON_note.jpg Примечание

Эти правила наследования применяются к типам и членам уровня 2. Типы в сборках уровня 1 могут наследоваться от критических с точки зрения безопасности типов и членов уровня 2. Таким образом, типы и члены уровня 2 должны иметь различные требования к наследованию для наследуемых типов и членов уровня 1.

К началу

Поддержка LinkDemand

Модель прозрачности уровня 2 заменяет LinkDemand атрибутом SecurityCriticalAttribute. В устаревшем коде (уровень 1) LinkDemand автоматически рассматривается как Demand.

Отражение

Вызов критического метода или чтение критического поля вызывает требование полного доверия (как при вызове закрытого метода или поля). Таким образом, критический метод может вызываться только в коде с полным доверием, а не в коде с частичным доверием.

В пространство имен System.Reflection добавлены следующие свойства, позволяющие определить, является ли тип, метод или поле SecurityCritical, SecuritySafeCritical или SecurityTransparent: IsSecurityCritical, IsSecuritySafeCritical и IsSecurityTransparent. Используйте эти свойства, чтобы определить прозрачность с помощью отражения, вместо проверки присутствия атрибута. Правила прозрачности достаточно сложны, и проверки существования атрибута может быть недостаточно.

System_CAPS_ICON_note.jpg Примечание

Метод SafeCritical возвращает true для IsSecurityCritical``и IsSecuritySafeCritical, так как код SafeCritical действительно является критическим (имеет те же возможности, что и критический код, но может вызываться из прозрачного кода).

Динамические методы наследуют прозрачность модулей, к которым они присоединены. Они не наследуют прозрачность типа (если они присоединены к типу).

Пропуск проверки при полном доверии

Для прозрачных сборок с полным доверием проверку можно пропустить, установив свойство SkipVerificationInFullTrust равным true в атрибуте SecurityRulesAttribute:

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

Свойство SkipVerificationInFullTrust по умолчанию равно false, поэтому для пропуска проверки его нужно установить равным true. Это следует делать только в целях оптимизации. Убедитесь в том, что прозрачный код в сборке подлежит проверке. Для этого используйте параметр transparent в средстве PEVerify.

Security-Transparent Code, Level 1
Изменения системы безопасности