ЗПС в Astra Linux — проверить и включить без потери доступа

Главная / Блог / ЗПС в Astra Linux — проверить и включить без потери доступа

После astra-digsig-control enable собственный агент или PAM-модуль может перестать запускаться, хотя права и владелец файла не менялись. Это ожидаемое поведение ЗПС, если файл не подписан подходящим ключом или система не настроена проверять выбранный тип подписи.

Что такое ЗПС

ЗПС — замкнутая программная среда: в режиме блокировки устройство исполняет только программное обеспечение, подпись которого проходит проверку. Проверку выполняет модуль ядра digsig_verif при запуске программы и загрузке библиотеки.

В Astra Linux 1.8 поддерживаются несколько типов подписей: встроенные в ELF, сохранённые в расширенных атрибутах файловой системы и отсоединённые. Какой тип проверяет ядро, зависит от настроек DIGSIG_ELF_MODE, DIGSIG_ELF_VERIFICATION_MODE и DIGSIG_XATTR_MODE.

Встроенная подпись живёт внутри ELF-файла, в отдельной секции. Её видно обычным readelf:

$ readelf -S /usr/bin/fly-dm | grep -i sig
  [28] signature         LOUSER+0x736967  ...

Отсутствие секции signature ещё не означает, что файл не подписан: в Astra Linux 1.8 подпись может храниться в xattr или отдельно от файла.

Пакеты из репозиториев Astra подписаны изготовителем ОС. В каталоге /etc/digsig/ находятся настройки и данные разных контуров проверки:

предустановленные ключи изготовителя и партнёров (*_rbt_root_key_*.gpg, primary_key_*.gpg);
keys/ — дополнительные ключи, подписанные изготовителем или уже доверенным ключом из цепочки;
xattr_keys/ — самостоятельно созданные ключи для проверки подписей в расширенных атрибутах;
external_sig/ — отсоединённые подписи;
revoked_keys — файл со списком отозванных ключей;
digsig_initramfs.conf — конфигурация, загружаемая на раннем этапе старта системы.

Произвольный открытый ключ организации нельзя просто положить в /etc/digsig/keys/: ядро загрузит его только при корректной цепочке доверия. Для самостоятельно созданного ключа нужно выбрать поддерживаемую схему с xattr- или отсоединёнными подписями и настроить соответствующий режим проверки.

astra-digsig-control: status, enable, disable

Управляется ЗПС одной утилитой:

$ sudo astra-digsig-control status
НЕАКТИВНО

status — человекочитаемое состояние: АКТИВНО / НЕАКТИВНО;
is-enabled — то же для скриптов (код возврата);
enable / disable — включение и выключение; изменение вступает в силу после перезагрузки.

Текущий режим блокировки виден и напрямую: cat /sys/digsig/elf_mode — 0 означает, что проверка встроенных подписей не блокирует запуск. Для полной картины на Astra Linux 1.8 проверьте также доступные интерфейсы elf_verification_mode и xattr_mode в том же каталоге.

«astra-digsig-control: команда не найдена»

Частый первый барьер. Утилита лежит в /usr/sbin, которого нет в PATH обычного пользователя, — поэтому без sudo оболочка её просто не находит. Запускайте через sudo:

$ astra-digsig-control status
bash: astra-digsig-control: команда не найдена
$ sudo astra-digsig-control status
НЕАКТИВНО

Если и под sudo команды нет, проверьте редакцию ОС и наличие пакета astra-safepolicy, которому принадлежит утилита.

Что произойдёт после enable

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

И сразу предупреждение: первое включение делайте только там, где есть путь назад, — на виртуальной машине или при наличии снапшота и консоли восстановления. Если под блокировку попадёт компонент цепочки входа (например, свой PAM-модуль или заменённая библиотека), вы рискуете потерять и графический вход, и SSH — и выполнять disable будет неоткуда.

Безопасный порядок действий такой:

