Изменения системы безопасности в платформе .NET Framework 4

Статья
08/11/2011

В .NET Framework 4 произошли два существенных изменения в области безопасности. Политика безопасности для всего компьютера больше не применяется, хотя система разрешений продолжает функционировать. Кроме того, прозрачность безопасности стала механизмом обеспечения безопасности по умолчанию. (Дополнительные сведения см. в разделе Прозрачный с точки зрения безопасности код, уровень 2.) Помимо этого некоторые действия с разрешениями, которые представляли собой угрозу безопасности, были отмечены как устаревшие.

Важно
Система управления доступом для кода (CAS) сохранена, из нее удалена политика безопасности, но свидетельства и разрешения по прежнему действуют.Удалены некоторые разрешения, а прозрачность позволила упростить обеспечение безопасности.Краткое описание изменений см. в разделе Сводка изменений в функции управления доступом для кода.

Система управления доступом для кода (CAS) сохранена, из нее удалена политика безопасности, но свидетельства и разрешения по прежнему действуют.Удалены некоторые разрешения, а прозрачность позволила упростить обеспечение безопасности.Краткое описание изменений см. в разделе Сводка изменений в функции управления доступом для кода.

Следует принять во внимание следующие основные факты.

Технология прозрачности отделяет код, выполняемый в составе приложения, от кода, выполняемого в составе инфраструктуры. Эта технология представлена в версии .NET Framework 2.0, а теперь усовершенствована для функционирования в качестве механизма обеспечения безопасности доступа к коду. В отличие от политики безопасности правила прозрачности 2 уровня применяются во время выполнения, а не во время загрузки сборки. Эти правила действуют всегда (даже для сборок, которые по умолчанию выполняются с полным уровнем доверия). При этом прозрачность второго уровня не затрагивает полностью доверенный код без аннотации (например, настольные приложения). Сборки (в том числе настольные сборки), отмеченные атрибутом SecurityTransparentAttribute, а также отмеченные методами вызова с помощью атрибута SecurityCriticalAttribute, получают исключение MethodAccessException. Это поведение можно изменить, применив атрибут SecurityRulesAttribute и задав для свойства SecurityRulesAttribute.RuleSet значение Level1; однако это рекомендуется делать только для обеспечения обратной совместимости. Чтобы применить к настольному приложению ограничения, накладываемые прозрачностью, необходимо явным образом отметить это приложение как прозрачное с точки зрения безопасности.
Код, вызывающий интерфейсы API политики безопасности, при выполнении получает исключение NotSupportedException и предупреждения компилятора. Политику можно повторно включить с помощью элемента конфигурации <NetFx40_LegacySecurityPolicy>. При включении политики технология прозрачности безопасности продолжает действовать. политика безопасности применяется при загрузке сборки и не влияет на прозрачность, которые применяется во время выполнения.
Для устаревших разрешений на запросы (RequestMinimum, RequestOptional и RequestRefuse) в компиляторе выводятся предупреждения. Эти элементы не работают в версии .NET Framework 4, но не вызывают возникновения исключений. Запросы Deny вызывают возникновение исключения NotSupportedException во время выполнения.
Действие безопасности LinkDemand не является устаревшим, но не должно использоваться для проверки разрешений. Вместо этого следует использовать атрибут SecurityCriticalAttribute для типов и методов с полным доверием или метод Demand для типов и методов со специальным набором разрешений.
Если приложение создано с помощью Visual Studio 2010, то его можно запустить без этих изменений путем указания в параметрах проекта Visual Studio целевой версии .NET Framework, предшествующей .NET Framework 4. При этом использование новых типов и участников .NET Framework 4 будет невозможным. Более раннюю версию платформы .NET Framework также можно указать с помощью элемента <supportedRuntime> в схеме параметров запуска файла конфигурации приложения.

В следующих разделах эти и другие изменения .NET Framework 4 рассматриваются более подробно:

Упрощение политики безопасности
Прозрачность безопасности уровня 2
Устаревшие запросы разрешений
Условный оператор APTCA
Объекты свидетельства
Коллекции свидетельств

