Обязательный контроль целостности

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
компонент Windows
Обязательный контроль целостности
Тип компонента Безопасность
Включён в Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows 10
Название сервиса Mandatory Integrity Control, MIC
Описание сервиса Контроль доступа к файлам и процессам
Состояние Активное

Обязательный контроль целостности (англ. Mandatory Integrity Control, MIC) представляет собой новую функцию безопасности, внедренную в Windows Vista и реализованную в следующей линейке операционных систем Windows, которая добавляет управление доступом с помощью уровней целостности (англ. Integrity Levels, IL). Уровень целостности представляет собой уровень надежности субъекта или объекта доступа. Цель этого механизма заключается в использовании политик управления целостностью и уровнями целостности задействованных субъектов и объектов для ограничения доступа процессам, которые считаются потенциально менее надежными, по сравнению с доверенными процессами, работающими под той же учетной записью пользователя.

Реализация[править | править код]

Обязательный контроль целостности определяется с помощью нового типа записи управления доступом (ACE) для представления уровня целостности объекта в его дескрипторе безопасности. В Windows списки управления доступом (ACL) обычно используются для предоставления прав доступа (разрешения на чтение, запись и выполнение) пользователям или группам. При инициализации маркеру доступа процесса присваивается уровень целостности. Когда поток пытается получить доступ к объекту (например, файлу), монитор ссылок сравнивает уровень целостности в маркере доступа процесса или потока с уровнем целостности в дескрипторе безопасности объекта. Windows ограничивает разрешенные права доступа в зависимости от того, является ли уровень целостности субъекта выше или ниже, чем уровень целостности объекта, в зависимости от заданной политики целостности в записи управления доступом (ACE). Подсистема безопасности использует уровни целостности для мандатного разграничения доступа, в отличие от дискреционного разграничения доступа, который реализован с помощью традиционных DACL.

В Windows Vista и более поздних определены 5 уровней целостности IL[1]:

недоверенный (SID: S-1-16-0),

низкий (SID: S-1-16-4096),

средний (SID: S-1-16-8192),

высокий (SID: S-1-16-12288)

системный (SID: S-1-16-16384).

По умолчанию процессы, запускаемые обычным пользователем (в том числе администратором), получают средний уровень целостности, а процессы запущенные через UAC с правами администратора — высокий.[2] С помощью задания различных уровней целостности, обязательный контроль целостности позволяет изолировать потенциально уязвимые приложения (например, приложения, ориентированные на работу в Интернете, офисные приложения, которые используются для открытия документов, полученных из недоверенных источников и т.д.). Процессы с низким уровнем целостности имеют меньший доступ (ограничены права на запись в объекты системы), чем процессы с более высокими уровнями целостности, т.к. обязательный (мандатный) контроль доступа осуществляется самой ОС Windows.

Объекты с ACL, такие как именованные объекты, включая файлы, ключи реестра или другие процессы и потоки, имеют запись в ACL, которая определяет уровень целостности этого объекта. Она определяет минимальный уровень целостности процесса, который может использовать данный объект. Для объектов Windows по умолчанию задана мандатная политика целостности No-Write-Up (запрет на запись вверх), которая определяет, что процесс может записывать или удалять объект только тогда, когда его уровень целостности равен или превышает уровень целостности объекта.[2] Поэтому, процесс, имеющий уровень целостности Low, не может открыть для записи файл, имеющий уровень целостности Medium, даже если DACL предоставляет процессу право записи.

Кроме того, процессы с низким уровнем целостности не могут открыть для чтения объекты процессов с более высоким уровнем целостности, поскольку для объектов процессов по умолчанию задана мандатная политика целостности No-Read-Up (запрет на чтение вверх).[3] Следовательно, процесс не может взаимодействовать с другим процессом, имеющим более высокий уровнем целостности. Процесс не может выполнять такие функции, как внедрение dll в процесс высшего уровня целостности, используя API-функцию создания удаленного потока[4], или отправить данные в другой процесс, используя функцию записи памяти процесса[5].

Применение[править | править код]

