Comments 25
secureboot - прекрасная технология если самому генерить ключи и подписывать ими строго определенный список исполняемых файлов
За годы использования SecureBoot должна была накопиться статистика, как эта "прекрасная технология" позволила почти полностью победить такое явление как вирусы и прочая малварь. Не подскажете, где можно почитать победные реляции на эту тему, с графиками и статистикой? И, заодно, не подскажете, почему антивирусные компании ещё не позакрывались все дружно?
позволила почти полностью победить такое явление как вирусы и прочая малварь
Это разные векторы атак, не должна была
Secure Boot нужен для организации верифицированной цепочки загрузки. Нет, если подписывать все и вся, и запретить ОС исполнять бинарники без соответсвующей подписи, наверное наглухо победить малварь можно. Только у меня вопрос, а как часто вы настраивали Secure Boot на использование собственных ключей? Тут я не говорю уже про верифицированную цепочку загрузки, только хотя-бы, про первый загрузчик
Я этот вопрос рассмотрел, и решил, что мне это нафиг не нужно. У меня линух, и я достаточно хорошо разбираюсь в безопасности чтобы адекватно его настроить и обновлять. И обычно мой домашний комп не выключается и не перегружается месяцами (пока обновление ядра этого не потребует). Так что если ко мне в систему незаметно попадёт малварь, которая получит рута (а без этого она в загрузчик всё-равно никак не попадёт), то мне уже будет плевать, прописала она себя в grub, или нет. Более того, даже если я пропишу ключи и заморочусь с подписью ядра и сторонних драйверов вроде nvidia при каждом обновлении ядра - с очень высокой вероятностью меня это никак не спасёт, если на компе в момент установки и подписывания нового ядра уже будет под рутом работать малварь, умеющая прописывать себя в загрузчик - она сможет либо незаметно подсунуть себя в список подписываемых файлов либо получить пароль от ключей кейлоггером и подписать себя самостоятельно.
P.S. Загрузка дополнительных модулей ядра после запуска системы у меня заблокирована. Это вот как раз полезная часть функционала SecureBoot, но она доступна и без SecureBoot.
P.S. Загрузка дополнительных модулей ядра после запуска системы у меня заблокирована
Любопытно, вставили вы, например, флешку, должен подгрузиться модуль usb-storage, и что произойдёт?
Ничего - он уже загружен. Потому что даже не собирался как модуль, он сразу включён в ядро. Как и все нужные мне модули кроме нескольких отсутствующих в ядре. У меня lsmod выглядит вот так:
Module Size Used by
xt_geoip 12288 0
vboxnetadp 24576 0
vboxnetflt 32768 0
vboxdrv 524288 2 vboxnetadp,vboxnetflt
nvidia_uvm 4710400 4
nvidia_drm 98304 13
nvidia_modeset 1536000 14 nvidia_drm
nvidia 59670528 302 nvidia_uvm,nvidia_modesetНо если возникает нужда загрузить новый модуль (напр. после обновления драйверов nvidia или после первой установки VirtualBox) то я просто перегружаюсь - это небольшая цена за повышение безопасности.
В принципе, в случае статичных систем, с упорядоченным планом работ - это правильно.
Аналогично делал на своих серверах, когда админил.
В случае пользователей, особенно тех, кто сам не знает чем заняться, тут уже подход дистрибутивов общего пользования.
Когда написано правил в udev и грамотно, прозрачно для пользователей подключается железо и модули ПО.
Но о безопасности в таком случае не говорят.
Т.к. для selinux или apparmor или других LSM-систем потребуется адекватно описать права доступа.
это просто компонент системы доверенной загрузки, только один элемент из длинной цепочки, которая обеспечит безопасность. достаточно важной, т.к. до работы систем защиты.
Ага. Только вот неясно, чью безопасность он обеспечивает. Пока единственное проявление SecureBoot на практике, которое я наблюдал - он усложняет установку альтернативных прошивок на Android телефоны, его приходится отключать при установке линуха, плюс иногда создаёт какие-то новые сложности под виндой (мельком что-то попадалось в статьях, я не вникал).
Всё это выглядит как попытка обеспечить безопасность сторонних компаний. Чтобы только выпущенный ими софт можно было использовать. Компаниям это выгодно, тут вопросов нет. Вопросы есть к тому, где выгода для пользователей? Реальная, а не чисто психологическое самоуспокоение "у меня SecureBoot, я в домике и мне безопасно".
К сожалению, любая система защиты должна быть комплексной,а набор не связанных компонент это дополнительные угрозы. Но пользователь об этом не знает и ему не скажут.
он усложняет установку альтернативных прошивок на Android телефоны
А его отсутствие упрощает установку прошивок не только вам, но и атакующему. Ничто не помешает атакующему, имеющему физический доступ к вашему телефону, прошить вам точно такую же альтернативную прошивку, которая у вас стоит, но с вредоносной добавкой в /system/app. Подмену вы не заметите.
Google, кстати, на своих Пикселях позволяет установить пользовательский ключ, чтобы можно было блокировать загрузчик даже с кастомными прошивками. Вот к этому надо стремиться остальным вендорам, а не заставлять пользователя выбирать между кастомноц прошивкой и заблокированным загрузчиком.
его приходится отключать при установке линуха
Во всех основных дистрах давно уже не приходится.
плюс иногда создаёт какие-то новые сложности под виндой
Никаких сложностей: просто внесли хэши старых уязвимых загрузчиков Windows в блеклист. Решение: сисадмины обновляют свои Windows LiveCD, вот и всех делов.
На днях еще случайно сломали дуалбут с линуксами, но это недосмотр майков. Они в обновлении забанили хэши старых уязвимых загрузчиков GRUB. Обновление планировалось раскатать синглбутчикам, но по недосмотру раскатали всем. Соответственно те дуалбутчики, которые использовали уязвимые версии GRUB, получили опаньки. Но, опять же, это не Secure Boot плохой, это недосмотр майков (ну и проблема элементарно решается временным отключением SB).
А его отсутствие упрощает установку прошивок не только вам, но и атакующему. Ничто не помешает атакующему, имеющему физический доступ к вашему телефону, прошить вам
Ну да, ведь пользовательский пароль для fastboot реализовать никак неможно. На BIOS можно, а тут - никак. Хотя он прекрасно бы решил эту проблему.
Google, кстати, на своих Пикселях позволяет установить пользовательский ключ, чтобы можно было блокировать загрузчик даже с кастомными прошивками.
Полагаю, это сломает OTA обновления сторонних прошивок. Так что хоть это решение и немного лучше, но всё ещё плохо.
Во всех основных дистрах давно уже не приходится.
Угу. Вероятно, ровно до тех пор, пока не понадобится собрать своё ядро. Да и понятие "основной дистр" довольно смутное - вот у меня Gentoo, это основной? А кто решает, каким дистрам выдать ключ для подписи, а каким нет?
Но, опять же, это не Secure Boot плохой, это недосмотр майков
Да нет, это именно он плохой. Он создаёт проблемы, а не решает. Это как политики - они обещают много хорошего, но на практике обещания не выполняют, зато вместо этого делают много плохого. Один-в-один SB.
Secure Boot защищает не от малвари в целом. А от конкретного класса малвари - буткитов.
Без SB малварь, добившись прав писнуть в ESP (тем или иным способом подняв себе права до System/рута), подменяет загрузчик на свой и дальше может делать все угодно, т.к. контролирует загрузку ядра и может патчить его на лету.
Зато с ним, после (неизбежной, и уже случавшейся) утечке ключей для подписи, малварь встраивается в систему так, что даже переустановка ОС не спасает (свежак про ключи: https://habr.com/ru/news/831752/, пример малвари: BlackLotus). Я уже молчу о том, что те же спец.службы вполне имеют возможность получить доступ к этим ключам и распространять свои закладки. Это плохой инструмент реализованный в неподходящем месте, от которого вреда больше, чем пользы.
Так не получится, различные компоненты UEFI тоже подписаны, и их подпись проверяется при загрузке системы. В моём случае удаление ключа Microsoft привело к невозможности старта материнской платы, не работал даже джампер Clear CMOS, пришлось восстанавливать прошивку.
Странно, так не должно быть. В серверных и промышленных платах есть возможность удалить все ключи и оставить только свои, и это работает как надо. Потенциально для запуска UEFI модулей от вендора может быть нужен ключ вендора, но вот ключ Microsoft точно не является обязательным. Возможно, особенность именно вашей платы.
Если вы удалили все ключи, то у вас даже GOP-драйвер видеокарты не стартанет.
И ключей Microsoft два: одним майки подписывают загрузчики Windows, а вторым компоненты третьих сторон (как раз GOP-драйверы, загрузчики Linux и так далее). Последний удалять не рекомендуется.
Конкретно комментатор выше, скорее всего, смог загнать прошивку в состояние "ключей нет, но Secure Boot включена". В идеале прошивка не должна позволять включать SB без ключей, поскольку это бессмысленно. Обычно в прошивке есть защита от дурака на этот случай - опция включения SB блокируется при удалении ключей. Но у некоторых производителей (привет, жыжабайт) определенными манипуляциями таки можно включить SB без ключей. После чего прошивка не может стартануть, поскольку SB требует, чтобы все было подписано ключом из списка, а список пуст - приплыли.
Жыжабайтовские мамки расценивают такой неудачный старт, как поврежденную прошивку, автоматически восстанавливают ее с резервной микросхемы (бесполезно, прошивка-то в норме) и сбрасывают настройки полностью, включая восстановление дефолтных ключей (что исправляет проблему).
Но это надо реально постараться, чтобы загнать прошивку в такую задницу: нужно сохранить пресет настроек с включенным SB, затем удалить ключи и восстановить пресет определенным образом, тогда защита от дурака не сработает и SB включится без ключей. Впрочем, это не отменяет факта, что прошивки у жыжабайта - глючное говно.
Возможно, это не баг. Эта фича :-) Интересно, как обстоят дела с этим моментом у MSI и Asrock
У кого-то есть копия этого репозитория? Или хотя бы сам ключ?
Проверил, нету
Тут забыли написать, что проверить прошивку на уязвимый сертификат можно тут https://pk.fail/
В тексте новости это есть: Проверить свою прошивку можно на этом сайте.
В матплатах Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo и Supermicro есть тестовый ключ для обхода UEFI Secure Boot