☰

======== ОБЗОР

tag-icon • tag-icon 16.04 drivers
======== ОБЗОР

Как установить любой модуль в Ubuntu 16.04 без подписи или редактирования каких-либо конфигураций ядра. Возможно ли это? Любая помощь будет оценена по достоинству.

решение1

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

Лично я отключаю безопасную загрузку в биосе.

Видетьhttps://wiki.ubuntu.com/SecurityTeam/SecureBoot

Или вручную подписать модуль ядра, см.

https://www.kernel.org/doc/Documentation/module-signing.txt

      ==============================          KERNEL MODULE SIGNING FACILITY
      ==============================

СОДЕРЖАНИЕ

  • Обзор.
  • Настройка подписи модуля.
  • Генерация ключей подписи.
  • Открытые ключи в ядре.
  • Подписание модулей вручную.
  • Подписанные модули и зачистка.
  • Загрузка подписанных модулей.
  • Недействительные подписи и неподписанные модули.
  • Администрирование/защита закрытого ключа.

======== ОБЗОР

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

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

=========================== НАСТРОЙКА ПОДПИСИ МОДУЛЯ

Функция подписи модулей включается путем перехода в раздел «Включить поддержку загружаемых модулей» конфигурации ядра и включения

CONFIG_MODULE_SIG "Проверка подписи модуля"

Здесь доступно несколько вариантов:

(1) «Требовать, чтобы модули были действительно подписаны» (CONFIG_MODULE_SIG_FORCE)

 This specifies how the kernel should deal with a module that has a
 signature for which the key is not known or a module that is unsigned.

 If this is off (ie. "permissive"), then modules for which the key is not
 available and modules that are unsigned are permitted, but the kernel will
 be marked as being tainted, and the concerned modules will be marked as
 tainted, shown with the character 'E'.

 If this is on (ie. "restrictive"), only modules that have a valid
 signature that can be verified by a public key in the kernel's possession
 will be loaded.  All other modules will generate an error.

 Irrespective of the setting here, if the module has a signature block that
 cannot be parsed, it will be rejected out of hand.

(2) «Автоматически подписывать все модули» (CONFIG_MODULE_SIG_ALL)

 If this is on then modules will be automatically signed during the
 modules_install phase of a build.  If this is off, then the modules must
 be signed manually using:

скрипты/файл подписи

(3) «Каким алгоритмом хеширования следует подписывать модули?»

 This presents a choice of which hash algorithm the installation phase will
 sign the modules with:

CONFIG_MODULE_SIG_SHA1 "Подписывать модули с помощью SHA-1" CONFIG_MODULE_SIG_SHA224 "Подписывать модули с помощью SHA-224" CONFIG_MODULE_SIG_SHA256 "Подписывать модули с помощью SHA-256" CONFIG_MODULE_SIG_SHA384 "Подписывать модули с помощью SHA-384" CONFIG_MODULE_SIG_SHA512 "Подписывать модули с помощью SHA-512"

 The algorithm selected here will also be built into the kernel (rather
 than being a module) so that modules signed with that algorithm can have
 their signatures checked without causing a dependency loop.

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

 Setting this option to something other than its default of
 "certs/signing_key.pem" will disable the autogeneration of signing keys
 and allow the kernel modules to be signed with a key of your choosing.
 The string provided should identify a file containing both a private key
 and its corresponding X.509 certificate in PEM form, or — on systems where
 the OpenSSL ENGINE_pkcs11 is functional — a PKCS#11 URI as defined by
 RFC7512. In the latter case, the PKCS#11 URI should reference both a
 certificate and a private key.

 If the PEM file containing the private key is encrypted, or if the
 PKCS#11 token requries a PIN, this can be provided at build time by
 means of the KBUILD_SIGN_PIN variable.

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

 This option can be set to the filename of a PEM-encoded file containing
 additional certificates which will be included in the system keyring by
 default.

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

========================= ГЕНЕРАЦИЯ КЛЮЧЕЙ ПОДПИСИ

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

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

сертификаты/ключ_подписи.pem

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

certs/x509.genkey

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

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

В частности, в файле x509.genkey следует изменить раздел req_distinguished_name по сравнению со значением по умолчанию:

[ req_distinguished_name ] #O = Неуказанная компания CN = Автоматически сгенерированный во время сборки ключ ядра #emailAddress = [email protected]

Размер сгенерированного ключа RSA также можно задать с помощью:

[треб] default_bits = 4096

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

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

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

Ядро содержит кольцо открытых ключей, которые может просматривать root. Они находятся в связке ключей под названием ".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: d69a84e6bce3d216b979e9505b3e3ef9a7118079: X509.RSA a7118079 [] ...

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

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

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

keyctl padd асимметричный "" [.system_keyring-ID] <[key-file]

например:

keyctl padd асимметричный "" 0x223c7853

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

=========================== ПОДПИСАНИЕ МОДУЛЕЙ ВРУЧНУЮ

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

  1. Алгоритм хеширования (например, sha256)
  2. Имя файла закрытого ключа или URI PKCS#11
  3. Имя файла открытого ключа
  4. Модуль ядра, который необходимо подписать

Ниже приведен пример подписи модуля ядра:

скрипты/файл подписи sha512 kernel-signkey.priv \ kernel-signkey.x509 module.ko

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

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

============================= ПОДПИСАННЫЕ МОДУЛИ И РАЗБОРКА

Подписанный модуль имеет цифровую подпись, просто добавленную в конец. Строка "~Подпись модуля добавлена~." в конце файла модуля подтверждает наличие подписи, но не подтверждает, что подпись действительна!

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

====================== ЗАГРУЗКА ПОДПИСАННЫХ МОДУЛЕЙ

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

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

Если CONFIG_MODULE_SIG_FORCE включен или module.sig_enforce=1 указан в командной строке ядра, ядро ​​будет загружать только действительно подписанные модули, для которых у него есть открытый ключ. В противном случае оно также будет загружать неподписанные модули. Любой модуль, для которого у ядра есть ключ, но который доказывает несовпадение подписи, не будет допущен к загрузке.

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

== ...

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

решение2

У меня была та же проблема с загрузкой драйвера. Я просто передал module.sig_enforce=0в командную строку своего ядра grub linux.

Вот шаги:

Постоянное добавление параметра загрузки ядра

  • Войдите в систему и запустите окно терминала (Приложения→Аксессуары→Терминал).

  • В $командной строке введите команду:

    sudo gedit /etc/default/grub

  • Введите пароль при появлении соответствующего запроса [sudo].

Если файл /etc/default/grubкажется пустым или не существует, см. инструкции для более ранних версий выше.

  • В окне редактора используйте клавиши со стрелками, чтобы переместить курсор на строку, начинающуюся с , а GRUB_CMDLINE_LINUX_DEFAULTзатем отредактируйте эту строку, добавив свой(и) параметр(ы) в текст внутри двойных кавычек после слов quiet splash. Я добавил module.sig_enforce=0. (Не забудьте добавить ПРОБЕЛ перед splashдобавлением нового параметра.)

  • Нажмите наСохранятькнопка

  • Закройте окно редактора.

  • В окне терминала в $командной строке введите:

    sudo update-grub

  • Перезагрузите систему.

Попробуйте загрузить ваш модуль, и мне это помогло.

решение3

Ubuntu 16.04 поддерживает pci_set_dma_mask вместо pci_dma_supported для сборки драйверов PCI. Неправильное использование API выведет ошибку несоответствия ключа безопасной загрузки при загрузке драйвера.

решение4

В ядре v5.4 можно отключить флаг MODULE_SIG_FORCEи затем пересобрать ядро.

Связанный контент