Составьте список ПО, которое работает на устройстве помимо штатных пакетов, включая PAM-модули, агенты мониторинга и библиотеки.
Для каждого файла выберите тип подписи и проверьте, каким ключам будет доверять ядро. Встроенная подпись требует ключа из доверенной цепочки; самостоятельно созданные ключи используют по схеме xattr или отсоединённой подписи.
Подпишите файлы и проверьте подписи на копии устройства или виртуальном стенде.
После изменения /etc/digsig/ обновите initramfs для всех установленных ядер: sudo update-initramfs -u -k all.
Выполните sudo astra-digsig-control enable, перезагрузите стенд и проверьте вход, SSH и прикладное ПО.
Просмотрите журнал ядра: sudo journalctl -k | grep DIGSIG.

Точный порядок размещения ключей и подписей сверяйте с документацией установленного обновления Astra. Обратный путь — sudo astra-digsig-control disable и перезагрузка — доступен лишь пока у вас остаётся вход в систему.

Чем подписывать собственное ПО

Для работы с подписями в штатной поставке есть bsign, а начиная с Astra Linux 1.8 — и bsign-integrator:

$ bsign --help
Usage: bsign [OPTION...] [FILE]...
Embed/verify secure hashes and digital signatures in executable files.

Тип подписи задаётся явно: -E для ELF-секции, -X для xattr, -D для отсоединённой подписи. Встроенную подпись имеет смысл создавать только ключом, которому ядро уже доверяет по цепочке. Самостоятельно созданный GPG-ключ не становится доверенным для встроенной подписи от простого копирования в /etc/digsig/keys/; для него выбирают xattr- или поддерживаемую в 1.8 отсоединённую схему.

Если ПО собирается внутри организации, подписывайте артефакт после каждой сборки: любое изменение файла делает прежнюю подпись недействительной. От вендора нужны не просто открытый ключ и бинарный файл, а поддерживаемая Astra схема подписи и цепочка доверия. Информацию о подписях показывает bsign -w <файл>, проверку выполняет bsign -V <файл> при загруженных в пользовательский GPG-набор ключах.

Бинарники, скрипты и обычные файлы: что именно контролирует ЗПС

ЗПС контролирует не файлы вообще, а допустимость их использования в заданных контурах проверки.

Исполняемые ELF-файлы и библиотеки. Ядро проверяет их при запуске программы и загрузке библиотек. Файл без допустимой подписи не запустится, но читать или копировать его как данные ЗПС не мешает.

Скрипты и другие не-ELF файлы. В скрипт ELF-секцию не встроить, поэтому используют подпись в расширенных атрибутах либо отсоединённую подпись. Шаблоны /etc/digsig/xattr_control относятся именно к xattr-проверке. Отсоединённые подписи хранятся в /etc/digsig/external_sig/ и загружаются через отдельный интерфейс ядра. Одного astra-digsig-control enable для настройки этих контуров недостаточно.

Чтение файлов ЗПС не блокирует. Запрет чтения — задача мандатного разграничения доступа (МРД), это другой механизм PARSEC со своими уровнями конфиденциальности.

Запись файлов ЗПС тоже не блокирует. Защита от записи — работа МКЦ, мандатного контроля целостности. У ЗПС с записью связь косвенная, но важная: если подписанный файл изменить, его подпись перестанет сходиться с содержимым — и при следующем запуске ядро его отклонит. То есть ЗПС не мешает записать в бинарник, она мешает потом его запустить.

Как понять, что запуск заблокировала именно ЗПС

Обычно программа просто отвечает Permission denied, хотя обычные права выглядят корректно. Решающий признак — запись DIGSIG об отказе проверки подписи в журнале ядра. Смотрите sudo journalctl -k | grep DIGSIG сразу после неудачного запуска. После обновления собственного ПО проверяйте журнал ещё раз: любое изменение подписанного файла делает прежнюю подпись недействительной.

Когда ЗПС вообще нужна

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