.NET 4, атрибут AllowPartiallyTrustedCallers и метки безопасности, такие как SecurityCritical

Я новый С# и пытаюсь понять новые функции безопасности .NET-4.

Чтобы заполнить некоторые детали, я в настоящее время пытаюсь обновить AutofacContrib.Moq для работы с последним Moq. У меня не было проблем с этим для .NET-3.5 и ниже. Но в .NET-4 ограничения безопасности приводят к многочисленным исключениям безопасности.

Moq имеет единственный метод GetObjectData, который помечен атрибутом SecurityCritical. AutofacContrib.Moq имеет атрибут AllowPartiallyTrustedCallers, который является источником исключений. Похоже, что вместо добавления атрибута SecurityRules с SecurityLevel из 1 мне было бы лучше удалить атрибут AllowPartiallyTrustedCallers. Я считаю, что это делает сборку SecurityTransparent по умолчанию, что может быть недостаточно (хотя проходят тесты модуля AutofacContrib.Moq).

Мой главный вопрос на данный момент заключается в том, должны ли сборки, предназначенные для .NET-4, использовать атрибут AllowPartiallyTrustedCallers? Но, учитывая, что я определенно все еще не понимаю, какие детали следует учитывать при работе с ассемблерами, отмеченными безопасностью? Должен ли я явно указывать свою сборку атрибутами безопасности в тех местах, где он использует, прямо или косвенно, что-то, что помечено SecurityCritical?

Ответ 1

Вы правы: в .NET 4, оставляя APTCA, делает сборку SecurityTransparent, и это может быть причиной того, что вас огорчает.

Статья MSDN Перенос сборки APTCA в .NET Framework 4 содержит хорошее обсуждение и объяснение изменений в AllowPartiallyTrustedCallersAttribute в .NET 4.

В частности:

Изменен атрибут AllowPartiallyTrustedCallers. В версии 4 он больше не имеет ничего общего с требованиями к ссылкам. Фактически, неявный спрос на связь, который присутствовал на подписанных библиотеках в версии 2, ушел. Вместо этого все полностью доверенные сборки в v4 по умолчанию являются SecurityCritical.

[snip/]

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

А...

Поскольку атрибут AllowPartiallyTrustedCallers заставляет всю сборку быть SecurityTransparent по умолчанию, автор сборок должен специально маркировать методы, требующие выполнения привилегированных операций как SecurityCritical или SecuritySafeCritical.

(Это действительно хорошая статья, с которой автор Майк Русос отлично справился. Я рекомендую вам прочитать его целиком.)

Если вы начинаете новую библиотеку .NET 4, вероятно, лучше всего придерживаться модели безопасности .NET 4 и при необходимости использовать соответствующие атрибуты SecurityCritical, SecuritySafeCritical и SecurityTransparent. Им гораздо легче управлять и понимать, чем безопасность старого кода.

Если вы переносите старую библиотеку в новую модель, есть хороший пример в статье о том, как это сделать... но в основном это сводится к удалению старых LinkDemands и добавлению [SecurityCritical] на их место.

В вашем конкретном случае способ быстрее всего - добавить атрибут SecurityRules, чтобы вы получили старое поведение, но я не уверен, что считаю, что правый. Правильный способ, вероятно, состоит в том, чтобы потерять APTCA и добавить SecurityCritical на сборку потому что сборка может содержать код SecurityCritical, а затем пометить различные типы, которые вызывают SecurityCritical code (например, материал, который ссылается на GetObjectData) с SecuritySafeCritical, поэтому ваш код SecurityTransparent может вызвать его. Конечно, этот второй подход будет намного больше работать, поэтому вы, вероятно, захотите запустить SecAnnotate.exe и получить некоторые автоматические советы.

Если посмотреть на сундук Moq, поиск GetObjectData показывает, что рассматриваемый метод является переопределением для механизма сериализации исключения (ISerializable.GetObjectData on System.Exception), который в любом случае будет вызывать только код SecurityCritical, поэтому вы не можете даже столкнуться с какой-либо проблемой, если вы просто потеряете APTCA и отметьте сборку SecurityCritical.

В Autofac есть проблема, чтобы обновить ее до последней модели безопасности. Если вам нравится идея, проголосуйте/прокомментируйте ее.

Жаль, что это был не короткий ответ. Безопасность, к сожалению, никогда не бывает легкой.: S