Что делает подписывание драйверов/модулей и каково это значение?
Пакеты Deb хранятся в /var/cache/apt/archives. Проверьте там.
Но если вы находитесь в режиме восстановления, неудивительно, что каталог архива доступен только для чтения. Я видел ваш другой вопрос и просто ответил на него. Не беспокойтесь об очистке пакетов, когда вам просто нужно переместить файл xorg.conf по умолчанию обратно на использование драйвера с открытым исходным кодом для вашей видеокарты.
Чтобы сделать каталог не только для чтения, вам нужно сделать только это:
# mount -o remount rw /var/cache/apt/archives
Но опять же, это только в образовательных целях, поскольку я настоятельно рекомендую вам не стрелять рыбу в бочку, пытаясь очистить пакеты с помощью dpkg в режиме восстановления. Делайте это корректно с помощью менеджера пакетов MINT после перезагрузки с видеокартой. В противном случае вы просто еще больше загрязните свою систему, поскольку dpkg удалит только один пакет и не будет возиться со всеми зависимостями.
Ядро можно настроить так, чтобы оно либо просто предупреждало вас об использовании неподписанных или неправильно подписанных модулей (сообщением журнала + путем установки флага taint в ядре ), либо полностью отклоняло любые модули ядра, которые не не имеют подписи, которую ядро может проверить.
При использовании процесса загрузки в стиле BIOS -или при использовании UEFI с отключенной безопасной загрузкой это, по сути, просто необязательная дополнительная процедура безопасности. Злоумышленникам будет несколько сложнее добавлять злонамеренные модули ядра (, такие как руткиты на основе ядра -, чтобы скрыть инструменты и действия злоумышленника )в системе.
Но при использовании UEFI с включенной безопасной загрузкой это является частью требований к безопасной загрузке. «Дух» безопасной загрузки заключается в том, чтобы запретить загрузку ненадежного кода в пространство ядра. Микропрограмма UEFI проверяет наличие действительной подписи (или хэша SHA256 из белого списка )в загрузчике; загрузчик обязан проверить то же самое на ядре ОС; предполагается, что ядро распространяет это требование на весь код, который будет выполняться в пространстве ядра.
Конечно, на практике ядро ОС может легко отказаться от этого требования.Но организации, разработавшие безопасную загрузку, решили, что этот отказ должен, по крайней мере, требовать определенных действий со стороны системного администратора :по умолчанию должно быть принудительное требование подписи.
(Кстати, это также одна из причин, по которой современная Windows требует, чтобы все установленные драйверы были подписаны по умолчанию. Если вы хотите установить неподписанные драйверы, вам необходимо явно изменить параметр, для которого требуется доступ администратора.)
Инструмент, который будет загружаться в системе с безопасной загрузкой и позволит выполнять неподписанный пробел ядра -«из коробки», будет называться устройством обхода безопасной загрузки и будет классифицироваться как вредоносное ПО.
Microsoft является наиболее известным -известным подписантом Secure Boot, и они будут подписывать только те версии shimx64.efiпрокладочного загрузчика, которые обеспечивают соблюдение требования подписи.
Микропрограмма UEFI, поддерживающая безопасную загрузку, будет иметь встроенную -возможность проверки подписей на двоичных файлах, использующих двоичный формат Microsoft PE+, который используется в файлах *.efi. Но мир Linux обычно не использует этот двоичный формат :, вместо него используется двоичный формат ELF.
И модули ядра Linux, и модули загрузчика GNU GRUB основаны на формате ELF. Это требует, чтобы загрузчик и ядро предоставили свои собственные алгоритмы проверки подписи для двоичных файлов ELF, но, по-видимому, UEFI Forum (, отраслевой консорциум, который управляет спецификациями UEFI и безопасной загрузки ), решил, что это нормально, пока поскольку требование по умолчанию для действительных подписей сохраняется.
Конечно, это не совсем работает, как ожидалось, если вы используете DKMS для автоматической сборки и подписи модулей ядра :это означает, что будет сертификат с его закрытым ключом, который можно использовать для автоматического создания действительной подписи, поэтому злоумышленник также может использовать его для подписи любых вредоносных модулей ядра.Это не менее безопасно, чем система без Secure Boot, но и не намного безопаснее.
Если у вас несколько систем, вы могли бы получить некоторое преимущество в плане безопасности, если бы закрытый ключ для вашего сертификата подписи модуля был только на одном хосте (, предположительно на том, который меньше всего угрожает злоумышленникам ), и использовать его для сборки любые пользовательские ядра и/или модули, которые могут вам понадобиться, и распространение их оттуда на любые другие хосты, которые в них нуждаются. Таким образом, другим хостам потребуется только общедоступная часть сертификата подписи модуля, которую можно использовать только для проверки существующих подписей, а не для создания новых.