Все, в чем Вы нуждаетесь, описаны здесь

ЯДЕРНОЕ СРЕДСТВО ДЛЯ ПОДПИСАНИЯ МОДУЛЯ

<час>

СОДЕРЖАНИЕ

• Обзор.
• подписание модуля Формирования.
• ключи подписания Создания.
• Открытые ключи в ядре.
• Вручную модули подписания.
• Подписанные модули и демонтаж.
• Погрузка подписала модули.
• Недействительные подписи и неподписанные модули.
• Управление/защита частным ключом.

<час>

ОБЗОР

ядерное средство для подписания модуля шифровальным образом подписывает модули во время установки и затем проверяет подпись после погрузки модуля. Это позволяет увеличенную ядерную безопасность, отвергая погрузку неподписанных модулей или модулей, подписанных с недействительным ключом. Модуль подписывая безопасность увеличений, мешая загружать злонамеренный модуль в ядро. Проверка подписи модуля сделана ядром так, чтобы не было необходимо доверять userspace битам.

Это средство использует свидетельства стандарта X.509 ITU-T, чтобы закодировать включенные открытые ключи. Подписи самостоятельно не закодированы ни в каком промышленном стандартном типе. Средство в настоящее время только поддерживает стандарт шифрования открытого ключа RSA (хотя это pluggable и разрешает другим использоваться). Возможные алгоритмы хеширования, которые могут использоваться, являются SHA-1, SHA-224, SHA-256, SHA-384 и SHA-512 (алгоритм отобран данными в подписи).

<час>

МОДУЛЬ ФОРМИРОВАНИЯ, ПОДПИСЫВАЯСЬ

средство для подписания модуля позволено, идя в раздел «Enable Loadable Module Support» ядерной конфигурации, и включая

CONFIG_MODULE_SIG   "Module signature verification"

Это имеет много вариантов в наличии:

1. «Требуют, чтобы модули были законно подписаны», (CONFIG_MODULE_SIG_FORCE)

   Это определяет, как ядро должно иметь дело с модулем, у которого есть подпись, которой ключ не известен или модуль, который не подписан.

   , Если это выключенное (т.е. «разрешающее»), то модули, для которых ключ не доступен и модули, которые не подписаны, разрешены, но ядро будет отмечено как испорченный, и заинтересованные модули будут отмечены, как испорчено, показаны с характером 'E'.

   , Если это идет (т.е. «строго»), только модули, у которых есть действительная подпись, которая может быть проверена открытым ключом во владении ядра, будут загружены. Все другие модули произведут ошибку.

   Независимо от урегулирования здесь, если у модуля есть блок электронно-цифровой подписи, который не может быть разобран, это будет отклонено из руки.

2. «Автоматически знак все модули» (CONFIG_MODULE_SIG_ALL)

   , Если это идет тогда, модули будут автоматически подписаны во время modules_install фазы строения. Если это выключено, то модули должны быть подписаны, вручную используя:

   scripts/sign-file
   

3. , «С которым должен быть подписан алгоритм хеширования модули?»

   Это представляет выбор, которого алгоритма хеширования инсталляционная фаза подпишет модули с:

   CONFIG_MODULE_SIG_SHA1      "Sign modules with SHA-1"
   CONFIG_MODULE_SIG_SHA224    "Sign modules with SHA-224"
   CONFIG_MODULE_SIG_SHA256    "Sign modules with SHA-256"
   CONFIG_MODULE_SIG_SHA384    "Sign modules with SHA-384"
   CONFIG_MODULE_SIG_SHA512    "Sign modules with SHA-512"
   

   алгоритм, отобранный здесь, будет также встроен в ядро (вместо того, чтобы быть модулем) так, чтобы модулям, подписанным с тем алгоритмом, можно было проверить их подписи, не вызывая петлю зависимости.

4. «Имя файла или URI PKCS#11 ключа подписания модуля» (CONFIG_MODULE_SIG_KEY)

   Урегулирование этот выбор к чему-то другому, чем его дефолт «certs/signing_key.pem» отключит автоматическую генерацию подписания ключей и позволит ядерным модулям быть подписанными с ключом Вашего выбора. Обеспеченная последовательность должна определить файл, содержащий и частный ключ и его соответствующее свидетельство X.509 в области формы PEM или — на системах, где OpenSSL ENGINE_pkcs11 - функциональный — URI PKCS#11, как определено RFC7512. В последнем случае URI PKCS#11 должен сослаться и на свидетельство и на частный ключ.

   , Если файл PEM, содержащий частный ключ, зашифрован, или если символ PKCS#11 требует PIN, это может быть обеспечено во время изготовления посредством переменной KBUILD_SIGN_PIN.

5. «Дополнительные ключи X.509 для системного брелока для ключей по умолчанию» (CONFIG_SYSTEM_TRUSTED_KEYS)

   Этот выбор может быть установлен в имя файла PEM-закодированного файла, содержащего дополнительные свидетельства, которые будут включены в системный брелок для ключей по умолчанию.

Примечание, что предоставление возможности подписания модуля добавляет зависимость от пакетов OpenSSL devel к ядру, строит процессы для инструмента, который делает подписание.

<час>

КЛЮЧИ ПОДПИСАНИЯ СОЗДАНИЯ

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

При нормальных условиях, когда CONFIG_MODULE_SIG_KEY неизменен от своего дефолта, ядро строит, автоматически произведет новый keypair, использующий openssl, если Вы не будете существовать в файле:

certs/signing_key.pem

во время создания vmlinux (общественная часть ключа должна быть встроена в vmlinux), использование параметров в:

certs/x509.genkey

файл (который также произведен, если он уже не существует).

сильно рекомендуется, чтобы Вы предоставили свой собственный x509.genkey файл.

Прежде всего, в x509.genkey файле, req_distinguished_name раздел должен быть изменен от дефолта:

[ req_distinguished_name ]
#O = Unspecified company
CN = Build time autogenerated kernel key
#emailAddress = unspecified.user@unspecified.company

произведенный ключевой размер RSA может также быть установлен с:

[ req ]
default_bits = 4096

также возможно вручную произвести ключевые частные/общественные файлы, используя x509.genkey ключевой конфигурационный файл поколения в узле корня ядерного исходного дерева Linux и команды openssl. Ниже приведен пример, чтобы произвести общественные/частные ключевые файлы:

openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509 \
   -config x509.genkey -outform PEM -out kernel_key.pem \
   -keyout kernel_key.pem

полное имя пути для получающегося kernel_key.pem файла может тогда быть определено в выборе CONFIG_MODULE_SIG_KEY, и свидетельство и ключ там будут использоваться вместо самозарожденного keypair.

<час>

ОТКРЫТЫЕ КЛЮЧИ В ЯДРЕ

ядро содержит кольцо открытых ключей, которые могут быть рассмотрены корнем. Они находятся в брелоке для ключей, названном «.system_keyring», который виден:

[root@deneb ~]# cat /proc/keys
...
223c7853 I------     1 perm 1f030000     0     0 keyring   .system_keyring: 1
302d2d52 I------     1 perm 1f010000     0     0 asymmetri Fedora kernel signing key: d69a84e6bce3d216b979e9505b3e3ef9a7118079: X509.RSA a7118079 []
...

Вне открытого ключа, произведенного специально для подписания модуля, дополнительные свидетельства, которым доверяют, могут быть предоставлены в PEM-закодированном файле, на который ссылается параметр конфигурации CONFIG_SYSTEM_TRUSTED_KEYS.

Далее, кодекс архитектуры может взять открытые ключи из хозяйственного магазина и включить их также (например, из ключевой базы данных UEFI).

Наконец, возможно добавить дополнительные открытые ключи, делая:

keyctl padd asymmetric "" [.system_keyring-ID] <[key-file]

, например:

keyctl padd asymmetric "" 0x223c7853 <my_public_key.x509

Примечание, однако, что ядро только разрешит ключам быть добавленными к .system_keyring , если обертка нового ключа X.509 будет законно подписана ключом, который является уже резидентским в .system_keyring в то время, когда ключ был добавлен.

<час>

ВРУЧНУЮ МОДУЛИ ПОДПИСАНИЯ

, Чтобы вручную подписать модуль, используйте scripts/sign-file инструмент, доступный в ядерном исходном дереве Linux. Сценарий требует 4 аргументов:

1.  The hash algorithm (e.g., sha256)
2.  The private key filename or PKCS#11 URI
3.  The public key filename
4.  The kernel module to be signed

следующее - пример, чтобы подписать ядерный модуль:

scripts/sign-file sha512 kernel-signkey.priv \
    kernel-signkey.x509 module.ko

используемый алгоритм хеширования не должен соответствовать настроенному тому, но если он не делает, Вы должны удостовериться, что алгоритм хеширования или встроен в ядро или может быть загружен, не требуя себя.

, Если частный ключ требует пароля или PIN, он может быть обеспечен в переменной окружения $KBUILD_SIGN_PIN.

<час>

ПОДПИСАННЫЕ МОДУЛИ И ДЕМОНТАЖ

А подписался, модулю приложили цифровую подпись просто в конце. Последовательность «~Module подпись приложила ~». в конце файла модуля подтверждает, что подпись присутствует, но это не подтверждает, что подпись действительна!

Подписанные модули ХРУПКИЕ, как подпись за пределами определенного контейнера ЭЛЬФА. Таким образом они НЕ МОГУТ быть раздеты, как только подпись вычислена и приложена. Обратите внимание, что весь модуль - подписанный полезный груз, включая любого и весь подарок информации об отладке во время подписания.

<час>

ПОГРУЗКА ПОДПИСАЛА МОДУЛИ

, Модули загружены insmod, modprobe, init_module () или finit_module (), точно что касается неподписанных модулей, поскольку никакая обработка не сделана в userspace. Проверка подписи все сделана в ядре.

<час>

НЕДЕЙСТВИТЕЛЬНЫЕ ПОДПИСИ И НЕПОДПИСАННЫЕ МОДУЛИ

, Если CONFIG_MODULE_SIG_FORCE позволен или enforcemodulesig=1 поставляется на ядерной командной строке, ядро только загрузит законно подписанные модули, для которых у этого есть открытый ключ. Иначе это также загрузит модули, которые не подписаны. Любому модулю, для которого у ядра есть ключ, но у которого, оказывается, есть несоответствие подписи, не разрешат загрузить.

Любой модуль, у которого есть unparseable подпись, будет отклонен.

<час>

УПРАВЛЕНИЕ/ЗАЩИТА ЧАСТНЫМ КЛЮЧОМ

, Так как частный ключ используется, чтобы подписать модули, вирусы и вредоносное программное обеспечение могли использовать частный ключ, чтобы подписать модули и поставить под угрозу операционную систему. Частный ключ должен быть или уничтожен или перемещен в безопасное местоположение и не сохранен в узле корня ядерного исходного дерева.

Редактирование ./include/generated/autoconf.h и изменение строка

define CONFIG_MODULE_SIG 1

к

define CONFIG_MODULE_SIG 0