Изменить уровень целостности в astra linux

Обновлено: 04.07.2024

22 октября вышла версия 1.7 отечественной операционной системы Astra Linux Special Edition. В этой статье рассмотрим изменения в схеме лицензирования, сертификации и сделаем обзор новинок защиты. Обзор состава новой версии в предыдущей статье.

Astra Linux Special Edition 1.7: цены.

Вместо двух разных дистрибутивов Astra Linux — Сommon Edition и Special Edition — вводится один. Но в трёх видах. Лицензирование будет происходить по уровню защиты информации:

базовый уровень (вариант «Орёл») — аналог Astra Linux Common Edition;
защита конфиденциальной информации и персональных данных (вариант «Воронеж») — новый вариант в версии 1.7;
защита государственной тайны (вариант «Смоленск») — аналог Astra Linux Special Edition до версии 1.6 включительно.

Как разобраться, какой вам нужен?

Astra Linux Special Edition «Орёл»

Подходит для работы с общедоступной информацией в ИТ-системах, а также для защиты информации в государственных информационных системах 3 класса защищенности, информационных системах персональных данных 3−4 уровня защищенности и значимых объектов критической информационной инфраструктуры.

Astra Linux Special Edition «Воронеж»

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

Astra Linux Special Edition «Смоленск»

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

Уровень лицензирования можно выбрать при установке системы (ролик с установкой есть на нашем канале):

«Требованиях по безопасности информации, устанавливающих уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий».
«Требованиях безопасности информации к операционным системам».
«Профиле защиты операционных систем типа, А первого класса защиты. ИТ.ОС.А1.ПЗ».

Новинка сертификата — наличие функций системы управления базами данных и среды виртуализации.

Новая возможность встроенного комплекса средств защиты информации — независимое использование имеющихся механизмов защиты. Вдобавок к существующим, появились новые:

изоляция контейнеров с помощью расширенного набора уровней целостности (ПО для контейнеров можно посмотреть здесь);
поддержка мандатной защиты в семействе протоколов IPv6;
доработка мандатной защиты для новых версий протокола SMB.

Экран выбора механизмов при установке ОС:

Подход первый, архитектурный

Для улучшения безопасности ОС мы используем два подхода. Первый, архитектурный, заключается в том, что мы разрабатываем и внедряем различные средства защиты информации еще на этапе проектирования. Эти средства образуют комплекс средств защиты (КСЗ), который реализует функции безопасности. С помощью КСЗ мы стараемся достичь того, чтобы в системе уже по умолчанию был минимизирован риск возможных потенциальных угроз.

Архитектура комплекса средств защиты Astra LInux Special Edition

Ключевой элемент КСЗ – монитор обращений, созданный чтобы предотвращать несанкционированный доступ и изменение защищаемых компонентов системы. Монитор предусматривает дискреционное, ролевое и мандатное управление доступом, а также мандатный контроль целостности.

Что такое мандатный контроль целостности? Поясним на примере. Ключевым компонентом ОС является ядро. Соответственно, мы обязаны обеспечить для него максимально защищенную среду выполнения в самой операционной системе, чтобы уменьшить количество возможных способов атаки на ядро.

Для этого мы реализуем в операционной системе мандатный контроль целостности, за счет чего сегментируем ОС по различным подсистемам — так, чтобы взлом одной подсистемы не повлиял на работоспособность других. Если произойдет взлом непривилегированного пользователя ОС (уровень целостности 0) или сетевой подсистемы (уровень целостности 1), системы виртуализации (уровень целостности 2), графического интерфейса (уровень целостности 8) или другого компонента, это не повлечет за собой дискредитацию всего КСЗ (уровень целостности 63).

При этом надо отметить, что указанные уровни не являются иерархическими, то есть не располагаются друг над другом и полностью изолированы друг от друга с точки зрения возможности прав записи. Принадлежность объекта к тому или иному уровню целостности монитор обращений определяет по битовой маске.

Чтобы уровни целостности не воспринимались как иерархические — то есть, например, «уровень 8 имеет больше прав, чем уровень 2», что неверно — каждый из уровней получает свое наименование. Так, например, восьмой уровень целостности называется «Графический сервер», максимально возможный уровень целостности администратора в системе — «Высокий», а нулевой уровень целостности (пользовательский) — «Низкий».

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

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

Поэтому если в результате эксплуатации уязвимости (в том числе, нулевого дня) злоумышленник получит контроль над каким-либо процессом в системе и повысит свои полномочия до привилегированного пользователя (например, root), его метка целостности останется прежней, и, соответственно, он не получит возможности влиять на системные процессы, менять настройки или скрыть свое присутствие в системе.

