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

Это мелкософт со своими репозиторием сертификатов для секуре бута зло

1. Покупается вторая система, настраивается, как надо adversary.

2. В случае необходимости сказать, что она вся такая немодифицированная, врет.

3. В случае необходимости что-то подписать, подписывает на первой.

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

Пользователи должны сами создавать свои сертификаты Secure Boot для подписи загрузчика. Чужие сертификаты для проверки целостности загружаемой системы использовать нельзя.

Можешь иметь хоть 100 систем для работы. Но к корпоративному VPN подключится только те, что пройдут «Linux IMA remote attestation».

Ну вот я и описал, как я это пройду с другой машины, была бы первая.

С каких пор secure boot научился менять опции монтирования ФС и настройки фаервола?

Какое отношение к этому имеет secure boot?

Да чего уж там. chmod -R a-rwx {/bin/,/sbin/}

Будет безопасно и производительность вырастет, так как лишний софт в памяти не будет висеть.

Машина, которая прошла «Linux IMA remote attestation» и подключилась к корпоративному VPN может и не иметь возможности работать роутером или ещё в какой способ передавать чужой трафик через свой VPN. IMA контролирует не только бинари и либы, а и настройки в /etc. В общем ноут на удалёнке можно очень сильно залочить и контролировать состояние многих систем его безопасности при подключении к VPN.

Это всё прекрасно и замечательно, но конкретно Secure Boot без всех остальных надстроек(99.(9)% инсталляций любых ОС) смысла не имеет. И то, что кто-то где-то включил у себя отдельно secure boot, непосредственно к secure отношения не имеет никакого.

Я уже понял, что ты верующий в «к VPN может подключиться только машина, прошедшая IMA». Мне бы ссылку на какое-то святое писание, потому что ты не в состоянии мне объяснить, чего бы вдруг мне помешало держать эту машину только ради IMA, а с нормальной машины не притвориться IMAнутой.

Это не про конкретно секьюр бут, это про то что можно залочить всё в ноль и даже свою систему не запустить чтобы это обойти.

понял, что ты верующий

У меня работает простая и правильная реализация Integrity более 5 лет, использует старую IMA с моими правилами. Все ключи свои. Никаких проблем с Integrity, всем советую.

Сегодня перевод нового IMA на LSM мне не нравится и очень не нравится возможность IMA слать чужим сервакам состояние безопасности моей OS.

Можно держать две разные машины. Можно на одной машине держать две системы.

Меня интересует из-за какакой такой религии в дистрибутивах Linux почти все желают удержать ключи у себя, а не написать простой инсталер где ВСЕ ключи создаются на стороне пользователя в процессе установки?

У меня работает простая и правильная реализация Integrity более 5 лет, использует старую IMA с моими правилами. Все ключи свои. Никаких проблем с Integrity, всем советую.

Где-то есть результаты аудита этой мертвому припарки?

Ты решаешь нерешаемую задачу. Если тебе кажется, что твоя IMA от чего-то защитила, тебе кажется.

Поставь у себя и проведи аудит: измени любой бинарь, конфиг либу или их права доступа или хеши/подписи, а потом попробуй запустить и смотри в логи.

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

Я знаю, что такое integrity. Я не спорю с тем, что иногда лучше эти проверки иметь, чем не иметь. Я спорю с тезисом, что этот велосипед полностью предотвращает возможность коннектиться к VPN с произвольных тостеров. Даже в теории это нифига не защита.

Ещё раз, каким механизмом это бы энфорсилось, фантазеры? Что мешает мне запустить Python, там взять syscall из libc и отплясывать что хочу?

Python помешает запусть DAC: отсутствие x на /usr/bin/python3 или MAC, если очень упороться.

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

mount обычному пользователю недоступен

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

Secure boot обеспечивает цепочку проверок загружаемого софта, начиная от UEFI, и записывает результаты в TPM PCR. Эти результаты можно использовать для удалённой аттестации, а можно на доверенные значения PCR лочить ключи аутентификации.

