Как установить модуль module.ko без подписи ядра или перестройки ядра в Ubuntu 16.04?

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

6
задан 26 April 2017 в 10:29

3 ответа

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

0
ответ дан 26 April 2017 в 20:29
  • 1
    Вы обновляли способное прежде, чем выполнить установку? sudo apt-get update && sudo dpkg --no-act --configure -a ' – Drymartini 2 November 2017 в 10:14

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

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

Видят https://, wiki.ubuntu.com/SecurityTeam/SecureBoot

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

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

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

СОДЕРЖАНИЕ

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

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

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

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

==========================, НАСТРАИВАЮЩИЙ МОДУЛЬ, ПОДПИСЫВАЯСЬ

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

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:

scripts/sign-file

(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 devel к процессам сборки ядра для инструмента, который делает подписание.

=======================, ГЕНЕРИРУЮЩИЙ КЛЮЧИ ПОДПИСИ

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

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

certs/signing_key.pem

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

файл certs/x509.genkey

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

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

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

[req_distinguished_name] #O = Неуказанная компания CN = Время изготовления автоматически сгенерировало ключ ядра #emailAddress = unspecified.user@unspecified.company

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

[req] default_bits = 4096

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

openssl req - новый - узлы-utf8-sha256 - дни 36500 - обрабатывают в пакетном режиме-x509 \-x509.genkey-outform PEM конфигурации - kernel_key.pem \-keyout kernel_key.pem

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

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

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

[root@deneb ~] # кошка/proc/keys... 223c7853 я перманент------1 1f030000 0 0 брелоков для ключей .system_keyring: 1 302d2d52 я перманент------
1 1f010000 0 0 ключей подписи ядра Fedora асимметрии: d69a84e6bce3d216b979e9505b3e3ef9a7118079: X509. RSA a7118079 []...

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

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

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

keyctl padd асимметричный "" [.system_keyring-идентификатор] < [файл ключей]

, например:

keyctl padd асимметричное "" Примечание 0x223c7853

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

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

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

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

, следующее является примером для подписания модуля ядра:

ядро-signkey.priv scripts/sign-file sha512 \ядро-signkey.x509 module.ko

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

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

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

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

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

======================, ЗАГРУЖАЮЩИЙ ПОДПИСАННЫЕ МОДУЛИ

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

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

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

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

=========================================, АДМИНИСТРИРУЮЩИЙ/ЗАЩИЩАЮЩИЙ ЗАКРЫТЫЙ КЛЮЧ

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

0
ответ дан 26 April 2017 в 20:29
  • 1
    Я тогда попытался установить и добрался roger@roger-MS-7994:~, $ sudo склонный - получают установку libappindicator1 Чтение списков пакета... Сделанное дерево зависимостей Здания, Чтение информация состояния... Сделанный Пакет libappindicator1 не доступен, но упомянут другим пакетом. Это может означать, что пакет отсутствует, был obsoleted или только доступен из другого источника E: Пакет ' libappindicator1' разве ни у какого кандидата установки нет roger@roger-MS-7994:~ $, Что я делаю для улаживания этого? – Roger Carver 2 November 2017 в 00:35

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

Вот шаги:

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

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

  • По запросу $ введите команду:

    sudo gedit /etc/default/grub
    
  • Введите пароль при появлении запроса [sudo].

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

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

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

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

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

    sudo update-grub
    
  • Перезагрузите систему.

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

2
ответ дан 24 September 2020 в 01:04

Другие вопросы по тегам:

Похожие вопросы: