Что такое ЗПС

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

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

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

Пакеты из репозиториев Astra подписаны разработчиком ОС; ключи для проверки лежат в /etc/digsig/:

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

astra-digsig-control: status, enable, disable

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

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

Полный набор аргументов — из её собственной подсказки:

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

Текущий режим ядра виден и напрямую: cat /sys/digsig/elf_mode — 0 означает, что проверка выключена.

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

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

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

Если и под sudo команды нет — вы, скорее всего, не на Astra Linux Special Edition: ЗПС входит только в SE-редакцию.

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

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

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

Порядок действий такой:

  1. Составьте список ПО, которое работает на машине помимо штатных пакетов.
  2. Подпишите собственные исполняемые файлы своим ключом и добавьте открытую часть ключа в /etc/digsig/keys/.
  3. Обновите initramfs: проверка подписей работает с раннего этапа загрузки (за это отвечает digsig_initramfs.conf), поэтому после изменения ключей выполните sudo update-initramfs -u.
  4. Только после этого — sudo astra-digsig-control enable и перезагрузка.
  5. Проверьте журнал ядра (journalctl -k) на отказы запуска: заблокированные файлы будут видны сразу.

Здесь намеренно дана общая схема: точный порядок подписи и размещения ключей сверяйте с документацией своей версии Astra — детали между релизами различаются.

Обратный путь — sudo astra-digsig-control disable и перезагрузка, — но лишь пока у вас остаётся вход в систему (см. предупреждение выше). На регулируемых системах выключение ЗПС обычно требует согласования, поэтому лучше отладить подписи до включения, а не после.

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

Подпись встраивается в исполняемый файл утилитой bsign из штатной поставки:

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

На живой машине помимо пакетов из репозитория живёт своё: скрипты автоматизации, агенты мониторинга, вендорские утилиты. Судьба каждого такого файла при включении ЗПС — забота администратора. Дальше два пути. ПО собирается внутри организации — подписывать его нужно на этапе сборки (bsign --sign с gpg-ключом организации), и это требование придётся донести до разработчиков: каждая пересборка снимает подпись, файл нужно подписывать заново. ПО вендорское — запрашивайте у поставщика подписанные сборки либо его открытый ключ; ключ кладётся в /etc/digsig/keys/. Проверить подпись конкретного файла можно той же утилитой (bsign --check-hash и verify-режим из --help).

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

Самая частая путаница вокруг ЗПС — ожидание, что она «закрывает файлы» вообще. На деле у неё узкая и чёткая зона ответственности: исполнение. Разложим по типам.

Исполняемые ELF-файлы и библиотеки. Это основной контур: подпись встроена секцией в сам файл, ядро проверяет её при запуске программы и при загрузке библиотек. Неподписанный или изменённый файл не запустится — но читать его как данные (открыть в редакторе, скопировать) ЗПС не мешает.

Скрипты и другие не-ELF файлы. В скрипт секцию не встроишь, поэтому для них предусмотрены два механизма: подпись в расширенных атрибутах файловой системы (xattr) либо отделённая подпись отдельным файлом (каталог external_sig рядом с ключами). Этот контур настраивается отдельно (конфигурация — /etc/digsig/xattr_control) и включает в замкнутую среду не только бинарники. Если в замкнутую среду должны попасть скрипты, планируйте этот контур сразу.

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

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

Как всё это выглядит на практике: заблокированный запуск — это отказ без внятного сообщения пользователю и запись в журнале ядра (journalctl -k); чтение и запись обычных данных живут как жили.

Обновления при включённой ЗПС

Штатные обновления из репозиториев Astra проблем не создают: пакеты приходят уже подписанными ключами разработчика ОС, которые система знает. Ломается обычно своё: пересобрали утилиту, забыли подписать — и после деплоя она молча не запускается. Симптом ищите в журнале ядра (journalctl -k) — отказ ЗПС виден там явно.

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

Со стороны пользователя симптом невнятный: программа «просто не запускается», оболочка говорит об отказе в доступе, хотя ls -l показывает нормальные права. Отличить ЗПС от обычных прав помогают два признака. Первый: права в порядке, владелец правильный, а запуск всё равно отклоняется. Второй, решающий: в журнале ядра в момент запуска появляется запись об отказе проверки подписи — смотрите journalctl -k сразу после неудачной попытки.

Для автоматизации пригодится is-enabled: он отвечает кодом возврата, так что в скрипте деплоя легко написать условие «если ЗПС активна — прогнать проверку подписей до раскатки, а не узнать о проблеме от пользователей».

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

ЗПС — требование ряда профилей защиты для государственных информационных систем и КИИ; включение «на всякий случай» на машине разработчика чаще мешает, чем помогает. Здравая эвристика: если машина обрабатывает то, что защищается по требованиям регулятора, — ЗПС планируется с самого начала вместе с процессом подписи ПО; если это рабочая станция инженера с постоянно меняющимся набором инструментов — сначала выстраивают процесс подписи, потом включают проверку.