Поясните про secure boot

некоторые переменные uefi недоступны в ос, из своей убунты ты их не поменяешь. но они доступны загрузчикам, которые должны быть подписаны

Ахаха, ещё один все понял.

От физдоступа он не спасает, остальное — такая тонкая гипотетика, что без слез не взглянешь. Используется не только потому что он есть, но ещё и потому, что в названии есть Secure. См. также TPM.

#SecureInTheNameOnly

От чего он защищает?

От линукса.

Тебе на работе выдали ноут, ты решил поставить туда стим. А облом, репы залочены, фс закриптована, софт можно ставить только с корпоративной репы. Это если линь.

А если винда, то это чтобы вендоры не могли больше старые винды использовать и пришлось закупать новые.

Тебе на работе выдали НОУТ, ты решил поставить туда стим. А облом

репы залочены

Что такое «репы заложены» , и как оно тебе помешает поставить стим?

фс закриптована,

Как оно тебе помешает поставить стим?

софт можно ставить только с корпоративной репы.

Каким механизмом это бы энфорсилось, если ты можешь выполнять произвольный код и писать в хомяк?

От чего он защищает?

От скучного и безболезненного пользования. Просто лишний затык, чтобы раздражать, когда что-то случилось, и ты на нервах и ты забыл, что он включен, и флешка не грузится. Чтоб не расслаблялся, так сказать.

Ноэкзек на тех местах куда ты можешь писать. Да ещё и иптейблы на корпоративную сеть только.

Пока придумал такой сценарий:

1. Грузится подписанный загрузчик, ядро, запускается initrd.

2. Ядро из TPM достаёт ключ для расшифровки раздела. TPM ключ отдаёт только если загрузчик, ядро и initrd совпадают с предыдущей загрузкой. Вроде бы он умеет так делать.

3. Если TPM не отдаёт ключ, юзера спрашивают про пароль.

4. Если юзер перед этим не обновлял ядро, то он обнаруживает атаку злой домработницы (evil maid attack). Т.е. после обновления ядра юзер должен перезагрузиться и ввести пароль один раз, чтобы TPM запомнил новое ядро.

Но я в этом ничего не понимаю и не уверен, что оно всё работает именно так.

Подписи, как таковые, в этом сценарии в общем-то и не нужны, достаточно лишь хеша, но видимо без secure boot нормально это проверить нельзя.

Хотя тут пишут что таки можно TPM пользовать без secure boot. Так что вопрос видимо остается актуальным :)

От чего он защищает?

От тебя.

От левака в цепочке загрузки. То что мелкософт понаподписывал дырявых бутлоадеров, а SB «выключается в биосе» этого не меняет, т.к. дефолтные ключи выкидываются, а настройки лочатся паролями.

А если как-то был загружен левак, то не сходятся PCR в TPM и секреты все равно «в безопасности». Ну, в теории так.

Но при этом ключи MS удалять нельзя тк это кирпичит девайс.

Это крайне редкий случай, у особо криворуких вендоров.

На устройствах из магазина ни от чего. Но теорИтически можно сделать свой уефу подписать, нарисовать свои дрова и подписать, удалить все предустановленные ключи и не давать грузить liveusb убунту или винду.

Она сделана чтобы всякие слишком умные не разгоняли USB устройства и не портили бизнес тем кто намеренно замедляет всякие мыши.

а как так вышло что ты смог загрузиться с внешнего носителя после установки ос?

Нажал F12 и выбрал устройство с которого надо грузиться.

Это крайне редкий случай, у особо криворуких вендоров.

Божественный Thinkpad же.

Ага, т.е. устройство не было должным образом настроено. Чему тогда удивляться?

Если поставить пароль на bios, то не получится загрузиться с livecd.

Если ты про пароль на биос, то к secure boot это же не имеет отношения. Я этот пароль и так могу поставить. Ну вытащил диск, подменил там исполняемые файлы на федорские, какая разница. Думаю одного grub-а будет достаточно.

Ты идёшь от решения. А хорошая злая домработница уже все сперла и оставила тебе лишь ноут-муляж для сбора пароля.

Ну а как ей ноут муляж поможет. Я увижу неожидаемый ввод пароля и гипотетически сожгу ноутбук и куплю новый не допустив взлома.

