Прозрачный с точки зрения безопасности код, уровень 2
Прозрачность второго уровня 2 была представлена в версии .NET Framework 4. Ключевыми элементами этой системы являются следующие компоненты: прозрачный код, надежный с точки зрения безопасности код и критический с точки зрения безопасности код.
Прозрачный код (в том числе код с полным доверием) может вызывать только другой прозрачный или надежный с точки зрения безопасности код. Прозрачный код может выполнять только действия, разрешенные набором разрешений частичного доверия домена (если он существует). Прозрачный код не может выполнять следующие действия:
Выполнять метод Assert или повышение привилегий.
Содержать небезопасный или непроверяемый код.
Напрямую вызывать критический код.
Вызывать машинный код или код с атрибутом SuppressUnmanagedCodeSecurityAttribute.
Вызывать участников, защищенных с помощью LinkDemand.
Наследовать от критических типов.
Кроме того, прозрачные методы не могут переопределять критические виртуальные методы или реализовывать критические методы интерфейсов.
Надежный с точки зрения безопасности код имеет полное доверие, но может вызываться прозрачным кодом. Он предоставляет ограниченный объем кода с полным доверием. В надежном с точки зрения безопасности коде выполняются проверки на правильность и безопасность.
Критический с точки зрения безопасности код может вызывать любой код, но не может вызываться из прозрачного кода.
В этом разделе содержатся следующие подразделы.
Примеры использования и поведение
Схемы переопределения
Правила наследования
Дополнительные сведения и правила
Примеры использования и поведение
Чтобы указать правила .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.
Атрибут сборки |
Уровень 2 |
Уровень 1 |
|---|---|---|
Частично доверенная сборка без атрибутов |
Типы и участники по умолчанию являются прозрачными, но могут быть критическими или надежными с точки зрения безопасности. |
Все типы и члены являются прозрачными. |
Атрибут не указан |
Если атрибут не указан, то определение правил прозрачность выполняется средой CLR. Все типы и участники являются критическими с точки зрения безопасности за исключением тех случаев, когда это нарушает правило наследования. |
В сборке с полным доверием (в глобальном кэше сборок или в сборке, для которой полное доверие указано в домене AppDomain) все типы являются прозрачными, а участники — надежными с точки зрения безопасности. |
SecurityTransparent |
Все типы и члены являются прозрачными. |
Все типы и члены являются прозрачными. |
SecurityCritical(SecurityCriticalScope.Everything) |
Неприменимо. |
Все типы являются критически важными для безопасности. |
SecurityCritical |
Код всех типов в этой сборке является критическим, а остальной код — прозрачным. При переопределении виртуального или абстрактного метод или при реализации метода интерфейса следует явным образом пометить этот метода как SecurityCritical или SecuritySafeCritical. |
Код становится прозрачным по умолчанию. Однако отдельные типы и члены могут иметь другие атрибуты. |
Заметки для типов и участников
Атрибуты безопасности, который применяются к типу, также применяются и к участникам, которые представлены данным типом. В то же время они не применяются к виртуальным или абстрактным переопределениям базового класса, а также к реализациям интерфейса. Ниже перечислены правила, которые применяются к использованию атрибутов на уровне типов и участников.
SecurityCritical: тип или участник являются критическими и могут быть вызваны только кодом с полным доверием. Методы, представленные в критическом с точки зрения безопасности коде, также являются критическими.
.gif "Важное примечание")
ВажноВиртуальные и абстрактные методы, представленные в базовых классах или интерфейсах, переопределяемые или реализуемые в критическом с точки зрения безопасности классе, по умолчанию являются прозрачными.Их необходимо отметить как SecuritySafeCritical или SecurityCritical.
SecuritySafeCritical: тип или участник являются надежными с точки зрения безопасности. В то же время эти типы и участники могут вызываться из прозрачного кода (с частичным доверием), а также имеют те же возможности, что и любой другой критический код. Код необходимо проверить на безопасность.
К началу
Схемы переопределения
В следующей таблице представлены разрешенные переопределения метода для прозрачности уровня 2.
Базовый виртуальный участник или участник интерфейса |
Переопределение или интерфейс |
|---|---|
Transparent |
Transparent |
Transparent |
SafeCritical |
SafeCritical |
Transparent |
SafeCritical |
SafeCritical |
Critical |
Critical |
К началу
Правила наследования
В этом разделе коду Transparent, Critical и SafeCritical в зависимости от доступа и возможностей присваивается следующий порядок:
Transparent < SafeCritical < Critical
Правила для типов: по мере движения справа налево доступ становится более ограниченным. Производные типы должны иметь как минимум те же ограничения, что и базовый тип.
Правила для методов: производные методы не могут изменять доступность из базового метода. По умолчанию все производные методы без пометок являются методами Transparent. Типы, производные от критических, вызывают возникновение исключения, если переопределенный метод явным образом не помечен как SecurityCritical.
В следующей таблице показана разрешенная схема наследования типов.
Базовый класс |
Производный класс может быть |
|---|---|
Transparent |
Transparent |
Transparent |
SafeCritical |
Transparent |
Critical |
SafeCritical |
SafeCritical |
SafeCritical |
Critical |
Critical |
Critical |
В следующей таблице показана неразрешенная схема наследования типов.
Базовый класс |
Производный класс не может быть |
|---|---|
SafeCritical |
Transparent |
Critical |
Transparent |
Critical |
SafeCritical |
В следующей таблице показана разрешенная схема наследования методов.
Базовый метод |
Производный метод может быть |
|---|---|
Transparent |
Transparent |
Transparent |
SafeCritical |
SafeCritical |
Transparent |
SafeCritical |
SafeCritical |
Critical |
Critical |
В следующей таблице показана неразрешенная схема наследования методов.
Базовый метод |
Производный метод не может быть |
|---|---|
Transparent |
Critical |
SafeCritical |
Critical |
Critical |
Transparent |
Critical |
SafeCritical |
.gif "Примечание") Примечание |
|---|
Эти правила наследования применяются к типам и участникам уровня 2.Типы в сборках уровня 1 могут наследовать от критических с точки зрения безопасности типов и участников уровня 2.Таким образом, типы и участники уровня 2 должны иметь различные требования к наследованию для базовых объектов уровня 1. |
К началу
Дополнительные сведения и правила
Поддержка LinkDemand
Модель прозрачность уровня 2 заменяет LinkDemand атрибутом SecurityCriticalAttribute. В устаревшем коде (уровень 1) LinkDemand автоматически рассматривается как Demand.
Отражение
Вызов критического метода или чтение критического поля вызывает требование полного доверия (как при вызове закрытого метода или поля). Таким образом, критический метод может вызываться только в коде с полным доверием, а не в коде с частичным доверием.
В пространство имен System.Reflection добавлены следующие свойства, позволяющие определить, является ли тип, метод или поле SecurityCritical, SecuritySafeCritical или SecurityTransparent: IsSecurityCritical, IsSecuritySafeCritical и IsSecurityTransparent. Используйте эти свойства, чтобы определить прозрачность с помощью отражения, вместо проверки присутствия атрибута. Правила прозрачности достаточно сложны, и проверки существования атрибута может быть недостаточно.
| Примечание |
|---|
Метод SafeCritical возвращает true для IsSecurityCritical и IsSecuritySafeCritical, так как SafeCritical действительно является критическим (имеет те же возможности, что и критический код, но может вызываться из прозрачного кода). |
Динамические методы наследуют прозрачность модулей, к которым они присоединены. Они не наследуют прозрачность типа (если они присоединены к типу).
Пропуск проверки при полном доверии
Для сборок с полным доверием проверку можно пропустить, установив свойство SkipVerificationInFullTrust равным true в атрибуте SecurityRulesAttribute:
[assembly: SecurityRules(SecurityRulesSet.Level2, SkipVerificationInFullTrust = true)]
Свойство SkipVerificationInFullTrust по умолчанию равно false, поэтому свойство должно быть установлено равным true для пропуска проверки. Это действие можно выполнять только в целях оптимизации. Следует убедиться в том, что прозрачный код в сборке подлежит проверке. Для этого используется параметр transparent в средстве PEVerify.
К началу