Astra Linux SE у заказчика с гостайной: PAM, SELinux-профили и SSSD на практике

Astra Linux Special Edition включена в реестр отечественного ПО и официально рекомендована для объектов, работающих с государственной тайной. Для нас это не просто новость из реестра - у нас уже идёт пилот у заказчика с соответствующими требованиями. Самое время написать, как это выглядит изнутри.

Заказчик - организация с требованиями по защите сведений, составляющих государственную тайну. ФСБ и ФСТЭК в анамнезе, мандатное управление доступом - не пожелание, а требование. Для таких клиентов аудит текущего состояния всегда предшествует выбору платформы, и мы его провели ещё в феврале. Вывод был прямолинейным: Astra Linux SE - единственный вариант, который закрывает регуляторные требования без больших вопросов к документам.

Установка: не Ubuntu и не CentOS

Astra Linux Special Edition - это Debian-based дистрибутив, но кто думает, что опыт с Debian тут переносится один к одному, быстро обнаруживает подводные камни. Первый сюрприз - инсталлятор. Он работает, он понятен, но ряд шагов требует принятия решений, которые потом дорого переделывать: разбивка диска с учётом требований мандатной метки, выбор уровня конфиденциальности, включение модуля безопасности Parsec.

Parsec - это собственный LSM (Linux Security Module) разработки RusBITech, обеспечивающий мандатное управление доступом. По механике похож на SELinux в mandatory access control части, но реализован иначе. Ядро Astra Linux SE собрано с поддержкой Parsec, и после установки он активен по умолчанию. Привычка по-быстрому сделать chmod 777 или проигнорировать метки - здесь не работает.

Установка на чистое железо прошла без проблем. Установка в виртуальную машину на VMware vSphere 6.0 - тоже, но с нюансом: нужно убедиться, что PVSCSI-адаптер распознаётся инсталлятором, иначе диски не видны. В нашем случае переключили на LSI Logic SAS, и дальше всё пошло штатно.

PAM: знакомый инструмент, незнакомые правила

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

Что мы поправили под требования конкретного заказчика:

• pam_faillock.so (или аналог pam_tally2.so в данной версии). Количество допустимых неудачных попыток и время блокировки - параметры конкретного регламента, не дефолты. Важно: конфигурация для auth и account должна быть согласованной, иначе блокировка включается, а разблокировка работает не так, как ожидается.
• pam_pwquality.so. Минимальная длина пароля в регламенте заказчика - 12 символов, в дефолтах дистрибутива - 8. Параметр minlen в /etc/security/pwquality.conf правится просто, но нужно проверить, что изменение применяется именно к тем сервисам, к которым нужно: ssh, sudo, локальный вход.
• Срок действия паролей. chage работает стандартно, но нужно убедиться, что новые учётные записи создаются с правильными параметрами aging. Если есть скрипты создания пользователей с унаследованной логикой - проверить их все.

Самый неприятный сюрприз с PAM: Parsec добавляет свои хуки в стек аутентификации. Если не разобраться с порядком модулей в /etc/pam.d/common-auth, можно получить ситуацию, когда аутентификация проходит, но уровень конфиденциальности сессии выставляется не тот. Мы потратили полдня, прежде чем поняли, что логин работает, а метка сессии - нет.

SELinux-профили: здесь всё сложнее

Astra Linux SE поставляется с политикой Parsec, а не классическим SELinux в том виде, к которому привыкли на RHEL/CentOS. Если у вас есть свои SELinux-профили под CentOS - они сюда не переносятся. Это отдельная работа.

Для стандартных серверных ролей (nginx, sshd, chronyd) политики Parsec из коробки достаточно разумные - конфликтов не было. Проблемы начались с прикладным ПО заказчика. Одна из систем - Java-приложение на Tomcat - при старте пыталась создать файлы в нестандартных путях. В CentOS мы бы написали .te-файл и скомпилировали модуль. В Astra Linux SE - аналогичный подход через инструменты Parsec, но документация на это значительно скуднее, чем у SELinux.

Решение нашли через анализ журнала Parsec (/var/log/parsec/audit.log) - он достаточно подробный, если уметь читать. Потребовалось скорректировать метки файлов в нестандартных путях через pdpl-file и добавить правило через mpdp. Заняло больше времени, чем аналогичная задача на CentOS, но решилось.

Интеграция с Active Directory через SSSD

Заказчик сохраняет Active Directory как основной каталог пользователей - мигрировать весь парк Windows на отечественное мгновенно никто не собирается. Значит, нужна аутентификация Linux-хостов через AD.

SSSD в Astra Linux SE есть, устанавливается из штатного репозитория. Конфигурация /etc/sssd/sssd.conf стандартная для realm-based join:

[sssd]
domains = corp.example.local
services = nss, pam

[domain/corp.example.local]
ad_domain = corp.example.local
krb5_realm = CORP.EXAMPLE.LOCAL
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
auth_provider = ad
access_provider = ad

realm join отработал штатно, кербер-тикет получается, пользователи из AD разрешаются через id. Но дальше начинается специфика Astra Linux SE: при входе пользователя из AD через ssh нужно убедиться, что Parsec присваивает сессии корректный уровень конфиденциальности. По умолчанию AD-пользователь получает нулевой уровень (несекретно), что для данной системы правильно - работа с секретными данными предполагает локальные учётные записи с явно выставленными метками.

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

Прикладное ПО: честная картина

Из стандартного серверного стека без проблем завелись: nginx, PostgreSQL 9.4 (из репозитория Postgres), OpenSSH, chrony, rsyslog. Java 8 - с небольшой правкой путей под Parsec, описанной выше.

Проблемы начались с несколькими вещами. Специализированная система мониторинга заказчика, написанная под CentOS 6, - не взлетела сразу: бинарный агент собран под glibc другой версии. Решение - перекомпилировать под Astra Linux SE или попросить вендора агента предоставить совместимую сборку. Вендор в процессе.

Одна из Java-систем использовала OpenJDK 7 с патчами вендора - аналог из репозитория Astra Linux SE не подходил, пришлось разбираться отдельно.

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

Где мы сейчас

Пилот идёт. Часть рабочих нагрузок уже на Astra Linux SE, часть в процессе переноса. Регуляторное основание теперь есть - включение в реестр и рекомендация для объектов с гостайной убирают последние вопросы у заказчика про «а можно ли вообще». Технически работает, но требует экспертизы именно в этой системе: знания Debian и CentOS помогают, но не заменяют понимания Parsec и специфики дистрибутива.

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