Astra Linux SE 2.14 на АРМах с YADRO: ядро 6.6 и сюрпризы мандатных меток

Astra Linux Special Edition 2.14 вышел в начале января. Главное в changelog для нас - два пункта: ядро 6.6 LTS вместо 5.15 и обновлённая подсистема мандатного управления. На бумаге звучит как рутинный апгрейд. На практике - несколько рабочих часов с NVMe-дисками и неожиданный разговор с настройками меток.

Зачем вообще обновлялись

У нескольких клиентов на сопровождении есть АРМ на отечественном железе YADRO - рабочие станции с NVMe-накопителями под новые контроллеры. На Astra Linux SE 1.8 с ядром 5.15 с этими машинами была систематическая история: система загружалась, диск определялся, но при интенсивной нагрузке - параллельная запись нескольких потоков, индексация, резервное копирование - контроллер периодически уходил в сброс. Не насмерть, не потеря данных, но dmesg засыпало сообщениями о таймаутах NVMe-команд, и IO на несколько секунд зависал.

Лечилось это обходным путём: ограничение глубины очереди через nvme_core.io_timeout и nvme_core.io_queue_depth. Работало, но некрасиво - и каждый раз нужно было проверять, что параметры выжили после обновления ядра. В 6.6 LTS этот контроллер поддерживается нормально на уровне драйвера, и никаких костылей не требуется. Это и был основной мотив.

Как прошло обновление ядра

Честно - без drama. Поставили 2.14 на тестовую машину с идентичным железом, загрузились, проверили dmesg - чисто. Прогнали нагрузку, которая раньше стабильно воспроизводила сброс контроллера: fio с параллельными потоками, потом rsync большого каталога. Всё прошло без таймаутов, IO-латентность ровная.

Параметры из старых /etc/modprobe.d/ убрали, перезагрузились - поведение то же. Хорошо.

На продакшн-машины обновление начали катить через неделю, по одной станции. Механика обновления у Astra стандартная, ничего необычного - apt update && apt full-upgrade, перезагрузка, проверка.

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

А вот с мандатной подсистемой вышло интереснее. В 2.14 обновилась версия Parsec - механизма мандатного управления доступом в Astra Linux. Изменения в основном касаются API управления метками и поведения при наследовании меток процессами.

На тестовой машине обнаружили: несколько корпоративных приложений, запускавшихся ранее в определённом мандатном контексте, после обновления стали вести себя иначе. Конкретно - приложение, которое запускается как системный сервис (через systemd), раньше наследовало метку от родительского процесса определённым образом. После 2.14 логика наследования изменилась, и сервис поднимался с другим уровнем, чем ожидалось.

Симптом: сервис запускается, но не может получить доступ к файлам конфигурации, лежащим в каталоге с меткой выше стандартного уровня. В журнале - avc: denied от parsec, и дальше разбирайся.

Что сделали:

Первое - сопоставили старое и новое поведение. Запустили на тестовой машине с 1.8 рядом, сравнили вывод pdp-ls для тех же файлов и pdp-ps для процессов. Увидели, что конкретный механизм наследования при Type=notify в systemd-юните изменился.

Второе - явно прописали мандатный контекст в юните. Вместо того чтобы полагаться на наследование, добавили явное указание через ParsecLabel в секции [Service]. Это, кстати, правильнее: явное лучше неявного, и при следующем обновлении такой конфигурации проще анализировать.

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

Документация RusBITech по изменениям в Parsec для 2.14 есть, но написана достаточно лаконично - описывает сами изменения в API, а не сценарии миграции. Нам пришлось сначала поймать симптом на тестовой машине, потом читать документацию с пониманием того, что именно искать. В другую сторону - сначала читать документацию, потом искать проблему - было бы сложнее.

Что учли для следующих обновлений

По итогам добавили в свой чеклист обновления Astra Linux пункт: перед обновлением мажорной версии явно документировать все кастомные systemd-юниты с нестандартными мандатными контекстами и проверять их на тестовой машине. Не потому что обновление сломало что-то существенное - сломало не оно, а неявная зависимость от поведения, которое нигде не было зафиксировано явно.

На сопровождении это теперь часть стандартного процесса перед обновлением ОС на АРМах.

Где сейчас

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

Контекст с новыми требованиями ФСТЭК к КИИ, которые появились в начале января, добавляет обновлению Astra до свежей версии актуальности - подробнее про изменения регуляторики писали в январском посте. Актуальное ядро и актуальная версия сертифицированной ОС - это теперь не просто удобство.