Принцип работы изолированных уровней целостности

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

Помимо мандатного, есть еще динамический и регламентный контроль целостности. Их применяют для исключения запуска и использования недоверенного или стороннего ПО, а также периодических проверок целостности системы.

Динамический контроль вычисляет и проверяет электронную цифровую подпись исполняемых файлов в момент их запуска. Если ЭЦП нет или она неправильная, в запуске программ будет отказано. В какой-то степени это реализация концепции белых списков, но за счет использования иерархии ключей, выданных разработчикам программного обеспечения.

Работа с динамическим контролем целостности

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

Таким образом в ОС применяется эшелонированная защита от уязвимостей в приложениях и их подмены, чем минимизируется вред от угроз безопасности, в том числе и тех, которые используют уязвимости «нулевого» дня.

Подход второй, процессный

Вместе с архитектурным мы параллельно используем процессный подход: постоянно выявляем и собираем сведения об уязвимостях, прорабатываем эту информацию и передаем результаты в банк данных уязвимостей ФСТЭК России. Так мы готовим и выпускаем плановые и оперативные обновлений ОС. Ищем уязвимости как в открытых источниках, так и самостоятельно — особенно в тех частях ПО, которые полностью разрабатываем сами. Много информации мы получаем от партнеров, занимающихся аналогичными исследованиями — тестированием и изучением безопасности операционных систем.

Организация работ по выявлению уязвимостей

Исследования безопасности в первую очередь ведутся в отношении компонентов, которые входят в состав ОС Astra Linux Special Edition («Смоленск»). Вместе с тем уязвимости закрываются также и для версии Astra Linux Common Edition, как в рамках обновлений безопасности, так и в процессе планового обновления компонентов системы.

Как только мы получаем сведения об уязвимости, проверяем, насколько она актуальна для наших пользователей. Если уязвимость не является критической, то описываем ее в ближайшем выпуске бюллетеня безопасности на официальном сайте. Уведомления об выпуске бюллетеней отправляются пользователю по электронной̆ почте, адрес которой̆ обязательно указывается в лицензионном договоре. Для критических уязвимостей в течение нескольких дней выпускаются методические указания: каким образом можно устранить ее своими силами, не дожидаясь кумулятивного обновления безопасности. В списке бюллетеней безопасности они отмечены буквами MD (мethodical direction).

Здесь хорошим примером является уязвимость, информация о которой была опубликована здесь же, на Хабре. К слову, автор данной статьи с нами заранее не связывался и предварительно не уведомлял о том, что им выявлена данная уязвимость и готовится материал. В качестве иллюстрации мы решили привести тайминг работ над уязвимостью с момента размещения текста на ресурсе.

Итак, ночью, в 4 утра, 9 июля 2019 года была опубликована сама статья, о том, что при манипуляциях с размером экрана виртуальной машины можно увидеть окна под блокировщиком экрана.

Стоит отметить, что для эксплуатации продемонстрированной на видео уязвимости нужно совершить ряд дополнительных действий: необходимо сначала установить на виртуальную машину Astra Linux, а затем и на гостевую машину дополнительные пакеты, которые отвечают за изменение разрешения виртуальной машины «на лету», но при этом не входят в состав сертифицированной операционной системы.

10 июля 2019 года сведения об уязвимости опубликованы в БДУ ФСТЭК. Серьёзность уязвимости была определена как средняя (базовая оценка по метрике CVSS 2.0 составила 4,9, по метрике CVSS 3.0 — 4).

12 июля нами опубликован бюллетень безопасности № 20190712SE16MD для Astra Linux Special Edition версии 1.6 и бюллетень безопасности № 20190712SE15MD для Astra Linux Special Edition версии 1.5. Аналогичное обновление безопасности получил и релиз Astra Linux Common Edition.

Таким образом, с момента размещения информации об уязвимости среднего уровня опасности до выпуска корректирующего патча для всех версий Astra Linux (где возможно использование виртуализации) прошло меньше 4 дней.

Схема выпуска оперативных обновлений для Astra Linux

Не реже чем раз в квартал мы выпускаем обновления безопасности — оперативные обновления, которые устраняют ранее неизвестные уязвимости, в том числе прикладного ПО, библиотек и функций ОС, не реализующих требования безопасности. Если угрозы безопасности, реализуемые с использованием уязвимости, нельзя исключить компенсирующими мерами, проводятся работы по доработке ОС. После завершения доработки и тестирования обновления безопасности на сайте также публикуется бюллетень и само обновление. За первые полгода 2019 года было выпущено два кумулятивных обновления для ОС Astra Linux Special Edition версии 1.6, закрывших сотни различных уязвимостей. Сейчас к выпуску готовится третье.

