Как проверить ГОСТ-подписи модулей в НАЙС.ОС¶
В этом руководстве приведены команды только для чтения: они не меняют параметры безопасности, не устанавливают пакеты, не отключают драйверы и не требуют перезагрузки. Для части команд могут понадобиться права root.
Шаг 1. Узнайте версию запущенного ядра¶
Откройте терминал и выполните:
Пример версии, для которой известны сведения о ГОСТ-подписях:
Это пример, а не обязательная версия для всех пользователей. Проверяется именно запущенное ядро: новая версия RPM может быть установлена, но ещё не загружена после перезагрузки.
Шаг 2. Посмотрите параметры поддержки подписей¶
В подходящей сборке можно увидеть, например:
CONFIG_MODULE_SIG=y означает, что в ядре имеется механизм проверки подписей модулей; CONFIG_PKCS7_MESSAGE_PARSER=y указывает на поддержку обработки PKCS#7. CONFIG_CRYPTO_ECRDSA=y — наличие функции проверки подписей EC-RDSA в ядре. Эти параметры не говорят, что каждый установленный модуль подписан алгоритмом ГОСТ Р 34.10-2012.
CONFIG_MODULE_SIG_SHA512=y описывает выбранный при сборке хэш для штатного механизма подписи. Однако фактический хэш конкретного файла смотрят отдельно через modinfo -F sig_hashalgo: он может отличаться.
Если файл /boot/config-$K отсутствует, наличие функции уточняют в документации конкретной сборки ядра; отсутствие файла само по себе не доказывает отсутствие криптографии.
Шаг 3. Найдите подпись штатного модуля¶
Для примера используйте модуль dummy, который обычно входит в комплект ядра. Только чтение сведений:
K="$(uname -r)"
modinfo -k "$K" -F filename dummy
modinfo -k "$K" -F signer dummy
modinfo -k "$K" -F sig_id dummy
modinfo -k "$K" -F sig_hashalgo dummy
Для рассматриваемой сборки возможен такой ответ:
/lib/modules/6.12.114-1.niceosc5.x86_64/kernel/drivers/net/dummy.ko
NiceOS GOST test module signing
PKCS#7
GOST R 34.11-2012 with 256 bit hash
filename— путь к установленному модулю.signer— имя подписанта из сведений о подписи.sig_id— формат подписи.sig_hashalgo— используемый в подписи хэш-алгоритм.
Если строки с подписью пустые, модуль может быть неподписан или его подпись не распознана утилитой. Само отсутствие вывода не позволяет сделать вывод обо всех модулях системы. Если модуля dummy нет, попробуйте другой установленный модуль, название которого известно администратору.
Важно: modinfo показывает метаданные файла, но не выполняет полноценную проверку доверия к подписи. Фактическое решение о допуске модуля принимает ядро при загрузке.
Шаг 4. Проверьте, доверяет ли ядро ключам подписи¶
Если установлена утилита keyctl, выполните от root:
В списке могут отображаться встроенные доверенные сертификаты. Пример распознаваемого имени:
Числовые идентификаторы ключей и отпечатки на каждой машине могут отличаться. Найденное имя означает, что в хранилище ядра имеется соответствующий доверенный ключ, но не доказывает само по себе действительность подписи какого-либо конкретного файла.
Если команда keyctl отсутствует, это означает только отсутствие пользовательской утилиты либо недоступность соответствующего интерфейса. Для базовой проверки подписей достаточно предыдущего шага.
Шаг 5. Узнайте, обязаны ли все модули быть подписаны¶
Результат интерпретируется следующим образом:
| Вывод | Значение |
|---|---|
Y |
Действует обязательная проверка: неподписанные и неподтверждённые модули не должны загружаться |
N |
Обязательная проверка выключена: ядро может разрешать неподписанные модули при прочих выполненных условиях |
| Файл отсутствует | Необходимо проверить конфигурацию именно этого ядра и способ запуска |
Внимание: N не означает, что все проверки отключены. Повреждённые или некорректные подписи могут отклоняться и в разрешительном режиме.
Не меняйте этот параметр при обычной диагностике. Включение строгого режима на работающем сервере может препятствовать последующей загрузке необходимых внешних драйверов.
Шаг 6. Проверьте доступные ГОСТ-алгоритмы в ядре¶
Для встроенного ГОСТ ожидаются названия kuznyechik, magma, streebog256, streebog512 и другие — в зависимости от сборки. Эта команда показывает наличие алгоритмов, а не успешность проверки подписи модуля. Расширенное объяснение см. в реестре алгоритмов ядра.
Что считать успешной проверкой¶
Вы узнали версию запущенного ядра, увидели включённый механизм подписи, определили формат и хэш подписи интересующего модуля, проверили список доверенных ключей (если доступен) и определили режим sig_enforce.
Это достаточная диагностика состояния для рабочего сервера. Для подтверждения, что подписанный модуль действительно допускается, а неподписанный отклоняется, используйте отдельный учебный стенд, не меняя настройку на действующей машине.