Да ещё и иптейблы на корпоративную сеть только.

Разработчику?

Можно и разработчику. Но ты думаешь кроме разработчиков никому компы не выдают?

Не знаю, может я дремучий, но как пр мне, запретить программисту интернет - это подрезать крылья.

Ну я спорить не стану, легко могу представить случаи когда зарезать интернет можно и нужно

Я лично один раз даже отказался от работы мечты, когда сказали что выдадут ноут и даже иде свою ставить нельзя… Больные ублюдки)

Ну а как ей ноут муляж поможет. Я увижу неожидаемый ввод пароля.

Давай сходу, без подглядывания — обновлял ты ядро с последней перезагрузки?

Если да, то ввод пароля ожидаем и ты ведёшь его, как миленький.

Если нет, то ты проиграл ещё раньше, и твои данные уже расшифровали сообщники домработницы простым нажатием кнопки «вкл».

Не понял. Как они получат к ним доступ? Ну без экзотики типа залили азотом, вытащили планки памяти и тд.

Ткнутся в thunderbolt и попробуют снять RAM через DMA. Если вдруг не получится, просто подождут дырки в каком-нибудь gdm/xscreensaver/…, крашнут его и скопируют все ручками через cp.

Зачем такие сложности?

Возьмут устройство, рядом посадят пользователя этого устройства и предложат на выбор: скрепки про ногти, пакет на голову, тряпка на рот и водичка в придачу.

Либо малолетку подложат, да наркоту детям подбросят.

Не знаю, что ты там обычно делаешь с горничными, но обычно это другая модель угроз.

УМВР ¯\_ (ツ) _/¯

Я правильно понимаю, что наличие потенциальной дырки в компоненте X означает, что закрывать грузовые ворота в компонентах Y и Z ненужно и даже вредно? 😊

ненужная переусложненная фигня, защищает только копирастов но не пользователей

Нет. Верно будет «отсутствие модели угроз, от которой SecureBoot помогает, ставит под сомнение всю пользу этого театра». Про отверстия в нем и начинать смысла нет.

В обоих вариантах, которые я там описал, SecureBoot вообще не поучаствовал. Не потому, что я его как-то хитро обошёл или потому что в нем дырки, а потому что эти ворота в пустыню просто бессмысленны.

сразу видно икспертов в треде

Это обычный вендорлок как у Мака, чтобы ты не мог поставить другую операционку на ноут с предустановленной Windows. В Евросоюзе Microsoft пригрозили штрафами за сговор с производителями материнок, и тогда добавили возможность выключать Secure Boot жалоба ответ на нее.

the Commission it appears that the OEMs are required to give end users the option to disable the UEFI secure boot

так дядя билли получил по носу и начал разрабатывать ГМО-кукурузу приводящую к бесплодию (типа случайно) и унитазы, фильтрующие воду из кала

Secure Boot относится к разделу Integrity. И необходим для верифицированной цепочки загрузки:

1. Если мамку и проц купить в разных магазинах и соединить самому, то ключ Intel Boot Guard в спец область ROM где-то в IntelME пользователь сможет прошить сам. Изменить ключ Intel Boot Guard физически невозможно. Пользователь лично создает ключ для Intel Boot Guard и публичную часть его прописывает единожды в ROM чипа, а секретным ключом лично подписывает UEFI(libreboot,coreboot) со своими личными ключами Secure Boot. А все чужие ключи с Secure Boot удаляет. Не покупать железо которое запрещает установку пользовательских публичных ключей и удаление всех остальных ключей. Еще лучше покупать железо поддерживающие открытые, свободные прошивки. При загрузке публичным ключом с Intel Boot Guard верифицируется целостность UEFI и неизменность ключей и настроек Secure Boot.

2. Secure Boot с помощью установленного пользователем публичного ключа верифицирует Загрузчик, core.img в случае с GRUB2. Загрузчик должен подписывать лично пользователь, своими личными ключами созданными для Secure Boot, публичная часть которых устанавливается лично пользователем в UEFI.

