Astra linux отключить мандатный контроль

Обновлено: 05.07.2024

Разработка

Выпускаемые релизы носят названия городов-героев России и стран СНГ.

Система применяется во многих государственных учреждениях. В частности, на ней построена информационная система Национального центра управления обороной РФ. В июле 2015 г. состоялись переговоры о переводе на Astra Linux госучреждений Республики Крым, в которой официальное использование популярных ОС затруднительно из-за антироссийских санкций. В ноябре 2015 года подписано соглашение о сотрудничестве с производителем серверов Huawei, который начал тестировать свои серверы на совместимость с Astra Linux.

Ос новные характеристики

Коммерческая тайна
Конфиденциальная информация
Персональные данные
Государственная тайна

Помимо базовых средств операционной системы в ее состав включены:

защищенный графический рабочий стол Fly;
защищенная реляционная СУБД PostgreSQL ;
защищенные сервера Exim и Dovecot и клиент электронной почты Thunderbird;
защищенный web-сервер Apache и браузер Firefox ;
средство организации сетевого домена и централизованного управления учетными данными пользователей Astra Linux Directory (ALD);
интегрированный пакет офисных приложений OpenOffice ,
а также большое количество других приложений.

В 2013 году приказом Министра обороны РФ ОС Astra Linux Special Edition была принята на снабжение Вооруженных Сил России.

История развития

2012г: Сертификация ОС

2014г: Мобильная версия

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

Помимо непосредственно необходимых заказчику компонентов ОС при сборке мобильной версии Astra Linux Special Edition учитывается также степень секретности обрабатываемой информации на устройстве и необходимая система сертификации СЗИ (Минобороны, ФСТЭК, ФСБ). Установка мобильной ОС и прошивка устройства ведутся в заводских условиях.

2015г: Astra Linux Common Edition

Особенности версии Special Edition

Функция идентификации и аутентификации пользователей в Astra Linux основывается на использовании механизма PAM. Кроме того, в состав операционной системы включены средства поддержки двухфакторной аутентификации.

В Astra Linux реализован механизм избирательного управления доступом, который заключается в том, что на защищаемые именованные объекты устанавливаются (автоматически при их создании) базовые правила разграничения доступа в виде идентификаторов номинальных субъектов (UID и GID), которые вправе распоряжаться доступом к данному объекту и прав доступа к объекту. Определяются три вида доступа: чтение (read, r), запись (write, w) и исполнение (execution, x).

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

Механизм мандатного разграничения доступа затрагивает следующие подсистемы:

механизмы IPC;
стек TCP/IP (IPv4);
файловые системы Ext2/Ext3/Ext4;
сетевую файловую систему CIFS;
файловые системы proc, tmpfs.
В Astra Linux Special Edition существует 256 мандатных уровней доступа (от 0 до 255) и 64 мандатных категории доступа

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

