Почему shim/mokmanager позволяет обойти _ALL_ защиту SecureBoot? И как это исправить?
Вот что я сделал:
- Сгенерировал свои собственные ключи SSL (db, KEK, PK) x (cer, key)
- Удал существующие подписи из ядра, GRUB, shim (и всех других двоичных файлов EFI в
/boot) и подписал их своим собственным сертификатом (db). - Перезагрузил и зарегистрировал свои сертификаты в UEFI (который перевел его в режим пользователя).
Пока все в порядке. Я надеялся, что с этого момента у противника есть только два способа изменить мой системный загрузчик (GRUB):
- Перейти в UEFI и отключить SecureBoot (=> нужен пароль)
- Скомпрометировать мой личный ключ KEK (или PK), который авторизует изменения в переменной db (или KEK) EFI, что позволит добавить еще один сертификат, который может подписать другой системный загрузчик.
Но
Что происходит в реальности, так это то, что shim DOES обнаруживает, что GRUB скомпрометирован/модифицирован, это показывает следующее:
ERROR
Verification failed: (0x1A) Security Violation
<OK>
и затем, когда я нажимаю
Press any key to perform MOK management
Enroll key from disk
Очевидно, это ломает всю "цепочку доверия" - это делает бесполезными все предыдущие шаги, в некотором смысле это черный ход (я понимаю, что это пытается быть полезным, слишком полезным, возможно...).
Вопросы
- Я прав? Может быть, я что-то упустил или неправильно понял? У меня сложилось впечатление, что только владелец ключей может заменить загрузчики/EFI/ядра (иначе становятся возможными атаки EvilMaid, кража паролей LUKS становится легкой задачей, и так далее...)
- Есть ли обходные пути? Можно ли полностью удалить MokManager (
mmx64.efi)? Можно ли удалить поведение, сделать его "менее полезным"?
P.S.
На тот случай, если вам интересно, как насчёт grub.cfg / initrd... - Я использую отдельную версию GRUB, которая проверяет подписи GPG всего, что она загружает (set check_signatures=enforce)
1 ответ
Я не понимаю, как это «разрывает всю цепочку доверия:». Он предупредил местного человека, имеющего физический доступ к машине, о том, что цепочка доверия была разорвана, а затем позвольте человек принимает исполнительное решение о том, что с этим делать.
Это ожидаемое поведение.
По сути, не существует набора средств защиты, который был бы полностью эффективным против квалифицированного человека, имеющего доступ к оборудованию и время, чтобы злоупотребить этим. доступ (другой стандарт, чем традиционная атака "Злой Девы"). Если бы это было так, маловероятно, что кто-либо из нас вообще смог бы установить Ubuntu на наши настольные ПК и ноутбуки - мы бы навсегда застряли в чем бы то ни было ОС предоставлена поставщиком.
Я не уверен, что это указывает на высокоприоритетную уязвимость. Все в / boot принадлежит пользователю root, поэтому похоже, что этот процесс требует, чтобы злоумышленник уже получил root другим способом.