On 2/1/23 10:19, Victor Wagner wrote:
В Wed, 1 Feb 2023 10:11:15 -0500
Tim Sattarov <sti...@gmail.com> пишет:

Если думаешь, что можно как то лучше и безопаснее - предлагай. Я
понимаю, что обличать и открывать глаза иногда полезно. Но ключевое
слово здесь "иногда".
По моим представлениям нужно:
1. Выстраивать непрерывную цепочку доверия от BIOS до конкретных
исполняемых модулей. Да, и скриптовых тоже, да, и разделяемых библиотек
тоже. То есть bsign это хорошо, но нужен еще scriptsign.
2. Проверка на подпись скриптов должна быть встроена в интерпретатор,
чтобы никакими средствами языка (. в shell, require в perl и т.д.)
нельзя было ее обойти.
3. По возможности физически разделять машины где ведется разработка (и
где подписываются исполняемые модули) и те, где защита секьюрбутом
применяется в боевом режиме в качестве защиты от реальных атак. Потому
что непонятно как совместить подпись каждого исполняемого файла в
системе с разработкой программ, а особенно скриптов-однострочников у
которых PKCS7-структура подписи будет больше места, чем содержательный
код занимать.

Вот это уже интересно. А процесс защиты ограничен именно этими алгоритмами?
Если ограничиться только secure boot и интерфейсом с BIOS/UEFI.
Как бы выглядела идеальная защита там?

Maksim Dmitrichenko выше недоволен отсутствием ввода секрета во время подписи драйверов, что делает процесс больше фикцией, Так как секреты (ключи подписи) находятся там же где и сами артифакты для подписи. И ничего их не защищает. Мало того, эти ключи находятся в публичном доступе, что не ограничивает злоумышленников от использования этих публично доступных ключей для своих целей.
Как здесь быть? Получается, что вся защита только в получении рута на машине.
Модули скачанные с сайта debian подписаны майнтейнером. Там более менее можно ограничить доступ к секретному ключу.
Но всё то что делает DKMS эту защиту опускает до своего уровня - права доступа 
к директории с модулями.

Ответить