Передать результат нескольким командам без вывода на экран

На языке сертификатов X.509v3:расширение сертификата может быть указано как критическое , если создатель сертификата (и/или удостоверяющий центр )требует, чтобы тот, кто проверяет этот сертификат, должен был понимать это расширение или считать этот сертификат недействительным.

Расширение «Базовые ограничения» является наиболее фундаментальным расширением сертификата. :оно определяет, является ли сертификат обычным сертификатом («CA :False» )или сертификатом центра сертификации («CA :True", с необязательным значением длины пути, т. е. максимально допустимой глубины промежуточных сертификатов ЦС после этого сертификата ЦС ).

Во всех современных системах расширение сертификата «Базовые ограничения» всегда должно быть критическим расширением.

Итак, эти атрибуты:

X509v3 Basic Constraints: critical
CA: False

означает в человеческом выражении :"Это не сертификат ЦС. Если он появляется в ситуации, когда сертификат ЦС необходим, значит, кто-то определенно делает что-то не так. Если вы этого не сделаете, понимаете это ограничение, вы вообще не должны полагаться на этот сертификат ни в каких целях». Другими словами, это совершенно нормальное и ожидаемое расширение для любого сертификата CA, отличного от -.

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

Поскольку нельзя ожидать, что безопасная загрузка будет проверять какие-либо центры сертификации во время загрузки, эти атрибуты на самом деле не имеют никакого значения для безопасной загрузки. Когда действует безопасная загрузка, микропрограмма должна проверять, что любые запросы на изменение существующего первичного ключа (PK )или ключей обмена ключами (KEK )подписаны закрытым ключом, соответствующим текущему сертификат PK и любые запросы на обновление существующего белого списка (db ),ключи blacklist (dbx )или timestamp (dbt )подписываются закрытым ключом, соответствующим текущему сертификату PK или любому из текущих сертификатов KEK. Во время загрузки любой загруженный исполняемый код не должен совпадать ни с одной из записей черного списка (dbx )и должен быть либо подписан ключом, соответствующим одному из сертификатов (db )из белого списка, либо криптографическим хэшем исполняемого файла. должны быть включены в белый список напрямую. Эти проверки полностью независимы от иерархии PKI X.509.

Сертификаты ключей безопасной загрузки могут по-прежнему быть частью иерархии PKI компании, чтобы сертификаты можно было при необходимости проверить извне, и в этот момент могут вступить в действие расширения сертификатов X.509v3. Но для проверки безопасной загрузки во время загрузки -любые расширения сертификата X.509v3 обычно полностью игнорируются.

Поскольку выяснилось, что некоторые системные микропрограммы не позволяют владельцу системы модифицировать ключи безопасной загрузки полезным образом, shim.efiбыл разработан загрузчик. Он предоставляет схему расширения для безопасной загрузки :, shim.efiподписан Microsoft, и предоставляет второй белый список (MOK, ключ владельца машины ), который с достаточной степенью уверенности гарантирует независимость от управления микропрограммой, но в противном случае в тех же условиях безопасности, что и другие переменные ключа безопасной загрузки.

Процесс регистрации MOK касается переменных NVRAM и shim.efi, поэтому результаты операции не сохраняются в обычных файлах, которые можно откатить с помощью timeshiftили аналогичного. На самом деле похоже, что соответствующие переменные NVRAM создаются с атрибутами, которые указывают только доступ к службе загрузки UEFI, поэтому только shim.efiили другой инструмент времени загрузки UEFI -может изменить их после создания... при условии, что прошивка работает в соответствии со стандартами UEFI и Secure Boot.