Обязательный контроль доступа

В компьютерной безопасности мандатный контроль доступа ( MAC ) относится к типу контроля доступа , с помощью которого защищенная среда (например, операционная система или база данных) ограничивает возможность субъекта или инициатора получать доступ или изменять объект или цель . ^[1] В случае операционных систем субъектом является процесс или поток, а объектами — файлы, каталоги, порты TCP / UDP , сегменты общей памяти или устройства ввода-вывода. Субъекты и объекты имеют набор атрибутов безопасности. Всякий раз, когда субъект пытается получить доступ к объекту, ядро операционной системы проверяет эти атрибуты безопасности, проверяет действующие правила авторизации (также известные как политика ) и решает, предоставлять ли доступ. Система управления базой данных в своем механизме контроля доступа также может применять обязательный контроль доступа; в данном случае объектами являются таблицы, представления, процедуры и т. д.

При обязательном контроле доступа политика безопасности централизованно контролируется администратором политики и гарантированно (в принципе) применяется ко всем пользователям. Пользователи не могут переопределить политику и, например, предоставить доступ к файлам, которые в противном случае были бы ограничены. Напротив, дискреционный контроль доступа (DAC), который также управляет возможностью субъектов получать доступ к объектам, дает пользователям возможность принимать политические решения или назначать атрибуты безопасности.

Исторически и традиционно MAC был тесно связан с многоуровневой безопасностью (MLS) и специализированными военными системами. В этом контексте MAC подразумевает высокую степень строгости для удовлетворения ограничений систем MLS. Совсем недавно, ^{[ когда? ]} однако MAC вышел из ниши MLS и начал становиться более распространенным. Более поздние реализации MAC, такие как SELinux и AppArmor для Linux и Mandatory Integrity Control для Windows, позволяют администраторам сосредоточиться на таких проблемах, как сетевые атаки и вредоносное ПО, без строгости или ограничений MLS.

История и предыстория

Исторически MAC был тесно связан с многоуровневой безопасностью (MLS) как средством защиты секретной информации США . « Критерии оценки доверенных компьютерных систем» (TCSEC), плодотворная работа по этому вопросу, часто известная как «Оранжевая книга», предоставила первоначальное определение MAC как «средства ограничения доступа к объектам на основе конфиденциальности (представленной меткой) информации, содержащейся в объектах, и формальное разрешение (т. е. разрешение) субъектов на доступ к информации такой конфиденциальности». ^[2] Ранние реализации MAC, такие как Honeywell SCOMP от USAF от , SACDIN , NSA от Blacker и MLS LAN от Boeing , были ориентированы на MLS для защиты уровней классификации безопасности, ориентированных на военные нужды, с надежным соблюдением требований.

Слово «обязательный» в MAC приобрело особое значение, обусловленное его использованием в военных системах. В этом контексте MAC подразумевает чрезвычайно высокую степень надежности, которая гарантирует, что механизмы контроля могут противостоять любому типу подрывной деятельности, тем самым позволяя им обеспечивать контроль доступа, который предусмотрен постановлением правительства, таким как Исполнительный указ 12958 . Предполагается, что обеспечение соблюдения требований является более императивным, чем в случае коммерческого применения. Это исключает правоприменение с помощью механизмов максимальных усилий. Для MAC приемлемы только механизмы, которые могут обеспечить абсолютное или почти абсолютное соблюдение мандата. Это трудная задача, которая иногда кажется нереальной для тех, кто не знаком со стратегиями высокой надежности, и очень трудна для тех, кто знаком с ней.

