В Wed, 1 Feb 2023 10:48:47 -0500 Tim Sattarov <[email protected]> пишет:
> On 2/1/23 10:19, Victor Wagner wrote: > > В Wed, 1 Feb 2023 10:11:15 -0500 > Вот это уже интересно. А процесс защиты ограничен именно этими > алгоритмами? Если ограничиться только secure boot и интерфейсом с > BIOS/UEFI. Как бы выглядела идеальная защита там? > > Maksim Dmitrichenko выше недоволен отсутствием ввода секрета во время > подписи драйверов, что делает процесс больше фикцией, > Так как секреты (ключи подписи) находятся там же где и сами артифакты > для подписи. И ничего их не защищает. И это вполне законная претензия > только в получении рута на машине. Модули скачанные с сайта debian > подписаны майнтейнером. Там более менее можно ограничить доступ к Можно-то можно, но делается ли? Конечно если утечет ключ дебановского мейнтейнера, скорее всего шуму будет на весть интернет. Как я уже писал в соседнем письме, в наше время правильно использовать подобные защиты не умеет почти никто. Даже в этом треде термин "модель угроз" употребил только Alexander Gerasiov <[email protected]> > секретному ключу. Но всё то что делает DKMS эту защиту опускает до > своего уровня - права доступа к директории с модулями. А DKMS это вообще паллиатив. Если мы используем DKMS, значит мы хотим использовать какие-то лиценизонно не совместимые с мейнлайн-ядром модули. Потому что если бы они были совместимы, был бы готовый пакет. То есть по хорошему счету, используя DKMS мы сразу говорим "мы тут доверяем какому-то левому коду исполняться в контексте ядра" Да, это конечно иногда наименьшее зло. Но, возможно что авторы DKMS именно так и рассудили, что снявши голову по волосам не плачут, и если мы используем dkms-модули вместе с secureboot, secureboot нам нужен не для безопасности, а для чего-то ещё (чтобы там TPM работал или чтобы какие-нибудь сертифицирующие органы отвязались). -- Victor Wagner <[email protected]>