3. GRUB2, публичным ключом, верифицирует все свои модули, настройки, ядро и Initramfs! Их должен подписывать лично пользователь, своими личными ключами созданными для GRUB2, публичная часть которых устанавливается лично пользователем в core.img от GRUB2.

4. Все исполняемые файлы, настройки и не изменяемые структуры верифицируются ядром OS, публичными ключами IMA/EVM, при их загрузке. Весе проги, либы и настройки должен подписывать лично пользователь, своими личными ключами созданными для IMA/EVM, публичная часть которых устанавливается лично пользователем в ядро Linux.

Наличие чужих ключей для верификации системы неприемлемо!

Наличие секретных ключей в рабочей системе недопустимо!

Установка системы поддерживающей верифицированную загрузку проходит в обратном порядке:

1. Создаются ключи IMA/EVM. Ими подписываются все исполняемые файлы, библиотеки, настройки и неизменяемые структуры. Публичные ключи IMA/EVM помещаются в ядро Linux. Секретные ключи удаляются с системы.

2. Создаются ключи GRUB2. Ими подписываются ядра, initramfs, модули и настрой и GRUB. Публичная скачать ключа записывается в core.img. Секретные ключи удаляются с системы.

3. Создаются свои ключи Secure Boot, а чужие удаляются. Своим ключом подписывается core.img - загрузчик GRUB. Секретные ключи удаляются с системы.

4. Создаются свой ключ для Intel Boot Guard. Он должен быть надёжно заархивирован, распечатан. В случае утери секретного ключа Intel Boot Guard любые изменения в системе станут невозможны!!! Им подписывается UDFI со своими настройками и публичными ключами. Секретный ключ удаляются с системы.

Integrity даёт гарантию целостности загружаемой системы. Для увеличения ее стабильности и препятствию DoS атак дополнительно настраивают безопасность системы: запрет изменений прошивок и их верификация, проверка аппаратной целостности, шифрование диска и использование режима только для чтения для его неизменяемых разделов, запрет на изменение исполняемых областей памяти и запрет на исполнение изменяемых областей памяти, …

Обновление системы в режиме верифицированной загрузки невозможно. Для обновления систем с поддержкой Integrity на нее скачивают все необходимые обновления, отключают от сети, перезагружают с выключенными IMA/EVM, в режиме дисков доступных для записи. Подключают секретные ключи и обновляют. Удаляют секретные ключи из системы. Перезагружают в режиме Integrity и подключают к сети.

Спасибо, интересно, но полагаю, такое больше для каких-то встраиваемых девайсов нужно.

Integrity существующие в GNU/Linux подойдёт и необходимо для всех серверов и рабочих станций. Гарантии целостности загружаемой системы есть необходимое минимальное ТРЕБОВАНИЕ к безопасной OS.

Если админа способного поддерживать Integrity нет, то как минимум рекомендуется использовать сканеры целостности системы не при загрузке, а по запросу, например: AIDE.

Сегодня безопасность OS развивается в сторону «автоматической аттестации рабочего места». Сервера перед установкой соединения определяют безопасность подключаемой рабочей станции и в случае недостаточного уровня безопасности отказывают в соединении. Скоро не настроев правильно цепочку Intel Boot Guard -> Secure Boot -> GRUB -> Linux IMA/EVM вы не сможете зайти в клиент банк, на госуслуги, в налоговую, подключится к VPN, … возможно даже авторизоваться на ЛОРе! Я не шучу. В GNU/Linux уже все необходимое добавили!!! IMA к сожалению перевели на LSM и научили получать состояние проверок безопасности с ранних этапов загрузки и к большому сожалению их IMA уже может передавать левым серверам в интернатах:

Ищем: «Line IMA remote attestation»

https://sourceforge.net/p/linux-ima/wiki/Home/#ima-appraisal

https://www.cncf.io/blog/2021/07/06/ibm-implements-remote-attestation-on-linux-with-a-hardware-root-of-trust-using-keylime/

https://docs.strongswan.org/docs/5.9/tnc/imaClient.html

Каким механизмом это бы энфорсилось, если ты можешь выполнять произвольный код и писать в хомяк?

Ты не можешь выполнять неподписанный код и запускать что-угодно из мест, куда можешь писать (i.e., $TMPDIR и $HOME).

