.NET 4, атрибут AllowPartiallyTrustedCallers и метки безопасности, такие как SecurityCritical
Я новый C# и пытаюсь понять новые функции безопасности .NET-4.
чтобы заполнить некоторые детали, я в настоящее время пытаюсь обновить AutofacContrib.Moq для работы с последним Moq. У меня не было проблем с этим для .NET-3.5 и ниже. Но в .NET-4 ограничения безопасности приводят к многочисленным исключениям безопасности.
Moq имеет одиночный метод,GetObjectData вот помеченные SecurityCritical. AutofacContrib.Обьем Moq имеет allowpartiallytrustedcallers, так набор атрибутов, который является источником исключения. Кажется, что вместо добавления SecurityRules атрибут с SecurityLevel 1, мне было бы лучше удалить . Я считаю, что это делает сборку SecurityTransparent по умолчанию, что может быть недостаточно (хотя AutofacContrib.Модульные тесты Moq проходят).
мой главный вопрос на данный момент, является ли сборки таргетинга .Объем-4 должны когда-либо использовать Атрибут AllowPartiallyTrustedCallers? Но, учитывая, что я определенно еще не все понимаю, какие детали следует учитывать при работе со сборками, которые отмечены безопасностью? Нужно ли явно отмечать мою сборку атрибутами безопасности в тех местах, где она использует, прямо или косвенно, что-то, что помечено SecurityCritical?
1 ответов
вы правы: в .NET 4, оставляя APTCA там, делает сборку SecurityTransparent, и это может быть то, что вызывает у вас горе.
статья MSDN перенос сборки APTCA в .NET Framework 4 имеет хорошее обсуждение и объяснение изменений в AllowPartiallyTrustedCallersAttribute в .NET 4.
в частности:
атрибут AllowPartiallyTrustedCallers изменился. В v4 он больше не имеет все, что связано с требованиями link. Фактически, неявное требование ссылки, которое присутствовало в подписанных библиотеках в v2, исчезло. Вместо этого все полностью доверенные сборки в v4 по умолчанию являются SecurityCritical.
[snip /]
в v4 эффект APTCA заключается в удалении автоматического SecurityCritical поведения из сборки, к которой он применяется.
и...
поскольку атрибут AllowPartiallyTrustedCallers вызывает чтобы вся сборка была SecurityTransparent по умолчанию, автор сборки должен специально отметить методы, необходимые для выполнения привилегированных операций как SecurityCritical или SecuritySafeCritical.
(Это действительно хорошая статья, с которой автор Майк Русос проделал большую работу. Я призываю вас прочитать его полностью.)
Если вы запускаете новую библиотеку .NET 4, вероятно, лучше придерживаться модели безопасности .NET 4 и использовать соответствующую SecurityCritical, SecuritySafeCritical и SecurityTransparent атрибуты, где это необходимо. Ими гораздо проще управлять и понимать, чем старый код безопасности доступа.
Если вы переносите старую библиотеку на новую модель, в статье есть хороший пример того, как это сделать... но в основном это означает удаление старых LinkDemands и добавление [SecurityCritical] на их место.
в вашем конкретном случае быстрый способ получить собирается было бы добавить атрибут SecurityRules, поэтому вы получаете старое поведение, но я не уверен, что буду считать, что право путь. Правильный путь, вероятно, будет потерять APTCA и добавить SecurityCritical на сборке потому что сборка может содержать SecurityCritical код, затем отметьте различные типы, которые вызывают SecurityCritical код (например, материал, который ссылается на GetObjectData) с SecuritySafeCritical так что ваш SecurityTransparent код может вызвать его. Конечно, этот второй подход будет намного больше работы, поэтому вы, вероятно, захотите запустить SecAnnotate.exe и получить некоторые автоматические советы.
глядя на магистраль Moq, поиск GetObjectData показывает, что рассматриваемый метод является переопределением механизма сериализации исключений (ISerializable.GetObjectData в системе.Исключение), который в любом случае будет вызывать только SecurityCritical code, поэтому вы даже не можете столкнуться с какими-либо проблемами, если вы просто потеряете APTCA и отметите сборку Как securitycritical.
существует проблема, поданная на Autofac, чтобы обновить его до последней модели безопасности. Если вам нравится идея, голосуйте / комментируйте ее.
извините, это был не короткий ответ. Безопасность, к сожалению, никогда не бывает легкой. : S