Упрощение политики безопасности

В версии .NET Framework 4 среда CLR больше не определяет политику безопасности для компьютеров. Платформа .NET Framework раньше предоставляла политику управления доступом для кода (CAS) в качестве механизма подробного контроля и настройки возможностей управляемого кода. Политика разграничения доступа кода CAS является мощным инструментом, но может оказаться чрезмерно сложным, а также может накладывать излишние ограничения. Более того, политика разграничения доступа кода не применяется к собственным приложениям, поэтому предоставляемые ей гарантии безопасности ограничены. Для замены политики разграничения доступа кода в системах Windows 7 и Windows Server 2008 R2 администраторам следует обратить внимание на решения уровня операционной системы, например на политики ограниченного использования программ Windows (SRP) или AppLocker. Политики SRP и AppLocker предоставляют простые механизмы доверия, которые могут применяться к управляемому и машинному коду. Технологии SRP и AppLocker представляют собой более простые решения безопасности и обеспечивают большие гарантии безопасности, чем политика разграничения доступа кода.

В версии .NET Framework 4 политика безопасности на уровне компьютера по умолчанию отключена. Неразмещенные приложения (т.е. приложения, выполняемые в проводнике Windows или из командной строки) теперь выполняются с полным уровнем доверия. Это также справедливо для всех приложений, которые размещены на общих ресурсах в локальной сети. Размещенные приложения или приложения изолированной среды выполняются в соответствии с политиками безопасности, определенными их узлами (например, приложением Internet Explorer, ClickOnce или ASP.NET). Приложения или элементы управления, выполняемые в изолированной среде, рассматриваются как частично доверенные.

Для упрощения политики безопасности модель прозрачности была применена к платформе .NET Framework. Приложения и элементы управления, выполняемые на узле или в изолированной среде с ограниченным набором разрешений, которые предоставлены средой, считаются прозрачными. Технология прозрачности позволяет не заниматься проверкой политики разграничения доступа кода при запуске частично доверенных приложений. Прозрачные приложения просто выполняются с использованием собственного предоставленного набора разрешений. Программистам следует учитывать только тот факт, что приложения должны использовать предоставленный набор разрешений для конкретной изолированной среды и не должны вызывать код, требующий полного доверия (критический с точки зрения безопасности).

Важно
В результате этих изменений политики безопасности при вызове устаревших типов политик и участников разграничения доступа кода CAS явным или неявным образом (через другие типы и члены) могут возникать предупреждения компиляции и исключения среды выполнения.Список устаревших типов и участников, а также заменяющих элементов см. в разделе Совместимость политики разграничения доступа кода и ее миграция. Можно избежать возникновения ошибок и предупреждений, если включить в элементе конфигурации <NetFx40_LegacySecurityPolicy> схемы параметров среды выполнения политику разграничения доступа кода прежних версий.При этом указание устаревшей политики безопасности не подразумевает использования любых пользовательских политик разграничения доступа кода CAS для данной версии, если они не перенесены в .NET Framework 4. Кроме того, устаревшую политику разграничения доступа CAS можно включить путем настройки версии, предшествующей .NET Framework 4, в качестве целевой версии платформы .NET Framework для проекта Visual Studio. Это обеспечивает использование устаревшей политики разграничения доступа CAS и включение пользовательских политик разграничения доступа CAS, указанных для данной версии.При этом использование новых типов и участников .NET Framework 4 будет невозможным.Более раннюю версию платформы .NET Framework также можно указать с помощью элемента <supportedRuntime> в схеме параметров запуска.

В результате этих изменений политики безопасности при вызове устаревших типов политик и участников разграничения доступа кода CAS явным или неявным образом (через другие типы и члены) могут возникать предупреждения компиляции и исключения среды выполнения.Список устаревших типов и участников, а также заменяющих элементов см. в разделе Совместимость политики разграничения доступа кода и ее миграция.

