Как я могу установить любой модуль в Ubuntu 16.04 без подписи или без редактирования каких-либо конфигураций ядра. Является ли это возможным? Любая помощь будет оценена.
Ubuntu 16.04 поддерживает pci_set_dma_mask вместо pci_dma_supported для создания драйверов PCI. Неправильное использование API распечатает безопасную ошибку несоответствия ключа начальной загрузки при загрузке драйвера.
Вы или отключаете безопасную начальную загрузку или подписываете модуль ядра.
Лично, я отключаю безопасную начальную загрузку в 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 аргументов:
- хеш-алгоритм (например, sha256)
- имя файла с закрытым ключом или PKCS#11 URI
- имя файла с открытым ключом
- модуль ядра, который будет подписан
, следующее является примером для подписания модуля ядра:
ядро-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 подпись, будет отклонен.
=========================================, АДМИНИСТРИРУЮЩИЙ/ЗАЩИЩАЮЩИЙ ЗАКРЫТЫЙ КЛЮЧ
Начиная с закрытого ключа, используется для подписания модулей, вирусы и вредоносное программное обеспечение могли использовать закрытый ключ, чтобы подписать модули и поставить под угрозу операционную систему. Закрытый ключ должен быть или уничтожен или перемещен в безопасное место и не сохранен в корневом узле исходного дерева ядра.
У меня была такая же проблема с загрузкой драйвера. Я просто передал 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
Перезагрузите систему.
Попробуйте загрузить свой модуль, и у меня это сработало.
sudo apt-get update && sudo dpkg --no-act --configure -a
' – Drymartini 2 November 2017 в 10:14