Integrity level astra linux что это

Параметры модуля ядра Parsec, задаваемые в загрузчике

При установленном обновлении БЮЛЛЕТЕНЬ № 2022-0819SE17 (оперативное обновление 1.7.2) и работе в режиме усиленного МКЦ (strict-mode, см. Изменения в документацию, связанные с обновлением № 2022-0819SE17 (оперативное обновление 1.7.2)) этот параметр игнорируется и следует использовать привилегию PARSEC_CAP_CCNR_RELAX (см. Привилегии PARSEC).

дает право непривилегированному пользователю производить создание и модификацию файловых объектов с разным классификационными метками в контейнере (каталоге) с установленным флагом ccnr.

Допустимые значения: 0/1.
Значение по умолчанию: 0

Текущее значение целостности: никак не влияет на поведение.
Допустимые значения : 0/1, y/n,…
Значение по умолчанию: 1 (обнуляет уровень)

Допустимые значения : 0/1, y/n,…
Значение по умолчанию: 1 (загрузка запрещена)
Допустимые значения : 0/1, y/n,…
Значение по умолчанию: 0 (установка флага разрешена).

Допустимые значения 0/1
Значение по умолчанию 0 (запуск сценариев и исполняемых файлов с файловых систем, смонтированных с помощью файловой системы FUSE запрещен).

Уровень конфиденциальности, категории конфиденциальности и целостность: что есть что, и как с этим работать?

Система защиты информации (далее — СЗИ) Astra Linux Special Edition оперирует следующими мандатными атрибутами:

Иерархический уровень конфиденциальности (далее по тексту- уровень конфиденциальности);
Неиерархическая категория конфиденциальности (далее по тексту — категории конфиденциальности);
Неиерархический уровень целостности (далее по тексту — уровень целостности);
Мандатные атрибуты управления доступом (в данной статье не рассматриваются).

Что есть что в этом списке, в чем сходство, и в чем различие?

«Уровни» и «категории» конфиденциальности, «целостность» — в чем различия?

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

Уровень конфиденциальности

Классический пример уровней конфиденциальности — это степени повышающейся секретности документов (сущностей): «Не секретно» — «ДСП» — «Секретно» — «Совершенно секретно», и соответствующие им уровни доступа к этим документам, назначенные персоналу (субъектам).

Очевидно, что в такой системе персоналу с уровнем доступа, например, «ДСП», разрешено читать только документы уровней «ДСП» и «Не секретно», и запрещено читать документы с более высокими уровнями конфиденциальности («Секретно» и «Совершенно секретно»).

Не столь очевидно, но персоналу с уровнем конфиденциальности, например «Секретно», запрещено передавать (преднамеренно или случайно) персоналу с более низким уровнем доступа «ДСП» документы уровня «Секретно» (теоретические подробности можно найти в многочисленных описаниях модели безопасности Белла-ЛаПадулы (англ. Bell-LaPadula).

Категории конфиденциальности

Для более точного управления доступом, в дополнение к разделению по уровням конфиденциальности,
СЗИ предоставляет возможность разделить материалы по категориям конфиденциальности.

Простой пример категорий конфиденциальности имеется в документе «Руководство по КСЗ. Часть 1 РУСБ.10015-01 97 01-1», где описано использование двух условных категорий «Танки» и «Самолёты». При этом персонал, работающий с «Танками», и имеющий соответствующую категорию конфиденциальности, не сможет ни получать сведения о «Самолётах», ни передавать сведения о «Танках» тем, кто работает с «Самолётами», но, в то же время, условному «Руководителю» могут быть предоставлены одновременно обе категории конфиденциальности, чтобы «Руководитель» мог получать полный объём информации.

Итак, с помощью параметров уровень конфиденциальности и категории конфиденциальности СЗИ обеспечивает защиту от несанкционированной передачи информации:

Невозможность прочитать информацию, к которой не предоставлен доступ:

«нижним» уровням запрещено читать информацию с «верхних» уровней;
всем запрещено читать информацию, на которую нет разрешенной категории конфиденциальности;

«верхним» уровням запрещено записывать свою информацию на «нижние» уровни;
всем запрещено передавать информацию тем, у кого нет соответствующей категории конфиденциальности.

Правила, по которым СЗИ определяет возможность доступа к данным, описаны ниже.

Целостность

Атрибут уровень целостности отвечает за то, чтобы информацию не могли изменять те, кому не положено её изменять.

И, в первую очередь, атрибут уровень целостности отвечает за безопасность самой информационной системы.

Пример для пояснения:

Модель контроля целостности с 2007 г. реализуется в механизме MIC (Mandatory Integrity Control) всех ОС семейства Microsoft Windows,
где показала свою эффективность при противодействии компьютерным вирусам и атакам, направленным на несанкционированное повышение привилегий.

(теоретические подробности модели контроля целостности можно найти в описаниях модели безопасности Биба (англ. Biba)).

В общем, требование защиты целостности выглядит так:

Субъект (процесс или пользователь), работающий на некотором уровне целостности, может записывать (изменять) только сущности (объекты) своего, или более низкого уровня (запись «вверх» запрещена).

В СЗИ ОС Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.5) была реализована двухуровневая модель целостности, далее, начиная с ОС Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.6) и в ОС Astra Linux Special Edition РУСБ.10265-01 (очередное обновление 8.1), модель целостности расширена до многоуровневой.

Правила, по которым СЗИ определяет возможность доступа к сущностям при работе с контролем целостности, также описаны ниже.

Сущности мандатного управления доступом

Система мандатного управления доступом работает со следующими понятиями:

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

и определяет условия, при которых субъектам разрешено выполнять операции с сущностями (создавать, получать доступ к содержимому, изменять).

Каждому субъекту и каждой сущности назначаются определённые мандатные атрибуты (или не назначаются никакие, что приравнивается к минимальным (нулевым) мандатным атрибутам).
Мандатные атрибуты субъекта/сущности объединяются в мандатный контекст этого субъекта/сущности.

Решение о возможности или невозможности выполнения операций доступа автоматически принимается СЗИ на основании сравнения меток безопасности субъекта и сущности.

Мандатный контекст, метка безопасности, мандатные атрибуты управления доступом

Атрибуты мандатного управления доступом

Иерархический уровень конфиденциальности (уровень конфиденциальности) — единичное (скалярное) числовое значение (иногда называется «уровень секретности» или просто «уровень»).
Каждой метке безопасности (классификационной метке в составе метки безопасности) в каждый момент времени может быть назначен один и только один уровень конфиденциальности.
Числовые значения уровня конфиденциальности сущности:

Все сравнимы между собой;
Могут находится в диапазоне 0 до 255, включая границы;
Технически реализованы как 8-ми битная беззнаковая величина (uint8_t);
В пользовательских интерфейсах представляются десятичным значением или наименованием единичного уровня конфиденциальности;
Теоретически, множество возможных значений уровня конфиденциальности сущности представляет собой линейное упорядоченное множество относительно операции сравнения.

Неиерархические категории конфиденциальности (категории конфиденциальности) — маска , состоящ ая из набора единичных значений категорий конфиденциальности ( так же применяются назва ние просто «категория») .
В Astra Linux Special Edition реализовано использование до 64-х единичных категорий конфиденциальности, таким образом, каждой метке безопасности (классификационной метке в составе метки безопасности)
в каждый момент времени могут быть назначены одновременно до 64-х категорий конфиденциальности. Единичные категории конфиденциальности несравнимы между собой.
Числовые значения категории конфиденциальности сущности:

Частично сравнимы между собой;
Определяются как суммы значений назначенных единичных категорий конфиденциальности;
Могут принимать значения от 0 до 0xFFFF FFFF FFFF FFFF, включая границы;
Технически реализованы как 64-x битная маска, беззнаковая величина (unsigned long long);
В пользовательских интерфейсах представляются шестнадцатеричным значением или списком наименований единичных категорий конфиденциальности;
Теоретически, множество возможных значений категорий конфиденциальности сущности представляет собой полное частично упорядоченное множество относительно операции сравнения.

