Обязательный контроль целостности (KQx[gmyl,udw tkumjkl, eylkvmukvmn)

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

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

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

Обязательный контроль целостности определяется с помощью нового типа записи управления доступом (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[источник не указан 289 дней].

Объекты с 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]

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

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

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

  1. 1 2 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 сентября 2007. Дата обращения: 29 декабря 2017.
  3. "PsExec, User Account Control and Security Boundaries". Mark's Blog (англ.). Архивировано из оригинала 15 апреля 2010. Дата обращения: 29 декабря 2017.
  4. CreateRemoteThread function (Windows) (англ.). msdn2.microsoft.com. Дата обращения: 29 декабря 2017. Архивировано 23 октября 2007 года.
  5. WriteProcessMemory function (Windows) (англ.). msdn2.microsoft.com. Дата обращения: 29 декабря 2017. Архивировано 8 октября 2007 года.
  6. Introducing Adobe Reader Protected Mode (англ.). blogs.adobe.com. Дата обращения: 29 декабря 2017. Архивировано 11 декабря 2013 года.
  7. Plan Protected View settings for Office 2010 (англ.). technet.microsoft.com. Дата обращения: 29 декабря 2017. Архивировано 2 февраля 2017 года.
  8. Keizer, Gregg. "Microsoft struts Office 2010 'sandbox' security". Computerworld (англ.). Архивировано из оригинала 2 февраля 2017. Дата обращения: 29 декабря 2017.

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