В некоторых системах пользователи имеют право решать, предоставлять ли доступ любому другому пользователю. Для этого все пользователи имеют доступ ко всем данным. Это не обязательно верно для системы MLS. Если существуют отдельные лица или процессы, которым может быть отказано в доступе к любым данным в системной среде, то системе необходимо доверять в обеспечении соблюдения MAC. Поскольку могут существовать различные уровни классификации данных и разрешений пользователей, это подразумевает количественную шкалу надежности. Например, более высокая надежность указана для системных сред, содержащих секретную информацию и неподтвержденных пользователей, чем для среды с «секретной» информацией и пользователями с уровнем доступа как минимум «конфиденциально». Чтобы обеспечить согласованность и устранить субъективность в отношении степени надежности, обширный научный анализ и оценка рисков по этой теме позволили создать знаковую эталонную стандартизацию, количественно определяющую возможности надежности систем безопасности и сопоставляющую их со степенями доверия, гарантированными для различных сред безопасности. Результат был задокументирован в CSC-STD-004-85. ^[3] Были определены два относительно независимых компонента надежности: уровень надежности и функциональность . Оба были указаны с такой степенью точности, которая гарантировала значительную уверенность в сертификации, основанной на этих критериях.

общих критериев Стандарт ^[4] основано на этой науке и призвано сохранить уровень доверия как уровни EAL , а спецификации функциональности как профили защиты . Из этих двух важнейших компонентов объективных показателей надежности достоверно сохранились только уровни EAL. В одном случае уровень TCSEC C2. ^[5] (категория, не поддерживающая MAC) довольно точно сохранилась в общих критериях как профиль защиты контролируемого доступа (CAPP). ^[6] Профили защиты MLS (например, MLSOSPP, аналогичный B2) ^[7] является более общим, чем B2. Они соответствуют MLS, но им не хватает детальных требований к реализации, как у их предшественников из Оранжевой книги , и они больше ориентированы на цели. Это дает органам по сертификации больше субъективной гибкости при принятии решения о том, соответствуют ли технические характеристики оцениваемого продукта поставленной цели, что потенциально снижает согласованность оцениваемых продуктов и облегчает получение сертификации для менее заслуживающих доверия продуктов. По этим причинам технические детали профиля защиты имеют решающее значение для определения пригодности продукта.

Такая архитектура не позволяет аутентифицированному пользователю или процессу определенной классификации или уровня доверия получить доступ к информации, процессам или устройствам на другом уровне. Это обеспечивает механизм сдерживания пользователей и процессов, как известных, так и неизвестных. Неизвестная программа может включать в себя ненадежное приложение, в котором система должна отслеживать или контролировать доступ к устройствам и файлам.

Несколько реализаций MAC, таких как проект Unisys Blacker , были сертифицированы достаточно надежными , чтобы отделить Совершенно секретно от Несекретно в конце прошлого тысячелетия. Их базовая технология устарела, и они не обновлялись. На сегодняшний день не существует реализаций, сертифицированных TCSEC на таком уровне надежной реализации. Однако существуют и менее надежные продукты.

В операционных системах

Майкрософт

Начиная с Windows Vista и Server 2008 , Microsoft включила обязательный контроль целостности (MIC) в операционную систему Windows, который добавляет уровни целостности (IL) к запущенным процессам. Цель — ограничить доступ менее надежных процессов к конфиденциальной информации. MIC определяет пять уровней целостности: низкий, средний, высокий, системный и доверенный установщик. ^[8] По умолчанию процессы запускаются на среднем уровне IL. Повышенные процессы получают высокий IL. ^[9] Дочерние процессы по умолчанию наследуют целостность своих родительских процессов, хотя родительский процесс может запускать их с более низким IL. Например, Internet Explorer 7 запускает свои подпроцессы с низким IL. Windows контролирует доступ к объектам на основе IL. Именованные объекты , включая файлы , ключи реестра или другие процессы и потоки , имеют запись в своем ACL, указывающую минимальный IL процесса, который может использовать объект. MIC обеспечивает, чтобы процесс мог записывать или удалять объект только тогда, когда его IL равен или выше IL объекта. Более того, чтобы предотвратить доступ к конфиденциальным данным в памяти, процессы не могут открывать процессы с более высоким IL для доступа на чтение . ^[10]

Яблоко

Apple Inc. внедрила реализацию платформы TrustedBSD в свои операционные системы iOS и macOS . ^[11] (Слово «mac» в «macOS» является сокращением от « Macintosh » и не имеет ничего общего с аббревиатурой «обязательный контроль доступа».) Функция командной строки sandbox_init предоставляет ограниченный интерфейс песочницы высокого уровня. ^[12]

Google