Неиерархический уровень целостности (уровень целостности)

№ п/п	Значение	Битовая маска	Комментарий
	000	0000 0000	Нулевой уровень. «Низкий», или «Low»
1	001	0000 0001	Уровень задействован как «Сетевые сервисы»
2	002	0000 0010	Уровень задействован как «Виртуализация»
3	004	0000 0100	Уровень задействован как «Специальное ПО»
4	008	0000 1000	Уровень задействован как «Графический сервер»
5	016	0001 0000	Свободен, может быть использован для СУБД
6	032	0010 0000	Свободен, может быть использован для сетевых сервисов
7	064	0100 0000	Зарезервирован, и может быть использован при поднятии max_ilev
8	128	1000 0000	Зарезервирован, и может быть использован при поднятии max_ilev

Дополнительно зарезервировано специальное наименование уровня целостности «Высокий» («High»).
Уровень «Высокий» не является единичным уровнем, а представляет собой максимальную сумму единичных уровней, определённых в системе
(имеет значение 63 при использовании 6-ти уровней, или значение 255 при использовании 8-ми уровней целостности).

Частично сравнимы между собой;
Определяются как суммы значений назначенных единичных уровней целостности;
Могут принимать значения от 0 до 63 (255), включая границы;
Технически реализованы как 8-ми битная маска, беззнаковая величина (uint8_t);
В пользовательских интерфейсах представляются десятичным значением или наименованием единичного уровня целостности;
Теоретически, множество возможных значений уровня целостности сущности представляет собой полное частично упорядоченное множествоотносительно операции сравнения.

Далее в тексте под терминами «уровень целостности» и «категория конфиденциальности» будут пониматься значения соответствующих мандатных атрибутов,
являющиеся суммами соответствующих единичных значений.

Сравнение мандатных атрибутов

Операции сравнения уровней конфиденциальности, категорий конфиденциальности уровней целостности определяются следующим образом:

Уровень конфиденциальности cL₀ больше или равен уровню конфиденциальности cL₁ (cL₀ >= cL₁),
если численное значение cL₀ больше или равно численному значению cL₁;
Категории конфиденциальности C₀ больше или равны категориям конфиденциальности C₁ ( C₀ >= C₁),
если все биты набора C₁ являются подмножеством набора бит C₀ или наборы совпадают.
В терминах побитовых операций: (C₀ & C₁) == C₁;
Уровень целостности iL ₀ больше или равен уровню целостности iL ₁ (iL ₀ >= iL ₁ ),
если все биты набора iL ₁ являются подмножеством набора бит iL ₀ или наборы совпадают.
В терминах побитовых операций: (iL₀ & iL₁) == iL₁.

Разрешения на доступ

Пусть метка безопасности субъекта содержит следующие атрибуты:

