Безопасность в Silverlight 2 - Знакомство с прозрачностью в Transparency
ОГЛАВЛЕНИЕ
Знакомство с прозрачностью в Transparency
Основное преимущество модели прозрачности Silverlight проявляется в простоте обеспечения безопасности платформы Silverlight. Поскольку Silverlight — закрытая платформа, то проверенных библиотек от независимых производителей для нее еще не выпущено. В результате взаимодействие разработчика с моделью прозрачности Silverlight ограничено прикладными программными интерфейсами, которые разрешено ему вызывать, и которые являются либо прозрачными, либо безопасными ключевыми, поскольку все приложения разработчика могут быть только прозрачными. В то же время .NET Framework закрытой платформой не является, для него поставляются дополнительные библиотеки, и их разработчики только выиграют от более простой модели обеспечения безопасности.
К сожалению, разработчики смогут воспользоваться этими преимуществами только в следующем основном выпуске инфраструктуры для настольных систем. Модель прозрачности, предложенная нами в .NET Framework версии 2.0, помогла существенно упростить анализ и определение степени безопасности библиотек APTCA; модель прозрачности Silverlight является следующим шагом вперед, гарантируя то, что раньше нужно было подтверждать тщательным анализом кода. В будущем мы планируем внедрить более строгие правила прозрачности кода, применения атрибута «безопасный ключевой код» и правила наследования в .NET Framework. Также предполагается, что эти правила будут доступны и сторонним разработчикам.
Одним из главных отличий инфраструктуры для настольных компьютеров от инфраструктуры Silverlight является то, что большинство приложения для настольных компьютеров создавалось для полностью проверенной среды исполнения, тогда как в Silverlight приложения строились с расчетом на частично проверенную среду. Большинство приложений для настольных компьютеров Most desktop applications can do anything they want and would continue to be able to do so—they won't have to think about Transparency at all. С точки зрения внедрения эти приложения будут рассматриваться как критические.
Преимуществами наших сборок для платфомы смогут воспользоваться разработчики библиотек APTCA. Теперь та часть библиотек, которая подвергается проверкам безопасности, сосредоточена на уровне безопасного ключевого кода, поскольку уровень ключевого кода недоступен для частично проверенного, прозрачного кода. Более того, внедрение правил наследования гарантирует, что переопределяемые методы библиотек и производные типы не приведут к появлению слабых мест в системе безопасности. (Необходимо отметить, что из-за большого разнообразия «песочниц» в инфраструктуре настольных систем, библиотеки APTCA должны обрабатывать отдельные разрешения. Таким образом, от API безопасного ключевого кода может потребоваться не только запрашивать разрешения, но и проводить другие проверки корректности входных значений).
Использование более строгих правил прозрачности также приведет к тому, что увеличится производительность и безопасность работы частично проверенных приложений. В .NET Framework, использующем модель прозрачности версии 2.0, если прозрачный код содержит или вызывает небезопасный или непроверяемый код, то происходит подстановка требования на разрешение UnmanagedCodePermission, после чего начинается ресурсоемкий анализ стека. Анализ стека обычно заканчивается неудачей, потому что большинство «песочниц» не имеет полномочий выдавать такое разрешение.
Новая модель прозрачности предполагает, что в этом случае произойдет ошибка, как и в CoreCLR, никаких требований подставлено не будет и, следовательно, анализ стека не потребуется. By bringing the new Transparency model to the next version of the desktop framework, we hope to make it easier to develop APTCA libraries as well as improve the experience around developing partially trusted applications.
Эндрю Дэй (Andrew Dai)