1. Режимы функционирования СЗИ
Каждый разумный владелец или пользователь информационной системы (IT-инфраструктуры) хотел бы, чтобы она работала устойчиво, была удобна, обрабатываемые в ней данные были доступны только тем, кому они предназначены, их нельзя было несанкционированно удалить, подменить и т.д. В той или иной степени это желание присуще пользователям всех информационных систем, больших или маленьких, государственных или частных. И совершенно не обязательно только тех систем, для которых требования по защите информации закреплены нормативно и нужны сертификаты, таких как критическая информационная инфраструктура или тех, что обрабатывают государственную тайну.
Т.е. фактически всем владельцам или пользователям информационных систем важно обеспечить их защиту от трех классических угроз: конфиденциальности, целостности и доступности. Самой исследованной и обсуждаемой из них является первая угроза. Защита от нее необходима, начиная с обеспечения безопасности личных данных, далее к коммерческой тайне и вплоть до государственной тайны. На втором месте по важности, как правило, угроза целостности. И дело здесь не только в целостности или отсутствии искажений самой информации (какого-либо контента, документа, медиа). Защита от вирусов и закладок нужна всем – они тоже проявление угрозы целостности. Третья из классических угроз – угроза доступности – не всегда по важности на последнем месте, а в ряде случаев, например, для интернет-ресурсов она выходит на передний план. Но во многих информационных системах, в особенности операционных системах (ОС), защита от нее обеспечивается средствами, изначально предназначенными для защиты от угроз целостности и конфиденциальности информации.
В этой связи в настоящей статье мы поговорим об угрозах конфиденциальности и целостности информации и о том, как им можно успешно противостоять средствами защиты информации (СЗИ) ОС Astra Linux Special Edition.
Для начала заметим, что подавляющее большинство пользователей отечественных информационных систем много лет работало с иностранными решениями, например, ОС Microsoft Windows, в которых используются СЗИ часто более развитые по сравнению с имеющимися в ОС семейства Linux. Пользователи даже не осознавали и не замечали того, что каждый день используют инструменты мандатного контроля целостности или замкнутой программной среды (о которых речь пойдет дальше). Это было само собой разумеющимся – работать в системе, в которой за ее безопасностью следят соответствующие СЗИ.
Вот почему важно, что ОС Astra Linux Special Edition (в отличие от других ОС семейства Linux) реализует СЗИ, где-то повторяющие, а чаще улучшающие функции безопасности привычных им иностранных систем. Иными словами, грамотное применение этой ОС позволяет достичь писанных или неписаных, но давно используемых стандартов качества и безопасности информационных систем.
Как известно, начиная с релиза 2021 г., в ОС Astra Linux Special Edition в зависимости от приобретенной лицензии СЗИ заказчики могут работать в одном из трех режимов (рис. 1): «Базовый» («Орел»), «Усиленный» («Воронеж») и «Максимальный» («Смоленск»). Режим «Усиленный» включает и дополняет СЗИ, реализованные в режиме «Базовый». Аналогично режим «Максимальный» включает и дополняет СЗИ режима «Усиленный». Рассмотрим их подробнее.
Уже начиная с режима функционирования СЗИ «Базовый» в ОС Astra Linux Special Edition доступны такие функции безопасности, как изоляция процессов, защита памяти, регистрация событий безопасности и др. Однако в части используемого механизма управления доступом этот режим функционирования СЗИ мало чем отличается от того, что можно увидеть в большинстве ОС семейства Linux, в том числе отечественных. Как говорят, это режим, в котором работает только дискреционное управление доступом. Т.е. когда администраторы или даже обычные пользователи сами, без каких-то общих правил, решают кому и к каким файлам или каталогам предоставить права доступа на чтение, запись или выполнение. Это очень просто для реализации и использования, но лишает возможности определить корректность установки этих прав. При этом сложность архитектуры ОС, неочевидные зависимости её компонент друг от друга, или просто ошибки при администрировании ОС могут привести к тому, что к некоторым важным для её безопасности файлам или каталогам будут установлены неверные права доступа. Причем это не будет явно сказываться на функционировании ОС и, как следствие, не будет оперативно выявлено. Кроме того, ОС только с дискреционным управлением доступом, как правило, уязвима для типовых атак, которые разрабатывают хакеры по всему миру, так как нет того, что могло бы ее дополнительно защитить.
Поэтому часто в ОС семейства Linux используют дополнительные механизмы, позволяющие задавать сложные политики управления доступом, учитывающие особенности функционирования компонент ОС, их взаимодействия между собой. Примерами таких механизмов являются AppArmor и Security Enhanced Linux (SELinux). Первый из них расширяет дискреционное управление за счет возможности задания политик, ограничивающих доступ к компонентам ОС. Второй механизм помимо этого включает элементы типизированного, ролевого и мандатного управления доступом.
Казалось бы, всё уже есть, и не надо делать ничего своего. Так в чем проблема? А она, как обычно, кроется в фундаменте этих технологий и упирается в математику. Во-первых, несмотря на существующие исходные тексты программного кода AppArmor и SELinux, ввиду его значительного объема и сложности, это не оказывает значительного влияния на возможность проверки эффективности данных механизмов, их доработки, сопровождения, т. е. обеспечения доверия к ним. Во-вторых, собственно доверие к механизмам управления доступом, как правило, основывается на наличии для них формальной (выраженной на математическом языке) модели управления доступом. Без такой модели невозможна верификация как самих AppArmor и SELinux, так и всей системы защиты ОС.
Дело в том, что с одной стороны, формальная модель задает четкие правила игры для ОС, а именно: как назначать права доступа процессам к файлам и каталогам, как их помечать метками конфиденциальности или целостности, управлять доступом на основе этих меток в самых разных ситуациях, например, создания нового файла, учетной записи пользователя или запуска процесса. С другой стороны, модель позволяет на своем уровне абстракции сформулировать условия безопасности ОС и математически доказать, что при их выполнении защиту ОС невозможно взломать.
Однако о существовании развитой модели управления доступом для AppArmor или SELinux авторам настоящей статьи ничего неизвестно. Разработанные в 70-е годы прошлого столетия модели Белла-ЛаПадулы или Биба, иногда упоминаемые в этом контексте, не заслуживают серьезного обсуждения как безнадежно устаревшие. В результате, использовать SELinux или AppArmor для управления доступом в ОС – это сродни созданию отечественного самолета с иностранными двигателями без тщательного тестирования, возможности технической поддержки и развития: летать будет, но долго ли или высоко ли – большой вопрос.
В связи с этим даже в «Базовом» режиме разработчики ГК «Астра» отказались от использования заимствованных механизмов защиты SELinux и AppArmor, чтобы в последующих режимах заместить их собственными СЗИ.
Следующий режим функционирования СЗИ в ОС Astra Linux Special Edition – это «Усиленный». Он самый интересный, т. к. с него начинают действовать СЗИ собственной разработки, входящие в подсистему безопасности PARSEC. В первую очередь это противостоящие угрозе целостности информации механизмы мандатного контроля целостности (МКЦ) и замкнутой программной среды (ЗПС). Самое главное, что делают эти СЗИ — существенно повышают защищенность ОС от взлома, заражения вирусами, внедрения закладок, захвата повышенных привилегий и т. д. Ведь для любой защищенной системы важно, чтобы ее механизмы защиты работали корректно. А если система взломана, нарушена целостность ее программной среды или ее контролирует нарушитель, то не имеет смысла говорить о каких-то еще защитных функциях такой системы, например, позволяющих предотвратить утечку конфиденциальных данных. При этом по сравнению с SELinux или AppArmor подсистема безопасности PARSEC разработана на основе адаптированной для ОС семейства Linux современной верифицированной формальной модели безопасности управления доступом и информационными потоками (МРОСЛ ДП-модели), значительную часть описания которой и необходимую для этого теорию можно увидеть в учебном пособии.
Таким образом, режим «Усиленный» либо непосредственно, либо как входящий в режим «Максимальный», желателен для применения большинством пользователей ОС Astra Linux Special Edition. Именно он позволяет значительно усилить защиту от многих типовых атак.
Полный комплект СЗИ в ОС Astra Linux Special Edition доступен в режиме функционирования «Максимальный». В первую очередь здесь идет речь о возможности использования мандатного управления доступом (МРД) для защиты от угрозы конфиденциальности информации. Самое главное в МРД то, что оно необходимо гораздо в более широком спектре случаев, чем может показаться на первый взгляд. Не только в случаях, когда речь идет о защите государственной тайны.
В целом СЗИ в ОС Astra Linux Special Edition, начиная с режима «Усиленный», формируют, как это говорится в нормативных документах ФСТЭК России, поверхность атаки (рис. 1) – основной рубеж обороны от нарушителя. При этом, в отличие от других российских ОС семейства Linux, в ОС Astra Linux Special Edition этот рубеж обороны реализуется СЗИ собственной разработки (не на базе заимствованных SELinux или AppArmor), построенных на основе развиваемых в ГК «Астра» научных подходов и применении технологий обеспечения доверия. Основные принципы этих подходов изложены в недавно опубликованной в журнале «Труды ИСП РАН» статье «Формирование методологии разработки безопасного системного программного обеспечения на примере операционных систем» .
2. Мандатный контроль целостности
Первое, на что надо обратить внимание, говоря о МКЦ, это часто неверная трактовка термина «мандатный». Большинство не только обычных пользователей СЗИ, но даже специалистов в области защиты информации, когда слышат термин «мандатный», понимают его как МРД, т. е. только как защиту от утечки конфиденциальных данных. Это не так, термин указывает на то, что информация в системе или ее компоненты распределяются по некоторым явно заданным уровням, и права доступа к ним назначаются исходя из этого. Например, в ОС Astra Linux Special Edition, начиная с режима «Усиленный», при включенном МКЦ обычные недоверенные пользователи работают на уровне целостности 0, а доверенный привилегированный «красный» администратор на уровне 63.
Явно заданные уровни целостности, в отличие от раздаваемых без четких правил прав доступа при штатном дискреционном управлении доступом ОС семейства Linux, вносят больше ясности в администрирование и настройку защиты системы. К слову, в прошлом году ГК «Астра» совместно с ИСП РАН удалось разработать и утвердить ГОСТ Р 59453.1-2021 «Защита информации. Формальная модель управления доступом. Часть 1. Общие положения», в котором впервые в отечественной практике стандартизации было дано официальное определение МКЦ.
Стоит отметить, что большинство пользователей информационных систем давно используют МКЦ. Связано это с тем, что данный вид управления доступом с 2007 г. был внедрен в ОС семейства Microsoft Windows на основе реализации двух механизмов MIC – Mandatory Integrity Control и UAC – User Account Control. 15 лет, прошедшие с того времени, показали высокую эффективность МКЦ для обеспечения контроля целостности программной среды ОС семейства Microsoft Windows, предотвращения заражения вирусами и внедрения программных закладок.
Основное удобство МКЦ с точки зрения обеспечения защиты достигается за счет возможности разложить все компоненты ОС Astra Linux Special Edition (файлы, процессы, учетные записи пользователей и т. д.) по уровням целостности. Далее средствами подсистемы безопасности PARSEC защищать компоненты более высокого уровня целостности от несанкционированной записи из компонент с меньшим уровнем целостности. Даже суперпользователь root, который в обычных ОС семейства Linux, практически не ограничен в правах, в ОС Astra Linux Special Edition по умолчанию работает на минимальном уровне целостности 0. А значит, захват его полномочий с использованием типовых атак на ОС семейства Linux не позволит получить контроль над всей системой, и безопасность ОС Astra Linux Special Edition в целом не пострадает.
Рассмотрим пример использования МКЦ в ОС Astra Linux Special Edition. Для обеспечения безопасности системы очень важно, чтобы доверенные, обладающие высоким уровнем целостности процессы (например, работающие от имени «красного» администратора), стартовали из высокоцелостных исполняемых файлов. Эти файлы защищены от записи (или «заражения») низкоцелостными процессами нарушителя (рис. 2). Поэтому запуская процессы, «красный» администратор ОС Astra Linux Special Edition может быть всегда уверен, что используемые им для этого исполняемые файлы не модифицированы и не подменены.
3. Замкнутая программная среда
Еще одним важным СЗИ, который в ОС Astra Linux Special Edition целесообразно активировать, начиная с режима «Усиленный», является замкнутая программная среда (ЗПС). При включенной ЗПС запуск исполняемых файлов и загрузка исполняемых библиотек возможна только в том случае, если они подписаны электронной цифровой подписью (ЭЦП) на доверительном ключе. Следовательно, ЗПС обеспечивает защиту от загрузки произвольного исполняемого файла или библиотеки, не обладающих корректной ЭЦП. Это значительно усложняет эксплуатацию уязвимостей, а в большинстве случаев делает ее невозможной (неэффективной).
Остающиеся у нарушителя некоторые незначительные возможности обойти защиту ЗПС практически полностью перекрываются включенным МКЦ. Это объясняется тем, что, во-первых, осуществить внедрение ЭЦП может только «красный» администратор, обладающий высоким уровнем целостности. Во-вторых, даже если «зараженный» файл с легальной ЭЦП был как-то ранее подписан и размещен в системе, а нарушителю удалось проэксплуатировать заложенную в этом файле уязвимость и получить привилегии, например, суперпользователя root, то все равно он продолжит работу на низком уровне целостности. Безусловно, это не позволит нарушителю оказать воздействие на системные процессы, сервисы и высокоцелостные компоненты системы.
4. Изоляция приложений
Наличие МКЦ в ОС Astra Linux Special Edition дает возможность разрабатывать и внедрять новые уникальные технологии защиты. Например, адаптированную контейнерную виртуализацию (рис. 1), которая в сочетании с МКЦ позволяет создавать для недоверенного, можно сказать «опасного», программного обеспечения своеобразные «песочницы» (рис. 3), где эти приложения изолируются от остальных доверенных приложений. В таких «песочницах», работающих на пониженном уровне целостности, недоверенное программное обеспечение (например, браузер, который обрабатывает самые разные непроверенные данные из интернета), даже если подвергнется атаке нарушителя или заражению вирусом, не будет представлять опасности для всей остальной системы.
Помимо этого, в ОС Astra Linux Special Edition имеются еще дополнительные СЗИ, включая запрет запуска интерпретаторов, а также ограничение прав непривилегированных пользователей — режим Киоск-2, в сочетании с МКЦ и ЗПС играющие не последнюю роль в предотвращении типовых угроз, связанных с эксплуатацией уязвимостей.
В том числе в Киоск-2 предусмотрена возможность задания для каждого пользователя ОС Astra Linux Special Edition собственных профилей безопасности. Каждый такой профиль содержит перечень имен каталогов или файлов, права доступа к которым надо дополнительно ограничить. У пользователя может вовсе не быть профиля. С другой стороны, ему может быть назначено сразу несколько профилей. Эти возможности обеспечивают гибкость назначения ему прав доступа в зависимости от выполняемых им в каждый конкретный момент времени функций или используемых им приложений.
5. Мандатное управление доступом
Когда говорим о МРД, следует понимать, что это принцип управления доступом, а не в коем случае не следствие наличия в системе информации, отнесенной к государственной тайне. Суть этого принципа заключается в распределении информации по явно заданным уровням (часто их называют уровнями конфиденциальности) и выполнении следующих трех основных условий. Первое – чтение данных (как правило, из файла или каталога) может осуществлять процесс (пользователь), обладающий не меньшим, чем у запрашиваемых данных уровнем конфиденциальности. Второе – запись данных в файл (каталог) может осуществлять процесс, обладающий не большим (а чаще равным), чем у файла, уровнем конфиденциальности. Третье (самое сложное) – действия процессов в системе не приводят к явной или неявной утечке конфиденциальных данных «сверху-вниз» – с высокого уровня конфиденциальности на низкий (т. е. к созданию так называемых скрытых каналов). Таким образом, непосредственно здесь речи о защите государственной тайны не идет. Эти ясные и четкие правила управления доступом позволяют пользователям и администраторам систем учитывать человеческий фактор, что однозначно способствует повышению информационной безопасности таких систем.
В связи с чем, распределение информации по некоторым условным уровням конфиденциальности (например, «открытая», «служебная», «важная», «очень важная») может быть полезным в деятельности компаний даже небольшого размера. При этом реализация в МРД еще и категорий информации (их называют неиерархическими), позволяет более тонко настроить доступ к ней в зависимости от принадлежности информации к структурным подразделениям компании (например, «отдел персонала», «бухгалтерия», «отдел продаж», «руководство компании» и т. д.). Кроме того, сочетание МКЦ, МРД и ЗПС полностью обеспечивает комплексную защиту системы.
Вывод:
Безопасность ОС Astra Linux Special Edition базируется на применении отечественных доверенных технологий разработки входящих в ее состав СЗИ, в основе которых лежат в целом простые и понятные правила управления доступом. При этом комплексное применение этих СЗИ (особенно в режимах их функционирования «Усиленный» или «Максимальный») обеспечивает реальную защищенность от основных угроз безопасности информации.
Комментарии (48)
Francyz
07.06.2022 14:24+4Непонятно зачем было отключать selinux в базовой версии, только ради того, чтобы во второй версии сделать его аналог платным, и чтобы пользователи не могли его сами настраивать в бесплатной, типа: хочешь защиты - плати, а не используй встроенный бесплатный функционал? Или я не так прочитал.
pdevyanin
07.06.2022 14:47Архитектура безопасности системы изначально должна выстраиваться правильно. Здесь основное качество не «платный или бесплатный» механизм защиты, а доверенный, верифицированный или нет. При этом с учетом того, что возможен переход из режима «Базовый» (путем приобретения соответствующей лицензии) в режим «Усиленный» или «Максимальный», то включать SELinux в дистрибутив крайне не желательно (его потом уже просто не отключишь, и прикладное ПО в работающей системе не перенастроишь).
Francyz
07.06.2022 15:20+4Так а никто и не говорит, про перенастройку и т.д. Хочешь продавать платную защиту в расширенной версии, окей, никто не запрещает, кто захотел - купил. Но тут в базовой версии просто выпилили selinux как таковой, как я понял оставив эту версию без малейшей защиты намекая на то, что если нужно защита, то будьте добры купить лицензию и перейти на другую версию - там вам будет защита наша. Я не говорю что она плохая или нет. Просто сейчас получается так, что человека просто принуждаю переходить на платную версию, потому что в базовой версии ее выпилили, хотя кому-то было бы достаточно и ее, но человека лишают возможности.
cogniter
07.06.2022 15:40+1Настройка SELinux в графике для пользовательских приложений, да еще в режимах запуска одним пользователем приложения под разными уровнями конфиденциальности очень проблематична.
Политика TE тут неприменима, а в режиме MLS слишком много проблем, в том числе при работе с доменом (каталогом пользователей).
Об этом писали в одной из предыдущих статей, вот пример проблем selinux в графике:https://habrastorage.org/getpro/habr/post_images/e12/7db/1a1/e127db1a1bded19abb9467212ef00330.png
pdevyanin
07.06.2022 17:14Совершенно верно, SELinux за счет применения многочисленных настроек правил управления доступом (часто называемых политиками) позволяет закрыть отдельные изъяны дискреционного Linux. При этом не дается обоснования, что это в целом будет хорошо, т. е. что всем этим политикам в совокупности можно доверять. В результате нет объективной оценки — действительно без SELinux все плохо, или только иногда и в каких-то отдельных случаях. По крайней мере мнение, что без SELinux использовать Linux нельзя, не является самым распространенным.
Для сравнения, описанные в статье механизмы МКЦ и ЗПС действительно выводят защиту на качественно более высокий уровень, во-первых, тому есть обоснование, во-вторых, практический опыт это подтверждает, в-третьих, упомянутые в статье чем-то похожие механизмы MIC и UAC в ОС семейства Windows яркий тому пример.
А у ОС Astra Linux Special Edition в режиме «Базовый» кроме отмеченных в статье механизмов защиты (изоляция процессов, защита памяти, регистрация событий безопасности и др.) есть еще другие полезные качества, например, техническая поддержка, документация, обучение и т. д., для многих это важно.
vitalif
07.06.2022 17:08+5Думаю, что выражу общее мнение, если скажу, что в статье много воды и не хватает описания того, как все эти мандаты работают с точки зрения юзера и чем отличаются от селинукса и аппармора, чем удобнее там и т.п… Крайне маловероятно, что конечного юзера волнуют модели Бибы и Бобы и прочих ла-падулов) я лично 100500 раз слышал что в астре какие-то мандаты, но нафиг это надо и как это работает, так и не читал / не слышал ни разу.
Это что. Получается что это просто целочисленный атрибутик на каждом файле от 0 до 63 и распиханные по коду ядра сравнения, которые запрещают бинарям с циферкой выше читать файл с циферкой ниже? Кстати а случайно то же самое на селинуксе аналогично не реализуется ли? Там же тоже атрибутики. Контекст селинукса это не аналог мандата ли в некотором роде?
ЗЫ и да, винду с её юаком приводить в пример это вообще ржака.cogniter
07.06.2022 17:51+2а что смешного в сравнении аналогичных подходов к контролю целостности?
vitalif
07.06.2022 18:11А что в UAC аналогично мандатам? UAC это же такое типа sudo просто интерактивное. Если это аналог, можно сказать, что и sudo аналог :-)
cogniter
07.06.2022 18:12+1почитайте как это работает в Windows - ровно те же самые уровни целостности:
"Уровень целостности является мерой доверия. Приложение с высоким уровнем целостности — это приложение, в котором выполняются задачи по изменению системных данных, например приложение для разбивки диска на разделы. Приложение с низким уровнем целостности выполняет задачи, которые могут потенциально подвергать риску операционную систему (например, веб-браузер). Приложения с более низким уровнем целостности не могут изменять данные в приложениях с более высоким уровнем целостности."
vitalif
07.06.2022 18:56+1Но самих-то уровня там по сути только два, юзер и админ. Разве нет? В линуксе тогда тоже можно сказать — высокий уровень это рут, низкий уровень это юзер. Но почему-то приводится в пример не линукс, а уак)
pdevyanin
07.06.2022 19:36В указанных в некотором смысле аналогах механизму МКЦ в ОС Astra Linux Special Edition механизмах MIC и UAC в ОС семейства Windows ключевым является первый — MIC (Mandatory Integrity Control). Однако их вернее указывать в паре, т. к. механизм UAC (User Account Control) показывает, что только меток целостности на файлах, каталогах, процессах и соответствующих проверок этих меток при предоставлении доступов не достаточно для полнофункциональной реализации МКЦ. Важно, например, надежно защитить процедуру и интерфейс перехода на высокий уровень целостности, а это делает как раз UAC.
v_tel_v
07.06.2022 21:35-1Не совсем так. Говоря про уровни целостности в Windows лучше обратиться к статье Mandatory Integrity Control Mandatory Integrity Control (https://docs.microsoft.com/en-us/windows/win32/secauthz/mandatory-integrity-control). По умолчанию там уже используются не менее 7 различных уровней (https://docs.microsoft.com/en-us/windows/win32/secauthz/well-known-sids): SECURITY_MANDATORY_UNTRUSTED_RID, SECURITY_MANDATORY_LOW_RID и т.д. При этом администратор может задействовать в ряде случаев и промежуточные значения уровней, правда это редко где применяется, во многом из-за того, что удобнее всего использовать уже встроенные правила управления доступом вместо написания собственных политик. В этом плане встроенная реализация МКЦ в ОС Astra Linux обеспечивает достойную замену, а в ряде случаев предоставляет и более гибкие механизмы администрирования.
pdevyanin
07.06.2022 19:25Согласен, что некоторые технические аспекты в статье изложены не достаточно глубоко. Это сделано специально, чтобы сделать ее удобной для прочтения широкого круга специалистов. При этом статья вводная и, надеюсь, не последняя. Два конкретных примера (с иллюстрацией на рис. 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 совершенно не реализуют мандатный контроль целостности (МКЦ).
vitalif
07.06.2022 22:21+4Ну вот на мой, условно посторонний, взгляд пока вся эта теория выглядит как сферический конь в вакууме, практические преимущества которого не понятны. Мне не понятно, почему система с одним видом меток (парсек) вдруг должна оказаться безопаснее системы с другим видом меток (селинукс), если всё равно всё сводится к наличию проверок доступа в коде ядра.
Возможно какие-то преимущества есть, я не отрицаю, но чтобы это юзер понял, это надо разъяснить) может, там, с точки зрения удобства эксплуатации. Но вот я даже щас документацию какую-то нашёл и почитал astralinux.ru/products/astra-linux-special-edition/relizyi/smolensk/dokumentacziya/rukovodstvo-po-kompleksu-sredstv-zashhityi.-chast-1.pdf и как-то не возникло ощущения простоты)pdevyanin
08.06.2022 08:57Действительно, и там LSM-модуль (SELinux) и там (PARSEC в ОС Astra Linux Special Edition), и тот и другой чего-то на основе меток проверяют, тогда в чем разница? А разница огромная. В первую очередь лежащие в основе МКЦ (и МРД) в PARSEC именно ясные и четкие правила управления доступом. Их не много, большая часть из них есть в ГОСТ Р 59453.1-2021. В нашем случае, например, правило – низкоцелостный процесс (даже от имени суперпользователя root) не должен модифицировать высокоцелостные (системные) файлы, или, нельзя запустить высокоцелостный процесс из низкоцелостного бинарного файла. Понять главный принцип МКЦ — нельзя с меньшего уровня целостности модифицировать или захватывать управление над компонентами большего уровня целостности, не составляет большого труда как пользователям, так и администраторам ОС. В SELinux для выражения подобных правил требуется многочисленные (исчисляемые в совокупности сотнями) труднопонимаемые отдельные политики.
И конечно надо еще раз отметить, что в случае SELinux в его безопасность вообще, и конкретных наборов политик в частности, надо по сути верить на слово. А безопасность PARSEC подтверждается, начиная с развитой формальной модели, и заканчивая всесторонним анализом и дедуктивной верификацией его кода, о чем подробнее можно посмотреть в нашей статье про методологию разработки безопасного системного ПО (https://ispranproceedings.elpub.ru/jour/article/view/1449).
Некоторая сложность документации объясняется тем, что ОС общего назначения достаточно сложный продукт, в ней велико разнообразие компонент (разные файловые системы, файлы и каталоги разных видов, сокеты и т. д.) доступом к которым надо управлять. Поэтому в документации (на то она и документация) приходится описывать все эти случаи и особенности.
Понимая это, мы стремимся ситуацию исправить. На это направлены и данная статья, и упомянутые в предыдущих комментариях учебные пособия, которые либо вышли, либо готовятся к выходу.
mylitsyn
08.06.2022 10:40Наверное, потому обычно SELinux обычно отключают, за редким исключением фиксированного сценария применения какого-то сервиса. Переписывать (а уж тем более разрабатывать политики с нуля) обычно никто желанием не горит и таких специалистов на мировом рынке не так уж и много. А уж специалистов, которые имеют опыт и знания верификации политик SELinux вообще днем с огнем не сыскать.
v_tel_v
07.06.2022 20:49В том и преимущество, что средства защиты информации ОС Astra Linux работают "прозрачно" для пользователей и для большинства ПО, непрерывно обеспечивая все заложенные в них еще на этапе разработки ОС правила управления доступом (МКЦ, ЗПС, МРД и т.д.). Т.е вне зависимости от типа ПО и выполняемых им функций, его системные компоненты будут защищены от непреднамеренной модификации за счет обладания высоким мандатным уровнем целостности (МКЦ), а пользовательские данные сохранены и доступны только на соответствующем пользователю уровне конфиденциальности (МРД). Например, не важно, используете ли вы для редактирования файлов vim, nano, mcedit, kate или что-то еще и от имени какого пользователя вы это делаете - СЗИ отработают в любом случае одинаково на основе одних и тех же "вшитых" правил.
Контексты (политики) же SELinux (AppArmor), например, могут и задаются для каждого ПО отдельно (для AppArmor - профиль ПО, для SELinux - домены процессов и типы файлов, соответствующие данному ПО, если совсем упрощенно). При этом нет гарантий, что разработчик этого ПО или администратор действительно задал и задал вообще правильные правила в рамках данных контекстов (политик), что эти контексты непротиворечивы между собой и т.п, что приводит к ситуациям, представленным в скринах по ссылке в комментариях выше. И тут проблема даже больше не в том, что были излишне запрещены какие-то доступы, а наоборот - что в попытках избежать подобных ситуаций, были предоставлены чрезмерно высокие полномочия. Да и осуществлять поддержку систем, где используются политики, сконфигурированные на "свой вкус и лад" (при этом без гарантии корректности), куда сложнее...
cogniter
07.06.2022 22:09-1все верно, при этом простота работы СЗИ в Астре подтверждается тем, что под мандатное управление доступом в Астре разработано довольно большое количество тяжелых приложений, например 1С Предприятие с поддержкой мандатного управления доступом.
Пройти такой подвиг под политики SELinux пока никто не решился.
sam_11
08.06.2022 12:19Вот про подвиг, это Вы в самую точку! Для корректной работы прикладных программ в “Астре” с “максимальным” уровнем безопасности все ограничения, накладываемые механизмами защиты, должны быть учтены на всех стадиях разработки системы. Существующее ПО использовать без доработки практически невозможно. При обмене данными по сети необходимо учитывать мандатные метки сетевых пакетов. Ну и так далее. “Астра” (по сравнению с тем же МСВС), конечно, большой шаг вперед. Но пора уже организовывать учебные курсы «Как разработать систему на «Астре» и не попасть в дурку».
mylitsyn
08.06.2022 12:21-1Так есть же все рекомендации и руководства: документация для разработчиков
Дополнительно еще готовим контрольные примеры в коде, скоро опубликуем уже
vitalif
07.06.2022 22:37Ну плюс-минус наверное понятно, типа имеется в виду, что принцип работы по меткам, как у селинукса, но при этом наворочено не так, как у селинукса… Ну возможно, фиг знает. Но так-то ведь может эти мандаты даже можно и на селинуксе смоделировать правилами, принцип-то вроде тот же примерно — какие-то метки на файлах, какой-то контекст на процессах…
// даже чего-то про «лападулу» в документации селинукса пишутpdevyanin
08.06.2022 09:46-1В самом общем виде можно с этим согласиться. Потенциально после доработки SELinux может начать делать то, что умеет PARSEC, например, реализовывать МКЦ. Но ключевым здесь все равно останется вопрос доверия, т. е. почему безопасности решений на основе SELinux можно доверять. На чем строится доверие несколько слов сказано в статье и в комментариях выше.
Здесь добавлю, что есть еще одно препятствие для применения SELinux во многих важных на практике случаях. Оно кроется в архитектуре самого SELinux — наборы подготовленных для него политик перед загрузкой в соответствующий LSM-модуль ядра ОС компилируются в бинарный формат. Это затрудняет применение SELinux в составе сертифицированных средств защиты информации (СЗИ), где возможность модификации исполняемого кода в процессе эксплуатации СЗИ четко регламентирована. Реализация рассматриваемой технологии в SELinux может потребовать запрета на изменение заранее подготовленных разработчиком СЗИ политик, что не удобно и не гибко (например, при эксплуатации СЗИ может быть запрещено корректировать политики управления доступом при установке нового ПО).
shuric_32
07.06.2022 17:53Еще не проверял этот вариант в Астре. Но хочу спросить. Как обстоять дела с безопасностью, если например сделать образ live линукса и загрузиться с него, где установленная Астра. Таким образом можно получить доступ к жесткому диску и его данным или будет отказано в доступе?
cogniter
07.06.2022 18:17+1Таким образом можно получить доступ к жесткому диску
shuric_32
07.06.2022 19:35тогда получается, что можно скопировать или прочесть информацию с жесткого диска (на разных дистрибутивах это было проверено). А какие методы защиты применяются в Астре против этого способа? Например, криптография используется для защиты папок и файлов?
cogniter
07.06.2022 22:15-1Можно использовать шифрование, можно средства доверенной загрузки - все, что угодно и все что применяется сейчас для таких типов угроз, как загрузка с внешнего носителя
shuric_32
07.06.2022 22:50А в Астре это есть ?
v_tel_v
07.06.2022 23:48Да, начиная с применения штатного защитного преобразования данных и встроенных утилит шифрования, в том числе на основе ГОСТовых алгоритмов, заканчивая применением модулей доверенной загрузки и специализированных криптографических средств.
cogniter
08.06.2022 09:36-1В Астре есть все эти возможности, в том числе можно сразу при инсталляции задать использование томов LVM с применением LUKS
sam_11
08.06.2022 10:13Все что угодно использовать, наверное, не стоит? :) Не так давно “РусБИТех”, кроме “Астры”, поставлял аппаратно- программные модули доверенной загрузки (АПМДЗ) “Максим”. Несколько лет назад это направление прикрыли. АПМДЗ “Соболь” (на него привел ссылку v_tel_v), насколько я знаю, сейчас не поставляются из-из проблем с закупкой комплектующих. Думаю, у других производителей АПМДЗ те же проблемы (этих производителей вcего три-четыре конторы). Как альтернатива – использование программных средств доверенной загрузки. Это, по сути, модернизированный UEFI (BIOS). Но это решения жестко завязаны на конкретные модели материнских плат.
Если собираетесь использовать серьезные средства криптографической защиты, придется получать соответствующую лицензию ФСБ (спокойно, мальчики, вами занимается другое управление этой организации ;)).
Так что, с защитой от загрузки с внешнего носителя не так все просто.mylitsyn
08.06.2022 10:31да, поэтому сейчас популярность программных СДЗ выросла, например, ViPNet SafeBoot
sam_11
08.06.2022 15:07У ПСДЗ свои недостатки. Если у меня сдох или заглючил АПМДЗ, я ( в крайнем случае ) могу вскрыть системный блок, удалить его и продолжить работу. В аналогичном случае с ПСДЗ мне нужно менять матиринку или перепрошивать BIOS.
Да и ещё морока с проверкой работоспособности конкретной матиринки после того как ее BIOS слегка «усовершенствовали» некие умельцы.
Оптимальный вариант, на мой взгляд, своя системная плата и свой BIOS с встроенным сертифицированным СДЗ. Кажется, «Крафтаэй» что-то такое делал.
9ella
07.06.2022 22:23много лет работало с иностранными решениями, например, ОС Microsoft Windows
Эта, а Линукс отечественный, значить?
AstraLinux_Group Автор
07.06.2022 22:45Astra — отечественный дистрибутив Linux
v_tel_v
07.06.2022 23:13Плюс к этому, в основе ОС лежит не просто открытое общедоступное ядро Linux - для обеспечения качества и доверия к нему прилагаются немалые усилия со стороны отечественных специалистов.
AstraLinux_Group Автор
07.06.2022 23:22Спасибо за дополнение. Стоит отметить, что компоненты собственной разработки решают ключевые задачи обеспечения безопасности и возможностей взаимодействия с графическим интерфейсом.
Volkodlak
08.06.2022 07:33Серверы-то успели закупить или теперь на базе JINGSHA всё будет собираться?)
Астралинуксы, РЕДОСы, Росы, Альты, etc готовы к внедрению "российского" ядра от ИСП РАН, а участвовать в процессе разработки будут?
AstraLinux_Group Автор
08.06.2022 09:39Сборка нашего дистрибутива всегда осуществлялась на собственных серверных мощностях
Volkodlak
08.06.2022 10:09Вопрос был касаемо статьи "Создание российской ветки ядра Linux", где для реализации проекта заявлено 4 сервера.
Ну и от вас хотелось бы услышать по второй части, если вдруг когда-нибудь таки создадут российскую ветку ядра Linux, то вы готовы перейти на него? или может непосредственно принимать участие в разработке планируете, есть у вас специалисты которые могут разрабатывать ядро?)
mylitsyn
08.06.2022 10:41Конечно, есть специалисты. Ведь в Астре используются собственные LSM и LKM модуля ядра, и ядерщики, безусловно, есть в штате. Как без них разрабатывать собственные СЗИ, работающие на уровне ядра ОС?
Urub
08.06.2022 13:06Ежели на форуме астры не хотят отвечать по поводу судьбы бесплатного "Common Edition" - отвечайте тут - какая судьба уготована ей ?
mylitsyn
08.06.2022 13:10Никаких изменений не было. Просто Common Edition из продаж выведен и всё.
Urub
08.06.2022 13:47Планируется ли далее развивать и поддерживать Common Edition ? На сайте она помещена в раздел "ПРЕДЫДУЩИЕ ОПЕРАЦИОННЫЕ СИСТЕМЫ" и судьба ее не очевидна.
AstraLinux_Group Автор
08.06.2022 18:59-2На сегодняшний день CE доступна для скачивания и некоммерческого использования на сайте компании (как вы и озвучили в разделе предыдущие операционные системы). О дальнейшей судьбе и развитии CE как дистрибутива мы обязательно сообщим.
saipr
А что с неосновными (какими?) угрозами безопасности информации?
mylitsyn
Основныее угрозы перечислены в методике ФСТЭК России:
СБОР ИНФОРМАЦИИИ
ПОЛУЧЕНИЕ ПЕРВОНАЧАЛЬНОГО ДОСТУПА
ВНЕДРЕНИЕ И ИСПОЛЬЗОВАНИЕ ВРЕДОНОСНОГО КОДА
ЗАКРЕПЛЕНИЕ В СИСТЕМЕ И СЕТИ
УПРАВЛЕНИЕ ВРЕДОНОСНЫМ КОДОМ И КОМПОНЕНТОМ
ПОВЫШЕНИЕ ПРИВИЛЕГИЙ
СОКРЫТИЕ ДЕЙСТВИЙ
ПОЛУЧЕНИЕ ДОСТУПА К ДРУГИМ КОМПОНЕНТАМ
СБОР И ВЫВОД ИНФОРМАЦИИ
НЕПРАВОМЕРНЫЙ ДОСТУП ИЛИ ВОЗДЕЙСТВИЕ