Можно избежать возникновения ошибок и предупреждений, если включить в элементе конфигурации <NetFx40_LegacySecurityPolicy> схемы параметров среды выполнения политику разграничения доступа кода прежних версий.При этом указание устаревшей политики безопасности не подразумевает использования любых пользовательских политик разграничения доступа кода CAS для данной версии, если они не перенесены в .NET Framework 4.

Кроме того, устаревшую политику разграничения доступа CAS можно включить путем настройки версии, предшествующей .NET Framework 4, в качестве целевой версии платформы .NET Framework для проекта Visual Studio. Это обеспечивает использование устаревшей политики разграничения доступа CAS и включение пользовательских политик разграничения доступа CAS, указанных для данной версии.При этом использование новых типов и участников .NET Framework 4 будет невозможным.Более раннюю версию платформы .NET Framework также можно указать с помощью элемента <supportedRuntime> в схеме параметров запуска.

К началу

Прозрачность безопасности уровня 2

Прозрачность безопасности была представлена в версии .NET Framework 2.0, но была ограничена и использовалась в основном для повышения эффективности проверки кода. В версии .NET Framework 4 прозрачность является механизмом обеспечения безопасности и отделяет код, выполняемый в составе приложения, от кода, выполняемого в составе инфраструктуры. Технология прозрачности разделяет код, которому разрешено выполнять привилегированные действия (критически важный код, например вызов машинного кода), и код, не имеющий подобного разрешения (прозрачный код). Прозрачный код может выполнять команды в рамках используемого набора разрешений, но не может выполнять, вызывать и содержать критический код, а также быть образованным от него.

Основной целью функции прозрачности является обеспечение простого и эффективного механизма для изоляции различных групп кода на основе привилегий. В модели изолированной среды такие группы привилегий имеют полное доверие (то есть не ограничены) или частичное доверие (то есть ограничены набором разрешений, предоставленных изолированной среде).

Настольные приложения выполняются с полным доверием, поэтому модель прозрачности не влияет на их работу. Дополнительные сведения об изменениях системы прозрачности безопасности см. в разделе Прозрачный с точки зрения безопасности код, уровень 2.

К началу

Устаревшие запросы разрешений

Применение запросов разрешений Deny, RequestMinimum, RequestOptional и RequestRefuse теперь не поддерживается средой выполнения. Обычно эти запросы трактовались неверно и повышали вероятность возникновения угроз безопасности при неправильном использовании.

Действие Deny можно было легко переопределить с помощью действия Assert. Код в сборке мог выполнить действие Assert для любого разрешения, если оно содержалось в предоставленном наборе для сборки. Действие Assert предотвращало отображение Deny в стопке, что снижало эффективность.
Эффективное использование RequestMinimum вне области приложения было невозможным. При возникновении RequestMinimum в исполняемом файле (расширение EXE) и несоответствующем наборе предоставленных разрешений конечные пользователи файла получали необработанное исключение FileLoadException, не содержавшее сведений об исправлении ошибки. Использование одного минимального набора запросов для библиотек (DLL-файлов) было невозможно, то как различные типы и участники сборки обычно имеют различные требования к разрешениям.
Элемент RequestOptional вызывал затруднения и часто некорректно использовался, что вызывало неожиданные результаты. Разработчики могли не включать разрешения в список, не сознавая при этом, что это вызывает явный отказ предоставления этих разрешений.
Элемент RequestRefuse не предоставлял эффективную модель наименьших привилегий, так как разработчику приходилось явным образом указывать все ненужные разрешения вместо указания только необходимых разрешений. Кроме того, при появлении новых разрешений их включение в список было невозможно. Более того, отказ не имел значения для всех разрешений. Например, можно было выполнить отказ от значения свойства UserQuota в разрешении IsolatedStoragePermission.

Наконец, указание только ненужных разрешений повышало вероятность возникновения уязвимости, если разработчик не определял все потенциально опасные разрешения.
RequestOptional и RequestRefuse позволяли разработчикам разбивать однородные домены путем создания нескольких наборов разрешений внутри домена.

