Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Как правильно подписывать пропиетарный драйвер nvidia для secureboot?
51 views
Skip to first unread message
Зиганшин Руслан
Jan 30, 2023, 12:50:04 PM1/30/23
to
Следуя инструкции на https://wiki.debian.org/SecureBoot, я натыкаюсь на проблему:
$ cd "$MODULES_DIR/updates/dkms"
bash: cd: /lib/modules/6.0.0-0.deb11.6-amd64/updates/dkms: Нет такого файла или каталога
bash: cd: /lib/modules/6.0.0-0.deb11.6-amd64/updates/dkms: Нет такого файла или каталога
Tim Sattarov
Jan 30, 2023, 1:20:05 PM1/30/23
to
А откуда установлены драйвера сейчас? Этот путь есть только там, где
есть dkms дрова...
```
$ ls -l $MODULES_DIR/updates/dkms/nvidia-current*
-rw-r--r-- 1 root root 150373 Jan 27 09:15 /lib/modules/6.1.0-1-amd64/updates/dkms/nvidia-current-drm.ko
-rw-r--r-- 1 root root 46155045 Jan 27 09:15 /lib/modules/6.1.0-1-amd64/updates/dkms/nvidia-current.ko
-rw-r--r-- 1 root root 1554549 Jan 27 09:15 /lib/modules/6.1.0-1-amd64/updates/dkms/nvidia-current-modeset.ko
-rw-r--r-- 1 root root 7101 Jan 27 09:15 /lib/modules/6.1.0-1-amd64/updates/dkms/nvidia-current-peermem.ko
-rw-r--r-- 1 root root 2321037 Jan 27 09:15 /lib/modules/6.1.0-1-amd64/updates/dkms/nvidia-current-uvm.ko
```
```
$ ls -l $MODULES_DIR/updates/dkms/nvidia-current*
-rw-r--r-- 1 root root 150373 Jan 27 09:15 /lib/modules/6.1.0-1-amd64/updates/dkms/nvidia-current-drm.ko
-rw-r--r-- 1 root root 46155045 Jan 27 09:15 /lib/modules/6.1.0-1-amd64/updates/dkms/nvidia-current.ko
-rw-r--r-- 1 root root 1554549 Jan 27 09:15 /lib/modules/6.1.0-1-amd64/updates/dkms/nvidia-current-modeset.ko
-rw-r--r-- 1 root root 7101 Jan 27 09:15 /lib/modules/6.1.0-1-amd64/updates/dkms/nvidia-current-peermem.ko
-rw-r--r-- 1 root root 2321037 Jan 27 09:15 /lib/modules/6.1.0-1-amd64/updates/dkms/nvidia-current-uvm.ko
```
Tim Sattarov
Jan 30, 2023, 3:20:03 PM1/30/23
to
On 1/30/23 14:29, Зиганшин Руслан wrote:
> Сейчас драйвера временно удалены, но вообще они были установлены командой sudo apt install
> nvidia-driver.
>
> P.S. Сейчас подумал, что, возможно, помешало то, что первоначально драйвера устанавливал от
> bullseye, а ядро от bullseye-updates. Если дело в этом, то предстоит также выяснить, как
> установить приоритет драйверов для updates, поскольку там, как ни странно, более старая версия,
> чем в bullseye.
>
По ссылке указанной ранее:
> cd "$MODULES_DIR/updates/dkms" # For dkms packages
То есть ожидается что установлен nvidia-kernel-dkms который кладёт драйвер в эту папку.
Как можно подписывать что-то, если оно не установлено?
> Сейчас драйвера временно удалены, но вообще они были установлены командой sudo apt install
> nvidia-driver.
>
> P.S. Сейчас подумал, что, возможно, помешало то, что первоначально драйвера устанавливал от
> bullseye, а ядро от bullseye-updates. Если дело в этом, то предстоит также выяснить, как
> установить приоритет драйверов для updates, поскольку там, как ни странно, более старая версия,
> чем в bullseye.
>
По ссылке указанной ранее:
> cd "$MODULES_DIR/updates/dkms" # For dkms packages
То есть ожидается что установлен nvidia-kernel-dkms который кладёт драйвер в эту папку.
Как можно подписывать что-то, если оно не установлено?
Andrey Jr. Melnikov
Jan 30, 2023, 5:30:04 PM1/30/23
to
Зиганшин Руслан <zigansh...@gmail.com> wrote:
> [-- text/plain, encoding base64, charset: UTF-8, 5 lines --]
А можно поинтересоваться - зачем? Если кто-то получил физический доступ к
машине, он свой shim принесёт, подписанный тем-же микрософтом и загрузится.
Удалишь ключи от M$ (ну если сможешь конечно) - поимеешь незапускаемый
видео-биос и отсутствие видеокарты. Или у тебя есть coreboot для своей платы?
> $ cd "$MODULES_DIR/updates/dkms"
> bash: cd: /lib/modules/6.0.0-0.deb11.6-amd64/updates/dkms: Нет такого файла
> или каталога
Дык, это задача dkms подписывать автоматически собранные модуля. Там правда
как всегда за последние пол года всё сломали три раза, но вроде последние
релизы dkms умеют отличать unsigned модули от signed и не падать после
сборки (подписывать при наличии ключей если это действительно требуется).
> [-- text/plain, encoding base64, charset: UTF-8, 5 lines --]
А можно поинтересоваться - зачем? Если кто-то получил физический доступ к
машине, он свой shim принесёт, подписанный тем-же микрософтом и загрузится.
Удалишь ключи от M$ (ну если сможешь конечно) - поимеешь незапускаемый
видео-биос и отсутствие видеокарты. Или у тебя есть coreboot для своей платы?
> $ cd "$MODULES_DIR/updates/dkms"
> bash: cd: /lib/modules/6.0.0-0.deb11.6-amd64/updates/dkms: Нет такого файла
> или каталога
как всегда за последние пол года всё сломали три раза, но вроде последние
релизы dkms умеют отличать unsigned модули от signed и не падать после
сборки (подписывать при наличии ключей если это действительно требуется).
Tim Sattarov
Jan 30, 2023, 7:40:04 PM1/30/23
to
On 1/30/23 17:09, Andrey Jr. Melnikov wrote:
>
> Дык, это задача dkms подписывать автоматически собранные модуля. Там правда
> как всегда за последние пол года всё сломали три раза, но вроде последние
> релизы dkms умеют отличать unsigned модули от signed и не падать после
> сборки (подписывать при наличии ключей если это действительно требуется).
>
И вправду, только вот проапдейтил одну машину с nvidia и там лог выглядит вот так:
>
> Дык, это задача dkms подписывать автоматически собранные модуля. Там правда
> как всегда за последние пол года всё сломали три раза, но вроде последние
> релизы dkms умеют отличать unsigned модули от signed и не падать после
> сборки (подписывать при наличии ключей если это действительно требуется).
>
```
Building module:
Cleaning build area...
env NV_VERBOSE=1 make -j8 modules KERNEL_UNAME=6.1.0-2-amd64....................
Signing module /var/lib/dkms/nvidia-current/510.108.03/build/nvidia.ko
Signing module /var/lib/dkms/nvidia-current/510.108.03/build/nvidia-modeset.ko
Signing module /var/lib/dkms/nvidia-current/510.108.03/build/nvidia-drm.ko
Signing module /var/lib/dkms/nvidia-current/510.108.03/build/nvidia-uvm.ko
Signing module /var/lib/dkms/nvidia-current/510.108.03/build/nvidia-peermem.ko
```
Maksim Dmitrichenko
Jan 31, 2023, 9:43:19 AM1/31/23
to
вт, 31 янв. 2023 г. в 04:31, Tim Sattarov <sti...@gmail.com>:
```
Building module:
Cleaning build area...
env NV_VERBOSE=1 make -j8 modules KERNEL_UNAME=6.1.0-2-amd64....................
Signing module /var/lib/dkms/nvidia-current/510.108.03/build/nvidia.ko
Signing module /var/lib/dkms/nvidia-current/510.108.03/build/nvidia-modeset.ko
Signing module /var/lib/dkms/nvidia-current/510.108.03/build/nvidia-drm.ko
Signing module /var/lib/dkms/nvidia-current/510.108.03/build/nvidia-uvm.ko
Signing module /var/lib/dkms/nvidia-current/510.108.03/build/nvidia-peermem.ko
```
Судя по твоему удивлению, ни ключ создать, ни ввести от него пароль при подписании тебе не было предложено.
Прелестно. Как в том мультике про уборщицу в банковском хранилище... )
With best regards
Maksim Dmitrichenko
Maksim Dmitrichenko
Tim Sattarov
Jan 31, 2023, 9:50:04 AM1/31/23
to
Ты прав, ничего вводить не пришлось, всё само. Автоматически. Даже
без моего ведома.
Я думаю в остальных операционках (винда, мак) та же ситуация и драйвера не подписываются юзером осознанно.
Но они и не компилируются (и не подписываются) на пользовательской машине.
Тут встаёт вопрос а зачем вообще нужен Secure Boot.
В моём случае когда то давно, когда я ставил дуал бут на лаптопе, 11-я винда очень хотела его и нельзя было иметь secure boot только для одной операционки.
Я думаю в остальных операционках (винда, мак) та же ситуация и драйвера не подписываются юзером осознанно.
Но они и не компилируются (и не подписываются) на пользовательской машине.
Тут встаёт вопрос а зачем вообще нужен Secure Boot.
В моём случае когда то давно, когда я ставил дуал бут на лаптопе, 11-я винда очень хотела его и нельзя было иметь secure boot только для одной операционки.
Alexander Gerasiov
Feb 1, 2023, 7:50:03 AM2/1/23
to
## 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
Maksim Dmitrichenko
Feb 1, 2023, 8:40:03 AM2/1/23
to
ср, 1 февр. 2023 г. в 16:40, Alexander Gerasiov <a...@gerasiov.net>:
/lib/modules/"$1"/build/scripts/sign-file sha512 /etc/sicherboot/keys/db.key /etc/sicherboot/keys/db.cer "$2"
Штрилитц ещё никогда не был так близок к провалу )
Для не знающих немецкий, "sicher" - по-немецки "безопасный" в смысле "secure" )
А кто и в какой момент тебе эти ключи создал? И была ли возможность задать пароли при генерации?
Потому что предыдущий оратор вроде как даже не заметил, как это всё произошло.
Maksim Dmitrichenko
Feb 1, 2023, 9:32:03 AM2/1/23
to
вт, 31 янв. 2023 г. в 18:43, Tim Sattarov <sti...@gmail.com>:
Тут встаёт вопрос а зачем вообще нужен Secure Boot.
В моём случае когда то давно, когда я ставил дуал бут на лаптопе, 11-я винда очень хотела его и нельзя было иметь secure boot только для одной операционки.
Неужель на винде нельзя отлючить SecureBoot? Вроде можно.
Винде он нужен, чтобы нельзя было её активировать мимо кассы, естественно. Линуксу, для того, чтобы руткитов избежать по максимуму. Но если можно даже пускай с рутовыми правами, но без ввода пароля, подписать любой модуль в бэкграунде, то увы, это говно.
Винде он нужен, чтобы нельзя было её активировать мимо кассы, естественно. Линуксу, для того, чтобы руткитов избежать по максимуму. Но если можно даже пускай с рутовыми правами, но без ввода пароля, подписать любой модуль в бэкграунде, то увы, это говно.
Alexander Gerasiov
Feb 1, 2023, 9:50:03 AM2/1/23
to
Пароль можно добавить, но в моей модели угроз он не нужен. Для меня
secureboot это гарантия, что на моем хосте нельзя забутить другую ОС
и/или подменить ядро/загрузчик получив физический доступ к ноутбуку.
Tim Sattarov
Feb 1, 2023, 10:20:03 AM2/1/23
to
On 2/1/23 09:28, Maksim Dmitrichenko wrote:
вт, 31 янв. 2023 г. в 18:43, Tim Sattarov <sti...@gmail.com>:Тут встаёт вопрос а зачем вообще нужен Secure Boot.
В моём случае когда то давно, когда я ставил дуал бут на лаптопе, 11-я винда очень хотела его и нельзя было иметь secure boot только для одной операционки.
Неужель на винде нельзя отлючить SecureBoot? Вроде можно.
Можно, но удобнее с ним. тот же TPM не включится без Secure Boot.
Винде он нужен, чтобы нельзя было её активировать мимо кассы, естественно. Линуксу, для того, чтобы руткитов избежать по максимуму. Но если можно даже пускай с рутовыми правами, но без ввода пароля, подписать любой модуль в бэкграунде, то увы, это говно.
Как ты уже заметил, в Линуксе это больше фикция и набор ритуалов,
если кто то получит доступ к системе и подпишет новые драйвера, то
всё доверие на помойку.
Если думаешь, что можно как то лучше и безопаснее - предлагай. Я понимаю, что обличать и открывать глаза иногда полезно. Но ключевое слово здесь "иногда".
--
Тимур
Если думаешь, что можно как то лучше и безопаснее - предлагай. Я понимаю, что обличать и открывать глаза иногда полезно. Но ключевое слово здесь "иногда".
--
Тимур
Victor Wagner
Feb 1, 2023, 10:20:03 AM2/1/23
to
В Wed, 1 Feb 2023 18:28:53 +0400
Maksim Dmitrichenko <dmit...@gmail.com> пишет:
В PKI и цепочки доверия в мире не умеет примерно никто ни в OpenSource
ни в проприетарщине. Даже bsign из большинства дистрибутивов
повыкидывали. Я его только в Astre имени различных российских городов
видел. (в смысле во всех Special Edition, их у них там много).
--
Victor Wagner <vi...@wagner.pp.ru>
Maksim Dmitrichenko <dmit...@gmail.com> пишет:
ни в проприетарщине. Даже bsign из большинства дистрибутивов
повыкидывали. Я его только в Astre имени различных российских городов
видел. (в смысле во всех Special Edition, их у них там много).
--
Victor Wagner <vi...@wagner.pp.ru>
Victor Wagner
Feb 1, 2023, 10:30:04 AM2/1/23
to
В Wed, 1 Feb 2023 16:42:47 +0200
Alexander Gerasiov <a...@gerasiov.net> пишет:
> Пароль можно добавить, но в моей модели угроз он не нужен. Для меня
> secureboot это гарантия, что на моем хосте нельзя забутить другую ОС
> и/или подменить ядро/загрузчик получив физический доступ к ноутбуку.
А можно подробнее про эту модель угроз?
Что мы защищаем - данные на диске ноутбука или сам ноутбук как набор
вычислительных ресурсов?
Каким временем располагает атакующий, получивший физический доступ к
ноутбуку, и какие средства обнаружения такого доступа предусмотрены?
--
Victor Wagner <vi...@wagner.pp.ru>
Alexander Gerasiov <a...@gerasiov.net> пишет:
> Пароль можно добавить, но в моей модели угроз он не нужен. Для меня
> secureboot это гарантия, что на моем хосте нельзя забутить другую ОС
> и/или подменить ядро/загрузчик получив физический доступ к ноутбуку.
Что мы защищаем - данные на диске ноутбука или сам ноутбук как набор
вычислительных ресурсов?
Каким временем располагает атакующий, получивший физический доступ к
ноутбуку, и какие средства обнаружения такого доступа предусмотрены?
--
Victor Wagner <vi...@wagner.pp.ru>
Victor Wagner
Feb 1, 2023, 10:30:04 AM2/1/23
to
В Wed, 1 Feb 2023 10:11:15 -0500
Tim Sattarov <sti...@gmail.com> пишет:
> Если думаешь, что можно как то лучше и безопаснее - предлагай. Я
> понимаю, что обличать и открывать глаза иногда полезно. Но ключевое
> слово здесь "иногда".
По моим представлениям нужно:
1. Выстраивать непрерывную цепочку доверия от BIOS до конкретных
исполняемых модулей. Да, и скриптовых тоже, да, и разделяемых библиотек
тоже. То есть bsign это хорошо, но нужен еще scriptsign.
2. Проверка на подпись скриптов должна быть встроена в интерпретатор,
чтобы никакими средствами языка (. в shell, require в perl и т.д.)
нельзя было ее обойти.
3. По возможности физически разделять машины где ведется разработка (и
где подписываются исполняемые модули) и те, где защита секьюрбутом
применяется в боевом режиме в качестве защиты от реальных атак. Потому
что непонятно как совместить подпись каждого исполняемого файла в
системе с разработкой программ, а особенно скриптов-однострочников у
которых PKCS7-структура подписи будет больше места, чем содержательный
код занимать.
--
Victor Wagner <vi...@wagner.pp.ru>
Tim Sattarov <sti...@gmail.com> пишет:
> Если думаешь, что можно как то лучше и безопаснее - предлагай. Я
> понимаю, что обличать и открывать глаза иногда полезно. Но ключевое
> слово здесь "иногда".
1. Выстраивать непрерывную цепочку доверия от BIOS до конкретных
исполняемых модулей. Да, и скриптовых тоже, да, и разделяемых библиотек
тоже. То есть bsign это хорошо, но нужен еще scriptsign.
2. Проверка на подпись скриптов должна быть встроена в интерпретатор,
чтобы никакими средствами языка (. в shell, require в perl и т.д.)
нельзя было ее обойти.
3. По возможности физически разделять машины где ведется разработка (и
где подписываются исполняемые модули) и те, где защита секьюрбутом
применяется в боевом режиме в качестве защиты от реальных атак. Потому
что непонятно как совместить подпись каждого исполняемого файла в
системе с разработкой программ, а особенно скриптов-однострочников у
которых PKCS7-структура подписи будет больше места, чем содержательный
код занимать.
--
Victor Wagner <vi...@wagner.pp.ru>
Tim Sattarov
Feb 1, 2023, 10:50:04 AM2/1/23
to
Если ограничиться только secure boot и интерфейсом с BIOS/UEFI.
Как бы выглядела идеальная защита там?
Maksim Dmitrichenko выше недоволен отсутствием ввода секрета во время подписи драйверов, что делает
процесс больше фикцией,
Так как секреты (ключи подписи) находятся там же где и сами артифакты для подписи. И ничего их не
защищает.
Мало того, эти ключи находятся в публичном доступе, что не ограничивает злоумышленников от
использования этих публично доступных ключей для своих целей.
Как здесь быть? Получается, что вся защита только в получении рута на машине.
Модули скачанные с сайта debian подписаны майнтейнером. Там более менее можно ограничить доступ к
секретному ключу.
Но всё то что делает DKMS эту защиту опускает до своего уровня - права доступа к директории с модулями.
Victor Wagner
Feb 1, 2023, 2:00:05 PM2/1/23
to
В Wed, 1 Feb 2023 10:48:47 -0500
> только в получении рута на машине. Модули скачанные с сайта debian
> подписаны майнтейнером. Там более менее можно ограничить доступ к
Можно-то можно, но делается ли? Конечно если утечет ключ дебановского
мейнтейнера, скорее всего шуму будет на весть интернет. Как я уже писал
в соседнем письме, в наше время правильно использовать подобные защиты
не умеет почти никто. Даже в этом треде термин "модель угроз" употребил
только Alexander Gerasiov <a...@gerasiov.net>
> секретному ключу. Но всё то что делает DKMS эту защиту опускает до
> своего уровня - права доступа к директории с модулями.
А DKMS это вообще паллиатив. Если мы используем DKMS, значит мы хотим
использовать какие-то лиценизонно не совместимые с мейнлайн-ядром
модули. Потому что если бы они были совместимы, был бы готовый пакет.
То есть по хорошему счету, используя DKMS мы сразу говорим "мы тут
доверяем какому-то левому коду исполняться в контексте ядра"
Да, это конечно иногда наименьшее зло. Но, возможно что авторы DKMS
именно так и рассудили, что снявши голову по волосам не плачут, и если
мы используем dkms-модули вместе с secureboot, secureboot нам нужен не
для безопасности, а для чего-то ещё (чтобы там TPM работал или чтобы
какие-нибудь сертифицирующие органы отвязались).
--
Victor Wagner <vi...@wagner.pp.ru>
Tim Sattarov <sti...@gmail.com> пишет:
> On 2/1/23 10:19, Victor Wagner wrote:
> > В Wed, 1 Feb 2023 10:11:15 -0500
> On 2/1/23 10:19, Victor Wagner wrote:
> > В Wed, 1 Feb 2023 10:11:15 -0500
> Вот это уже интересно. А процесс защиты ограничен именно этими
> алгоритмами? Если ограничиться только secure boot и интерфейсом с
> BIOS/UEFI. Как бы выглядела идеальная защита там?
>
> Maksim Dmitrichenko выше недоволен отсутствием ввода секрета во время
> подписи драйверов, что делает процесс больше фикцией,
> Так как секреты (ключи подписи) находятся там же где и сами артифакты
> для подписи. И ничего их не защищает.
И это вполне законная претензия
> алгоритмами? Если ограничиться только secure boot и интерфейсом с
> BIOS/UEFI. Как бы выглядела идеальная защита там?
>
> Maksim Dmitrichenko выше недоволен отсутствием ввода секрета во время
> подписи драйверов, что делает процесс больше фикцией,
> Так как секреты (ключи подписи) находятся там же где и сами артифакты
> для подписи. И ничего их не защищает.
> только в получении рута на машине. Модули скачанные с сайта debian
> подписаны майнтейнером. Там более менее можно ограничить доступ к
мейнтейнера, скорее всего шуму будет на весть интернет. Как я уже писал
в соседнем письме, в наше время правильно использовать подобные защиты
не умеет почти никто. Даже в этом треде термин "модель угроз" употребил
только Alexander Gerasiov <a...@gerasiov.net>
> секретному ключу. Но всё то что делает DKMS эту защиту опускает до
> своего уровня - права доступа к директории с модулями.
использовать какие-то лиценизонно не совместимые с мейнлайн-ядром
модули. Потому что если бы они были совместимы, был бы готовый пакет.
То есть по хорошему счету, используя DKMS мы сразу говорим "мы тут
доверяем какому-то левому коду исполняться в контексте ядра"
Да, это конечно иногда наименьшее зло. Но, возможно что авторы DKMS
именно так и рассудили, что снявши голову по волосам не плачут, и если
мы используем dkms-модули вместе с secureboot, secureboot нам нужен не
для безопасности, а для чего-то ещё (чтобы там TPM работал или чтобы
какие-нибудь сертифицирующие органы отвязались).
--
Victor Wagner <vi...@wagner.pp.ru>
Tim Sattarov
Feb 1, 2023, 2:20:03 PM2/1/23
to
On 2/1/23 13:52, Victor Wagner wrote:
>
> А DKMS это вообще паллиатив. Если мы используем DKMS, значит мы хотим
> использовать какие-то лиценизонно не совместимые с мейнлайн-ядром
> модули. Потому что если бы они были совместимы, был бы готовый пакет.
>
> То есть по хорошему счету, используя DKMS мы сразу говорим "мы тут
> доверяем какому-то левому коду исполняться в контексте ядра"
DKMS как система сборки тут ни при чём. Это никак не отменяет наличия общественно доступных ключей,
>
> А DKMS это вообще паллиатив. Если мы используем DKMS, значит мы хотим
> использовать какие-то лиценизонно не совместимые с мейнлайн-ядром
> модули. Потому что если бы они были совместимы, был бы готовый пакет.
>
> То есть по хорошему счету, используя DKMS мы сразу говорим "мы тут
> доверяем какому-то левому коду исполняться в контексте ядра"
которым доверяет BIOS.
Даже если я не использую DKMS, злоумышленник сможет подсунуть мне подписанный драйвер, собранный у
него на компьютере и подписанный тем самым публичным ключом.
Или я что то не понимаю в системе подписи и доверия?
> Да, это конечно иногда наименьшее зло. Но, возможно что авторы DKMS
> именно так и рассудили, что снявши голову по волосам не плачут, и если
> мы используем dkms-модули вместе с secureboot, secureboot нам нужен не
> для безопасности, а для чего-то ещё (чтобы там TPM работал или чтобы
> какие-нибудь сертифицирующие органы отвязались).
>
градация, чем "да" или "нет".
Чем сложнее получить доступ к данным, тем безопаснее.
SecureBoot усложняет доступ злоумышленникам. И то что нам не нравится, это то, что это усложнение
недостаточно сложно.
Мы можем рассуждать и ругать существующую ситуацию, или можем прийти к какому нибудь выводу, схеме,
решению, которое может быть лучше, чем то что есть в данный момент.
И начать пинать мейнтейнеров.
--
Тимур
Victor Wagner
Feb 1, 2023, 2:40:03 PM2/1/23
to
В Wed, 1 Feb 2023 14:11:17 -0500
Tim Sattarov <sti...@gmail.com> пишет:
.
> Чем сложнее получить доступ к данным, тем безопаснее.
Совершенно не факт, что защищать надо именно данные. Сейчас на
большинстве компьютеров достойных защиты данных нет. Есть только
выкачанная из сети информация, которую воровать нет смысла. Можно
честно скачать оттуда же, откуда ее взял владелец компьютера.
И тогда объектом защиты является сам компьютер, его вычислительные
ресурсы, и цель - не дать его превратить в элемент ботнета для DDoS или
майнер биткойнов (в интересах, естественно, отнюдь не того, кто
оплачивает счета за электроэнергию).
> SecureBoot усложняет доступ злоумышленникам. И то что нам не
> нравится, это то, что это усложнение недостаточно сложно.
SecureBoot похож на стоящий посреди чистого поля (ну ладно, густого
леса) КПП, вокруг которого нет никакого забора. Кому не лень, может
сойти с дороги и спокойно его обойти.
Если мы ведем речь о сетевых атаках, то скорее объектом атаки будут
userspace программы, которые secureboot вообще не защищает.
Если об атаках с физическим доступом, то против отвертки и паяльника
чисто программные средства мало чего могут сделать.
Поэтому и интересна модель угроз Александра Герасиова, который тут
упомянул что защищает свой ноутбук именно от физического доступа, но
пока не расписал, при каких ограничениях. Точнее, на какие варианты
физических угроз он готов тратить свое время и деньги, а какие лучше не
рассматривать.
>
> Мы можем рассуждать и ругать существующую ситуацию, или можем прийти
> к какому нибудь выводу, схеме, решению, которое может быть лучше, чем
> то что есть в данный момент. И начать пинать мейнтейнеров.
Начинать надо с себя. Безопасность она как фитнес. В какой бы дорогой
тренажерный зал ты ни ходил, каких бы продвинутых тренеров ни нанимал,
если сам не будешь впахивать до седьмого пота, мышц не накачаешь. Так и
с безопасностью.
Тут первое с чем надо определиться - а кто у нас решает, кому можно
доверять и в чём - мейнтейнер dkms, фирма микрософт, производитель
железа или все-таки владелец компьютера? Пока ответ на этот вопрос
"какая-то коммерческая фирма непонятно в какой стране", понятно чья
безопасность будет обеспечиваться и кто будет считаться потенциальным
злоумышленником.
--
Victor Wagner <vi...@wagner.pp.ru>
Tim Sattarov <sti...@gmail.com> пишет:
.
> Чем сложнее получить доступ к данным, тем безопаснее.
большинстве компьютеров достойных защиты данных нет. Есть только
выкачанная из сети информация, которую воровать нет смысла. Можно
честно скачать оттуда же, откуда ее взял владелец компьютера.
И тогда объектом защиты является сам компьютер, его вычислительные
ресурсы, и цель - не дать его превратить в элемент ботнета для DDoS или
майнер биткойнов (в интересах, естественно, отнюдь не того, кто
оплачивает счета за электроэнергию).
> SecureBoot усложняет доступ злоумышленникам. И то что нам не
> нравится, это то, что это усложнение недостаточно сложно.
леса) КПП, вокруг которого нет никакого забора. Кому не лень, может
сойти с дороги и спокойно его обойти.
Если мы ведем речь о сетевых атаках, то скорее объектом атаки будут
userspace программы, которые secureboot вообще не защищает.
Если об атаках с физическим доступом, то против отвертки и паяльника
чисто программные средства мало чего могут сделать.
Поэтому и интересна модель угроз Александра Герасиова, который тут
упомянул что защищает свой ноутбук именно от физического доступа, но
пока не расписал, при каких ограничениях. Точнее, на какие варианты
физических угроз он готов тратить свое время и деньги, а какие лучше не
рассматривать.
>
> Мы можем рассуждать и ругать существующую ситуацию, или можем прийти
> к какому нибудь выводу, схеме, решению, которое может быть лучше, чем
> то что есть в данный момент. И начать пинать мейнтейнеров.
тренажерный зал ты ни ходил, каких бы продвинутых тренеров ни нанимал,
если сам не будешь впахивать до седьмого пота, мышц не накачаешь. Так и
с безопасностью.
Тут первое с чем надо определиться - а кто у нас решает, кому можно
доверять и в чём - мейнтейнер dkms, фирма микрософт, производитель
железа или все-таки владелец компьютера? Пока ответ на этот вопрос
"какая-то коммерческая фирма непонятно в какой стране", понятно чья
безопасность будет обеспечиваться и кто будет считаться потенциальным
злоумышленником.
--
Victor Wagner <vi...@wagner.pp.ru>
Alexander Gerasiov
Feb 1, 2023, 2:50:03 PM2/1/23
to
самом деле очень важная и нужная вещь), но некоторые рассуждения,
которыми я руководствовался:
- данные на ноутбуке являются чувствительными
- на случай утери ноутбука данные должны быть зашифрованы
- предположим есть "добрый" злоумышленник, желающий получить доступ к
данным на ноутбуке (про злого с паяльником отдельный тред), тогда у
него есть два основных вектора атаки:
1. взлом работающего ноутбука по сети и т.п. тут цифровая гигиена,
всякие файрволы, контейнеры и прочее, о чем сейчас не говорим.
2. физический доступ к ноутбуку. (от 5 минут в кафе пописать, до пары
часов в офисе пообедать, варианты бывают разные)
В случае физического доступа получить доступ к данным не получится
(так как они зашифрованы), но можно залить модифицированный
загрузчик/ядро/инитрамфс, так как что-то из этого должно
лежать на диске не зашифрованное.
От подмены этих файлов защищает secureboot с кастомными ключами.
Следующий шаг - сбросить биос, подменить материнку или ноутбук целиком.
Это все не является нереализуемым, но усложняет атаку. Плюс есть
разумные способы это усложнить (enterprise ноутбуки, которые не
сбрасываются просто так, tamper detection, наклейки с героями аниме,
уникальная гравировка, памятная царапина в форме любимой буквы
армянского алфавита и т.п.). Где-то в этом месте здравый смысл должен
сказать, что гаечный ключ будет дешевле и можно успокоиться.
Tim Sattarov
Feb 1, 2023, 4:20:04 PM2/1/23
to
On 2/1/23 14:46, Alexander Gerasiov wrote:
> От подмены этих файлов защищает secureboot с кастомными ключами.
А можно поподробнее про этот момент как кастомные ключи в этом случае работают?
> От подмены этих файлов защищает secureboot с кастомными ключами.
ты грузишь свои собственные ключи в BIOS и указываешь степень доверия?
Если да, то я думаю этот момент даёт достаточно хорошую защиту, если не доводить до гаечных ключей,
и прочих горячих предметов.
Alexander Gerasiov
Feb 2, 2023, 5:00:04 AM2/2/23
to
это.
Victor Wagner
Feb 2, 2023, 8:50:04 AM2/2/23
to
В Wed, 1 Feb 2023 21:46:59 +0200
disk encryption - она защищает от подмены user-space бинарников,
которые не защищает secureboot.
Так-то я всегда полагал что FDE это вещь скорее вредная, чем полезная,
потому что является ярким сигналом "здесь есть что-то ценное". И
провоцирует нашего противника на применение терморектального (или, в
случае толетантных демократических стран rubber hose) крипоанализа.
Гораздо лучше было бы, если бы для того чтобы браузить интернет,
вводить пассфразу для расшифровки тех данных, которые мы хотим скрыть
от всего мира, не требовалось бы. Мы тут котиков смотрим. а данные себе
лежат зашифрованные. И даже таможенник на границе, решивший проверить
компьютер, их, скорее всего просто не найдет.
Но вот для того, чтобы избежать подмены /usr/bin/ls или /bin/echo, увы,
необходима либо сквозная система подписи исполняемых файлов с цепочкой
доверия от BIOS до последнего скрипта, либо таки да, FDE.
--
Victor Wagner <vi...@wagner.pp.ru>
Alexander Gerasiov <a...@gerasiov.net> пишет:
> On Wed, 1 Feb 2023 18:12:59 +0300
> Victor Wagner <vi...@wagner.pp.ru> wrote:
>
> > В Wed, 1 Feb 2023 16:42:47 +0200
> > Alexander Gerasiov <a...@gerasiov.net> пишет:
> >
> >
> > > Пароль можно добавить, но в моей модели угроз он не нужен. Для
> > > меня secureboot это гарантия, что на моем хосте нельзя забутить
> > > другую ОС и/или подменить ядро/загрузчик получив физический
> > > доступ к ноутбуку.
>
> On Wed, 1 Feb 2023 18:12:59 +0300
> Victor Wagner <vi...@wagner.pp.ru> wrote:
>
> > В Wed, 1 Feb 2023 16:42:47 +0200
> > Alexander Gerasiov <a...@gerasiov.net> пишет:
> >
> >
> > > Пароль можно добавить, но в моей модели угроз он не нужен. Для
> > > меня secureboot это гарантия, что на моем хосте нельзя забутить
> > > другую ОС и/или подменить ядро/загрузчик получив физический
> > > доступ к ноутбуку.
>
> В случае физического доступа получить доступ к данным не получится
> (так как они зашифрованы), но можно залить модифицированный
> загрузчик/ядро/инитрамфс, так как что-то из этого должно
> лежать на диске не зашифрованное.
О, наконец мне кто-то объяснил зачем может быть нужна на ноутбуке full
> (так как они зашифрованы), но можно залить модифицированный
> загрузчик/ядро/инитрамфс, так как что-то из этого должно
> лежать на диске не зашифрованное.
disk encryption - она защищает от подмены user-space бинарников,
которые не защищает secureboot.
Так-то я всегда полагал что FDE это вещь скорее вредная, чем полезная,
потому что является ярким сигналом "здесь есть что-то ценное". И
провоцирует нашего противника на применение терморектального (или, в
случае толетантных демократических стран rubber hose) крипоанализа.
Гораздо лучше было бы, если бы для того чтобы браузить интернет,
вводить пассфразу для расшифровки тех данных, которые мы хотим скрыть
от всего мира, не требовалось бы. Мы тут котиков смотрим. а данные себе
лежат зашифрованные. И даже таможенник на границе, решивший проверить
компьютер, их, скорее всего просто не найдет.
Но вот для того, чтобы избежать подмены /usr/bin/ls или /bin/echo, увы,
необходима либо сквозная система подписи исполняемых файлов с цепочкой
доверия от BIOS до последнего скрипта, либо таки да, FDE.
--
Victor Wagner <vi...@wagner.pp.ru>
Alexander Gerasiov
Feb 2, 2023, 9:00:04 AM2/2/23
to
On Thu, 2 Feb 2023 16:45:33 +0300
> Так-то я всегда полагал что FDE это вещь скорее вредная, чем полезная,
> потому что является ярким сигналом "здесь есть что-то ценное". И
> провоцирует нашего противника на применение терморектального (или, в
> случае толетантных демократических стран rubber hose) крипоанализа.
Для грубой силы - вредная. Для угрозы "любопытный нос полез в утерянный
ноутбук" - всё же полезная.
Victor Wagner <vi...@wagner.pp.ru> wrote:
> В Wed, 1 Feb 2023 21:46:59 +0200
> Alexander Gerasiov <a...@gerasiov.net> пишет:
>
> > On Wed, 1 Feb 2023 18:12:59 +0300
> > Victor Wagner <vi...@wagner.pp.ru> wrote:
> >
> > > В Wed, 1 Feb 2023 16:42:47 +0200
> > > Alexander Gerasiov <a...@gerasiov.net> пишет:
> > >
> > >
> > > > Пароль можно добавить, но в моей модели угроз он не нужен. Для
> > > > меня secureboot это гарантия, что на моем хосте нельзя забутить
> > > > другую ОС и/или подменить ядро/загрузчик получив физический
> > > > доступ к ноутбуку.
>
> >
> > В случае физического доступа получить доступ к данным не получится
> > (так как они зашифрованы), но можно залить модифицированный
> > загрузчик/ядро/инитрамфс, так как что-то из этого должно
> > лежать на диске не зашифрованное.
>
> О, наконец мне кто-то объяснил зачем может быть нужна на ноутбуке
> full disk encryption - она защищает от подмены user-space бинарников,
> которые не защищает secureboot.
Да, и это, конечно же тоже.
> В Wed, 1 Feb 2023 21:46:59 +0200
> Alexander Gerasiov <a...@gerasiov.net> пишет:
>
> > On Wed, 1 Feb 2023 18:12:59 +0300
> > Victor Wagner <vi...@wagner.pp.ru> wrote:
> >
> > > В Wed, 1 Feb 2023 16:42:47 +0200
> > > Alexander Gerasiov <a...@gerasiov.net> пишет:
> > >
> > >
> > > > Пароль можно добавить, но в моей модели угроз он не нужен. Для
> > > > меня secureboot это гарантия, что на моем хосте нельзя забутить
> > > > другую ОС и/или подменить ядро/загрузчик получив физический
> > > > доступ к ноутбуку.
>
> >
> > В случае физического доступа получить доступ к данным не получится
> > (так как они зашифрованы), но можно залить модифицированный
> > загрузчик/ядро/инитрамфс, так как что-то из этого должно
> > лежать на диске не зашифрованное.
>
> О, наконец мне кто-то объяснил зачем может быть нужна на ноутбуке
> full disk encryption - она защищает от подмены user-space бинарников,
> которые не защищает secureboot.
> Так-то я всегда полагал что FDE это вещь скорее вредная, чем полезная,
> потому что является ярким сигналом "здесь есть что-то ценное". И
> провоцирует нашего противника на применение терморектального (или, в
> случае толетантных демократических стран rubber hose) крипоанализа.
ноутбук" - всё же полезная.
Victor Wagner
Feb 2, 2023, 9:30:04 AM2/2/23
to
В Thu, 2 Feb 2023 15:57:32 +0200
Alexander Gerasiov <a...@gerasiov.net> пишет:
>
хакнуть пароль на grub или на bios (чтобы загрузиться с другого
носителя).
Когда заходит речь о таком уровне атакующего, это уже
несколько намекает на таржетированную атаку.
--
Victor Wagner <vi...@wagner.pp.ru>
Alexander Gerasiov <a...@gerasiov.net> пишет:
>
> > Так-то я всегда полагал что FDE это вещь скорее вредная, чем
> > полезная, потому что является ярким сигналом "здесь есть что-то
> > ценное". И провоцирует нашего противника на применение
> > терморектального (или, в случае толетантных демократических стран
> > rubber hose) крипоанализа.
> Для грубой силы - вредная. Для угрозы "любопытный нос полез в
> утерянный ноутбук" - всё же полезная.
Мне как-то с трудом верится в любопытный нос, который в состоянии
> > полезная, потому что является ярким сигналом "здесь есть что-то
> > ценное". И провоцирует нашего противника на применение
> > терморектального (или, в случае толетантных демократических стран
> > rubber hose) крипоанализа.
> Для грубой силы - вредная. Для угрозы "любопытный нос полез в
> утерянный ноутбук" - всё же полезная.
хакнуть пароль на grub или на bios (чтобы загрузиться с другого
носителя).
Когда заходит речь о таком уровне атакующего, это уже
несколько намекает на таржетированную атаку.
--
Victor Wagner <vi...@wagner.pp.ru>
Victor Wagner
Feb 2, 2023, 10:50:03 AM2/2/23
to
В Thu, 2 Feb 2023 17:01:12 +0300
li...@mail.ru пишет:
> 02.02.2023 16:45, Victor Wagner пишет:
> мне не пришлось судорожно не вспоминать, какие именно фотографии я на
> нем хранил и нет ли там чего-то такого, что сделало бы мою жизнь чуть
> более сложной в случае, если новый хозяин ноутбука будет достаточно
> любопытен, чтобы покопаться в моих файлах. В случае FDE ему останется
> только переформатировать диски.
>
Поскольку в мою модель угроз входит появление в доме вежливого офицера
ФСБ с ордером на обыск или встреча с не менее вежливым таможенником при
пересечении границы, меры, рассчитанные на противодействие этим
угрозам, спасают и от излишне любопытного нашедшего ноутбук.
--
Victor Wagner <vi...@wagner.pp.ru>
li...@mail.ru пишет:
> 02.02.2023 16:45, Victor Wagner пишет:
> > О, наконец мне кто-то объяснил зачем может быть нужна на ноутбуке
> > full disk encryption - она защищает от подмены user-space
> > бинарников, которые не защищает secureboot.
> Не только. FDE еще полезно в случае потери или гражи ноутбука, чтобы
> > full disk encryption - она защищает от подмены user-space
> > бинарников, которые не защищает secureboot.
> мне не пришлось судорожно не вспоминать, какие именно фотографии я на
> нем хранил и нет ли там чего-то такого, что сделало бы мою жизнь чуть
> более сложной в случае, если новый хозяин ноутбука будет достаточно
> любопытен, чтобы покопаться в моих файлах. В случае FDE ему останется
> только переформатировать диски.
>
Поскольку в мою модель угроз входит появление в доме вежливого офицера
ФСБ с ордером на обыск или встреча с не менее вежливым таможенником при
пересечении границы, меры, рассчитанные на противодействие этим
угрозам, спасают и от излишне любопытного нашедшего ноутбук.
--
Victor Wagner <vi...@wagner.pp.ru>
Eugene Berdnikov
Feb 2, 2023, 12:40:11 PM2/2/23
to
On Thu, Feb 02, 2023 at 06:40:40PM +0300, Victor Wagner wrote:
> Поскольку в мою модель угроз входит появление в доме вежливого офицера
> ФСБ с ордером на обыск или встреча с не менее вежливым таможенником при
> пересечении границы, меры, рассчитанные на противодействие этим
> угрозам, спасают и от излишне любопытного нашедшего ноутбук.
Второй раз читаю тут про таможенника, и ума не приложу, какое может быть
> Поскольку в мою модель угроз входит появление в доме вежливого офицера
> ФСБ с ордером на обыск или встреча с не менее вежливым таможенником при
> пересечении границы, меры, рассчитанные на противодействие этим
> угрозам, спасают и от излишне любопытного нашедшего ноутбук.
дело таможне до содержимого диска... Биты и байты вроде никакими пошлинами
не облагаются, а у таможенника нет ни времени, ни средств изучать их:
другие пассажиры в очереди нервничают и матерятся.
К слову, лучшее средство от ордера на обыск -- бэкап, тщательно спрятанный
вне дома, плюс запасной комплект вычислительной техники к нему, плюс заначка
для того, чтобы сразу после обыска докупить ещё один запасной комплект.
--
Eugene Berdnikov
Victor Wagner
Feb 3, 2023, 1:10:03 AM2/3/23
to
В Thu, 2 Feb 2023 20:35:05 +0300
Eugene Berdnikov <b...@protva.ru> пишет:
> On Thu, Feb 02, 2023 at 06:40:40PM +0300, Victor Wagner wrote:
> > Поскольку в мою модель угроз входит появление в доме вежливого
> > офицера ФСБ с ордером на обыск или встреча с не менее вежливым
> > таможенником при пересечении границы, меры, рассчитанные на
> > противодействие этим угрозам, спасают и от излишне любопытного
> > нашедшего ноутбук.
>
> Второй раз читаю тут про таможенника, и ума не приложу, какое может
> быть дело таможне до содержимого диска... Биты и байты вроде никакими
Таможенник - он человек государственный. А государству до всего есть
дело. Со мной уже был случай когда магнитные носители которые я вез с
собой в командировку в Австрию, проверяли. И был случай, когда ничего
не проверяя, просто не пропустили. Пришлось сдавать в камеру хранения в
Шереметьево.
> пошлинами не облагаются, а у таможенника нет ни времени, ни средств
> изучать их: другие пассажиры в очереди нервничают и матерятся.
Ну понятно, что если человека задерживают по подозрению что он вывозит
из страны секрентную информацию его из очереди отводят в такую
неприметную комнатку поблизости.
> К слову, лучшее средство от ордера на обыск -- бэкап, тщательно
> спрятанный вне дома, плюс запасной комплект вычислительной техники к
> нему, плюс заначка для того, чтобы сразу после обыска докупить ещё
> один запасной комплект.
Это, кстати, многие не понимают. Что всегда надо рассматривать две
угрозы
1. Что ваши данные попадут не в те руки
2. Что ваши руки не дотянутся до ваших данных в тот момент, когда вам
эти данные будут нужны.
Предложенный тобой способ защищает от второй угрозы. А пользователи
всяких FDE надеются, что применение этих средств защитит их от первой
Кстати, лежащий вне дома бэкап помогает не только от обыска, но и от
пожара, домовой кражи и даже от криптолокера (впрочем от криптолокера
помогает и бэкап лежащий в ящике стола, на котором стоит компьютер)
--
Victor Wagner <vi...@wagner.pp.ru>
Eugene Berdnikov <b...@protva.ru> пишет:
> On Thu, Feb 02, 2023 at 06:40:40PM +0300, Victor Wagner wrote:
> > Поскольку в мою модель угроз входит появление в доме вежливого
> > офицера ФСБ с ордером на обыск или встреча с не менее вежливым
> > таможенником при пересечении границы, меры, рассчитанные на
> > противодействие этим угрозам, спасают и от излишне любопытного
> > нашедшего ноутбук.
>
> Второй раз читаю тут про таможенника, и ума не приложу, какое может
> быть дело таможне до содержимого диска... Биты и байты вроде никакими
дело. Со мной уже был случай когда магнитные носители которые я вез с
собой в командировку в Австрию, проверяли. И был случай, когда ничего
не проверяя, просто не пропустили. Пришлось сдавать в камеру хранения в
Шереметьево.
> пошлинами не облагаются, а у таможенника нет ни времени, ни средств
> изучать их: другие пассажиры в очереди нервничают и матерятся.
из страны секрентную информацию его из очереди отводят в такую
неприметную комнатку поблизости.
> К слову, лучшее средство от ордера на обыск -- бэкап, тщательно
> спрятанный вне дома, плюс запасной комплект вычислительной техники к
> нему, плюс заначка для того, чтобы сразу после обыска докупить ещё
> один запасной комплект.
угрозы
1. Что ваши данные попадут не в те руки
2. Что ваши руки не дотянутся до ваших данных в тот момент, когда вам
эти данные будут нужны.
Предложенный тобой способ защищает от второй угрозы. А пользователи
всяких FDE надеются, что применение этих средств защитит их от первой
Кстати, лежащий вне дома бэкап помогает не только от обыска, но и от
пожара, домовой кражи и даже от криптолокера (впрочем от криптолокера
помогает и бэкап лежащий в ящике стола, на котором стоит компьютер)
--
Victor Wagner <vi...@wagner.pp.ru>
Eugene Berdnikov
Feb 3, 2023, 2:50:03 AM2/3/23
to
On Fri, Feb 03, 2023 at 09:07:59AM +0300, Victor Wagner wrote:
> В Thu, 2 Feb 2023 20:35:05 +0300
> Eugene Berdnikov <b...@protva.ru> пишет:
> В Thu, 2 Feb 2023 20:35:05 +0300
> Eugene Berdnikov <b...@protva.ru> пишет:
> > К слову, лучшее средство от ордера на обыск -- бэкап, тщательно
> > спрятанный вне дома, плюс запасной комплект вычислительной техники к
> > нему, плюс заначка для того, чтобы сразу после обыска докупить ещё
> > один запасной комплект.
>
> Это, кстати, многие не понимают. Что всегда надо рассматривать две
> угрозы
> 1. Что ваши данные попадут не в те руки
> 2. Что ваши руки не дотянутся до ваших данных в тот момент, когда вам
> эти данные будут нужны.
>
> Предложенный тобой способ защищает от второй угрозы. А пользователи
> всяких FDE надеются, что применение этих средств защитит их от первой
В слове FDE буква E как раз защищает, а вот FD, как верно было замечено,
> > спрятанный вне дома, плюс запасной комплект вычислительной техники к
> > нему, плюс заначка для того, чтобы сразу после обыска докупить ещё
> > один запасной комплект.
>
> Это, кстати, многие не понимают. Что всегда надо рассматривать две
> угрозы
> 1. Что ваши данные попадут не в те руки
> 2. Что ваши руки не дотянутся до ваших данных в тот момент, когда вам
> эти данные будут нужны.
>
> Предложенный тобой способ защищает от второй угрозы. А пользователи
> всяких FDE надеются, что применение этих средств защитит их от первой
скорее бесит нападающих и толкает их на применение радикальных средств...
Всё ценное должно быть зашифровано, включая бэкап, но шифровать всё
подряд это глупость, IMHO.
--
Eugene Berdnikov
Victor Wagner
Feb 3, 2023, 3:00:05 AM2/3/23
to
В Fri, 3 Feb 2023 10:46:50 +0300
Eugene Berdnikov <b...@protva.ru> пишет:
> > Это, кстати, многие не понимают. Что всегда надо рассматривать две
> > угрозы
> > 1. Что ваши данные попадут не в те руки
> > 2. Что ваши руки не дотянутся до ваших данных в тот момент, когда
> > вам эти данные будут нужны.
> >
> > Предложенный тобой способ защищает от второй угрозы. А пользователи
> > всяких FDE надеются, что применение этих средств защитит их от
> > первой
>
> В слове FDE буква E как раз защищает, а вот FD, как верно было
> замечено, скорее бесит нападающих и толкает их на применение
> радикальных средств... Всё ценное должно быть зашифровано, включая
> бэкап, но шифровать всё подряд это глупость, IMHO.
А при таком подходе приходится головой думать, что ценное, а что не
ценное. Что нужно защищать от несанкционированного прочтения, а что -
только от несанкционированного изменения (что лучше делать не
шифрованием, а подписью с её своевременной проверкой)
--
Victor Wagner <vi...@wagner.pp.ru>
Eugene Berdnikov <b...@protva.ru> пишет:
> > Это, кстати, многие не понимают. Что всегда надо рассматривать две
> > угрозы
> > 1. Что ваши данные попадут не в те руки
> > 2. Что ваши руки не дотянутся до ваших данных в тот момент, когда
> > вам эти данные будут нужны.
> >
> > Предложенный тобой способ защищает от второй угрозы. А пользователи
> > всяких FDE надеются, что применение этих средств защитит их от
> > первой
>
> В слове FDE буква E как раз защищает, а вот FD, как верно было
> замечено, скорее бесит нападающих и толкает их на применение
> радикальных средств... Всё ценное должно быть зашифровано, включая
> бэкап, но шифровать всё подряд это глупость, IMHO.
ценное. Что нужно защищать от несанкционированного прочтения, а что -
только от несанкционированного изменения (что лучше делать не
шифрованием, а подписью с её своевременной проверкой)
--
Victor Wagner <vi...@wagner.pp.ru>
0 new messages