Re: Как правильно подписывать пропиетарный драйвер nvidia для secureboot?
On 2/1/23 14:46, Alexander Gerasiov wrote: От подмены этих файлов защищает secureboot с кастомными ключами. А можно поподробнее про этот момент как кастомные ключи в этом случае работают? ты грузишь свои собственные ключи в BIOS и указываешь степень доверия? Если да, то я думаю этот момент даёт достаточно хорошую защиту, если не доводить до гаечных ключей, и прочих горячих предметов.
Re: Как правильно подписывать пропиетарный драйвер nvidia для secureboot?
On Wed, 1 Feb 2023 18:12:59 +0300 Victor Wagner wrote: > В Wed, 1 Feb 2023 16:42:47 +0200 > Alexander Gerasiov пишет: > > > > Пароль можно добавить, но в моей модели угроз он не нужен. Для меня > > secureboot это гарантия, что на моем хосте нельзя забутить другую ОС > > и/или подменить ядро/загрузчик получив физический доступ к > > ноутбуку. > > А можно подробнее про эту модель угроз? > > Что мы защищаем - данные на диске ноутбука или сам ноутбук как набор > вычислительных ресурсов? > > Каким временем располагает атакующий, получивший физический доступ к > ноутбуку, и какие средства обнаружения такого доступа предусмотрены? Сейчас речь не совсем про то, что у меня (security through obscurity на самом деле очень важная и нужная вещь), но некоторые рассуждения, которыми я руководствовался: - данные на ноутбуке являются чувствительными - на случай утери ноутбука данные должны быть зашифрованы - предположим есть "добрый" злоумышленник, желающий получить доступ к данным на ноутбуке (про злого с паяльником отдельный тред), тогда у него есть два основных вектора атаки: 1. взлом работающего ноутбука по сети и т.п. тут цифровая гигиена, всякие файрволы, контейнеры и прочее, о чем сейчас не говорим. 2. физический доступ к ноутбуку. (от 5 минут в кафе пописать, до пары часов в офисе пообедать, варианты бывают разные) В случае физического доступа получить доступ к данным не получится (так как они зашифрованы), но можно залить модифицированный загрузчик/ядро/инитрамфс, так как что-то из этого должно лежать на диске не зашифрованное. От подмены этих файлов защищает secureboot с кастомными ключами. Следующий шаг - сбросить биос, подменить материнку или ноутбук целиком. Это все не является нереализуемым, но усложняет атаку. Плюс есть разумные способы это усложнить (enterprise ноутбуки, которые не сбрасываются просто так, tamper detection, наклейки с героями аниме, уникальная гравировка, памятная царапина в форме любимой буквы армянского алфавита и т.п.). Где-то в этом месте здравый смысл должен сказать, что гаечный ключ будет дешевле и можно успокоиться. -- Best regards, Alexander Gerasiov Contacts: e-mail: a...@gerasiov.net WWW: https://gerasiov.net TG/Skype: gerasiov PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1
Re: Как правильно подписывать пропиетарный драйвер nvidia для secureboot?
В Wed, 1 Feb 2023 14:11:17 -0500 Tim Sattarov пишет: . > Чем сложнее получить доступ к данным, тем безопаснее. Совершенно не факт, что защищать надо именно данные. Сейчас на большинстве компьютеров достойных защиты данных нет. Есть только выкачанная из сети информация, которую воровать нет смысла. Можно честно скачать оттуда же, откуда ее взял владелец компьютера. И тогда объектом защиты является сам компьютер, его вычислительные ресурсы, и цель - не дать его превратить в элемент ботнета для DDoS или майнер биткойнов (в интересах, естественно, отнюдь не того, кто оплачивает счета за электроэнергию). > SecureBoot усложняет доступ злоумышленникам. И то что нам не > нравится, это то, что это усложнение недостаточно сложно. SecureBoot похож на стоящий посреди чистого поля (ну ладно, густого леса) КПП, вокруг которого нет никакого забора. Кому не лень, может сойти с дороги и спокойно его обойти. Если мы ведем речь о сетевых атаках, то скорее объектом атаки будут userspace программы, которые secureboot вообще не защищает. Если об атаках с физическим доступом, то против отвертки и паяльника чисто программные средства мало чего могут сделать. Поэтому и интересна модель угроз Александра Герасиова, который тут упомянул что защищает свой ноутбук именно от физического доступа, но пока не расписал, при каких ограничениях. Точнее, на какие варианты физических угроз он готов тратить свое время и деньги, а какие лучше не рассматривать. > > Мы можем рассуждать и ругать существующую ситуацию, или можем прийти > к какому нибудь выводу, схеме, решению, которое может быть лучше, чем > то что есть в данный момент. И начать пинать мейнтейнеров. Начинать надо с себя. Безопасность она как фитнес. В какой бы дорогой тренажерный зал ты ни ходил, каких бы продвинутых тренеров ни нанимал, если сам не будешь впахивать до седьмого пота, мышц не накачаешь. Так и с безопасностью. Тут первое с чем надо определиться - а кто у нас решает, кому можно доверять и в чём - мейнтейнер dkms, фирма микрософт, производитель железа или все-таки владелец компьютера? Пока ответ на этот вопрос "какая-то коммерческая фирма непонятно в какой стране", понятно чья безопасность будет обеспечиваться и кто будет считаться потенциальным злоумышленником. -- Victor Wagner
Re: Как правильно подписывать пропиетарный драйвер nvidia для secureboot?
On 2/1/23 13:52, Victor Wagner wrote: А DKMS это вообще паллиатив. Если мы используем DKMS, значит мы хотим использовать какие-то лиценизонно не совместимые с мейнлайн-ядром модули. Потому что если бы они были совместимы, был бы готовый пакет. То есть по хорошему счету, используя DKMS мы сразу говорим "мы тут доверяем какому-то левому коду исполняться в контексте ядра" DKMS как система сборки тут ни при чём. Это никак не отменяет наличия общественно доступных ключей, которым доверяет BIOS. Даже если я не использую DKMS, злоумышленник сможет подсунуть мне подписанный драйвер, собранный у него на компьютере и подписанный тем самым публичным ключом. Или я что то не понимаю в системе подписи и доверия? Да, это конечно иногда наименьшее зло. Но, возможно что авторы DKMS именно так и рассудили, что снявши голову по волосам не плачут, и если мы используем dkms-модули вместе с secureboot, secureboot нам нужен не для безопасности, а для чего-то ещё (чтобы там TPM работал или чтобы какие-нибудь сертифицирующие органы отвязались). Как говорил один мой знакомый безопасник: Безопасность это не конечная точка, это процесс и больше градация, чем "да" или "нет". Чем сложнее получить доступ к данным, тем безопаснее. SecureBoot усложняет доступ злоумышленникам. И то что нам не нравится, это то, что это усложнение недостаточно сложно. Мы можем рассуждать и ругать существующую ситуацию, или можем прийти к какому нибудь выводу, схеме, решению, которое может быть лучше, чем то что есть в данный момент. И начать пинать мейнтейнеров. -- Тимур
Re: Как правильно подписывать пропиетарный драйвер nvidia для secureboot?
В Wed, 1 Feb 2023 10:48:47 -0500 Tim Sattarov пишет: > 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 > секретному ключу. Но всё то что делает DKMS эту защиту опускает до > своего уровня - права доступа к директории с модулями. А DKMS это вообще паллиатив. Если мы используем DKMS, значит мы хотим использовать какие-то лиценизонно не совместимые с мейнлайн-ядром модули. Потому что если бы они были совместимы, был бы готовый пакет. То есть по хорошему счету, используя DKMS мы сразу говорим "мы тут доверяем какому-то левому коду исполняться в контексте ядра" Да, это конечно иногда наименьшее зло. Но, возможно что авторы DKMS именно так и рассудили, что снявши голову по волосам не плачут, и если мы используем dkms-модули вместе с secureboot, secureboot нам нужен не для безопасности, а для чего-то ещё (чтобы там TPM работал или чтобы какие-нибудь сертифицирующие органы отвязались). -- Victor Wagner
Re: Как правильно подписывать пропиетарный драйвер nvidia для secureboot?
On 2/1/23 10:19, Victor Wagner wrote: В Wed, 1 Feb 2023 10:11:15 -0500 Tim Sattarov пишет: Если думаешь, что можно как то лучше и безопаснее - предлагай. Я понимаю, что обличать и открывать глаза иногда полезно. Но ключевое слово здесь "иногда". По моим представлениям нужно: 1. Выстраивать непрерывную цепочку доверия от BIOS до конкретных исполняемых модулей. Да, и скриптовых тоже, да, и разделяемых библиотек тоже. То есть bsign это хорошо, но нужен еще scriptsign. 2. Проверка на подпись скриптов должна быть встроена в интерпретатор, чтобы никакими средствами языка (. в shell, require в perl и т.д.) нельзя было ее обойти. 3. По возможности физически разделять машины где ведется разработка (и где подписываются исполняемые модули) и те, где защита секьюрбутом применяется в боевом режиме в качестве защиты от реальных атак. Потому что непонятно как совместить подпись каждого исполняемого файла в системе с разработкой программ, а особенно скриптов-однострочников у которых PKCS7-структура подписи будет больше места, чем содержательный код занимать. Вот это уже интересно. А процесс защиты ограничен именно этими алгоритмами? Если ограничиться только secure boot и интерфейсом с BIOS/UEFI. Как бы выглядела идеальная защита там? Maksim Dmitrichenko выше недоволен отсутствием ввода секрета во время подписи драйверов, что делает процесс больше фикцией, Так как секреты (ключи подписи) находятся там же где и сами артифакты для подписи. И ничего их не защищает. Мало того, эти ключи находятся в публичном доступе, что не ограничивает злоумышленников от использования этих публично доступных ключей для своих целей. Как здесь быть? Получается, что вся защита только в получении рута на машине. Модули скачанные с сайта debian подписаны майнтейнером. Там более менее можно ограничить доступ к секретному ключу. Но всё то что делает DKMS эту защиту опускает до своего уровня - права доступа к директории с модулями.
Re: Как правильно подписывать пропиетарный драйвер nvidia для secureboot?
В Wed, 1 Feb 2023 16:42:47 +0200 Alexander Gerasiov пишет: > Пароль можно добавить, но в моей модели угроз он не нужен. Для меня > secureboot это гарантия, что на моем хосте нельзя забутить другую ОС > и/или подменить ядро/загрузчик получив физический доступ к ноутбуку. А можно подробнее про эту модель угроз? Что мы защищаем - данные на диске ноутбука или сам ноутбук как набор вычислительных ресурсов? Каким временем располагает атакующий, получивший физический доступ к ноутбуку, и какие средства обнаружения такого доступа предусмотрены? -- Victor Wagner
Re: Как правильно подписывать пропиетарный драйвер nvidia для secureboot?
В Wed, 1 Feb 2023 10:11:15 -0500 Tim Sattarov пишет: > Если думаешь, что можно как то лучше и безопаснее - предлагай. Я > понимаю, что обличать и открывать глаза иногда полезно. Но ключевое > слово здесь "иногда". По моим представлениям нужно: 1. Выстраивать непрерывную цепочку доверия от BIOS до конкретных исполняемых модулей. Да, и скриптовых тоже, да, и разделяемых библиотек тоже. То есть bsign это хорошо, но нужен еще scriptsign. 2. Проверка на подпись скриптов должна быть встроена в интерпретатор, чтобы никакими средствами языка (. в shell, require в perl и т.д.) нельзя было ее обойти. 3. По возможности физически разделять машины где ведется разработка (и где подписываются исполняемые модули) и те, где защита секьюрбутом применяется в боевом режиме в качестве защиты от реальных атак. Потому что непонятно как совместить подпись каждого исполняемого файла в системе с разработкой программ, а особенно скриптов-однострочников у которых PKCS7-структура подписи будет больше места, чем содержательный код занимать. -- Victor Wagner
Re: Как правильно подписывать пропиетарный драйвер nvidia для secureboot?
В Wed, 1 Feb 2023 18:28:53 +0400 Maksim Dmitrichenko пишет: > вт, 31 янв. 2023 г. в 18:43, Tim Sattarov : > > > Тут встаёт вопрос а зачем вообще нужен Secure Boot. > > > > В моём случае когда то давно, когда я ставил дуал бут на лаптопе, > > 11-я винда очень хотела его и нельзя было иметь secure boot только > > для одной операционки. > > > > Неужель на винде нельзя отлючить SecureBoot? Вроде можно. > > Винде он нужен, чтобы нельзя было её активировать мимо кассы, > естественно. Линуксу, для того, чтобы руткитов избежать по максимуму. > Но если можно даже пускай с рутовыми правами, но без ввода пароля, > подписать любой модуль в бэкграунде, то увы, это говно. > В PKI и цепочки доверия в мире не умеет примерно никто ни в OpenSource ни в проприетарщине. Даже bsign из большинства дистрибутивов повыкидывали. Я его только в Astre имени различных российских городов видел. (в смысле во всех Special Edition, их у них там много). -- Victor Wagner
Re: Как правильно подписывать пропиетарный драйвер nvidia для secureboot?
On 2/1/23 09:28, Maksim Dmitrichenko wrote: вт, 31 янв. 2023 г. в 18:43, Tim Sattarov : Тут встаёт вопрос а зачем вообще нужен Secure Boot. В моём случае когда то давно, когда я ставил дуал бут на лаптопе, 11-я винда очень хотела его и нельзя было иметь secure boot только для одной операционки. Неужель на винде нельзя отлючить SecureBoot? Вроде можно. Можно, но удобнее с ним. тот же TPM не включится без Secure Boot. Винде он нужен, чтобы нельзя было её активировать мимо кассы, естественно. Линуксу, для того, чтобы руткитов избежать по максимуму. Но если можно даже пускай с рутовыми правами, но без ввода пароля, подписать любой модуль в бэкграунде, то увы, это говно. Как ты уже заметил, в Линуксе это больше фикция и набор ритуалов, если кто то получит доступ к системе и подпишет новые драйвера, то всё доверие на помойку. Если думаешь, что можно как то лучше и безопаснее - предлагай. Я понимаю, что обличать и открывать глаза иногда полезно. Но ключевое слово здесь "иногда". -- Тимур
Re: Как правильно подписывать пропиетарный драйвер nvidia для secureboot?
On Wed, 1 Feb 2023 17:34:22 +0400 Maksim Dmitrichenko wrote: > ср, 1 февр. 2023 г. в 16:40, Alexander Gerasiov : > > > /lib/modules/"$1"/build/scripts/sign-file sha512 > > /etc/sicherboot/keys/db.key /etc/sicherboot/keys/db.cer "$2" > > > > Штрилитц ещё никогда не был так близок к провалу ) > > Для не знающих немецкий, "sicher" - по-немецки "безопасный" в смысле > "secure" ) > > А кто и в какой момент тебе эти ключи создал? И была ли возможность > задать пароли при генерации? > Потому что предыдущий оратор вроде как даже не заметил, как это всё > произошло. Ты не поверишь, их создал sicherboot. Пароль можно добавить, но в моей модели угроз он не нужен. Для меня secureboot это гарантия, что на моем хосте нельзя забутить другую ОС и/или подменить ядро/загрузчик получив физический доступ к ноутбуку. -- Best regards, Alexander Gerasiov Contacts: e-mail: a...@gerasiov.net WWW: https://gerasiov.net TG/Skype: gerasiov PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1
Re: Как правильно подписывать пропиетарный драйвер nvidia для secureboot?
вт, 31 янв. 2023 г. в 18:43, Tim Sattarov : > Тут встаёт вопрос а зачем вообще нужен Secure Boot. > > В моём случае когда то давно, когда я ставил дуал бут на лаптопе, 11-я > винда очень хотела его и нельзя было иметь secure boot только для одной > операционки. > Неужель на винде нельзя отлючить SecureBoot? Вроде можно. Винде он нужен, чтобы нельзя было её активировать мимо кассы, естественно. Линуксу, для того, чтобы руткитов избежать по максимуму. Но если можно даже пускай с рутовыми правами, но без ввода пароля, подписать любой модуль в бэкграунде, то увы, это говно. -- With best regards Maksim Dmitrichenko
Re: Как правильно подписывать пропиетарный драйвер nvidia для secureboot?
ср, 1 февр. 2023 г. в 16:40, Alexander Gerasiov : > /lib/modules/"$1"/build/scripts/sign-file sha512 > /etc/sicherboot/keys/db.key /etc/sicherboot/keys/db.cer "$2" > Штрилитц ещё никогда не был так близок к провалу ) Для не знающих немецкий, "sicher" - по-немецки "безопасный" в смысле "secure" ) А кто и в какой момент тебе эти ключи создал? И была ли возможность задать пароли при генерации? Потому что предыдущий оратор вроде как даже не заметил, как это всё произошло. -- With best regards Maksim Dmitrichenko
Re: Как правильно подписывать пропиетарный драйвер nvidia для secureboot?
On Mon, 30 Jan 2023 20:47:11 +0300 Зиганшин Руслан wrote: > Следуя инструкции на https://wiki.debian.org/SecureBoot, я натыкаюсь > на проблему: > > $ cd "$MODULES_DIR/updates/dkms" > bash: cd: /lib/modules/6.0.0-0.deb11.6-amd64/updates/dkms: Нет такого > файла или каталога [gq@fran:/etc]$ cat /etc/dkms/framework.conf ## This configuration file modifies the behavior of ## DKMS (Dynamic Kernel Module Support) and is sourced ## in by DKMS every time it is run. ## Source Tree Location (default: /usr/src) # source_tree="/usr/src" ## DKMS Tree Location (default: /var/lib/dkms) # dkms_tree="/var/lib/dkms" ## Install Tree Location (default: /lib/modules) # install_tree="/lib/modules" ## tmp Location (default: /tmp) # tmp_location="/tmp" ## verbosity setting (verbose will be active if you set it to a non-null value) # verbose="" ## symlink kernel modules (will be active if you set it to a non-null value) ## This creates symlinks from the install_tree into the dkms_tree instead of ## copying the modules. This preserves some space on the costs of being less ## safe. # symlink_modules="" ## Automatic installation and upgrade for all installed kernels (if set to a ## non-null value) # autoinstall_all_kernels="" ## Script to sign modules during build, script is called with kernel version ## and module name sign_tool="/etc/dkms/sign_helper.sh" [gq@fran:/etc]$ cat /etc/dkms/sign_helper.sh #!/bin/sh /lib/modules/"$1"/build/scripts/sign-file sha512 /etc/sicherboot/keys/db.key /etc/sicherboot/keys/db.cer "$2" -- Best regards, Alexander Gerasiov Contacts: e-mail: a...@gerasiov.net WWW: https://gerasiov.net TG/Skype: gerasiov PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1
