Comments 28
Если вы имеете в виду намеренно оставленные закладки, то здесь нужно учесть область применения Secure Boot и взвесить важность вашей информации против стоимости атаки на неё. Эффективно используя Secure Boot, вы ограничиваете круг противников (adversary) до тех, кто способен использовать эти закладки, значительно увеличивая стоимость атаки. Как мне кажется, для ноутбука с личными данными такой защиты достаточно. Для информации, вызывающей острый интерес иностранных служб разведки, наверное, нет.
У представленных на рынке устройств есть свой предел по обеспечению информационной безопасности. Правильное использование Secure Boot позволяет максимально приблизиться к этому пределу для конкретного устройства. Если в устройстве реализован Secure Boot, то есть смысл его использовать.
Пару простых советов по защите от физического доступа я описал в статье. Сможете воспроизвести все пятна, царапины и наклейки на моём ноутбуке так, чтобы я не заметил подмены?
> Ещё раз: в чём польза простому юзеру от секуребута?
Пользователю, который не шифрует свои данные, пользы от него нет. Для себя я пользу нашёл — в качестве защиты от атаки Evil Maid. Если вы считаете, что в таком качестве он непригоден, объясните. Остальное офтопик.
Насчет доверия к uefi, есть вообще какие либо альтернативы? Допустим я могу прошить свой чип с биосом.
https://www.coreboot.org/
http://www.tianocore.org/
https://libreboot.org/
Поправлю немного по примечаниям:
4. Выбрать загрузочное устройство в Windows 8 и Windows 10 очень просто, даже не имея пароля. На стартовом экране есть кнопка Power, которая открывает меню с Power off/Standby/Restart. Если нажать на Restart удерживая Shift, вместо перезагрузки произойдет переход в меню Troubleshooting, откуда можно перейти сначала на Advanced Settings, а затем и на Startup Settigs, где и выбрать следующее загрузочное устройство. Пишу по памяти и не имею сейчас доступа к машине с Windows, но когда я пробовал вышеописанное в последний раз пару месяцев назад — работало.
5. Лучше не создавать больше одного ESP (и не создавать ESP меньше 200 Мб, ограничение не жесткое, но некоторым старым загрузчикам не нравится), а просто сложить все загрузчики на один раздел. Efibootmgr действительно лучше не пользоваться, а вот UEFI Shell намного чаще приходится загружать с внешнего носителя, т.к. встраивать его себе в прошивку — потенциальная проблема безопасности, и потому не очень рекомендуется.
Нужно бежать на работу, потом допишу еще пару замечаний, когда смогу прочитать статью вдумчиво, а не на бегу.
4. Я об этом способе и говорю, пароль не нужен. У меня Windows передаёт команду на загрузку устройства UEFI, а в нём загрузка с USB отключена, поэтому загрузка не срабатывает. Не исключено, что раньше Windows делала это как-то по-другому, или моя прошивка не имеет такой уязвимости. Из вашей же статьи о нём и узнал.
5. Откуда можно стянуть UEFI Shell? Добавил бы ссылку в статью. В гугле находятся бинарники неизвестного происхождения. В вики Ubuntu вообще написано: «Если вы ставили Ubuntu на чистый диск, а в прошивке нет встроенного UEFI shell, то его можно доставить руками. Сам бинарный файл легко находится через любой поисковик».
Откуда можно стянуть UEFI Shell?
Я пользуюсь шеллом из состава Tianocore EDK2
Для арча есть пакетик в AUR'e, для остальных ОСей не знаю, к сожалению, но можно собрать ручками по аналогии. Либо взять бинарную сборку из репы.
Технология Secure Boot нацелена на предотвращение исполнения недоверенного кода при загрузке операционной системы
Не, она нацелена на поддержание vendor lock-in от Mi©ro$oft
Кстати, а что делать если система перестанет загружаться по какой-то причине?
Чрут с live cd уже не сделать…
трюк с /tmp/cmdline вполне можно сделать и без временного файла:
CMDLINE="quiet nosplash"
objcopy \
--add-section .cmdline=<(echo $CMDLINE) --change-section-vma .cmdline=0x30000
# etc
Хотя ничего критичного нет, всё равно выполняется на доверенной системе.
Статья почти слово в слово повторяет мою запись в личной wiki. Мне порой кажется, что если я что-то подобное опубликую, то в меня полетит критика в роде "капитан очевидность" или "задрот".
У меня вопрос к следующей фразе:
Однако отсутствие верификации initramfs позволяет встроить в него вредоносный код, имея доступ на запись в ESP. Teddy Reed предлагает компилировать ядро, встраивая в него initramfs.
Как это может быть, если initramfs находится на зашифрованном разделе (а не на ESP), а grub при загрузке сначала запросит пароль перед тем как считать initramfs и ядро с зашифрованного диска. Зачем нужна морока со сборкой и подписью своего ядра?
На ESP в моём случае находится лишь только grubx64.efi
В сноске 2 как раз правильное решение используется.
Теоретически можно исправить, установив пароль, встроив grub.cfg в образ GRUB с помощью grub-mkstandalone и установив в grub.cfg prefix на невалидный путь, чтобы GRUB не мог найти второй grub.cfg на диске. Но опять же требуется подписывать образ самостоятельно.
UEFI secure boot кстати вполне спокойно работает на MBR (не могу точно сказать насколько это соответствует стандарту, давно проблему решал). Только необходимо osprober пофиксить https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817023
Не оставляйте устройство включённым без присмотра. Устройство в ждущем режиме (suspend to RAM) содержит в RAM расшифрованные данные и мастер-ключи от криптоконтейнеров
А есть какая-то информация о способах получить доступ к этой памяти?
Вот стоит включенный ноут, с заставкой и требует пароль (вход уже выполнен, так что в памяти нешифрованные данные). Каким образом можно получить доступ к данным в оперативке, даже при наличии физического доступа? Память ведь энергозависима, да и к работающей подключиться и что-то считать сторонним устройством скорее всего не выйдет.
https://ru.wikipedia.org/wiki/Cold_boot_attack
https://en.wikipedia.org/wiki/Cold_boot_attack
Но в целом суть я понял, спасибо.
А правильным будет, после проделанного в статье, удалить сертификаты MS и Canonical?
Возможно ли, и как?
И вопрос 2. шифрование на уровне всего диска делает невозможным прочитать данные?
если это так то зачем мазать лаком винт, что бы уберечься от подмены файлов, винт же будет не читаемым без пароля?
если нет то смысл вклюать шифрование?
Я правильно понимаю что при этом сертификаты MS остаются, и позволяют запустить подписанные им программы? например shim (что как я понял из статьи та еще дыра).
Сертификатов MS не будет, если их не добавлять специально. В этой статье рассматривается их добавление в db, но делать это необязательно. Насколько это безопасно — сразу сказать не могу, надо подумать.
если это так то зачем мазать лаком винт, что бы уберечься от подмены файлов, винт же будет не читаемым без пароля?
Мазать не винчестер, а крепёж на ноутбуке или системном блоке, чтобы факт вскрытия был заметен. Прочитать данные невозможно, но при физическом доступе к материнской плате можно сбросить настройки Secure Boot или банально заложить подслушивающее устройство.
Используем Secure Boot в Linux на всю катушку