Хотя процессы наследуют уровень целостности процесса, создавшего его, уровень целостности можно настроить во время создания процесса. Помимо ограничения отправки оконных сообщений в технологии изоляции пользовательских интерфейсов (UIPI), обязательный контроль целостности используется такими приложениями, как Adobe Reader, Google Chrome, Internet Explorer и« проводник Windows», чтобы изолировать документы от уязвимых объектов в системе.[1]

Internet Explorer 7 применяет параметр «Защищенный режим» на основе обязательного контроля целостности, чтобы контролировать, открыта ли веб-страница как процесс с низким уровнем целостности или нет (при условии, что операционная система поддерживает обязательный контроль целостности) на основе настроек зон безопасности, тем самым предотвращая некоторые классы уязвимостей в безопасности. Поскольку Internet Explorer в этом случае работает как процесс с низким уровнем целостности, он не может изменять объекты системного уровня — файлы и операции реестра вместо этого «виртуализируются». Adobe Reader 10 и Google Chrome — это два других известных приложения, которые внедряют эту технологию, чтобы снизить их уязвимость для вредоносных программ.[6]

В Microsoft Office 2010 была представлена изолированная среда («песочница») под названием «Защищенный просмотр» для Excel, PowerPoint и Word, которая запрещает потенциально опасным документам изменять компоненты, файлы и другие ресурсы в системе.[7] «Защищенный просмотр» работает как процесс с низким уровнем целостности, а в Windows Vista и более поздних выпусках Windows использует обязательный контроль целостности и технологию изоляции пользовательских интерфейсов (UIPI) для дальнейшего ограничения «песочницы».[8]

Однако в некоторых случаях процесс с более высоким уровнем целостности должен выполнять определенные функции против процесса с более низким уровнем целостности, или для процесса с более низким уровнем целостности требуется доступ к ресурсам, доступ к которым может получить только процесс с более высоким уровнем целостности (например, при просмотре веб-страницы в защищенном режиме, сохранении файла, загруженного из Интернета, в папку, указанную пользователем).[1] Процессы с высоким и низким уровнями целостности все еще могут взаимодействовать друг с другом, используя файлы, Именованные каналы, LPC или другие общие объекты. Общий объект должен иметь низкий уровень целостности и делиться как процессами низкого уровня целостности, так и высокого.[3] Поскольку обязательный контроль целостности не мешает процессу с низким уровнем целостности обмениваться объектами с процессом с более высоким уровнем целостности, он может вызвать недостатки в процессе с более высоким уровнем целостности и заставить его работать от имени низкого уровня целостности, вызывая Squatting-атаку.[3] Тем не менее, «подрывные атаки» могут быть предотвращены за счет использования привилегии пользователя, которая использует преимущества обязательного контроля целостности.

См. также[править | править код]

Примечания[править | править код]

  1. 1 2 3 Matthew Conover. "Анализ модели безопасности Windows Vista" (англ.) (недоступная ссылка). symantec.. Symantec Corporation. Дата обращения: 29 декабря 2017. Архивировано 16 мая 2008 года.
  2. 1 2 Mandatory integrity control in Windows Vista (англ.), Steve Riley on Security. Дата обращения 29 декабря 2017.
  3. 1 2 3 PsExec, User Account Control and Security Boundaries (англ.), Mark's Blog. Дата обращения 29 декабря 2017.
  4. CreateRemoteThread function (Windows) (англ.). msdn2.microsoft.com. Дата обращения: 29 декабря 2017.
  5. WriteProcessMemory function (Windows) (англ.). msdn2.microsoft.com. Дата обращения: 29 декабря 2017.
  6. Introducing Adobe Reader Protected Mode (англ.). blogs.adobe.com. Дата обращения: 29 декабря 2017.
  7. Plan Protected View settings for Office 2010 (англ.). technet.microsoft.com. Дата обращения: 29 декабря 2017.
  8. Keizer, Gregg. Microsoft struts Office 2010 'sandbox' security (англ.), Computerworld. Дата обращения 29 декабря 2017.

Ссылки[править | править код]