Спасибо, интересно, но полагаю, такое больше для каких-то встраиваемых девайсов нужно.

Такое нужно, например, в организациях для того, чтобы в процессе подключения устройства (десктопа или лептопа) к сети можно было удалённо убедиться в целостности всего аппратно-программного стека - что это именно тот компьютер, с ожидаемым составом устройств и ожидаемым софтом - без неожиданных модулей ядра, например. И если подключаемое устройство может продемонстрировать целостность операционной системы, то, например, это означает, что данным, предоставленным операционной системой, можно доверять.

Операционная система может предоставлять данные о версиях установленного софта, или о версии сингатур антивируса, или о том, какие апдейты установлены - всё это удалённо. На основе этих данных можно принять решение, подключать эту машину в сеть, оправить её в карантин, или не подключать вовсе, а отправить наряд на рабочее место (это уже в очень специфических организациях). Такая удалённая аттестация клиентских систем - это супер-удобная штука в организациях, где работают тысячи людей или есть заметная доля удалённых сотрудников.

PS. Первый раз за многое временя вижу, чтобы анонимус что-то дельное сказал.

Ещё раз, каким механизмом это бы энфорсилось, фантазеры?

Что мешает мне запустить Python, там взять syscall из libc и отплясывать что хочу? enable-нуть башем кастомную .soшку, например, ctypes? Примонтировать себе через user mount namespaces tmpfs без noexec?

Такое нужно, например, в организациях для того, чтобы в процессе подключения устройства (десктопа или лептопа) к сети можно было удалённо убедиться в целостности всего аппратно-программного стека - что это именно тот компьютер, с ожидаемым составом устройств и ожидаемым софтом - без неожиданных модулей ядра, например.

Классные у вас фантазии, а механизм для этого какой-то есть? Потому что SecureBoot ваш этого не дает, и любимая bring-your-own-железяка нерадивого сотрудника отправит все что надо, обе стороны и не поморщатся.

Ещё раз, каким механизмом это бы энфорсилось

В GNU/Linux есть много разных средств для ограничения изменения системных бинарей и запуска левых бинарей.

Свежий, «бесплатный» антивирус Касперского... для линукса. (комментарий)

Что мешает мне запустить Python, … баш…

На интерпретаторы можно резать права в DAC.

# usermod -a -G python ...
# chown root:python /usr/bin/python*
# chmod o-rwxst /usr/bin/python*

Примонтировать себе через user mount namespaces tmpfs без noexec?

У меня ядро Linux запрещает монтировать диски в режиме для записи. Также запрещает монтировать новые диски в режиме exec. Да, примонтировать флеху в режиме rw, чтобы что то на нее записать не сможет даже root.

Напугаю вас ещё больше, ядро Linux через IMA, уже может настучать на пользователя попытавшегося запустить левую прогу, или отключившего Secure Boot, или отключившего SELinux… И за эти грехи VPN сервер уже может отказать в подключении оставив донос в своих логах.

Классные у вас фантазии, а механизм для этого какой-то есть?

«Linux IMA remote attestation» умеет считывать результаты проверок безопасности с ранних этапов загрузки, включая проверки UEFI Secure Boot, GRUB и проверяет цифровые подписи всех запускаемых файлов, библиотек, настроек. Так что Linux IMA о безопасности системы знает много.

Потому что SecureBoot ваш этого не дает,

Оно пишет результаты проверок в PCR, а Linux IMA от туда их умеет считывать.

и любимая bring-your-own-железяка нерадивого сотрудника отправит все что надо, обе стороны и не поморщатся.

Linux IMA подпишет донос ключом защищённым от юзверя и публичный ключ IMA есть на сервере, для расшифровки и проверки авторизации. Пользователь донос Linux IMA подделать не сможет.

На интерпретаторы можно резать права в DAC.

Можно и контроллер SSD насквозь просверлить. А так, чтобы потом хотя бы залогиниться можно было?

Напугаю вас ещё больше, ядро Linux через IMA, уже может настучать на пользователя попытавшегося запустить левую прогу, или отключившего Secure Boot, или отключившего SELinux… И за эти грехи VPN сервер уже может отказать в подключении оставив донос в своих логах.

