Кому действительно необходимо разобраться с мандатным управлением доступом и мандатным контролем целостности в ОС Astra Linux, рекомендую профильную учебно-методическую и научную литературу:
К сожалению, статья по своему содержанию была бы актуальна четверть века назад. С той поры наука, технологии, практика и нормативная база в предметной области моделирования управления доступом шагнули далеко вперед.
Статья содержит массу научных, технических и терминологический ошибок и неточностей. Например: • не «модель информационной безопасности», а «формальная модель управления доступом» (см. ГОСТ Р 59453.1-2021); • «Моделями называют системы распределения полномочий в информационной инфраструктуре компаний» – ошибочное определение, модель не система, а «формальная модель управления доступом – математическое или формализованное (машиночитаемое, пригодное для автоматизированной обработки) описание средства защиты информации и компонентов среды его функционирования, предоставление доступов между которыми регламентируется политиками управления доступом, реализуемыми этим средством защиты информации», т.е. данное автором определение больше соответствует термину «политика управления доступом»; • не «уровень допуска», а «уровень доступа», при этом объектам назначаются «уровни конфиденциальности»; • «Одной из проблем этой модели считается беспрепятственность обмена информацией между пользователями одного уровня» – ошибочное суждение, классическая модель Белла-ЛаПадулы включает дискреционное управление доступом (в ней есть матрица доступов и ds-свойство безопасности); • «У пользователей с высоким уровнем допуска нет никаких возможностей коммуникации с нижними уровнями. Возможно, наверху сидят очень умные люди, советы которых были бы просто бесценны, но мы об этом никогда не узнаем» – это не проблема систем с мандатным управлением доступом, такого вида суждения не состоятельны; • «(DAC), разрешает или запрещает доступ к элементу на основе политики, установленной группой владельцев и/или субъектами объекта» - при реализации дискреционного управления доступом наличие владельца у каждого объекта не обязательно; • «RBAC позволяет сотрудникам иметь права доступа только к той информации, которая им необходима для работы, и не позволяет им получать доступ к информации, которая у ним не относится» – ошибочное суждение, суть ролевого управления доступом – получение субъектами прав доступа к объектам только через роли, и все; • «Роль сотрудника в организации определяет разрешения, которые ему предоставляются, и гарантирует, что сотрудники более низкого уровня не смогут получить доступ к конфиденциальной информации или выполнить задачи высокого уровня» – ошибочное суждение, ролевое управление доступом непосредственно не связано с защитой информации различных уровней конфиденциальности (мандатным управлением доступом); • Формально соответствующей атрибутивному управлению доступом (ABAC) можно считать любую модель. При этом автор упускает из виду основной недостаток ABAC – отсутствие возможности в общем случае строгого доказательства безопасности системы, т. е. получения доверия к ней. Таким образом, ABAC при всей его гибкости можно использовать только в «бытовых» целях, в этом смысле оно ничем не лучше дискреционного управления доступом.
Снова обращаю внимание, что путать мандатное управление доступом и мандатный контроль целостности (см. ГОСТ Р 59453.1-2021) не желательно. Первый (МРД) в основном предназначен для защиты от утечки данных различных уровней конфиденциальности, второй (МКЦ) в первую очередь для обеспечения целостности программной среды и ее системных компонент. Более подробно с этими отличиями на примере ОС Astra Linux можно начать знакомиться со статьи https://habr.com/ru/company/astralinux/blog/670060/. При этом напомню, что МКЦ - «Mandatory Integrity Control» (MIC) очень хорошо с 2007 г. зарекомендовал себя в ОС семейства Microsoft Windows, им пользуются сотни миллионов пользователей по всему миру, поэтому суждение «обычным пользователям мандатный контроль вообще не нужен» (если речь идет о МКЦ) – голословно.
Также фраза «но наверно по бумажкам он прошел все испытания» вероятно вызвана незнанием предметной области и того, что здесь все давно ушло от «бумажной» защиты. Чтобы это понять, рекомендую начать с ГОСТ Р 56939-2016 «Разработка безопасного программного обеспечения», далее собрать информацию о утвержденных ФСТЭК России «Требованиях по безопасности информации, устанавливающих уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» и «Методике выявления уязвимостей и недекларированных возможностей в программном обеспечении». После чего посмотреть на лучшие практики лидеров рынка в этой области. Тогда станет понятным, что разработка безопасного ПО в первую очередь сложный, высокотехнологичный, наукоемкий и вместе с тем очень интересный процесс. Как это делается в ОС Astra Linux в целом, можно увидеть здесь — https://ispranproceedings.elpub.ru/jour/article/view/1449, а в очень частном случае здесь — https://habr.com/ru/company/astralinux/blog/692030.
Ничего подобно в других системах и близко нет (где дальше заимствования SELinux не ушли), что подтверждается соответствием ОС Astra Linux первому уровню доверия (все остальные только четвертый).
При этом желательно, говоря о «ограниченных функциях и возможностях, а также недостаточно оперативной техподдержке», не путать готовность разработчика, особо не претендующего ни на безопасность своего решения, ни на высокое доверие к нему, включать в свой дистрибутив все, что угодно, лишь бы быстрее и как-то работало, с разработкой доверенного средства защиты информации с полноценной многоуровневой технической поддержкой и организацией помощи партнерам и заказчикам по адаптации их ПО к уникальным (как минимум, для ОС семейства Linux) механизмам защиты ОС Astra Linux, таким как мандатный контроль целостности, мандатное управление доступом и др.
Андроид был как пример компактной системы, с четко очерченными сценариями взаимодействия и тщательно прописанными правилами мандатного доступа. Что мандатный контроль это не панацея. Обычно как только получен (через уязвимость) kernel rw - игра окончена
Во-первых, желательно не путать терминологию. В наших и англоязычных источниках под "Мандатным упРавлением Доступом" (МРД) и "Mandatory Access Control" (MAC) понимают разные вещи. Поэтому реализуемый в Android с использованием SELinux механизм MAC - это не наше мандатное управление доступом (см. ГОСТ Р 59453.1-2021), а скорее ближе к тому, что у нас назвали бы сочетанием ролевого и типизированного управления доступом. Во-вторых, наш "Мандатный Контроль Целостности" (МКЦ), который по смыслу близок к англоязычному "Mandatory Integrity Control" (MIC), SELinux, а, значит, и Android не реализуют ни в каком виде. В-третьих, в том и дело, что в ОС Astra Linux Special Edition средствами ее собственных механизмов защиты - мандатного контроля целостности, замкнутой программной среды и др., существенно затрудняется эксплуатация уязвимостей. Т.е. от полномочий непривилегированного пользователя с уровнем целостности ноль до "kernel rw" еще надо суметь добраться.
"Astra Linux, мандатный контроль" - там свое собственное решение ? Нетselinux/apparmor ? Мандатный доступ это хорошо, но это не панацея. Что прекрасно видно на примере Android. Причем там гораздо проще настроить жёсткие политики, благодаря ограниченным сценариям использования.
В Astra Linux Special Edition мандатный контроль целостности (не путать с мандатным управлениям доступом, см. ГОСТ Р 59453.1-2021) - собственная разработка на основе собственной математической (формальной) модели. При этом, конечно, изучались предшествующая теория - модель Биба, и практика - реализация механизма MIC в ОС семейства Windows (в Android этого механизма нет). Для реализации мандатного контроля целостности в Astra Linux Special Edition не используются SELinux или AppArmor.
Более подробно об этом можно прочитать в нашей статье "Преимущества использования СЗИ в ОС Astra Linux Special Edition": https://habr.com/ru/company/astralinux/blog/670060/ . В этой статье и комментариях к ней есть ссылки на более глубокие и развернутые, в том числе научные публикации по данной теме. Кроме того, на днях вышло обещанное учебное пособие "Основы безопасности операционной системы Astra Linux Special Edition. Управление доступом": https://www.techbook.ru/book.php?id_book=1247, в котором реализация мандатного контроля целостности и многое другое детально рассматриваются.
Если приглядеться, для пользователя в этом и есть вся прелесть простых, но надежных и научно обоснованных правил управления доступом, которые реализованы в наших МКЦ и МРД. Ведь как хорошо и удобно, что даже если нарушителю удастся «подсунуть» высокоцелостному «красному» администратору зараженный вирусом исполняемый файл, то администратор его все равно не запустит, т. к. нарушитель сможет это сделать только на низком уровне целостности. При этом «красному» администратору ни о чем таком даже думать не надо, ОС все сделает. Или о помеченных высоким уровнем целостности системных каталогах (/bin, /etc и т. д.) также можно не беспокоиться, на то как в них права rwx расставить время не тратить. ОС сама уровни целостности на системные каталоги и файлы правильно расставит и их защитит — у нее для этого есть ясные и четкие правила. Таких примеров много.
А быть сертифицированной — это не основной смысл существования ОС Astra Linux Special Edition. Это только часть общей задачи - быть лучше, надежнее и безопаснее.
Статический анализ программного кода не позволяет проверить логику работы обсуждаемых в статье механизмов управления доступом. Этот анализ в основном направлен на выявление типичных «программистских» ошибок (деление на ноль, выход за границы массива, разыменование нулевого указателя и т.п.) и поэтому его применяют очень широко и не только при разработке сертифицированных СЗИ. Ведь никому ненадежное сбоящее ПО не нужно.
В части того, что системный вызов может случайно что-то «секретное» выдать, то, как правило, это не происходит. Хотя проблема такая есть, она решается в рамках анализа скрытых каналов по памяти и по времени (что это такое, можно посмотреть в ГОСТ Р 53113.1-2008 или с теорией и практическими примерами из «жизни» ОС в учебном пособии - http://www.techbook.ru/book.php?id_book=1137). Дело это конечно сложное, но мы работаем над этим, и результаты есть — они в основном реализованы в нашей ОС в режиме «Максимальный» в механизме мандатного управления доступом (МРД).
В самом общем виде можно с этим согласиться. Потенциально после доработки SELinux может начать делать то, что умеет PARSEC, например, реализовывать МКЦ. Но ключевым здесь все равно останется вопрос доверия, т. е. почему безопасности решений на основе SELinux можно доверять. На чем строится доверие несколько слов сказано в статье и в комментариях выше.
Здесь добавлю, что есть еще одно препятствие для применения SELinux во многих важных на практике случаях. Оно кроется в архитектуре самого SELinux — наборы подготовленных для него политик перед загрузкой в соответствующий LSM-модуль ядра ОС компилируются в бинарный формат. Это затрудняет применение SELinux в составе сертифицированных средств защиты информации (СЗИ), где возможность модификации исполняемого кода в процессе эксплуатации СЗИ четко регламентирована. Реализация рассматриваемой технологии в SELinux может потребовать запрета на изменение заранее подготовленных разработчиком СЗИ политик, что не удобно и не гибко (например, при эксплуатации СЗИ может быть запрещено корректировать политики управления доступом при установке нового ПО).
Действительно, и там LSM-модуль (SELinux) и там (PARSEC в ОС Astra Linux Special Edition), и тот и другой чего-то на основе меток проверяют, тогда в чем разница? А разница огромная. В первую очередь лежащие в основе МКЦ (и МРД) в PARSEC именно ясные и четкие правила управления доступом. Их не много, большая часть из них есть в ГОСТ Р 59453.1-2021. В нашем случае, например, правило – низкоцелостный процесс (даже от имени суперпользователя root) не должен модифицировать высокоцелостные (системные) файлы, или, нельзя запустить высокоцелостный процесс из низкоцелостного бинарного файла. Понять главный принцип МКЦ — нельзя с меньшего уровня целостности модифицировать или захватывать управление над компонентами большего уровня целостности, не составляет большого труда как пользователям, так и администраторам ОС. В SELinux для выражения подобных правил требуется многочисленные (исчисляемые в совокупности сотнями) труднопонимаемые отдельные политики.
И конечно надо еще раз отметить, что в случае SELinux в его безопасность вообще, и конкретных наборов политик в частности, надо по сути верить на слово. А безопасность PARSEC подтверждается, начиная с развитой формальной модели, и заканчивая всесторонним анализом и дедуктивной верификацией его кода, о чем подробнее можно посмотреть в нашей статье про методологию разработки безопасного системного ПО (https://ispranproceedings.elpub.ru/jour/article/view/1449).
Некоторая сложность документации объясняется тем, что ОС общего назначения достаточно сложный продукт, в ней велико разнообразие компонент (разные файловые системы, файлы и каталоги разных видов, сокеты и т. д.) доступом к которым надо управлять. Поэтому в документации (на то она и документация) приходится описывать все эти случаи и особенности.
Понимая это, мы стремимся ситуацию исправить. На это направлены и данная статья, и упомянутые в предыдущих комментариях учебные пособия, которые либо вышли, либо готовятся к выходу.
В указанных в некотором смысле аналогах механизму МКЦ в ОС Astra Linux Special Edition механизмах MIC и UAC в ОС семейства Windows ключевым является первый — MIC (Mandatory Integrity Control). Однако их вернее указывать в паре, т. к. механизм UAC (User Account Control) показывает, что только меток целостности на файлах, каталогах, процессах и соответствующих проверок этих меток при предоставлении доступов не достаточно для полнофункциональной реализации МКЦ. Важно, например, надежно защитить процедуру и интерфейс перехода на высокий уровень целостности, а это делает как раз UAC.
Согласен, что некоторые технические аспекты в статье изложены не достаточно глубоко. Это сделано специально, чтобы сделать ее удобной для прочтения широкого круга специалистов. При этом статья вводная и, надеюсь, не последняя. Два конкретных примера (с иллюстрацией на рис. 2 и 3) в статье есть. В ней есть ссылки на ряд источников, например, учебное пособие (http://www.techbook.ru/book.php?id_book=1137) или ГОСТ Р 59453.1-2021, где основные свойства МКЦ и МРД описываются. Есть другие источники, например, учебное пособие – http://www.techbook.ru/book.php?id_book=1075.
Однако, понимаю, что разъяснений и профильной литературы маловато, поэтому мы работаем над этим. Например, с коллегами подготовили (надеюсь, летом будет издано) учебное пособие «Основы безопасности операционной системы Astra Linux Special Edition. Управление доступом». В нем первая глава посвящена управлению доступом в режиме «Базовый», вторая - «Усиленный», третья - «Максимальный», а четвертая — лабораторному практикуму.
Также отмечу, что было бы очень хорошо, чтобы специалисты по возможности обращались и к теории информационной безопасности, которая успешно развивается и внедряется в практику более 50 лет. Тогда бы отдавалось должное уважение классикам, внесшим фундаментальный вклад в эту теорию, таким как Bell D.E., LaPadula L.J., Biba K.J. и др. Написанные ими в 70-е годы прошлого столетия формальные (математические) модели были впервые в истории ориентированы на реальную «живую» систему — ОС Multics. И в этих описаниях было много конкретных примеров, как «целочисленные атрибуты» или «циферки» (метки конфиденциальности и целостности) используются для реализации МКЦ и МРД.
В итоге, сходство SELinux, AppArmor и механизмов защиты в ОС Astra Linux Special Edition весьма отдаленное. Например, SELinux и AppArmor совершенно не реализуют мандатный контроль целостности (МКЦ).
Совершенно верно, SELinux за счет применения многочисленных настроек правил управления доступом (часто называемых политиками) позволяет закрыть отдельные изъяны дискреционного Linux. При этом не дается обоснования, что это в целом будет хорошо, т. е. что всем этим политикам в совокупности можно доверять. В результате нет объективной оценки — действительно без SELinux все плохо, или только иногда и в каких-то отдельных случаях. По крайней мере мнение, что без SELinux использовать Linux нельзя, не является самым распространенным.
Для сравнения, описанные в статье механизмы МКЦ и ЗПС действительно выводят защиту на качественно более высокий уровень, во-первых, тому есть обоснование, во-вторых, практический опыт это подтверждает, в-третьих, упомянутые в статье чем-то похожие механизмы MIC и UAC в ОС семейства Windows яркий тому пример.
А у ОС Astra Linux Special Edition в режиме «Базовый» кроме отмеченных в статье механизмов защиты (изоляция процессов, защита памяти, регистрация событий безопасности и др.) есть еще другие полезные качества, например, техническая поддержка, документация, обучение и т. д., для многих это важно.
Архитектура безопасности системы изначально должна выстраиваться правильно. Здесь основное качество не «платный или бесплатный» механизм защиты, а доверенный, верифицированный или нет. При этом с учетом того, что возможен переход из режима «Базовый» (путем приобретения соответствующей лицензии) в режим «Усиленный» или «Максимальный», то включать SELinux в дистрибутив крайне не желательно (его потом уже просто не отключишь, и прикладное ПО в работающей системе не перенастроишь).
Кому действительно необходимо разобраться с мандатным управлением доступом и мандатным контролем целостности в ОС Astra Linux, рекомендую профильную учебно-методическую и научную литературу:
https://astragroup.ru/info/reference-information/library/,
а также иные достоверные источники информации:
статья на Хабр - https://habr.com/ru/companies/astralinux/articles/670060/.
ГОСТ Р 59453.1-2021 "Защита информации. Формальная модель управления доступом. Часть 1. Общие положения" (https://rst.gov.ru:8443/file-service/file/load/1699609661497).
К сожалению, статья по своему содержанию была бы актуальна четверть века назад. С той поры наука, технологии, практика и нормативная база в предметной области моделирования управления доступом шагнули далеко вперед.
Статья содержит массу научных, технических и терминологический ошибок и неточностей. Например:
• не «модель информационной безопасности», а «формальная модель управления доступом» (см. ГОСТ Р 59453.1-2021);
• «Моделями называют системы распределения полномочий в информационной инфраструктуре компаний» – ошибочное определение, модель не система, а «формальная модель управления доступом – математическое или формализованное (машиночитаемое, пригодное для автоматизированной обработки) описание средства защиты информации и компонентов среды его функционирования, предоставление доступов между которыми регламентируется политиками управления доступом, реализуемыми этим средством защиты информации», т.е. данное автором определение больше соответствует термину «политика управления доступом»;
• не «уровень допуска», а «уровень доступа», при этом объектам назначаются «уровни конфиденциальности»;
• «Одной из проблем этой модели считается беспрепятственность обмена информацией между пользователями одного уровня» – ошибочное суждение, классическая модель Белла-ЛаПадулы включает дискреционное управление доступом (в ней есть матрица доступов и ds-свойство безопасности);
• «У пользователей с высоким уровнем допуска нет никаких возможностей коммуникации с нижними уровнями. Возможно, наверху сидят очень умные люди, советы которых были бы просто бесценны, но мы об этом никогда не узнаем» – это не проблема систем с мандатным управлением доступом, такого вида суждения не состоятельны;
• «(DAC), разрешает или запрещает доступ к элементу на основе политики, установленной группой владельцев и/или субъектами объекта» - при реализации дискреционного управления доступом наличие владельца у каждого объекта не обязательно;
• «RBAC позволяет сотрудникам иметь права доступа только к той информации, которая им необходима для работы, и не позволяет им получать доступ к информации, которая у ним не относится» – ошибочное суждение, суть ролевого управления доступом – получение субъектами прав доступа к объектам только через роли, и все;
• «Роль сотрудника в организации определяет разрешения, которые ему предоставляются, и гарантирует, что сотрудники более низкого уровня не смогут получить доступ к конфиденциальной информации или выполнить задачи высокого уровня» – ошибочное суждение, ролевое управление доступом непосредственно не связано с защитой информации различных уровней конфиденциальности (мандатным управлением доступом);
• Формально соответствующей атрибутивному управлению доступом (ABAC) можно считать любую модель. При этом автор упускает из виду основной недостаток ABAC – отсутствие возможности в общем случае строгого доказательства безопасности системы, т. е. получения доверия к ней. Таким образом, ABAC при всей его гибкости можно использовать только в «бытовых» целях, в этом смысле оно ничем не лучше дискреционного управления доступом.
Также рекомендации статьи полностью игнорируют требования отечественных регуляторов, например, «Требования по безопасности информации к операционным системам» ФСТЭК России (https://fstec.ru/dokumenty/vse-dokumenty/spetsialnye-normativnye-dokumenty/trebovaniya-po-bezopasnosti-informatsii-utverzhdeny-prikazom-fstek-rossii-ot-14-aprelya-2023-g-n-64?ysclid=lqbzah5ahx83092092).
Вывод. Для погружения в проблематику моделирования управления доступом и применения соответствующих формальных моделей рекомендую использовать профильную литературу, а также примеры успешного использования формальных моделей в практике разработки и эксплуатации отечественных средств защиты информации (например, в ОС Astra Linux Special Edition):
• https://docs.cntd.ru/document/1200179191?ysclid=lqbysxrpsi185680278;
• http://www.techbook.ru/book.php?id_book=1137;
• https://www.techbook.ru/book.php?id_book=1247;
• https://habr.com/ru/companies/astralinux/articles/670060/.
Для информации: https://habr.com/ru/companies/astralinux/articles/670060/ .
Снова обращаю внимание, что путать мандатное управление доступом и мандатный контроль целостности (см. ГОСТ Р 59453.1-2021) не желательно. Первый (МРД) в основном предназначен для защиты от утечки данных различных уровней конфиденциальности, второй (МКЦ) в первую очередь для обеспечения целостности программной среды и ее системных компонент. Более подробно с этими отличиями на примере ОС Astra Linux можно начать знакомиться со статьи https://habr.com/ru/company/astralinux/blog/670060/. При этом напомню, что МКЦ - «Mandatory Integrity Control» (MIC) очень хорошо с 2007 г. зарекомендовал себя в ОС семейства Microsoft Windows, им пользуются сотни миллионов пользователей по всему миру, поэтому суждение «обычным пользователям мандатный контроль вообще не нужен» (если речь идет о МКЦ) – голословно.
Также фраза «но наверно по бумажкам он прошел все испытания» вероятно вызвана незнанием предметной области и того, что здесь все давно ушло от «бумажной» защиты. Чтобы это понять, рекомендую начать с ГОСТ Р 56939-2016 «Разработка безопасного программного обеспечения», далее собрать информацию о утвержденных ФСТЭК России «Требованиях по безопасности информации, устанавливающих уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» и «Методике выявления уязвимостей и недекларированных возможностей в программном обеспечении». После чего посмотреть на лучшие практики лидеров рынка в этой области. Тогда станет понятным, что разработка безопасного ПО в первую очередь сложный, высокотехнологичный, наукоемкий и вместе с тем очень интересный процесс. Как это делается в ОС Astra Linux в целом, можно увидеть здесь — https://ispranproceedings.elpub.ru/jour/article/view/1449, а в очень частном случае здесь — https://habr.com/ru/company/astralinux/blog/692030.
Говорить о ОС Astra Linux как о «хайпе» можно только от недостаточной информированности. Это в первую очередь результат многолетнего труда по разработке собственных механизмов защиты, научного сопровождения этого процесса, внедрения технологий разработки безопасного ПО и обеспечения доверия к нему (от формальной модели до дедуктивной верификации кода). Подтверждение этому можно увидеть как в самой ОС Astra Linux, так и здесь: https://astralinux.ru/information/library/publications/, и в особенности в этих публикациях: https://habr.com/ru/company/astralinux/blog/670060/, https://ispranproceedings.elpub.ru/jour/article/view/1449, https://www.techbook.ru/book.php?id_book=1247.
Ничего подобно в других системах и близко нет (где дальше заимствования SELinux не ушли), что подтверждается соответствием ОС Astra Linux первому уровню доверия (все остальные только четвертый).
При этом желательно, говоря о «ограниченных функциях и возможностях, а также недостаточно оперативной техподдержке», не путать готовность разработчика, особо не претендующего ни на безопасность своего решения, ни на высокое доверие к нему, включать в свой дистрибутив все, что угодно, лишь бы быстрее и как-то работало, с разработкой доверенного средства защиты информации с полноценной многоуровневой технической поддержкой и организацией помощи партнерам и заказчикам по адаптации их ПО к уникальным (как минимум, для ОС семейства Linux) механизмам защиты ОС Astra Linux, таким как мандатный контроль целостности, мандатное управление доступом и др.
Во-первых, желательно не путать терминологию. В наших и англоязычных источниках под "Мандатным упРавлением Доступом" (МРД) и "Mandatory Access Control" (MAC) понимают разные вещи. Поэтому реализуемый в Android с использованием SELinux механизм MAC - это не наше мандатное управление доступом (см. ГОСТ Р 59453.1-2021), а скорее ближе к тому, что у нас назвали бы сочетанием ролевого и типизированного управления доступом. Во-вторых, наш "Мандатный Контроль Целостности" (МКЦ), который по смыслу близок к англоязычному "Mandatory Integrity Control" (MIC), SELinux, а, значит, и Android не реализуют ни в каком виде. В-третьих, в том и дело, что в ОС Astra Linux Special Edition средствами ее собственных механизмов защиты - мандатного контроля целостности, замкнутой программной среды и др., существенно затрудняется эксплуатация уязвимостей. Т.е. от полномочий непривилегированного пользователя с уровнем целостности ноль до "kernel rw" еще надо суметь добраться.
В Astra Linux Special Edition мандатный контроль целостности (не путать с мандатным управлениям доступом, см. ГОСТ Р 59453.1-2021) - собственная разработка на основе собственной математической (формальной) модели. При этом, конечно, изучались предшествующая теория - модель Биба, и практика - реализация механизма MIC в ОС семейства Windows (в Android этого механизма нет). Для реализации мандатного контроля целостности в Astra Linux Special Edition не используются SELinux или AppArmor.
Более подробно об этом можно прочитать в нашей статье "Преимущества использования СЗИ в ОС Astra Linux Special Edition": https://habr.com/ru/company/astralinux/blog/670060/ . В этой статье и комментариях к ней есть ссылки на более глубокие и развернутые, в том числе научные публикации по данной теме. Кроме того, на днях вышло обещанное учебное пособие "Основы безопасности операционной системы Astra Linux Special Edition. Управление доступом": https://www.techbook.ru/book.php?id_book=1247, в котором реализация мандатного контроля целостности и многое другое детально рассматриваются.
Если приглядеться, для пользователя в этом и есть вся прелесть простых, но надежных и научно обоснованных правил управления доступом, которые реализованы в наших МКЦ и МРД. Ведь как хорошо и удобно, что даже если нарушителю удастся «подсунуть» высокоцелостному «красному» администратору зараженный вирусом исполняемый файл, то администратор его все равно не запустит, т. к. нарушитель сможет это сделать только на низком уровне целостности. При этом «красному» администратору ни о чем таком даже думать не надо, ОС все сделает. Или о помеченных высоким уровнем целостности системных каталогах (/bin, /etc и т. д.) также можно не беспокоиться, на то как в них права rwx расставить время не тратить. ОС сама уровни целостности на системные каталоги и файлы правильно расставит и их защитит — у нее для этого есть ясные и четкие правила. Таких примеров много.
А быть сертифицированной — это не основной смысл существования ОС Astra Linux Special Edition. Это только часть общей задачи - быть лучше, надежнее и безопаснее.
Статический анализ программного кода не позволяет проверить логику работы обсуждаемых в статье механизмов управления доступом. Этот анализ в основном направлен на выявление типичных «программистских» ошибок (деление на ноль, выход за границы массива, разыменование нулевого указателя и т.п.) и поэтому его применяют очень широко и не только при разработке сертифицированных СЗИ. Ведь никому ненадежное сбоящее ПО не нужно.
В части того, что системный вызов может случайно что-то «секретное» выдать, то, как правило, это не происходит. Хотя проблема такая есть, она решается в рамках анализа скрытых каналов по памяти и по времени (что это такое, можно посмотреть в ГОСТ Р 53113.1-2008 или с теорией и практическими примерами из «жизни» ОС в учебном пособии - http://www.techbook.ru/book.php?id_book=1137). Дело это конечно сложное, но мы работаем над этим, и результаты есть — они в основном реализованы в нашей ОС в режиме «Максимальный» в механизме мандатного управления доступом (МРД).
В самом общем виде можно с этим согласиться. Потенциально после доработки SELinux может начать делать то, что умеет PARSEC, например, реализовывать МКЦ. Но ключевым здесь все равно останется вопрос доверия, т. е. почему безопасности решений на основе SELinux можно доверять. На чем строится доверие несколько слов сказано в статье и в комментариях выше.
Здесь добавлю, что есть еще одно препятствие для применения SELinux во многих важных на практике случаях. Оно кроется в архитектуре самого SELinux — наборы подготовленных для него политик перед загрузкой в соответствующий LSM-модуль ядра ОС компилируются в бинарный формат. Это затрудняет применение SELinux в составе сертифицированных средств защиты информации (СЗИ), где возможность модификации исполняемого кода в процессе эксплуатации СЗИ четко регламентирована. Реализация рассматриваемой технологии в SELinux может потребовать запрета на изменение заранее подготовленных разработчиком СЗИ политик, что не удобно и не гибко (например, при эксплуатации СЗИ может быть запрещено корректировать политики управления доступом при установке нового ПО).
Действительно, и там LSM-модуль (SELinux) и там (PARSEC в ОС Astra Linux Special Edition), и тот и другой чего-то на основе меток проверяют, тогда в чем разница? А разница огромная. В первую очередь лежащие в основе МКЦ (и МРД) в PARSEC именно ясные и четкие правила управления доступом. Их не много, большая часть из них есть в ГОСТ Р 59453.1-2021. В нашем случае, например, правило – низкоцелостный процесс (даже от имени суперпользователя root) не должен модифицировать высокоцелостные (системные) файлы, или, нельзя запустить высокоцелостный процесс из низкоцелостного бинарного файла. Понять главный принцип МКЦ — нельзя с меньшего уровня целостности модифицировать или захватывать управление над компонентами большего уровня целостности, не составляет большого труда как пользователям, так и администраторам ОС. В SELinux для выражения подобных правил требуется многочисленные (исчисляемые в совокупности сотнями) труднопонимаемые отдельные политики.
И конечно надо еще раз отметить, что в случае SELinux в его безопасность вообще, и конкретных наборов политик в частности, надо по сути верить на слово. А безопасность PARSEC подтверждается, начиная с развитой формальной модели, и заканчивая всесторонним анализом и дедуктивной верификацией его кода, о чем подробнее можно посмотреть в нашей статье про методологию разработки безопасного системного ПО (https://ispranproceedings.elpub.ru/jour/article/view/1449).
Некоторая сложность документации объясняется тем, что ОС общего назначения достаточно сложный продукт, в ней велико разнообразие компонент (разные файловые системы, файлы и каталоги разных видов, сокеты и т. д.) доступом к которым надо управлять. Поэтому в документации (на то она и документация) приходится описывать все эти случаи и особенности.
Понимая это, мы стремимся ситуацию исправить. На это направлены и данная статья, и упомянутые в предыдущих комментариях учебные пособия, которые либо вышли, либо готовятся к выходу.
В указанных в некотором смысле аналогах механизму МКЦ в ОС Astra Linux Special Edition механизмах MIC и UAC в ОС семейства Windows ключевым является первый — MIC (Mandatory Integrity Control). Однако их вернее указывать в паре, т. к. механизм UAC (User Account Control) показывает, что только меток целостности на файлах, каталогах, процессах и соответствующих проверок этих меток при предоставлении доступов не достаточно для полнофункциональной реализации МКЦ. Важно, например, надежно защитить процедуру и интерфейс перехода на высокий уровень целостности, а это делает как раз UAC.
Согласен, что некоторые технические аспекты в статье изложены не достаточно глубоко. Это сделано специально, чтобы сделать ее удобной для прочтения широкого круга специалистов. При этом статья вводная и, надеюсь, не последняя. Два конкретных примера (с иллюстрацией на рис. 2 и 3) в статье есть. В ней есть ссылки на ряд источников, например, учебное пособие (http://www.techbook.ru/book.php?id_book=1137) или ГОСТ Р 59453.1-2021, где основные свойства МКЦ и МРД описываются. Есть другие источники, например, учебное пособие – http://www.techbook.ru/book.php?id_book=1075.
Однако, понимаю, что разъяснений и профильной литературы маловато, поэтому мы работаем над этим. Например, с коллегами подготовили (надеюсь, летом будет издано) учебное пособие «Основы безопасности операционной системы Astra Linux Special Edition. Управление доступом». В нем первая глава посвящена управлению доступом в режиме «Базовый», вторая - «Усиленный», третья - «Максимальный», а четвертая — лабораторному практикуму.
Также отмечу, что было бы очень хорошо, чтобы специалисты по возможности обращались и к теории информационной безопасности, которая успешно развивается и внедряется в практику более 50 лет. Тогда бы отдавалось должное уважение классикам, внесшим фундаментальный вклад в эту теорию, таким как Bell D.E., LaPadula L.J., Biba K.J. и др. Написанные ими в 70-е годы прошлого столетия формальные (математические) модели были впервые в истории ориентированы на реальную «живую» систему — ОС Multics. И в этих описаниях было много конкретных примеров, как «целочисленные атрибуты» или «циферки» (метки конфиденциальности и целостности) используются для реализации МКЦ и МРД.
В итоге, сходство SELinux, AppArmor и механизмов защиты в ОС Astra Linux Special Edition весьма отдаленное. Например, SELinux и AppArmor совершенно не реализуют мандатный контроль целостности (МКЦ).
Совершенно верно, SELinux за счет применения многочисленных настроек правил управления доступом (часто называемых политиками) позволяет закрыть отдельные изъяны дискреционного Linux. При этом не дается обоснования, что это в целом будет хорошо, т. е. что всем этим политикам в совокупности можно доверять. В результате нет объективной оценки — действительно без SELinux все плохо, или только иногда и в каких-то отдельных случаях. По крайней мере мнение, что без SELinux использовать Linux нельзя, не является самым распространенным.
Для сравнения, описанные в статье механизмы МКЦ и ЗПС действительно выводят защиту на качественно более высокий уровень, во-первых, тому есть обоснование, во-вторых, практический опыт это подтверждает, в-третьих, упомянутые в статье чем-то похожие механизмы MIC и UAC в ОС семейства Windows яркий тому пример.
А у ОС Astra Linux Special Edition в режиме «Базовый» кроме отмеченных в статье механизмов защиты (изоляция процессов, защита памяти, регистрация событий безопасности и др.) есть еще другие полезные качества, например, техническая поддержка, документация, обучение и т. д., для многих это важно.
Архитектура безопасности системы изначально должна выстраиваться правильно. Здесь основное качество не «платный или бесплатный» механизм защиты, а доверенный, верифицированный или нет. При этом с учетом того, что возможен переход из режима «Базовый» (путем приобретения соответствующей лицензии) в режим «Усиленный» или «Максимальный», то включать SELinux в дистрибутив крайне не желательно (его потом уже просто не отключишь, и прикладное ПО в работающей системе не перенастроишь).