Классификационная метка:
- Уровень конфиденциальности cL_суб;
- Категории конфиденциальности C_суб;
- Уровень целостности iL_суб.
а метка безопасности сущности содержит атрибуты:
- Метка конфиденциальности:
  - Уровень конфиденциальности cL_об;
  - Категории конфиденциальности C_об;
  - Уровень целостности iL_об.
  Правила наследования и изменения
  - Если субъект создаёт другого субъекта (например, процесс создаёт процесс),
    то созданный субъект полностью наследует метку безопасности родителя,
    т.е. наследует и уровень конфиденциальности, и категории конфиденциальности, и уровень целостности ;
  Преимущества использования СЗИ в ОС Astra Linux Special Edition
  
  Каждый разумный владелец или пользователь информационной системы (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 базируется на применении отечественных доверенных технологий разработки входящих в ее состав СЗИ, в основе которых лежат в целом простые и понятные правила управления доступом. При этом комплексное применение этих СЗИ (особенно в режимах их функционирования «Усиленный» или «Максимальный») обеспечивает реальную защищенность от основных угроз безопасности информации.
  
  Astra Linux Special Edition
  
  информационная безопасность
  
  режимы функционирования СЗИ
  
  мандатный контроль целостности
  
  управление доступом
  
  контроль целостности
  
  сзи
  
  astra linux
  
  «Хакер» — Русский бронированный Debian. Как устроена новая модель управления доступом в Astra Linux SE
  
  Россия, как известно, родина слонов. А также ракетных комплексов, подводных лодок, танков и, как оказалось, не менее бронированных операционных систем. Если ты рубишь в ИБ и живешь в России, то это как раз тот вид вооружений, которым ты можешь интересоваться и даже гордиться. Astra Linux SE — одна из таких ОС. Наш автор Евгений Лебеденко — специалист по таким системам, так что приготовься взглянуть на безопасность в Linux с самой серьезной стороны!
  
  Операционные системы сегодня — это не просто набор служебных функций, который позволяет компьютеру работать. Операционки стали играть огромную роль в мире потребительской электроники: Microsoft приспосабливает Windows для всех возможных устройств, Apple экспериментирует с интерфейсом мобильных и десктопных систем, Google развивает Android и одновременно превращает в операционную систему Chrome.
  
  В корпоративной среде прогресс ОС тоже идет по полной: программно-конфигурируемые сети (SDN), виртуальные серверы, глобальные и частные облака. Здесь на первый план выходит не юзабилити, а защищенность и соответствие жестким требованиям к безопасности.
  
  Есть и еще одна область, в которой защита превыше всего, — это ОС для государственных и военных нужд. Это еще один параллельный мир операционных систем — безумно консервативный, но и в нем существует прогресс. Причем не только за рубежом, но и у нас. Показательный пример — это дистрибутив Astra Linux SE.
  
  Пять лет. Полет нормальный
  
  Astra Linux — не единственный российский защищенный дистрибутив. Есть и другие, и все они успешно прошли проверку в органах сертификации и нашли свои рыночные ниши. Детище НПО «РусБИТех» — не исключение. Astra Linux SE с завидной регулярностью получает сертификаты соответствия в системах сертификации ФСТЭК, Министерства обороны и ФСБ. Действующие на настоящий момент версии имеют «срок годности» до 2018 года.
  
  На основе Astra Linux развернуты и функционируют десятки информационных систем — как в государственных, так и в коммерческих структурах. Среди них, например, такие крупные, как защищенная платформа для государственной автоматизированной системы гособоронзаказа.
  
  В составе дистрибутива Astra Linux SE есть все необходимое, чтобы развернуть защищенную инфраструктуру
  
  Astra Linux отметился и в популярной ныне теме импортозамещения. Вполне вероятно, что органы госвласти самого «санкционированного» российского региона — Республики Крым — будут использовать эту ОС в качестве базы для своей инфраструктуры ИТ. В общем, менеджерам «РусБИТех» есть чем гордиться. Но нас, конечно, больше всего интересуют не те достижения, что связаны с продажами и историями успеха.
  
  Первый релиз Astra Linux вышел в конце 2009 года. С тех пор дистрибутив совершенствуется, следуя за основной веткой Debian, но при этом разработчики не забывают о главном — повышенной безопасности. Предприятие «РусБИТех» неплохо оснащено научными кадрами и при этом ведет активное сотрудничество с вузами и исследовательскими институтами, которые специализируются на информационной безопасности.
  
  Черты, которые делают Astra Linux 1.4 уникальным, относятся как раз к этой теме. В фирменной подсистеме безопасности PARSEC используется формальная модель разграничения доступа. Она была разработана в Институте криптографии, связи и информатики Академии ФСБ России, а в оценке качества принял участие Центр верификации ОС Linux Института системного программирования РАН. Реализация этой модели в Astra Linux SE ведется поэтапно, и в версии 1.4 добавлена большая ее часть, но еще не последняя.
  
  MAC в LSM. Далеко не фастфуд в управлении доступом
  
  Прежде чем разбирать модель разграничения доступа в Astra Linux SE 1.4, следует вспомнить некоторые основы. Очевидно, что пользователям информационных систем требуется доступ к данным, а также к набору механизмов ОС, которые обеспечивают этот доступ, — например, к файловым системам и стекам сетевых протоколов.
  
  Именно поэтому в моделях разграничения доступа пользователей именуют субъектами доступа. На самом деле доступ к данным пользователь получает не лично, а через программы, которые «переваривают» эти данные. Именно они и являются настоящими (действительным) субъектами доступа и представляют зарегистрированного в системе пользователя (номинального субъекта). Совокупность программ, которые получают доступ к данным в течение сеанса работы зарегистрированного пользователя, обычно именуется субъект-сессией.
  
  Объектами доступа выступают, конечно же, не сами данные, а их носители, представленные логическими структурами: директориями, файлами, сетевыми сокетами и областями памяти, которые участвуют в межпроцессном взаимодействии.
  
  Задача любой модели разграничения доступа — определить, разрешить (allow) доступ к тем или иным объектам для тех или иных субъектов (субъект-сессий) или отказать (deny) в нем в соответствии с правилами. Если коротко, любая модель разграничения доступа задает некоторые отношения между субъектами и объектами доступа.
  
  Базовая (как говорится, «из коробки») модель безопасности в GNU/Linux — это DAC, дискреционная модель доступа (discretionary access control). Она представляет собой комбинацию произвольного управления доступом (субъект-субъектная модель) и доступа на основе списков (ACL — Access Control Lists).
  
  Субъект-субъектная модель подразумевает, что каждому объекту сопоставляется один субъект — владелец объекта. Он наделен правом давать или отнимать доступ к этому объекту другим субъектам. ACL — это таблица, объединяющая субъекты и объекты доступа при помощи перечисления прав, которыми субъект обладает в отношении объекта.
  
  В общем виде модель DAC в GNU/Linux соответствует «виртуальному» стандарту POSIX ACL (настоящая стандартизация POSIX.1e и POSIX.2с была свернута в силу безбрежности стандартизуемой предметной области) и для большинства случаев вполне подходит на роль «диспетчера доступа» субъектов к объектам.
  
  В DAC-модели Astra Linux SE используется полновесная поддержка стандарта POSIX ACL
  
  Однако защищенные операционные системы — это не «большинство случаев». Одно из важных требований, предъявляемых к ним органами сертификации, — это реализация принудительного контроля доступа, который устраняет определенный волюнтаризм модели DAC. Как и в некомпьютерном секретном делопроизводстве, модель принудительного управления доступом основана на сопоставлении меток конфиденциальности, присвоенных объектам доступа, с официальным разрешением (допуском, мандатом) субъекта. Именно это «официальное разрешение» (мандат) дало такой модели название MAC (Mandatory access control) — мандатное управление доступом.
  
  В GNU/Linux попытки расширения DAC-модели безопасности MAC-моделью предпринимались с 2001 года. Именно тогда АНБ США показало первую версию SELinux с реализацией мандатного управления доступом на основе формальной модели MLS (Multilevel Security). Было предложено включить MLS в состав ядра версии 2.5. Благо сообщество разработчиков Linux такое решение отвергло. Наряду с SELinux похожие реализации MAC-модели разрабатывались в рамках проекта AppArmor и, позже, — в Smack, TOMOYO и других. С какой стати отдавать предпочтение какому-то одному из них?
  
  Вместо жесткой интеграции MAC-модели в состав ядра было принято соломоново решение: использовать расширение модели безопасности GNU/Linux. Она продолжит базироваться на модели DAC, но с использованием особых модулей ядра. В них можно реализовать какой угодно вариант модели управления доступом. Это решение было претворено в жизнь в виде фреймворка LSM (Linux Security Modules), который официально включили в ядро Linux 2.6.
  
  Идея LSM проста. На ключевые с точки зрения управления доступом функции ядра навешивается совокупность «крючков» — хуков (hooks). Они представляют собой интерфейсы подключения обработчиков из модуля LSM, которые вызываются в том случае, если нужен контроль доступа. То есть фреймворк LSM предоставляет разработчику модуля LSM возможность перехвата управления в ходе выполнения тех участков кода ядра, которые отвечают за реализацию доступа субъектов к объектам.
  
  INFO
  
  В ядро новой версии Astra Linux SE включен известный патч безопасности PaX, который обеспечивает возможность тонкой настройки разрешений для приложений при их работе со страничной памятью.
  
  Прелесть такого подхода заключается в том, что внутри модуля LSM можно реализовать любую модель управления доступом — как общего назначения, так и с учетом специфических особенностей эксплуатации системы. Естественно, эффективность подхода LSM напрямую зависит от широты охвата хуками функций ядра Linux. Но с этим, судя по всему, проблем нет. С момента включения LSM в ядро 2.6 по настоящее время было реализовано около двухсот хуков, и их внедрение ведется параллельно с появлением новых функций ядра.
  
  Фреймворк LSM не заменяет модель DAC — она остается «первой линией обороны». Обработка хуков LSM начинается только после успешного прохождения контроля доступа по линии DAC. Такая двухъярусность позволяет не перегружать функциями безопасности те системы, где это не нужно. Там можно попросту не использовать LSM.
  
  Безопасность SELinux базируется как раз на модулях LSM, равно как все остальные рассмотренные выше проекты, которые реализуют мандатное управление доступом. Подсистема безопасности PARSEC, функционирующая в составе Astra Linux SE, — это тоже модуль LSM. И даже не один.
  
  В Astra Linux SE подсистема безопасности PARSEC базируется на фреймворке LSM
  
  XPARSEC
  
  Подсистема безопасности PARSEC в Astra Linux SE 1.4 содержит модуль XPARSEC, благодаря которому сервер X.Org получает возможность определять привилегии клиента X.Org (программы с графическим интерфейсом) и передавать их с использованием модифицированного X-протокола менеджеру окон Fly-wm. Тот выполняет привилегированные операции во время запуска клиента X.Org с различными мандатными контекстами. При этом на рабочем столе Fly отображается:
  
  мандатный контекст пользовательской сессии в системном лотке (область tray);
  
  мандатный уровень каждого окна;
  
  мандатный уровень всех приложений, размещенных на рабочем столе Fly;
  
  уровень доверенности окна для локально и удаленно запущенных приложений (цвет рамки окна приложения).
  
  В качестве DE в Astra Linux используется Fly — «брат по коду» KDE 4. В отличие от KDE, Fly — защищенная рабочая среда
  
  Контроль доступа, контроль целостности и роли
  
  Поскольку Astra Linux вовсю используется в разных проектах, связанных с обработкой информации различных уровней конфиденциальности, у разработчиков уже есть статистика, по которой можно судить о корректности реализации модели управления доступом. Не менее важны исследовательские работы, в которых формировались модели нарушителей в рамках известных уязвимостей информационной безопасности CVE (Common Vulnerabilities and Exposures).
  
  Проверке подверглись известные «проблемы» модели Белла — Лападулы. К примеру, деклассификация — когда пользователь с высоким уровнем конфиденциальности случайно или намеренно помещает данные из объекта с соответствующей мандатной меткой в объект с меткой более низкого уровня. Или нарушение логики доступа к данным при обработке потока информации в распределенной среде.
  Моделировалась и проблема компрометации субъекта доступа, в ходе которой повышается уровень его привилегий (включая получение привилегий PARSEC). В результате можно получить возможность управлять доступом к защищаемой информации.
  
  Очевидное решение таких проблем — это модификация формальной модели управления доступом. В случае Linux это делается добавлением модулей LSM, которые реализуют систему PARSEC. Ее основой стала мандатная сущностно-ролевая ДП-модель. Разработка ведется в рамках научной школы в Институте криптографии, связи и информатики Академии ФСБ России.
  
  Подсистема безопасности PARSEC — не только LSM-модули, в которых реализована та или иная модель управления доступом, но и «обвязка»: собственная файловая система parsecfs, конфигурационные файлы, демоны и утилиты
  
  В общем случае эта модель относится к классу ДП-моделей, то есть моделей управления доступом (Д) и информационными потоками (П), в которых учитывается не только единичный акт доступа к данным, но и направления распространения потоков информации при выполнении операций над данными.
  
  Кардинальное отличие мандатной сущностно-ролевой ДП-модели от «классики» MAC — это объединение мандатного и ролевого управления доступом. При этом традиционный подход (уровни конфиденциальности, категории безопасности) мандатной модели в ней усиливается применением мандатного же контроля целостности (MIC, Mandatory Integrity Control) — механизма, который нашел широкое применение в семействе операционных систем Windows, начиная с релизов Vista и Server 2008.
  
  Мандатная сущностно-ролевая модель управления доступом в версии 1.4 Astra Linux SE относится к широкому классу ДП-моделей
  
  Приоритет в мандатной сущностно-ролевой ДП-модели — это MAC-модель, усиленная ролевой моделью и моделью управления целостностью
  
  Фактически управление целостностью (integrity) правильнее называть управлением уровнем доверия. К традиционной проверке целостности данных (например, на основе подсчета их контрольных сумм) механизм MIC отношения не имеет. Назначаемые объектам и субъектам доступа уровни доверия дополняют традиционную модель управления доступом и гарантируют, что субъекты с низким уровнем целостности (IL — Integrity Level) не могут влиять на объекты с более высоким уровнем целостности.
  
  Реализация мандатной сущностно-ролевой модели в Astra Linux SE 1.4 поддерживает наличие двух уровней целостности: высокий (hi) и низкий (low). Этого достаточно для разделения субъектов и объектов доступа на доверенные и недоверенные. При этом переменная, которая определяет значение IL, может принимать одно из 255 значений. Это означает, что в последующих реализациях модели может появиться более чем один уровень целостности. Подобный подход используется в модели MIC операционных систем Windows, поддерживающей пять (от untrusted до system) значений IL.
  
  Еще одна важная особенность мандатной сущностно-ролевой модели — это учет иерархичности организации как ряда объектов доступа, так и функций (ролей), выполняемых субъектами. Такой учет позволил отнести и подобные объекты, и роли субъектов доступа к единой категории «сущность». В рамках этой категории могут формироваться отношения иерархии. Например, каталог может считаться сущностью-контейнером. Размещенные в нем объекты — файлы и подкаталоги — будут для него дочерними сущностями.
  
  Аналогичным образом можно рассматривать и роли субъектов. Корневыми будут роли администратора (суперпользователя) и индивидуального пользователя. На самом деле иерархии сущностей-ролей — это вложенные друг в друга функции субъекта, вся совокупность которых в сумме и определяет корневые роли.
  
  Что дает учет иерархии сущностей? Например, совместно с моделями MAC и MIC он позволяет определять правила размещения обычных объектов-сущностей с разными мандатными метками и уровнями IL в сущности-контейнере с определенными мандатной меткой и уровнем IL. Именно эта возможность и используется в текущей реализации сущностно-ролевой модели путем добавления к DAC-, MAC- и MIC-атрибутам директорий (напомним, что это — сущности-контейнеры) дополнительных атрибутов ccnr и ccnri. Они ограничивают возможность размещения в контейнерах объектов с мандатными метками и уровнями целостности, которые превышают таковые у самой директории.
  
  Чтобы создать дочерний объект в отмеченных подобным образом директориях, даже с мандатными метками и уровнями IL ниже, чем у «родителя», субъект должен иметь соответствующие PARSEC-привилегии. Равно как и для установки ненулевого значения указанных атрибутов. При этом установка этих атрибутов не мешает просмотру объектов внутри директории.
  
  Кроме ограничивающих атрибутов, для любых сущностей (не только сущностей-контейнеров) возможна установка атрибута ehole. Он позволяет игнорировать мандатные метки целостности при выполнении операций записи в них. Такой атрибут необходим для работы с объектами общего пользования — к примеру, директорией tmp.
  
  Правила разграничения доступа в мандатной сущностно-ролевой ДП-модели учитывают иерархическую организацию ряда сущностей-объектов доступа
  
  Скрипт инициализации правил разграничения доступа для ключевых директорий корневой файловой системы Astra Linux SE
  
  Реализовав в LSM-модулях PARSEC мандатную сущностно-ролевую ДП-модель, разработчики не забыли и о средствах ее администрирования. Ведь набор утилит мандатного управления доступом в Astra Linux SE 1.3 был ориентирован на традиционную MAC-модель и не учитывал рассмотренные выше новшества.
  
  В версии 1.4 появилась совокупность утилит pdp-, которые поддерживают просмотр и модификацию как традиционных MAC-атрибутов (уровни и категории), так и MIC-атрибута (уровни целостности) и дополнительных атрибутов (ccnr, ccnri, ehole). Впрочем, утилиты из предыдущей версии никуда пока не делись и применяются, чтобы облегчить администраторам уже функционирующих информационных систем миграцию субъектов и объектов доступа на новую модель.
  
  В настройках среды окружения нового варианта подсистемы PARSEC первую скрипку играют новые pdp-утилиты
  
  Распространение абстракции «сущность» не только на объекты доступа, но и на роли, реализуемые субъектами, позволяет применить подобный подход и к иерархии «роль-контейнер» — «дочерняя роль». Правда, в реализации модели для Astra Linux SE 1.4 gjkysq переход к ролевому управлению не выполнен (сущности-контейнеры «административная роль» и «индивидуальная роль» еще пусты).
  
  Сейчас вовсю идет разработка версии 1.5, где в полном объеме будет реализована главная особенность мандатной сущностно-ролевой модели — приоритетное выполнение требований мандатного управления доступом при реализации ролевого управления в сочетании с мандатным контролем целостности.
  
  Следует еще задать вот какой вопрос: корректна ли новая, достаточно сложная и для понимания, и для реализации модель управления доступом? Не несет ли она на логическом уровне возможностей для несанкционированного доступа? Достоинство Astra Linux SE здесь в том, что корректность его решений проверяет научное сообщество. В частности, в процессе занят Центр верификации ОС Linux Института системного программирования РАН — там разрабатываются тесты и технологии тестирования как модулей ядра Linux, так и в целом инфраструктуры LSB (Linux System Base).
  
  Так, Центром в рамках проекта Linux Deductive Verification на основе методологии дедуктивной верификации последовательных программ был разработан набор свободно распространяемых инструментов верификации — Astraver Toolset 1.0. Они помогают убедиться в корректности реализации LSM-модулей подсистемы PARSEC, которые поддерживают новую мандатную сущностно-ролевую модель. Они же помогут тестировать и будущие версии Astra Linux SE.
  
  В tray-области рабочего стола Fly-wm для пользователя отображается его уровень конфиденциальности и категории безопасности
  
  Файловый менеджер fly-fm отмечает цветовыми метками документы с разными MAC-атрибутами и цветной рамкой уровень доверенности окна приложения
  
  Выводы
  
  К отечественным системным программным разработкам, особенно если они ведутся на основе опенсорсных проектов, зачастую относятся с изрядной долей снисхождения. Мол, сложно ли? Любой сможет взять отовсюду понемногу и сделать нечто, выдаваемое за свое. Возможно, иногда так и есть. Но только не в области операционных систем специального назначения. Их разработка скрупулезна, а сертификация проходит не для галочки. Именно такой подход продемонстрирован в Astra Linux SE 1.4, и именно его можно ожидать в последующих версиях этой операционной системы специального назначения.
  
  Добавить комментарий Отменить ответ
  
  Для отправки комментария вам необходимо авторизоваться.
  
  Похожие публикации:
  
  Как выключить индукционную плиту dexp
  
  Как отключить пробуждение от мыши win 7
  
  Как узнать версию питона в jupiter notebook
  
  Что означает передача знаний в программировании