.NET Framework 4 удаляет применение этих значений перечисления во время выполнения. Загрузка сборок, содержащих атрибуты, которые используют эти значения SecurityAction, будет продолжена, но среда CLR не выполнит отказ от загрузки ссылочных сборок и не изменит набор предоставленных разрешений в зависимости от набора разрешений.

К началу

Условный оператор APTCA

Условный атрибут AllowPartiallyTrustedCallersAttribute (APTCA) позволяет основным приложениям определять сборки, доступ к которым может быть разрешен частично доверенному вызывающему коду, загруженному в контексте приложения. Сборки-кандидаты необходимо заранее подготовить для частичного доверия. Это означает, что эти сборки должны быть либо надежными с точки зрения безопасности в модели прозрачности (то есть содержать атрибут APCTA), либо являться полностью прозрачными. С помощью нового конструктора класса AllowPartiallyTrustedCallersAttribute ведущее приложение может указывать уровень видимости для сборки APTCA, используя перечисление PartialTrustVisibilityLevel в вызове конструктора.

К началу

Объекты свидетельства

До версии .NET Framework 4 в качестве объекта свидетельства мог использоваться практически любой объект, если он применялся в коде размещения как свидетельство. Например, предположим, что код платформы .NET Framework распознает объекты System.Uri как свидетельство. Среда выполнения определяет объекты свидетельства как ссылки System.Object и не применяет к ним средства безопасности типа.

Это вызывало проблемы, так как платформа .NET Framework накладывала неявные ограничения на типы, которые могли использоваться в качестве объектов свидетельства. В частности, все объекты свидетельства должны были быть сериализуемыми и не могли иметь значение null. Если эти требования не были выполнены, среда CLR вызывала исключение при каждом выполнении операции, требующей выполнения одного из предположений.

Чтобы наложить ограничения на типы объектов, использующихся в качества свидетельства, и предоставить возможность добавления новых функций и требований для всех объектов свидетельства, в версии .NET Framework 4 используется новый базовый класс System.Security.Policy.EvidenceBase, производными от которого должны быть все объекты свидетельства. Класс EvidenceBase обеспечивает возможность сериализации объекта свидетельства после создания экземпляра. Кроме того, разработчик может создавать новые требования к свидетельствам путем добавления новых реализаций по умолчанию в базовый класс.

Обратная совместимость

Все типы, используемые средой CLR как объекты свидетельств, были обновлены в .NET Framework 4; теперь они наследуют от EvidenceBase. При этом пользовательские типы свидетельства, используемые приложениями сторонних разработчиков, не определяются и не могут быть обновлены. Таким образом, такие типы свидетельства не могут использоваться с новыми членами, которые ожидают объекты свидетельства, производные от класса EvidenceBase.

К началу

Коллекции свидетельств

В версиях до .NET Framework 4 среда CLR создавала полный набор объектов свидетельства, которые применялись к сборке при ее загрузке. Такие объекты хранились в особом списке. Для использования конкретного объекта пользователи выполняли последовательный поиск по этому списку. Таким образом, были доступны все объекты свидетельства (вне зависимости от их использования). Для большинства объектов свидетельства это поведение не представляло собой проблемы, но для таких объектов свидетельства, как System.Security.Policy.Publisher (этот объект требует проверки Authenticode), оно было неэффективным.

Чтобы усовершенствовать технологию обработки, процесс взаимодействия с коллекцией свидетельств в .NET Framework 4 был переработан. Теперь коллекция свидетельств выступает в роли словаря, а не списка. Вместо последовательного поиска требуемого объекта свидетельства в коллекции свидетельств пользователи могут запросить определенный тип свидетельства, а коллекция возвратит его, если он был найден. Например, вызов StrongName name = evidence.GetHostEvidence<StrongName>(); возвращает объект StrongName, если свидетельство существует. В противном случае возвращается значение null.

Модель словаря откладывает создание объектов до момента их запроса. В примере свидетельства Publisher процедура проверки подписи Authenticode в сборке выполняется только при запросе такой информации. В общем случае приложений с полным доверием, не требующих свидетельства Publisher, процесс проверки полностью пропускается.

К началу