В отличие от классической модели мандатного управления доступом, в МРОСЛ ДП-модели дополнительно к мандатному управлению доступом реализован мандатный контроль целостности дистрибутива и файловой системы (препятствующий доступу к защищаемой информации скомпрометированными субъектами после перехвата управления и повышения привилегий (получения административных прав), предусмотрено ролевое управление доступом, наличие иерархии сущностей и применено противодействие запрещённым потокам по памяти и по времени[.

В настоящее время используемая в Astra Linux Special Edition модель разграничения доступа является единственной практически реализованной моделью, не основанной на SELinux, в российских реализациях операционных систем на базе Linux.

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

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

Нормативные документы по НСД выделяют семь классов защищённости, объединённых в четыре группы. Системы, отнесённые к первой группе, в которую входит всего один класс номер 7, обладают самой низкой защищённостью. В противоположность им системы группы 1, отнесённые к классу номер 1, благодаря верифицированной защите имеют наивысший уровень защищённости. Группа 2, в состав которой входят классы номер 5 и 6, определяет системы с дискреционными методами защиты, а в третьей группе объединены классы номер 2, 3 и 4 для систем с мандатными методами защиты. В рамках каждого класса чётко определено, какие функции системы разграничения доступа должна поддерживать сертифицируемая система. Именно их наличие и определяет решение экспертов об отнесении её к тому или иному классу.

Семь классов защищённости от НСД собраны в четыре группы, характеризующиеся разными методами защиты.

Операционных систем без уязвимостей не бывает — вопрос лишь в том, как эффективно разработчики их выявляют и закрывают. Наша ОС Astra Linux Special Edition здесь не исключение: мы постоянно проверяем и тестируем код на ошибки, нарушения логики, прочие баги и оперативно их устраняем. Иначе бы ФСТЭК России вряд ли сертифицировала Astra Linux на обработку данных, составляющих гостайну. Но о сертификации мы поговорим подробней в другом посте. А в этом расскажем о том, как организована работа над уязвимостями Astra Linux и взаимодействие с отечественным банком данных угроз безопасности информации.

Фото: Leonhard Foeger/Reuters

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

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

Архитектура комплекса средств защиты 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. А открытый доступ к информации об уязвимостях через БДУ ФСТЭК повышает уровень доверия к нашему продукту.

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

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

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

Мандатная модель в Astra Linux

Мандатная модель Astra Linux (далее будем использовать термин MAC, от англ. Mandatory Access Control) реализует два ключевых понятия: мандатные уровни и мандатные категории доступа. Мандатные уровни (мандатные метки) используются для пометки субъектов и объектов, чтобы обозначить тот или иной мандатный уровень доступа. Мандатные категории могут быть использованы для разграничения доступа по структурным подразделениям организации. Мандатная метка объекта в AL описывается целым числом, и всегда хранится в тесной связке с помеченным объектов.

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

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

В ОС поставляется набор приложений, в которых реализована полная поддержка мандатной модели управления доступом. Данные приложения предоставляют функциональность обработки объектов приложения (записей в БД, дочерних процессов и т.д.) с учётом правил и требований MAC. Наиболее важными из них для нас являются:

СУБД PostgreSQL. PostgreSQL имеет интеграцию с хранилищем учётных записей и мандатных меток ОС. СУБД предоставляет функциональность присваивания мандатной метки к таким объектам, как кластер, база данных, таблица, столбец и запись.
Веб-сервер Apache2. Обязателен при разработке веб-приложений. Позволяет считывать мандатную метку посредством модуля pam_auth, создавать процессы веб-приложения в режиме мандатной метки, переданной из браузера.
Браузер Mozilla Firefox. Обязателен для работы с приложением в режиме мандатной метки. Позволяет транслировать мандатную метку в веб-сервер Apache2.

Проектирование и разработка веб-приложения, поддерживающего мандатную модель управления доступом

Именно поэтому имеется первая, но крайне важная рекомендация:

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

Этим вы сохраните своему приложению возможность развиваться с любыми другими Linux и не-Linux операционными системами. Если даже речь не идёт о production-использовании данного параметра, возможность завести приложение внутри Docker-контейнера может дорогого стоить!

Поэтому при проектировании приложения под Astra Linux обязательно необходимо выделить модули, в которых требуется поддержка нескольких мандатных меток.

Для модуля возможны следующие варианты:

Модуль работает с данными только 0 мандатной метки;
модуль работает с данными только одной, не 0 мандатной метки;
модуль работает с данными нескольких мандатных меток.

Простой случай: модуль работает с данными только 0 мандатной метки

Этот кейс является наиболее простым случаем. Проектирование модуля в режиме работы с данными 0 метки целесообразно в следующих случаях:

В системе Jet Signal примером такого модуля является модуль «Безопасность», реализующий управление учётными записями пользователей, ролями и операциями:

Данный модуль реализует функциональность создания учётных записей пользователей в ОС, СУБД, управление правами доступа к объекту БД и каталогам. Данные, обрабатываемые данным модулем, должны быть видны под любой мандатной меткой. Именно поэтому данный модуль позволяет изменять данные только в режиме 0 мандатной метки.

Случай средней сложности: модуль работает с данными только одной, не 0 мандатной меткой

Этот кейс чуть сложнее, но во многом похож на случай с 0 мандатной меткой.

Данный кейс может быть полезен в следующих случаях:

Была допущена ошибка при аналитике и проектировании модуля (не были заложены особенности обработки записей в MAC) и нет ни времени, ни ресурсов всё переписывать;
в соответствии с бизнес-требованиями модуль должен обрабатывать именно указанную мандатную метку.

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

На что следует обратить внимание при реализации подобного кейса:

Нельзя менять мандатную метку по умолчанию (MAC_DEFAULT_LEVEL) в процессе эксплуатации приложения. Это гарантированно приведёт к неожиданным и сложным в диагностике проблемам, а бизнес-логика приложения может попросту развалиться.
По возможности следует добавить проверку мандатной метки какой-нибудь эталонной записи, создаваемой при инсталляции приложения, и данного параметра. В случае некорректной установки параметра приложению следует бить в колокола и звать на помощь системного администратора!

Сложный случай: модуль работает с данными нескольких мандатных меток

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

Функция получение мандатной метки текущего процесса приложения;
функция получения мандатной метки записи (если речь идёт о работе с записью в БД) или файла (если мы обрабатываем файлы в каталоге);
функция получения мандатной метки записей/файлов в коллекции.

Получение мандатной метки текущего процесса приложения

Для получения мандатной метки текущего процесса приложения мы используем команду:

Получение мандатной метки записи в базе данных

Для получения мандатной метки записи в базе данных потребовалось доработать механизм чтения схемы БД. Мандатная метка записи в БД хранится в поле maclabel.

При выполнении SQL-запроса SELECT * FROM public.incident; СУБД вернёт все имеющиеся столбцы, но не вернёт столбец, содержащий мандатную метку записи. Делать это необходимо принудительно:

SELECT *,maclabel FROM public.incident;

В результате получим выборку, содержащую maclabel (пропущены остальные столбцы):

Доработка запроса получения схемы фреймворком для ORM

Большинство фреймворков, предоставляющих функциональность ORM, требуют доработки функции чтения схемы БД и конструктора запросов, чтобы «научиться» читать и писать корректным образом столбец maclabel . Например, в Yii2 была произведена доработка запроса получения схемы (компонент yii\db\Schema ) следующим образом:

В запрос было добавлено считывание параметра a.attname = 'maclabel'.

Бизнес-процессы при использовании нескольких мандатных меток

Указанные выше функции очень понадобятся нам при реализации обязательных для обработки множества мандатных меток бизнес-процессов:

Разрешение/запрещение редактирования записи/файла с мандатной меткой, отличной от мандатной метки текущего процесса;
получение коллекции записей/файлов с определённой мандатной меткой (фильтрация обрабатываемых данных на основе мандатной метки).

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

Например, в системе Jet Signal реализована обработка записей с учётом мандатной метки: пользователь не может отредактировать запись, если метка текущего сеанса пользователя не соответствует мандатной метке приложения.

В системе Jet Signal реализована поддержка нескольких мандатных меток в модуле управления инцидентами информационной безопасности. Мандатная метка каждой записи выводится справа в пользовательском интерфейсе:

Управление структурой базы данных

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

Мы реализовали компонент, который производит установку мандатных меток командами MAC LABEL и MAC CCR на следующие объекты:

База данных (database);
схема (schema);
последовательность (sequence);
таблица (table).

Аутентификация пользователя и использование учётных данных

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

На схеме изображено следующее взаимодействие:

Аутентификация пользователя в веб-приложении

В данном примере реализуется следующий алгоритм:

Особенности метода аутентификации

Минусы данного метода аутентификации:

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

Работа веб-приложения с файлами и каталогами

При выполнении своих задач веб-приложение часто формирует следующие файлы:

Логи приложения;
кеш;
статика CSS+JS (в случае сборки «на лету»).

В Astra Linux используется целый «бутерброд» из средств управления доступом к файлам и каталогам:

Стандартные средства разграничения прав доступа к фалам и каталогам ( chmod/chown );
механизм ACL ( getfacl/setfacl );
мандатная модель ( pdpl-file ).

Поддержка трёх средств управления доступом к файлам в веб-приложении

Большинство фреймворков и библиотек не понимают таких сложностей, и поэтому может потребоваться «научить» фреймворк правильно понимать следующие вещи:

Имеется ли права на запись в каталог/файл?
Существует ли каталог или файл в ФС?

Всем учётным записям пользователей приложения после создания необходимо выставлять группу www-data: adduser admin www-data

Хранение файлов с различными мандатными метками

Если нам необходимо хранить файлы с различными мандатными метками, следует делать это по отдельности, в разных каталогах!

Например, журналы, кеш и прочие файлы пишутся у нас в каталог /var/www/webapp/runtime/. В таком случае создаём на каждую метку свой подкаталог:

Использование указанных рецептов по работе с файлами позволит избежать множества проблем и трат времени.

Резюме

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

Главный вывод: инфраструктура оказывает сильное влияние на бизнес-процессы приложения при использовании мандатной модели управления доступом. Имеется целый ряд функциональных ограничений, допустимых в классическом бизнес-прилжении, и невозможных при использовании мандатной модели. Всем участникам процесса проектирования и подготовки требований к системе необходимо детально ознакомиться со всеми нюансами применения мандатной модели управления доступом.

Дмитрий Грудинин, руководитель группы PHP-разработки. Центр внедрения бизнес-систем «Инфосистемы Джет»

Разграничение прав доступа — важнейший элемент обеспечения безопасности информационной системы, однако сама по себе безопасность не самоцель, хотя об этом не всегда помнят. Если на одном компьютере разместить исключительно секретные материалы и физически отрезать его от сети, то проблемы с безопасностью будут решены. В ряде случаев так и поступают, однако выделять по компьютеру на каждую категорию секретности неразумно — иногда требуется, не покидая защищенную систему, иметь доступ ко всей информации, в том числе и несекретной. Каким образом, запуская в защищенной среде таких разных ОС, как Astra Linux Special Edition и SELinux/SEPGSQL, приложение, использующее СУБД PostgreSQL, обеспечить разграничение прав доступа и предоставить пользователю ровно тот уровень секретности, который ему положен? При этом очевидно, что ставить мандатную СУБД поверх немандатной ОС бессмысленно.

Всегда можно представить ситуацию, когда в большой базе данных лишь часть информации секретна и важно обеспечить гранулированность доступности. Например, сотрудники районных отделений полиции получают доступ к данным только о жителях своего района, а на уровне города должна быть доступна информация о любом жителе мегаполиса. Такое разграничение доступа реализуется на уровне записей, или строк таблицы (Row Level Security, RLS), однако оно поддерживается не всеми СУБД.

В современных безопасных системах может быть реализована комбинация дискреционного (избирательного) разграничения доступа (Discretionary Access Control, DAC), ролевого разграничения доступа (Role Based Access Control, RBAC) и мандатного (принудительного, обычно многоуровневого) разграничения доступа (Mandatory Access Control, MAC). Как правило, они реализуются именно в таком порядке: следующий «поверх» предыдущего. То есть ресурс, доступный по правилам мандатного доступа, заведомо доступен по правилам дискреционного доступа, но не наоборот.

Мандатное управление доступом обсуждается редко, мало того, его иногда трактуют искаженно, опираясь на опыт работы с бумажными документами, для которых установлены различные уровни секретности. Перенос представлений о работе с бумажными документами на работу с электронными, на уровни доступа ОС и тем более на СУБД, иногда дезориентирует — сходство обманчиво. Для многоуровневой политики имеется простой принцип «читай вниз, пиши вверх», который не похож на то, что подразумевается в реальном мире. Принцип «Write up, read down. No read up, no write down» (субъект, обладающий определенным уровнем доступа, не может читать информацию, относящуюся к более высокому уровню, но может читать менее секретные документы; субъект, обладающий определенным уровнем доступа, не сможет создавать объекты с более низким уровнем допуска, чем имеет сам, но при этом может писать в более высокоуровневые объекты), входящий в модель Белла — Лападулы, прописан и в отечественных документах, регламентирующих требования к безопасности информационных систем. Первая половина этого принципа очевидна, а про вторую этого сказать нельзя: невозможно представить себе ситуацию из «бумажного» мира, когда сотрудник получает доступ на запись в документ высокой секретности, не имея при этом права (и возможности) его читать. Однако именно так исключается попадание данных, доступных высокоуровневым объектам, в низкоуровневые объекты.

Мандатное разграничение доступа еще называют принудительным контролем доступа: пользователь не может управлять доступом к информации, а сами правила доступа жестко определены политикой безопасности. Наличие разграничения доступа MAC, DAC и RBAC — обязательное требование при защите информации категории «гостайна», однако для разных ОС и СУБД оно может трактоваться по-разному. Например, в мандатном управлении доступа для операционной системы Astra Linux пользователь сам может выбирать уровень секретности из тех, что разрешены ему системным администратором, и этот уровень будет сохраняться на протяжении сессии. Теоретически мандатная система доступа не обязательно должна иметь различные уровни конфиденциальности (секретности или доступа), однако в реальной жизни редко находятся причины использовать немногоуровневую политику: именно она обязательна для систем с обеспечением гостайны.

Имеется некоторый набор средств для реализации мандатных ОС, но для российской действительности актуальны две — SELinux [1] и Astra Linux Special Edition [2].

SELinux (Security-Enhanced Linux) представляет собой обычный дистрибутив Linux, скомпилированный с набором модулей (LSM, Linux Security Modules), перехватывающих системные вызовы.

Модули представляют собой «крюки» («хуки»), к которым можно «подвесить» свои обработчики. Код SELinux открыт, и мандатный доступ строится поверх обычной системы доступа Linux — то есть файл, недоступный в Linux, будет недоступен и в SELinux, но не наоборот. При определении доступности файла система сравнивает метки субъекта и объекта, а затем принимает решение о допустимости операции. Метка представляет собой набор полей, содержимое которых может по-разному задаваться в различных политиках безопасности. Для создателей и пользователей мандатных систем наиболее интересна многоуровневая политика защиты (Multi Level Security, MLS), основанная на иерархии уровней секретности (чувствительности) и набора категорий. Пользователь SELinux — это сущность, определенная в политике, отвечающая за конкретный набор ролей и других атрибутов контекста безопасности. Пользователи SELinux отличаются от пользователей Linux, поэтому необходимо сопоставление (mapping) между ними через политику SELinux, позволяющее пользователям Linux наследовать ограничения пользователей SELinux.

Версия Astra Linux Special Edition разработана компанией «РусБИТех» на основе подсистемы PARSEC, целиком реализованной в виде модулей LSM, причем разработчики не декларируют следование модели Белла — Лападулы, а предлагают собственную патентованную «мандатную сущностно-ролевую ДП-модель» (модель логического управления доступом «Д» и информационными потоками «П»). Объекты располагаются в монотонной по доступу иерархии контейнеров (каталог — это контейнер для файлов, таблица базы данных — контейнер для записей). Уровень конфиденциальности контейнера не уступает уровню содержащихся в нем объектов. По умолчанию запись «вверх» в модели безопасности Astra Linux невозможна — можно писать только на свой уровень. Однако, поскольку работать с такой жесткой системой запретов трудно, а в некоторых ситуациях просто невозможно, вводятся средства игнорирования мандатных меток контейнера или объекта. Атрибут «ehole» мандатной метки позволяет игнорировать любые мандатные правила, а бит CCR делает «прозрачными» контейнеры, непрозрачные для нижележащих уровней секретности.

MAC В POSTGRESQL ДЛЯ SELINUX

В среде SELinux для поддержки разграничения доступа MAC для СУБД PostgreSQL имеется расширение sepgsql, которому необходима поддержка в ядре операционной системы, поэтому он может работать только в Linux 2.6.28 и выше. Это расширение работает на базе мандатной системы SELinux, используемой в Red Hat, CentOS, Fedora и др., а также в их российских собратьях: ОС «Синергия-ОС» (РФЯЦ-ВНИИЭФ), ОС «Заря» и ряде других.

При принятии решения о предоставлении доступа к объекту базы данных, sepqsql сверяется с политиками безопасности SELinux, поскольку внутри sepgsql нет самостоятельного механизма назначения, хранения и модификации меток пользователей. Расширение обеспечивает присвоение меток безопасности пользователям и объектам базы данных через внешних «провайдеров», одним из которых является SELinux. Можно назначать метки безопасности схемам, таблицам, столбцам, последовательностям, представлениям и функциям. Когда расширение sepgsql активно, метки безопасности автоматически назначаются поддерживаемым объектам базы в момент их создания в соответствии с политикой безопасности, которая учитывает метку создателя, метку, назначенную родительскому объекту создаваемого объекта, и, в некоторых случаях, имя создаваемого объекта. Для схем родительским объектом является текущая база данных; для таблиц, последовательностей, представлений и функций — схема, содержащая эти объекты; для столбцов — таблица.

Существующая реализация sepgsql имеет ряд особенностей и ограничений, которые необходимо принимать во внимание, но самое важное — это неспособность ограничения доступа на уровне строк. В версиях PostgreSQL 9.5 и 9.6 и во всех версиях Postgres Pro такая возможность предусмотрена.

MAC В POSTGRESQL ДЛЯ ASTRA LINUX

Защищенные версии СУБД PostgreSQL, поставляемые компанией «РусБИТех» вместе с Astra Linux Special Edition v.1.5, собраны со специальными патчами, позволяющими взаимодействовать с мандатной системой PARSEC. Они базируются на стандартных версиях PostgreSQL 9.2 либо PostgreSQL 9.4 и отличаются реализацией мандатного разграничения (в 9.4 более полный функционал и реализована ДП-модель управления доступом и информационными потоками, соответствующая модели безопасности в ОС Astra Linux). СУБД PostgreSQL использует механизмы ОС для того, чтобы пользователь получил те же поля метки мандатного доступа, что и пользователь ОС, вошедший с соответствующими мандатными атрибутами. В сессии возможен только один уровень конфиденциальности, а не диапазон, как в SELinux и sepgsql.

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

«СИНЕРГИЯ-БД»

В реальности встречаются ситуации, когда sepgsql недостаточно, — например, когда требуется защита на уровне строк. В поставку ОС Astra Linux входит защищенная СУБД, привязанная к мандатной системе безопасности ОС Astra Linux. При этом многие потребители нуждаются в защищенной, но платформенно-независимой СУБД. Кроме того, такую комбинацию СУБД и ОС проще сертифицировать: получить сертификат на комбинацию защищенной сертифицированной ОС и защищенной сертифицированной СУБД легче, чем на комплекс, в котором СУБД и ОС тесно взаимосвязаны. В последнем случае при изменении ОС (даже при переходе на другую версию той же ОС) придется заново начинать процесс инспекционного контроля сертифицированного продукта или процедуру сертификации.

Однако абсолютно кросс-платформенное решение невозможно — ОС, созданные даже на основе одного и того же ядра Linux, могут сильно отличаться [3]. Технически задача упростится, если исключить из набора платформ специфические ОС и взять за основу стандартные средства SELinux. Но тогда пришлось бы отказаться от поддержки платформы Astra Linux, популярной на ряде отечественных предприятий.

Возможно компромиссное решение — создать ПО связующего слоя, которое предоставит все необходимые для работы защищенной СУБД мандатные атрибуты, не требуя изменения кода ядра СУБД и исходного кода расширений ОС. Однако разработчикам придется потрудиться и над тем, чтобы универсальность не достигалась в ущерб производительности СУБД.

Мандатная СУБД «Синергия-БД», включающая в себя такое ПО промежуточного слоя, обеспечивает достаточную функциональность и приемлемую производительность (потери на уровне 15%). Эта СУБД разработана РФЯЦ-ВНИИЭФ и компанией Postgres Professional и представляет собой кросс-платформенную среду, работающую на отечественных системах «Синергия-ОС» и Astra Linux Special Edition.

Поскольку Astra Linux и «Синергия-ОС» по-разному решают проблемы доступа, то унификацию берет на себя ПО связующего слоя. Например, в Astra Linux пользователь регистрируется в системе с одним на сессию уровнем конфиденциальности, а «Синергия-ОС» предоставляет своим пользователям диапазон уровней — в этом случае «Синергия-БД» выбирает минимальный уровень из возможных. При этом, чтобы избежать деградации производительности СУБД, атрибуты безопасности пользователя кэшируются на время сессии. Пользоваться базой могут не только сотрудники с определенным уровнем доступа, заданным параметрами пользователя в ОС, но и те, кто входит в систему без метки доступа.

За основу «Синергии-БД» была взята версия СУБД PostgreSQL 9.5.5, в которой имеются штатные методы аутентификации, настраиваемые через pg_hba.conf. На рис. 1 показан порядок взаимодействия удаленных пользователей с подсистемами безопасности двух разных ОС и «Синергии-БД». Рис. 1. Политики ОС управляют правами доступа удаленного клиента

Пользователь авторизуется через механизмы СУБД, например PAM (Pluggable Authentication Modules — «подключаемые модули аутентификации») или GSS (Generic Security Services — «общий программный интерфейс сервисов безопасности», например Kerberos), после чего запускается проверка механизма мандатного доступа. Например, если таблица-контейнер «прозрачна», то для любого пользователя она открыта для чтения и записи, но увидит он в ней только те строки, уровень конфиденциальности которых равен его собственному или меньше. Это и есть разделение доступа на уровне строк, отвечающее модели Белла — Лападулы.

На рис. 2 приведена иерархия объектов «Синергии-БД» — если наследуется таблица, то она считается логически входящей в контейнер родительской таблицы. Видно, что доступ к средствам процедурных языков базы данных (и тем более к функциям) определяется на уровне базы данных, а не на глобальном уровне. Рис. 2. Объекты-контейнеры и содержимое контейнеров в «Синергии-БД»

Модульная структура провайдеров безопасности дает возможность подключать новые модули и интегрировать СУБД в состав других защищенных ОС, имеющих мандатное разграничение доступа, что существенно упрощает и ускоряет процесс сертификации. ***

Очевидно, что по разным причинам безопасные мандатные системы будут достаточно активно развиваться, а значит, будут развиваться подходы к обеспечению совместимости и кросс-платформенности ОС и СУБД. Кроме того, дополнительные исследования потребуются в области организации работы сетей в мандатной среде, обеспечения репликации, а также создания удобных интерфейсов взаимодействия с различными ОС и СУБД.

Читайте также: