Безопасность в Silverlight 2 - Модель прозрачности

Модель прозрачности

Модель прозрачности была известна со времен выхода .NET Framework 2.0, откуда она и была перенесена в CoreCLR (так называется версия CLR для Silverlight). Она была разработана, чтобы решить проблему все увеличивающегося количества библиотек инфраструктуры, которые позволяли обращаться к службам из частично проверенного кода, что вызывало проблемы с внутренним аудитом безопасности. Использование библиотек с установленным атрибутом AllowPartiallyTrustedCallers (APTCA) позволяло обращаться к полностью проверенным службам из частично проверенного кода. Из-за этой потенциально опасной операции над определенной частью любой библиотеки с атрибутом APTCA приходилось проводить необходимые проверки безопасности.

Перед созданием модели прозрачности аудит качества кода проводился для сборок APTCA в целом, что требовало большого количества ресурсов, особенно если учесть, что в коде библиотек обычно вызывались лишь привилегированные функции общего назначения. Остальной код был совершенно безопасен.

Основной целью разработки модели прозрачности было создание четких границ между областями исполнения привилегированного и непривилегированного кода. В данной модели использовались две категории кода — Transparent («прозрачный») и Critical («ключевой»). На код, относящийся к категории «прозрачного», накладывались следующие ограничения:

• В нем не должны были подтверждаться полномочия и повышаться права.
• В нем не должно было содержаться небезопасного или непроверяемого кода. В противном случае операция, встретившаяся в прозрачном коде, рассматривалась как ключевая и в прозрачный код включались необходимые требования.
• Ключевой код нельзя было вызывать напрямую. Исключения из этого правила объясняются ниже.
• Нельзя было вызывать системные функции или API, помеченные атрибутом SuppressUnmanagedCodeSecurity.
• Нельзя было удовлетворять LinkDemands, все эти требования должны были приводить к полному анализу стека.
  

Любые требования полномочий проходят через прозрачный код и разрешаются в области приложения. В пределах этого кода требования полномочий подтвердить нельзя. Таким образом, прозрачный код всегда ограничен в правах до уровня «песочницы». Ключевому коду разрешено выполнять функции, о которых было упомянуто выше, на него не накладываются такие ограничения, как на прозрачный код, поэтому качество кода сборок APTCA можно проверять только для ключевых областей сборки.

Как же происходит взаимодействия кода, принадлежащего к разным категориям? Если разработчик уверен, что вызов некоторый ключевого API можно безопасно выполнить из прозрачного кода (например, обращение к API операционной системы, который возвращает дату и время), он помечает такой вызов как TreatAsSafe (в коде используется атрибут SecurityTreatAsSafe). Важно отметить, что в рамках модели прозрачности версии 2.0 правила прозрачности применяются только внутри сборки, в результате все общедоступные ключевые модули неявно становятся TreatAsSafe. (В этой статье я буду ссылаться на эту модель прозрачности как на модель прозрачности версии 2.0 . Такая модель прозрачности используется в .NET Framework версий 3.0, 3.5 и 3.5 с пакетом обновлений 1). В модели прозрачности версии 2.0 общедоступный ключевой метод может быть вызван из прозрачного кода.

Широкое применение модели прозрачности версии 2.0 в последних версиях варианта .NET Framework для настольных систем облегчило рассмотрения вопросов безопасности и обеспечило нашей группе возможность использовать разрабатываемые службы в частично проверенных приложениях. В ходе разработки CoreCLR нам предоставилась возможность не просто улучшить систему прозрачности, но сделать ее основным механизмом обеспечения безопасности библиотеки исполнения и кода, построенного на ее основе.