Программирование для Silverlight с помощью CoreCLR - Модель безопасности CoreCLR
ОГЛАВЛЕНИЕ
Модель безопасности CoreCLR
Другое большое изменение в ядре относится к новой модели безопасности. Обратите внимание, что разработчики .NET традиционно использовали разграничение доступа из кода (Code Access Security – CAS) для предотвращения выполнения привилегированных операций не пользующимся доверием кодом. CAS обладает большими возможностями, но довольно замысловато. Оно позволяет пользователю или администратору определять различные «песочницы» для кода, используя наборы разрешений, и затем сопоставлять индивидуальные сборки с этими «песочницами». Для приложений Silverlight нам нужна лишь одна «песочница», эквивалентная той, что Internet Explorer использует для выполнения сценариев на веб-странице. Этот упрощенный случай позволил нам целиком удалить политику CAS.
Мы также упростили модель обеспечения безопасности. Новая модель основана на прозрачности безопасности – концепции, появившейся в CLR версии 2.0. В центре модели прозрачности лежит разделение кода на три категории: Transparent («Прозрачный»), SafeCritical («Безопасный ключевой») и Critical («Ключевой»). Transparent, низший уровень доверия для кода, не может повышать уровень прав, а также получать доступ к конфиденциальным ресурсам и информации на компьютере. В Silverlight 2 весь код приложений имеет уровень Transparent. Код уровня Critical, наивысшего уровня доверия, может взаимодействовать с системой через P/Invoke или даже содержать непроверяемый код. Для Silverlight 2 весь код уровня Critical должен быть частью платформы Silverlight. Тогда код SafeCritical действует как мост, позволяющий коду уровня Transparent получать доступ к системным ресурсам путем вызова кода Critical. Считайте коде уровня Critical интерфейсом API ядра Windows, код уровня Transparent кодом приложений пользователя и коде SafeCritical интерфейсом API между пользовательским кодом и кодом ядра.
Код уровня Transparent может вызывать только код уровней Transparent и SafeCritical. Код SafeCritical может затем вызвать код уровня Critical от имени пользовательского кода. Обязанностью кода уровня SafeCritical является «канонизация», или помещение в стандартный формат, ввода и «дезинфекция» вывода кода уровня Critical для защиты безопасности системы (см. рис. 1).
Необходимость канонизации ввода в код уровня Critical чуть более самоочевидна, чем необходимость дезинфекции вывода. Например, если моему веб-приложению необходимо записать файл на локальный диск, оно может сделать это используя изолированное хранилище. Однако весьма желательно, чтобы мое приложение не требовало записи в файл, именуемый "..\..\..\..\bootmgr", так что важно убедиться, что ввод находится в регулярном, каноническом формате. Мысль о том, что вывод кода уровня Critical является угрозой безопасности, несколько более необычна. Ключевая концепция безопасности состоит в том, что контроль над раскрытием информации очень важен при уменьшении общей области, открытой для атак. Предположим, я попытаюсь получить доступ к какому-то элементу пользовательской информации на вашей системе и получу ответ «в разрешении отказано». Когда я повторю ту же операцию доступа, но для другого пользователя, я получу ответ «пользователь Боб не существует». Если я знаю, что выдаются оба ответа, я могу повторять неверные попытки доступа, чтобы собрать список имен пользователей системы.
Упрощенная политика безопасности является явным выигрышем для разработчиков, работающих в коде .NET, но она также помогает разработчикам, работающим над кодом .NET. Мы постарались отмечать код как Critical и SafeCritical, только когда это необходимо. Пребывание большинства кода на уровне Transparent помогает нам уменьшить объем кода, которому необходимо внимательное рассмотрение с точки зрения безопасности. Нам все еще приходится просматривать наш код уровня Transparent на предмет верности и безопасности, но, по крайней мере, мы знаем, что он не может выполнять привилегированных операций. Большие куски Silverlight, включая среду выполнения динамического языка (DLR), целиком написаны в коде уровня Transparent. Ограничение привилегированной части Silverlight позволяет нам поставлять более безопасный продукт путем сосредоточения нашего внимания на областях, которым оно действительно требуется.