«любимая bring-your-own-железяка нерадивого сотрудника» даже к сети организации подключиться не сможет потому, что у неё нет ключей аутентификации и она 802.1X не пройдёт.

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

• Что такое TPM и какие функции он несёт
• Что записывается в PCR и как этим можно пользоваться
• Как работает key sealing с TPM PCR

Покупается вторая система, настраивается, как надо adversary. В случае необходимости сказать, что она вся такая немодифицированная, врет. В случае необходимости что-то подписать, подписывает на первой.

Это не работает, потому, что во второй системе нет ключей. И на первой тех ключей, которыми бинарники подписываются, нет. Они вообще могут быть только у производителя операционной системы.

Это всё прекрасно и замечательно, но конкретно Secure Boot без всех остальных надстроек(99.(9)% инсталляций любых ОС) смысла не имеет. И то, что кто-то где-то включил у себя отдельно secure boot, непосредственно к secure отношения не имеет никакого.

Secure boot позволяет добиться определённых гарантий целостности, которые являются частью комплекса мер безопасности. Безопасность проявляется именно в комплексе, бессмысленно рассматривать части в отдельности. Сказать «secure boot смысла не имеет» - всё равно, что сказать «DAC смысла не имеет» потому, что можно с флешки загрузиться.

Integrity даёт гарантию целостности загружаемой системы.

для каких-то встраиваемых девайсов

У нас же есть смартфоны в качестве примера. Залочивают всё так, что инструкции по рутованию через годы появляются.

А ещё есть Playstation.

Это всё для того, чтобы в магазинах продавать софт за деньги, да.

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

Я спорю с тезисом, что этот велосипед полностью предотвращает возможность коннектиться к VPN с произвольных тостеров. Даже в теории это нифига не защита.

этот велосипед может:

• запечатывать ключи в TPM на определённые значения PCR. Если PCR неправильный, то ключ недоступен и аутентификация VPN просто не работает. У Microsoft хорошо описаны базовые функции: https://learn.microsoft.com/en-us/windows/security/hardware-security/tpm/tpm-fundamentals

Devices that incorporate a TPM can also create a key wrapped and tied to certain platform measurements. This type of key can be unwrapped only when those platform measurements have the same values that they had when the key was created. This process is referred to as sealing the key to the TPM. Decrypting the key is called unsealing. The TPM can also seal and unseal data that is generated outside the TPM. With sealed key and software, such as BitLocker Drive Encryption, data can be locked until specific hardware or software conditions are met.

Вот всё тоже самое, только вместо Bitlocker - приватный ключ для VPN.

• обеспечивать remote attestation через TPM PCR, отправляя подписанные значения PCR (с защитой от replay атаки). Ключ подписи тоже находится в TPM и залочен на доверенное значение PCR, поэтому подписывать им запросы к тостеру не получится. Больше про протокол можно почитать тут: https://tpm2-software.github.io/tpm2-tss/getting-started/2019/12/18/Remote-Attestation.html

Ключевой момент:

The attestor loads the Endorsement Key (EK) and Attestation Key (AK), if they are not already loaded, and issues a TPM2_Quote command to the TPM, referencing the Attestation Key. TPM will only be able to use the key if the given PCRs will be in a valid state, defined at the time when the PCR policy is created. After that TPM creates and signs an instance of TPMS_ATTEST structure as defined by [5] and sends it back to the verifier. The Verifier uses the information included in the TPMS_ATTEST structure to perform appraisal by validating the public part of the AK and comparing the software measurement logs (Event Log) against the good-know-state of the system software configuration stored in the local database.

Для того, чтобы TPM выполнил запрос на аттестацию, нужно, чтобы он работал на системе с secure boot, и нужным значением PCR. То есть, нельзя загрузить свою убунту на доверенный ноутбук и разговаривать с TPM, представляясь VPN сервером, PCR будет другой и TPM не будет ничего аттестовать. Нельзя разговаривать с TPM с поддельного сервера, потому, что операционная система находится в гарантированно известном состоянии, и не станет с левым сервером говорить. Нельзя реплеить атаку, потому, что сервер отправляет challenge и следит за их использованием.

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

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

У вас эта вера есть. Это именно что вера, потому что «а я запрещу выполнять баш и вообще все бинари» только для совсем неинтерактивных киосков подходит, сотруднику интеллектуального труда такой ноут не дашь.

Простыни про все остальное мне не нужны, не надо каждый раз их писать.

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

Вот взламаешь Linux IMA remote attestation с аппаратными фича и Secure Boot и TPM-2.*, тогда и приходи с готовым решением.

Использование TPM-2.* в GNU/Linux может быть очень полезным не только для удаленной аттестации. TPM-2.* не самое плохое хранилище ключей. Состояния PCR с TPM-2.* можно использовать и в локальных средствах контроля безопасности и защиты от булкитов.

Перечитав ветку опять хочу сделать акцент на базовом понимании принципов Integrity и цепочки верификации загрузки:

Intel Boot Guard -> Secure Boot -> GRUB -> Linux IMA/EVM

Покупается вторая система, настраивается, как надо adversary. В случае необходимости сказать, что она вся такая немодифицированная, врет. В случае необходимости что-то подписать, подписывает на первой.

Это не работает, потому, что во второй системе нет ключей. И на первой тех ключей, которыми бинарники подписываются, нет. Они вообще могут быть только у производителя операционной системы.

Опять сделана стандартная ошибка которую делают, возможно умышленно, все разрабы Линукс дистрибутивов. Именно эта стандартная ошибка мешает внедрению Integrity в дистрибутивах GNU/Linux «из коробки». Уже дважды в этом треде на этом акцентировал:

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

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

Ещё раз напомню 3 базовых аксиомы Integrity:

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

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

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

Теперь, уже в третий раз, подробнее рассмотрим как правильно организовать Integrity на компе пользователя.

Теорема о ключах Integrity.

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

То есть полная верификация системы загрузки возможна только в случае когда все ключи: Intel Boot Guard, Secure Boot, GRUB, Linux IMA/EVM - создаёт конечный пользователь (администратор) системы.

Доказательство:

1. Ключи IMA/EVM. Пользователь (админ) установил GNU/Linux на свою машину. После установки ВСЕГДА необходимо настроить систему GNU/Linux иэизменив файлы настроек в /etc/. После из мнения файлов в /etc/ их необходимо заново переподписать, а значит конечному пользователю необходимо иметь приватные ключи IMA/EVM для создания новой подписи. Следовательно ключи IMA/EVM должны создаваться на компе конечного пользователя.

2. Ключи GRUB. Свои созданные ключи IMA/EVM пользователь вынужден добавить в ядро Linux и/или initrd в зависимости от конкретной реализации IMA/EVM в конечной системе. А значит ядро Linux и initrd будут ВСЕГДА изменены конечным пользователем в процессе установки. Также в процессе установки системы будет изменён конечным пользователем файл /boot/grub/grub.cfg. Изменённые ядра, initrd, файл настроек загрузчика необходимо подписать приватным ключом GRUB в процессе установки, а значит конечному пользователю необходимо иметь приватные ключи GRUB для создания новых подписей. Следовательно ключи GRUB должны создаваться на компе конечного пользователя.

3. Ключи Secure Boot. Свои созданные ключи GRUB пользователь вынужден добавить в начальный загрузчик GRUB - core.img. А значит core.img будет ВСЕГДА изменён конечным пользователем системы в процессе установки. Измененный core.img необходимо подписать приватным ключом Secure Boot в процессе установки, а значит конечному пользователю необходимо иметь приватные ключи Secure Boot для создания новой подписи. Следовательно ключи Secure Boot должны создаваться на компе конечного пользователя.

4. Ключ Intel Boot Guard. Свои созданные ключи Secure Boot пользователь вынужден добавить в UEFI. А значит общее содержание UEFI ВСЕГДА будет изменено конечным пользователем во время установки системы. Измененные части UEFI необходимо подписать приватным ключом Intel Boot Guard в процессе установки, а значит конечному пользователю необходимо иметь приватный ключ Intel Boot Guard для создания новых подписей. Следовательно ключ Intel Boot Guard должен создаваться на компе конечного пользователя.

Вот взламаешь Linux IMA remote attestation с аппаратными фича и Secure Boot и TPM-2.*, тогда и приходи с готовым решением.

Я не это «ламаю», а вы глухие тут все или что. Положенный сбоку модифицированный клиент VPN вашей attestation не покрыт => она от него не защищает даже в теории.

Ладно, к удаленной аттестации пока отношусь насторожено и не использую.

IMA не даст запустится левому VPN клиенту. А левому IMA пропускающиму левый VPN уже TPM-2.* не даст ключики необходимые для шифрования и подписи левого ответа на аттестацию.

Предлагаю всем внедрять Integrity по моему алгоритму без использования TPM-2.*

Технологии TPM-2.* можно отдельно использовать локально для дополнительной защиты от буткитов и как аппаратное хранилище ключей.

что можно так запечатать юзерспейс

Это не юзерспейс. Юзерспейс выполняет исключительно роль транспорта, как недоверенный роутер где-то в интернете. Роутер сколько угодно может быть недоверенным, это не мешает TLS или VPN создать защищенное соединение. Роутер может пакеты дропать, и юзерспейс может пакеты дропать, но тогда клиент этот просто аттестацию не пройдёт.

чтобы я его не расколупал, не порутал и не научился либо подписывать вообще что угодно

в вот это уже даже не вера, а так - самоуверенность. :) Как только сможешь - проходи. На Pwn2Own за это номально денег отсыпят, вперёд.

Простыни про все остальное мне не нужны, не надо каждый раз их писать.

Это для тех, кто разобраться хочет.

Это не юзерспейс. Юзерспейс выполняет исключительно роль транспорта, как недоверенный роутер где-то в интернете.

А вот хренушки, вы ему доверяете, что он не скажет TPMу подписать хэндшейк для чужого соединения. И слепое отрицание этого вас не красит.

Как только сможешь - проходи. На Pwn2Own за это номально денег отсыпят, вперёд.

Могу предложить круче. Присылаете ноут, который из коробки подключается к VPNу и открывает браузер с внутренним урлом. Я подключаюсь туда же со своего девайса, вы увольняет всех обалдуев, вравших вам, что это секьюрно, а мне отдаёте каких-то 10% их зарплаты за три года.

А вот хренушки, вы ему доверяете, что он не скажет TPMу подписать хэндшейк для чужого соединения. И слепое отрицание этого вас не красит.

Для этого надо на доверенной машине с secure boot как-то это сказать TPM’у. Чем и как?

Могу предложить круче.

Нет, pwn2own круче, чем я. Там будет мировая слава.

Присылаете ноут, который из коробки подключается к VPNу и открывает браузер с внутренним урлом. Я подключаюсь туда же со своего девайса, вы увольняет всех обалдуев, вравших вам, что это секьюрно, а мне отдаёте каких-то 10% их зарплаты за три года.

Спасибо, мне пентесты делают. Обязательно в скоуп включу на следующий год. Пока всё, что нашли - это поснифать с i2c шины ключи в случае дискретного TPM. Что, безусловно, значимый результат, но к делу не относится.

Дополню практическими ссылками на инструкции по настройке Integrity.

Linux IMA/EVM.

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

https://ima-doc.readthedocs.io/en/latest/index.html

https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture

https://wiki.gentoo.org/wiki/Extended_Verification_Module

Лично мне пришлось чуть править файл: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/security/integrity/ima/ima_policy.c По умолчанию реализована классическая политика TCB. Она для GNU/Linux не подходит. Много изменяемых файлов в TMP, LOG, … пишутся под пользователем root. Это надо разрешить правилами. А все что мапится в память для исполнения - проверять. В системах с initrd надо позаботится о XATTR атрибутах с подписями или подкорректировать для его запуска правила.

GRUB2.

https://www.gnu.org/software/grub/manual/grub/grub.html#Using-digital-signatures

UEFI Secure Boot

Матплата должна поддерживать удаление всех чужих ключей Secure Boot и добавление своего публичного ключа Secure Boot. А ещё лучше поддерживать libreboot, coreboot.

https://habr.com/en/post/273497

Security Boot и подпись загрузчика Windows (комментарий)

Intel Boot Guard

Если матплату и проц покупать раздельно, то пользователь будет иметь возможность единожды прописать ключ Intel Boot Guard в спец область ROM где-то в IntelME. Отключить Intel Boot Guard или изменить его ключ физически будет невозможным. Это безоткатная операция. По этому терять ключ Intel Boot Guard нельзя. Информации о том как закрытый, проприетарный IntelME проверяет целостность UEFI и ключей Secure Boot почти нет.

https://github.com/corna/me_cleaner/wiki/Intel-Boot-Guard

Никаких технических проблем для поддержки по умолчанию Integrity в Linux IMA/EVM и GRUB2 - во всех дистрибутивах GNU/Linux не существует! Надо просто чуть подправить инсталлер каждого дистрибутива.

Поддержка Secure Boot и Boot Guard зависит от производителя железа. Возможна опциональная поддержка для конкретного железа.

Для этого надо на доверенной машине с secure boot как-то это сказать TPM’у. Чем и как?

Произвольным кодом, очевидно, я уже говорил. И да, я слышал, что у тебя есть IMA (которой все не покрыть) и якобы запрещён запуск всех бинарников, скриптов, верб-страниц и вообще разъём питания отпаян, работать на таком нельзя.

pwn2own круче, чем я. Там будет мировая слава.

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

https://www.opennet.ru/opennews/art.shtml?num=61610

Все что надо знать покупателю это:

1. Версию прошивки с UEFI > 2.3.1C

2. Возможность удаления текущего PK и перевод Secure Boot в Setup Mode

3. Дистрибутив GNU/Linux без systemd, и с поддержкой Integrity (Secure Boot, GRUB, Linux IMA/EVM)

Дистрибутив GNU/Linux без systemd

Когда вас всех уже на дурдом заберут?

https://www.opennet.ru/opennews/art.shtml?num=57984

https://www.opennet.ru/opennews/art.shtml?num=58045

У нас все нормально. Это у вас проблемы. И дурак вам не поможет, только усугубит. Хозяйва на поводке держат, ключи создавать не дают. Водят вокруг сызды, как Мойсей водил пока не здохли там… А вы отравленные и облученные ослепли. В место того, чтобы просто подписать загрузчик своим ключом Secure Boot, как требует теория, ведетесь как стадо на shim, systemd-boot, другуюю дрянь от поцтеринга… Ещё и ядом плюетесь в сторону людей, которые хотят вам глаза приоткрыть. Просто неблагодарный стадный скот.

Нашел бъяснение сложной теоремы Integrity для местных домохозяек на примере замка от квартиры. Поймут, может расслабляться и нервничать перестанут:

Gentoo анонсировали бинарную сборку gentoo-kernel-bin (комментарий)

Gentoo анонсировали бинарную сборку gentoo-kernel-bin (комментарий)

Gentoo анонсировали бинарную сборку gentoo-kernel-bin (комментарий)

Вот настоящий ресеч и настоящая проблема: https://arstechnica.com/security/2024/07/secure-boot-is-completely-compromised-on-200-models-from-5-big-device-makers/

Да, я видел: https://social.unboiled.info/notice/AkIfIThV7urMH4HaO8