Наконец, мы активно взаимодействуем с сообществом разработчиков:

сообщаем в багтрекеры проектов о самостоятельно обнаруженных ошибках;
в проекты готовые исправления недостатков, закрытые нами;
обращаемся к коммьюнити с просьбами оказать содействие в устранении недостатков — знание логики работы программы позволяет на порядок быстрее получить исправление нежели реверсивный инжиниринг, проводимый собственными силами;
используем и включаем в свои обновления все выпускаемые сообществом исправления. Мы понимаем, что тем самым повышаем качество продукта. При этом применяем методы контроля и обеспечения доверия, о которых писали в предыдущей статье.

Открытость — это важно

Поскольку наша ОС сертифицирована ФСТЭК России, мы в первую очередь добавляем информацию о найденных уязвимостях в банк данных угроз безопасности информации (БДУ) ФСТЭК для официальной публикации: если вы зайдете в БДУ, то найдете информацию о более чем 350 устраненных уязвимостей в разных версиях Astra Linux, а также подробную информацию по ним.

Таким образом мы обеспечиваем открытость в работе. Благодаря этому пользователи — и регулятор в том числе — могут быть в определенной степени уверены в том, что безопасность действительно находится под контролем. Мало получить обновление, нужно понимать, какие конкретно уязвимости оно закрыло.

Пока что наш архитектурно-процессный подход по поддержанию безопасности ОС полностью себя оправдывает — мы успешно соблюдаем высокий уровень защищенности информационных систем с ОС Astra Linux Special Edition. А открытый доступ к информации об уязвимостях через БДУ ФСТЭК повышает уровень доверия к нашему продукту.

Будем рады ответить на вопросы о безопасности нашей системы в комментариях. Также, если вам интересно узнать что-то новое о системе, оставляйте ваши пожелания — мы их обязательно учтем при дальнейшей работе с блогом.

По умолчанию, после установки ОС:
- включен режим МКЦ ОС:
  - установлен параметр ядра `max_ilev = 63`
  - все процессы, начиная от init до менеджера входа fly-dm, имеют уровень целостности 63 (если в конфигурации юнита явно не указано иное).
  - Графический сервер Xorg по умолчанию работает не от имени суперпользователя root (uid 0), а от пользователя, и работает на выделенном уровне МКЦ 8.
  - Администратор, созданный при установке ОС, получает 63-й «красный» уровень МКЦ,
  - Пользователи получают нулевой «синий» уровень МКЦ
  - Администраторы из группы astra-admin автоматически получают 63-й «красный» уровень МКЦ
  - Пользователи получают нулевой «синий» уровень МКЦ.
  для сетевых сервисов: - 1
  
  для подсистем виртуализации (для гостевых систем, отличных от ОССН Смоленск и контейнеров LXC на нулевом уровне): 2,
  
  для внешнего СПО: 4
  - На контейнеры (каталоги) больше нельзя устанавливать флаги ehole.
    Допускается только установка флагов
  Можно использовать псевдоним CCNRA (соответствует одновременно установленным флагам ccnr и ccnri).
  - Флаг ehole доступен, как и ранее, для установки на файлах, и, дополнительно, введен новый флаг
  дающий разрешение записывать в файл «снизу вверх» (чтение по обычным правилам МРД).
  Новый флаг whole также нельзя устанавливать на контейнерах.
  - Запись в каталог с высокой целостностью и установленным флагом ccnri
    не может быть выполнена процессом с более низким уровнем целостности чем у контейнера (каталога).
  - Пользователь не может производить запись в контейнер (каталог)
    с установленным больше нуля уровнем МКЦ и с установленным флагом ccnri,
    если он не вошел в систему на уровне МКЦ равном или большем уровню МКЦ контейнера,
    или не обладает привилегией parsec_cap_ignmacint.
  - Пользователь не может производить запись в контейнер (каталог)
    с установленной (ненулевой) меткой конфиденциальности и с установленным флагом ccnr
    информации, отличной от уровня конфиденциальности контейнера,
    если он не зашел под уровнем конфиденциальности равным уровню конфиденциальности контейнера (каталога),
    или не обладает привилегиями parsec_cap_ignmaccat и parsec_cap_ignmaclvl.
  - Eсли в загрузчике указать параметр ядра
  то непривилегированный пользователь получит возможность производить запись файлов с разным уровнем конфиденциальности в контейнер (каталог) с установленным флагом ccnr.
  - Сравнение уровней целостности проводится по битовой маске:
  запись в объект (или остановка процесса или юнита) разрешена,
  если набор бит уровня МКЦ субъекта
  "включает" в себя (операция сравнения &) набор бит уровня МКЦ объекта.
  - В системе определен набор из восьми ненулевых изолированных уровней МКЦ:
  000 0b00000000 - Нулевой уровень. "Низкий", или "Low"
  001 0b00000001 - Уровень задействован как "Сетевые сервисы"
  002 0b00000010 - Уровень задействован как "Виртуализация"
  004 0b00000100 - Уровень задействован как "Специальное ПО"
  008 0b00001000 - Уровень задействован как "Графический сервер"
  016 0b00010000 - Свободен, может быть использован для сетевых сервисов.
  032 0b00100000 - Свободен, может быть использован для сетевых сервисов.
  064 0b01000000 - Зарезервирован, и может быть использован при поднятии max_ilev.
  128 0b10000000 - Зарезервирован, и может быть использован при поднятии max_ilev.
  - Уровень МКЦ после установки контроля целостности на ФС по умолчанию будет равен 63 (0b00111111), и запись в объекты ФС возможна только для процессов с уровнями
  63 0b00111111
  127 0b01111111
  191 0b10111111
  255 0b11111111
  - Механизм одновременной работы с разными уровнями sumac теперь доступен только для тех пользователей,
    которым задана привилегия parsec_cap_sumac.
  - В ОС реализована возможность назначения уровня целостности и конфиденциальности для systmed-служб.
    Для этого в unit-файле службы <name>.service нужно добавить параметр PDPLabel с нужной мандатной меткой в разделе [Service] :
  Формат метки аналогичен принятому в системе Parsec (pdpl-file --help) , за исключением поля типа метки: метка процесса не может иметь флагов ccnr/ccnri/ehole/whole .
  
  При этом, при задании уровней мандатных привилегий рекомендуется использовать числовые обозначения,
  так как при разрешении имён могут оказаться задействованы сетевые ресурсы (например, LDAP-каталоги),
  что может приводить к сложно диагностируемым ошибкам конфигурации.
  
  После редактирования unit-файла вызовите:
  
  systemctl daemon-reload; systemctl restart <name>.service
  
  Для проверки реально полученной метки процесса определите pid процесса:
  
  systemctl status <name>.service
  
  и по определённому pid процесса узнайте метку
  - Добавлена Parsec-привилегия PARSEC_CAP_SUMAC , позволяющая запускать процессы другим уровнем конфиденциальности.
  Поддерживаются привилегии, добавленные в предыдущей версии ОССН Смоленск:
  Astra Linux не плохая альтернатива от отечественных разработчиков. Если вам необходимо заменить Windows, на неё стоит обязательно обратить внимание. Сам пользовался, ставил в качестве рабочих станции. В обоих случаях показала себя не плохо. Поэтому решил написать несколько статей, небольших инструкций так сказать, по работе с данной ОС. Сегодня рассмотрим политику безопасности.
  
  По умолчанию в Astra Linux полита настроена не достаточно строго. Например, пароль должен содержать не менее 8 символов, причем можно использовать только цифры. Также только после 8 неуспешных попыток ввода пароля учетная запись заблокируется. В наше время политика должна быть настроена намного строже.
  
  Системный администратор помни безопасность превыше всего!
  
  Как настроить политику учетных записей
  
  Админ ни когда не используй простые пароли тиап Qwe123, Qaz123 и тому подобные.
  
  Пароли должны обновляться хотя бы один раз в месяц.
  
  На следующей вкладке можно создать шаблоны устаревания.
  
  Вводим имя шаблона и заполняем остальные поля.
  
  Большинство системных администраторов не уделяют особое внимания политикам безопасности. Особенно это касается начинающих, которые делают всем одинаковые пароли Qwe123 без ограничения срока. Потом плачут, как так взломали пароль, зашифровали диск украли важную инфу и требуют выкуп.
  
  Всего этого можно очень легко избежать если соблюдать минимальные требования безопасности, в 2020 году это очень актуальна. Так как очень много злоумышленников появилось. Которые без особого труда подберут пароль.
  
  Системный администратор помни пароли должны быть сложными, желательно быть сгенерированными автоматически и меняться раз в месяц!
  
  Читайте также:

Изменить уровень целостности в astra linux

Astra Linux Special Edition «Орёл»

Astra Linux Special Edition «Воронеж»

Astra Linux Special Edition «Смоленск»

Похожие статьи

Astra Linux Special Edition 1.7: цены

Astra Linux Special Edition 1.7: состав

Сборка Mono для Debian и Astra Linux

Подход первый, архитектурный

Подход второй, процессный

Открытость — это важно

Как настроить политику учетных записей