Это все невероятно страшно в описанной мной модели, где юзер уже работает себе с личной системы без лишних имамов и в ус не дует.

Linux IMA подпишет донос ключом защищённым от юзверя

Нет такой сущности на железе, к которому есть физдоступ, а следовательно и рут доступ.

Пользователь донос Linux IMA подделать не сможет.

Not with that attitude.

«Linux IMA remote attestation» умеет считывать результаты проверок безопасности с ранних этапов загрузки, включая проверки UEFI Secure Boot, GRUB и проверяет цифровые подписи всех запускаемых файлов, библиотек, настроек. Так что Linux IMA о безопасности системы знает много.

Всё это круто, конечно, но реально будет полезно только тогда, когда будет из коробки работать в дистрибутивах. А там даже с элементарной поддержкой TPM беда. Только Ubuntu сейчас предлагает изкоробочное решение для FDE с TPM без не подписанных кусков вроде initramfs. До проверки исполняемых файлов, боюсь, ждать ещё долго.

Linux IMA подпишет донос ключом защищённым от юзверя

Нет такой сущности на железе, к которому есть физдоступ, а следовательно и рут доступ.

Они доверяют TPM-2.0 и надеятся что пользователь/вирус секретный ключ с TPM не достанет. Реализация готова для промышленного использования и аудита, на кону репутация IBM: https://keylime.dev/ https://github.com/keylime/

Я лично придерживаюсь других, более строгих принципов Integrity:

1. Все перед запуском должно верифицироваться по цифровой подписи с использованием публичного ключа.
2. Использование чужих публичных ключей для верификации системы неприемлемо.
3. Наличие секретных ключей в рабочей системе недопустимо.

По этому их идею с использованием TPM для хранения секретных ключей Integrity в рабочей системе категорически не одобряю.

Предлагаю свой вариант: Поясните про secure boot (комментарий)

Всё это круто, конечно, но реально будет полезно только тогда, когда будет из коробки работать в дистрибутивах.

Никогда не будет из коробки в дистрах Integrity нормально работать. Жидомасоны не дадут.

Принципы: Поясните про secure boot (комментарий)

Схема и реализация: Поясните про secure boot (комментарий)

без не подписанных кусков вроде initramfs. До проверки исполняемых файлов, боюсь, ждать ещё долго.

Вот, дистрибутивам надо начинать именно с проверки исполняемых файлов, а не с Secure Boot.

Чем они не хотят поступится? Властью! Integrity прекрасно сегодня работает, когда ключи генерятся и хранятся у пользователя, а не у них:

Установка системы поддерживающей верифицированную загрузку проходит в обратном порядке:

1. Создаются ключи IMA/EVM. Ими подписываются все исполняемые файлы, библиотеки, настройки и неизменяемые структуры. Публичные ключи IMA/EVM помещаются в ядро Linux. Да ядро и они рд пересобираются на стороне пользователя во время установки. Секретные ключи удаляются с системы.

2. Создаются ключи GRUB2. Ими подписываются ядра которые содержат публичные ключи IMA/EVM, initramfs, модули и настрой и GRUB. Публичная скачать ключа записывается в core.img. Секретные ключи удаляются с системы.

3. Создаются свои ключи Secure Boot, а все чужие удаляются. Своим ключом Secure Boot подписывается core.img (загрузчик GRUB) который содержит публичные ключи GRUB. Секретные ключи удаляются с системы.

4. Создаются свой ключ для Intel Boot Guard. Он должен быть надёжно заархивирован, распечатан. В случае утери секретного ключа Intel Boot Guard любые изменения в UEFI станут невозможны!!! Им подписывается UDFI со своими настройками и публичными ключами Secure Boot. Секретный ключ удаляются с системы.

Инсталлятор дистрибутива должен создавать ключи и подписывать на стороне пользователя в процессе установки или обновления системы. Тогда инсталлятор будет иметь секретный ключ GRUB для подписи initrd: https://www.gnu.org/software/grub/manual/grub/grub.html#Using-digital-signatures

Можете попробовать для вашего дистра дописать модуль Integrity для инсталера и добавить в апстрим…

Shim - ненужное зло и тупик!