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/ убрали, перезагрузились - поведение то же. Хорошо.

На production-машины обновление начали катить через неделю, по одной станции. Механика обновления у 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-юниты с нестандартными мандатными контекстами и проверять их на тестовой машине. Не потому что обновление сломало что-то существенное - сломало не оно, а неявная зависимость от поведения, которое нигде не было зафиксировано явно.

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

Где сейчас

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

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