Astra Linux SE 1.8: что изменилось в ядре, загрузчике и мандатном доступе
Разбираем релиз Astra Linux SE 1.8 - новое ядро, изменения в PARSEC и поддержка отечественного железа. Что из этого реально закрывает старые боли.
Релиз Astra Linux SE 1.8 - новая версия сертифицированной ОС с обновлённым ядром и расширенной поддержкой оборудования
Astra Linux Special Edition 1.8 вышла в конце декабря, и мы дождались первых недель января, чтобы пощупать её на реальном железе, а не только пробежаться по release notes. У нас как раз несколько объектов на managed-сопровождении, где план перехода с 1.7.x уже был согласован - так что тестовый запуск превратился в почти боевой.
Ядро и поддержка железа
Главное изменение в 1.8 - переход на ядро 6.1 LTS. В 1.7.x использовалось 5.15, и разрыв между ними ощутим именно в части поддержки оборудования. С ядром 5.15 несколько типов отечественных серверных платформ ставили команду в неловкое положение: либо патчить ядро вендорскими модулями, либо объяснять заказчику, почему сертифицированная ОС не видит его контроллер.
С 6.1 картина заметно лучше для нескольких классов устройств.
Серверы на ARM-архитектуре (это касается Байкал-М и S в первую очередь) - поддержка в upstream-ядре значительно улучшилась за год между 5.15 и 6.1, и это напрямую переносится в Astra. На одном из стендов нам удалось поднять 1.8 на Байкал-S без каких-либо дополнительных патчей - в 1.7.3 для того же оборудования требовался вендорский BSP.
Контроллеры RAID и NVMe - ещё одна точка боли в 1.7.x. Часть отечественных и ввезённых через параллельный импорт серверных платформ поставлялась с контроллерами, которые 5.15 поддерживал со скрипом. В 6.1 это по большей части решено на уровне upstream.
Встроенные сетевые карты на ряде серверов РУСТЭК и аналогичных отечественных решений теперь определяются без плясок с модулями. Не все - но доля случаев, когда надо было что-то доустанавливать руками, явно меньше.
Загрузчик: наконец UEFI Secure Boot
В 1.7.x Secure Boot с российскими MOK-сертификатами работал, но требовал ручной возни. В 1.8 появилась нормальная интеграция shim-загрузчика с поддержкой пользовательских ключей, что упрощает развёртывание на платформах, где политика безопасности требует верификации загрузки.
Это важно не само по себе, а в связке с требованиями ФСТЭК: для ряда категорий КИИ контроль целостности загрузки - обязательная мера, и раньше её приходилось закрывать либо аппаратными средствами, либо нестандартными конфигурациями. Теперь решение из коробки, и его проще показать на проверке.
Один нюанс: если на объекте уже настроен кастомный шим из 1.7.x - при обновлении его надо перевыпускать. Просто обновить пакеты мало.
PARSEC: что поправили в мандатном управлении
PARSEC - традиционно самое болезненное место при внедрении Astra на объектах КИИ. В прошлый раз, когда разворачивали 1.7.3, потратили изрядное время на то, чтобы сервисы в systemd корректно наследовали мандатные метки, а PostgreSQL не падал при переустановке.
В 1.8 заявлены исправления в нескольких направлениях:
Наследование меток при fork/exec - это хроническая проблема, когда дочерний процесс получал не ту метку, что ожидалась. Судя по тому, что мы видим в первых тестах, ситуация улучшилась: запуск сервисов через systemd с явно прописанным pdpl-service ведёт себя предсказуемее. Но «предсказуемее» - не «идеально», и сложные цепочки вызовов всё ещё требуют проверки.
Сетевые метки и маршрутизация - в 1.7.x при включённой маркировке трафика PARSEC иногда роняло соединения между хостами на одном уровне из-за рассинхронизации меток на сетевом интерфейсе и в заголовках пакетов. В 1.8 это, судя по release notes и первым тестам, закрыто - по крайней мере для стандартных топологий с одним контроллером домена.
fly-admin-smc получил обновлённый интерфейс настройки правил для мандатного брандмауэра. Функционально - то же самое, но редактировать политики стало немного менее мучительно. Это звучит несерьёзно, но когда ты объясняешь администратору заказчика, как настраивать мандатный firewall, UX инструмента имеет значение.
Что не изменилось и где всё ещё больно
Честный разговор требует сказать и о том, что 1.8 не починила.
Репозитории по-прежнему обновляются медленнее, чем хотелось бы. Часть CVE, которые в Debian 12 закрыты несколько месяцев назад, в Astra 1.8 ещё в процессе - это особенность цикла сертификации, и с ней ничего не сделать, но об этом надо помнить при построении модели угроз.
Документация осталась на привычном уровне «найди то, чего нет». Официальные release notes есть, а вот внятное руководство по миграции с 1.7.x - это то, что команде придётся составлять самостоятельно в процессе.
Совместимость прикладного ПО - отдельная история. Всё, что собрано под Debian 11, в целом работает, но есть специфика по пакетам, завязанным на glibc конкретных версий. Прежде чем катить 1.8 на prod - стоит прогнать приложение на тестовом стенде.
Где мы сейчас
На двух тестовых стендах 1.8 поднята, первичная совместимость с корпоративными сервисами (PostgreSQL, Samba-домен, 1С в веб-режиме) проверена. Пока блокеров для перехода нет, но до полноценного перевода объектов КИИ - ещё несколько итераций с проверкой мандатных политик и обновление runbook-ов.
Обновление до 1.8 имеет смысл планировать - особенно для тех, кто сидит на железе с поддержкой через вендорские патчи. Сертификат ФСТЭК на новую версию ожидается в первом квартале, и торопиться до его появления на prod-объектах КИИ не стоит. Но готовиться - стоит уже сейчас.