Версия 5.0 и более поздние версии операционной системы Android , разработанной Google , используют SELinux для реализации модели безопасности MAC поверх исходного подхода DAC на основе UID. ^[13]

Семейство Linux

Linux и многие другие дистрибутивы Unix имеют MAC-адреса для процессора (многокольцевого), диска и памяти. Хотя программное обеспечение ОС может плохо управлять привилегиями, Linux прославился в 1990-х годах как более безопасный и гораздо более стабильный вариант, чем альтернативы, отличные от Unix. ^{[ нужна ссылка ]}

(контроль доступа на основе набора правил) от Amon Ott RSBAC предоставляет основу для ядер Linux, которая позволяет использовать несколько различных модулей политики безопасности/решений. Одной из реализованных моделей является модель обязательного контроля доступа. Общая цель разработки RSBAC заключалась в том, чтобы попытаться достичь (устаревшего) уровня B1 Оранжевой книги (TCSEC). Модель обязательного контроля доступа, используемая в RSBAC, во многом такая же, как в Unix System V/MLS версии 1.2.1 (разработана в 1989 году Национальным центром компьютерной безопасности США с классификацией B1/TCSEC). RSBAC требует набора патчей к стандартному ядру, которые довольно хорошо поддерживаются владельцем проекта .

Smack (Simplified Mandatory Access Control Kernel) — это ядра Linux модуль безопасности , который защищает данные и взаимодействие процессов от злонамеренных манипуляций с помощью набора пользовательских правил обязательного контроля доступа, основной целью которого является простота. ^[14] Он был официально объединен с момента выпуска Linux 2.6.25. ^[15]

TOMOYO Linux — это облегченная реализация MAC для Linux и встроенного Linux , разработанная NTT Data Corporation . Он был включен в основную версию Linux Kernel версии 2.6.30 в июне 2009 года. ^[16] В отличие от подхода на основе меток, используемого SELinux , TOMOYO Linux выполняет на основе имени пути обязательный контроль доступа , разделяя домены безопасности в соответствии с историей вызовов процессов, которая описывает поведение системы. Политики описываются в терминах путей. Домен безопасности просто определяется цепочкой вызовов процесса и представлен строкой. Есть 4 режима: отключенный, обучение , разрешающий, принудительный. Администраторы могут назначать разные режимы для разных доменов. В TOMOYO Linux введен режим «обучения», в котором доступы, произошедшие в ядре, автоматически анализируются и сохраняются для создания политики MAC: этот режим может стать первым шагом при написании политики, что упростит ее последующую настройку.

В SUSE Linux и Ubuntu 7.10 добавлена реализация MAC под названием AppArmor , которая использует интерфейс модулей безопасности Linux (LSM) Linux 2.6. LSM предоставляет API ядра , который позволяет модулям кода ядра управлять ACL (DAC ACL, списки контроля доступа). AppArmor не способен ограничивать все программы и опционально присутствует в ядре Linux, начиная с версии 2.6.36. ^[17]

grsecurity — это патч для ядра Linux, обеспечивающий реализацию MAC (точнее, реализацию RBAC ). grsecurity не реализуется через LSM API. ^[18]

ОС Astra Linux, разработанная для российской армии, имеет собственный обязательный контроль доступа. ^[19]

Другие ОС

FreeBSD поддерживает Mandatory Access Control , реализованный в рамках проекта TrustedBSD. Он был представлен во FreeBSD 5.0. Начиная с FreeBSD 7.2, поддержка MAC включена по умолчанию. Фреймворк является расширяемым; различные модули MAC реализуют такие политики, как Biba и многоуровневая безопасность .

Sun Trusted Solaris использует обязательный и обеспечиваемый системой механизм контроля доступа (MAC), в котором разрешения и метки используются для реализации политики безопасности. Однако обратите внимание, что возможность управлять метками не подразумевает способность ядра работать в многоуровневой безопасности . режиме ^{[ нужна ссылка ]}. Доступ к меткам и механизмам контроля отсутствует. ^{[ нужна ссылка ]} надежно защищен от повреждений в защищенном домене, поддерживаемом ядром. Приложения, которые запускает пользователь, объединяются с меткой безопасности, с которой пользователь работает в сеансе. Доступ к информации, программам и устройствам контролируется слабо. ^{[ нужна ссылка ]}.

См. также

Контроль доступа

Другие темы

Сноски

^ Белим, С.В.; Белим, С.Ю. (декабрь 2018 г.). «Реализация обязательного контроля доступа в распределенных системах» . Автоматическое управление и информатика . 52 (8): 1124–1126. дои : 10.3103/S0146411618080357 . ISSN 0146-4116 . S2CID 73725128 .
^ «Критерии оценки надежного компьютера» (PDF) . Национальный институт стандартов и технологий . 15 августа 1983 года. Архивировано (PDF) из оригинала 13 апреля 2023 года . Проверено 25 июня 2023 г.
^ «Техническое обоснование CSC-STD-003-85: Требования компьютерной безопасности» . 25 июня 1985 г. Архивировано из оригинала 15 июля 2007 года . Проверено 15 марта 2008 г.
^ «Портал общих критериев» . Архивировано из оригинала 18 июля 2006 г. Проверено 15 марта 2008 г.
^ Министерство обороны США (декабрь 1985 г.). «DoD 5200.28-STD: Критерии оценки доверенной компьютерной системы» . Проверено 15 марта 2008 г.
^ «Профиль защиты контролируемого доступа, версия 1.d» . Агентство национальной безопасности. 08.10.1999. Архивировано из оригинала 7 февраля 2012 г. Проверено 15 марта 2008 г.
^ «Профиль защиты для многоуровневых операционных систем в средах, требующих средней надежности, версия 1.22» (PDF) . Агентство национальной безопасности. 23 мая 2001 г. Проверено 6 октября 2018 г.
^ Мэтью Коновер. «Анализ модели безопасности Windows Vista» . Корпорация Симантек . Архивировано из оригинала 25 марта 2008 г. Проверено 8 октября 2007 г.
^ Стив Райли. «Обязательный контроль целостности в Windows Vista» . Проверено 8 октября 2007 г.
^ Марк Руссинович . «PsExec, контроль учетных записей пользователей и границы безопасности» . Проверено 8 октября 2007 г.
^ Проект TrustedBSD. «Структура обязательного контроля доступа (MAC) TrustedBSD» . Проверено 15 марта 2008 г.
^ «Справочная страница sandbox_init(3)» . 07.07.2007. Архивировано из оригинала 25 июля 2008 г. Проверено 15 марта 2008 г.
^ «Linux с повышенной безопасностью в Android» . Проект Android с открытым исходным кодом. Архивировано из оригинала 19 июня 2023 года . Проверено 25 июня 2023 г.
^ «Официальная документация SMACK из дерева исходного кода Linux» . Архивировано из оригинала 1 мая 2013 г.
^ Джонатан Корбет. «Больше материала для 2.6.25» . Архивировано из оригинала 2 ноября 2012 г.
^ «TOMOYO Linux, альтернативный обязательный контроль доступа» . Линукс 2 6 30 . Ядро Linux для новичков.
^ «Linux 2.6.36 выпущен 20 октября 2010 г.» . Линукс 2.6.36 . Ядро Linux для новичков.
^ «Почему grsecurity не использует LSM?» .
^ (in Russian) Ключевые особенности Astra Linux Special Edition по реализации требований безопасности информации Archived 2014-07-16 at the Wayback Machine

Ссылки

П.А. Лоскокко, С.Д. Смолли, П.А. Макельбауэр, Р.С. Тейлор, С.Дж. Тернер и Дж.Ф. Фаррелл. Неизбежность неудачи: ошибочное предположение о безопасности в современных вычислительных средах . В материалах 21-й конференции по безопасности национальных информационных систем, страницы 303–314, октябрь 1998 г.
П.А. Лоскокко, С.Д. Смолли, Решение критически важных задач безопасности с помощью Linux с повышенной безопасностью. Архивировано 8 июля 2017 г. в материалах Wayback Machine Proceedings Симпозиума Linux в Оттаве 2001 г.
ISO/IEC DIS 10181-3, Информационные технологии, Модель безопасности OSI, Системы безопасности, Часть 3: Контроль доступа, 1993 г.
Роберт Н.М. Уотсон. « Десятилетие расширяемости контроля доступа ОС ». Коммун. ACM 56, 2 (февраль 2013 г.), 52–63.

Внешние ссылки

Публикация в блоге о том, как виртуализацию можно использовать для реализации обязательного контроля доступа.
Сообщение в блоге сотрудника Microsoft с подробным описанием обязательного контроля целостности и его отличий от реализаций MAC.
Модель формальной политики безопасности GWV Формальная политика безопасности разделительного ядра, Дэвид Грев, Мэтью Уайлдинг и В. Марк Ванфлит.

[1] Белим, С.В.; Белим, С.Ю. (декабрь 2018 г.). «Реализация обязательного контроля доступа в распределенных системах» . Автоматическое управление и информатика . 52 (8): 1124–1126. дои : 10.3103/S0146411618080357 . ISSN 0146-4116 . S2CID 73725128 .

[2] «Критерии оценки надежного компьютера» (PDF) . Национальный институт стандартов и технологий . 15 августа 1983 года. Архивировано (PDF) из оригинала 13 апреля 2023 года . Проверено 25 июня 2023 г.

[Ref_1985-3] «Техническое обоснование CSC-STD-003-85: Требования компьютерной безопасности» . 25 июня 1985 г. Архивировано из оригинала 15 июля 2007 года . Проверено 15 марта 2008 г.

[Ref_a-4] «Портал общих критериев» . Архивировано из оригинала 18 июля 2006 г. Проверено 15 марта 2008 г.

[Department1985-5] Министерство обороны США (декабрь 1985 г.). «DoD 5200.28-STD: Критерии оценки доверенной компьютерной системы» . Проверено 15 марта 2008 г.

[Ref_1999-6] «Профиль защиты контролируемого доступа, версия 1.d» . Агентство национальной безопасности. 08.10.1999. Архивировано из оригинала 7 февраля 2012 г. Проверено 15 марта 2008 г.

[Ref_2001-7] «Профиль защиты для многоуровневых операционных систем в средах, требующих средней надежности, версия 1.22» (PDF) . Агентство национальной безопасности. 23 мая 2001 г. Проверено 6 октября 2018 г.

[symantec-8] Мэтью Коновер. «Анализ модели безопасности Windows Vista» . Корпорация Симантек . Архивировано из оригинала 25 марта 2008 г. Проверено 8 октября 2007 г.

[steve-9] Стив Райли. «Обязательный контроль целостности в Windows Vista» . Проверено 8 октября 2007 г.

[mark-10] Марк Руссинович . «PsExec, контроль учетных записей пользователей и границы безопасности» . Проверено 8 октября 2007 г.

[TrustedBSD-11] Проект TrustedBSD. «Структура обязательного контроля доступа (MAC) TrustedBSD» . Проверено 15 марта 2008 г.

[Ref_2007-12] «Справочная страница sandbox_init(3)» . 07.07.2007. Архивировано из оригинала 25 июля 2008 г. Проверено 15 марта 2008 г.

[android-13] «Linux с повышенной безопасностью в Android» . Проект Android с открытым исходным кодом. Архивировано из оригинала 19 июня 2023 года . Проверено 25 июня 2023 г.

[Major-14] «Официальная документация SMACK из дерева исходного кода Linux» . Архивировано из оригинала 1 мая 2013 г.

[Merge-15] Джонатан Корбет. «Больше материала для 2.6.25» . Архивировано из оригинала 2 ноября 2012 г.

[Ref_b-16] «TOMOYO Linux, альтернативный обязательный контроль доступа» . Линукс 2 6 30 . Ядро Linux для новичков.

[Ref_c-17] «Linux 2.6.36 выпущен 20 октября 2010 г.» . Линукс 2.6.36 . Ядро Linux для новичков.

[Ref_d-18] «Почему grsecurity не использует LSM?» .

[19] (in Russian) Ключевые особенности Astra Linux Special Edition по реализации требований безопасности информации Archived 2014-07-16 at the Wayback Machine

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]