OpenBSD 7.7

Я и говорю, что secure boot от рута не спасает.

Ты просто его неправильно используешь. Если у тебя ядро из дистрибутива, его CA добавлен в UEFI и нет доступа на изменение UEFI, то никакой проблемы нет.

Ты просто его неправильно используешь

Конечно я его правильно использую.

Если у тебя ядро из дистрибутива, его CA добавлен в UEFI и нет доступа на изменение UEFI, то никакой проблемы нет.

Нет таких дистрибутивов. Дистрибутивы используют либо подпись микрософта, что почти равносильно отключению secureboot, либо ничего никуда не добавляют. В федоре только начали в последнее время говорить о том, что неплохо бы initramfs собирать не у юзера.

Конечно я его правильно использую.

Нет. Так как ты его используешь, он бесполезен, потому что атакующему достаточно получить рута. Что есть SB, что нет SB – разницы никакой.

Нет таких дистрибутивов.

RHEL.

Дистрибутивы используют либо подпись микрософта, что почти равносильно отключению secureboot

У тебя есть доступ к их private key? Выкладывай!

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

И, подчеркну ещё раз, initramfs они не защищают. Т.е. подменить его и вытащить ключ для расшифровки диска при следующей загрузке очень легко. Стало быть защиты от root у RHEL нет.

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

Ты нам рассказывал что «нет таких дистрибутивов». Наврал, вестимо.

И, подчеркну ещё раз, initramfs они не защищают. Т.е. подменить его и вытащить ключ для расшифровки диска при следующей загрузке очень легко. Стало быть защиты от root у RHEL нет.

Не совсем. Ты можешь валидировать ядро и модули. Т.е. ты можешь быть уверен, что все процессы, происходящие в системе, наблюдаемы со стороны ядра. Но если тебе нужен trusted boot, ты выделяешь билд-сервер и делаешь это все сам. Но то что ты делаешь с ключом в /boot это, прости пожалуйста, театр безопасности.

Театр безопасности это утверждать, что есть защита от рута, когда её нет. А я и не утверждаю. У меня защита от конкретных угроз вроде воровства ноутбука или софтовых попыток его взлома, пока меня нет. От рута я не защищаюсь, т.к. в этом нет примерно никакого смысла. Я даже от своего пользователя не защищаюсь по сути, т.к. все мои данные под ним и так доступны, у меня однопользовательская система и я смело пишу su - не переживая, что su подменили и мой пароль кто-то логгирует.

Театр безопасности это утверждать, что есть защита от рута, когда её нет.

Ты её сам придумал. Есть защита от подмены ядра и его модулей. И в случае OpenBSD можно было бы сделать все как надо, ибо ядро не меняется и initrd тоже. Но чуваки почему-то облажались на пустом месте.

У меня защита от конкретных угроз вроде воровства ноутбука или софтовых попыток его взлома, пока меня нет.

И как тут secure boot помогает-то?

И как тут secure boot помогает-то?

Secure boot помогает не вводить пароль от диска при каждой загрузке, что во-первых улучшает user experience, во-вторых защищает от логгирования этого самого пароля, если мне подменят initramfs (если сравнивать с вариантом без secure boot или с имитацией безопасности из RHEL).

Secure boot помогает не вводить пароль от диска при каждой загрузке, что во-первых улучшает user experience, во-вторых защищает от логгирования этого самого пароля, если мне подменят initramfs (если сравнивать с вариантом без secure boot или с имитацией безопасности из RHEL).

Причем здесь пароль?

Secure boot is a security standard developed by members of the PC industry to help make sure that a device boots using only software that is trusted by the Original Equipment Manufacturer (OEM).

При том, что Secure Boot обеспечивает правильную работу TPM, а TPM обеспечивает расшифровку диска.

При том, что Secure Boot обеспечивает правильную работу TPM, а TPM обеспечивает расшифровку диска.

Это вообще не связанные вещи, лол.

Конечно же это связанные вещи. Почитай про PCR 7, например.

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

Ну ок. Поработаю копипастой.

7 secure-boot-policy Secure Boot state; changes when UEFI SecureBoot mode is enabled/disabled, or firmware certificates (PK, KEK, db, dbx, …) changes.

Итого, когда мы привязываем ключ шифрования к PCR 7 (поведение по умолчанию у systemd-cryptenroll), отключение secureboot или же изменение состава сертификатов, которым доверяет secureboot делает невозможным расшифровку диска.

А secureboot сам по себе уже обеспечивает загрузку только подписанного ядра (с захардкоденной cmdline и initramfs), которое обеспечивает корректную работу с расшифрованной файловой системой.

У тебя опять все в кучу смешалось. LUKS и Secure Boot это мать его разные вещи :DDDD

Secure boot помогает не вводить пароль от диска при каждой загрузке, что во-первых улучшает user experience

Подожди, а какой тогда смысл в шифровании диска, если украв твой ляптоп я получаю доступ к системе и имею возможность вращать твой PAM как моей душе угодно? Ты опять убил весь смысл шифрования диска. Вся идея шифрования в том что через полчаса ляптоп засыпает и уходит в гибернацию.

Я же вроде всё расписал.

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

Начнём с того, что шифрование диска это важно и нужно. Если нет шифрования, во-первых могут вставить диск в другой компьютер и скопировать оттуда данные, во-вторых могут подменить любой файл и вернуть диск обратно. Это LUKS.

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

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

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

TPM до сего момента не нужен, но если не хочется вводить пароль от диска при каждой загрузке, то удобно его заюзать, в том числе для пущего удобства используя интеграцию с Secure Boot в виде PCR 7.

Можно без TPM обойтись. Если использовать один пароль для диска и для юзера и включить автологин, то оно даже автоматом будет gnome keyring открывать. Хотя по-мне это скорей анти-фича, но кому как.

Украв мой лаптоп ты получаешь возможность смотреть на экран загрузки и потом на gdm. Если знаешь магическое сочетание клавиш ctrl+alt+f2, можешь ещё на tty посмотреть. На этом всё.

Украв мой лаптоп ты получаешь возможность смотреть на экран загрузки и потом на gdm. Если знаешь магическое сочетание клавиш ctrl+alt+f2, можешь ещё на tty посмотреть. На этом всё.

https://www.rapid7.com/db/vulnerabilities/redhat_linux-cve-2019-3825/

TPM до сего момента не нужен

Молодец. Он вообще не нужен, строго говоря. Просто оказалось удобно его сделать, потому что он много где полезен.

но если не хочется вводить пароль от диска при каждой загрузке, то удобно его заюзать, в том числе для пущего удобства используя интеграцию с Secure Boot в виде PCR 7.

Линукс настолько полон дыр, что screenlock bypass находят буквально каждые пару лет. Поэтому если у тебя там что-то действительно важное, загружать ляптоп без ключа это лол.

Ну удачи искать подобные уязвимости.

Более реальный вектор атаки это всякие Thunderbolt-ы через USB, говорят они память могут читать, но я в этом не очень разбираюсь. И думаю, что в моей стране в этом никто «очень» не разбирается.

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

Но в целом я планирую исследовать systemd-homed с отдельным шифрованием home каталога, так что этот вектор атаки тоже закрывается доступными средствами. Там home каталог будет уже шифроваться паролем пользователя, вроде даже ключи при засыпании умеет удалять из памяти…

Ну удачи искать подобные уязвимости.

Недавно нашли в swaylock. Опять.

Более реальный вектор атаки это всякие Thunderbolt-ы через USB, говорят они память могут читать, но я в этом не очень разбираюсь. И думаю, что в моей стране в этом никто «очень» не разбирается.

Запросто. Ещё сетевой стек. Ещё всякая странь вроде avahi и DHCP клиентов. Тысячи вариантов.

Но в целом я планирую исследовать systemd-homed с отдельным шифрованием home каталога, так что этот вектор атаки тоже закрывается доступными средствами. Там home каталог будет уже шифроваться паролем пользователя, вроде даже ключи при засыпании умеет удалять из памяти…

А можно просто LUKS поставить и не страдать.

NVMe диски тоже не у каждого

OpenBSD успешно ставится на nvme. Проверено мною.

Я знаю. Только утилизировать их по полной не может.

https://dataswamp.org/~solene/2024-11-15-why-i-stopped-using-openbsd.html - однако, не знал что в бзде даже аудита нет. Его ж лет 15 как сделали - это ж надо настолько отстать от ликуса.

Ты пошел читать мои старые комментарии? Ты странный.

У тебя мания величия - выдохни и таблетки не забудь. Я пошёл читать топ обсуждений на ЛОР.

Это коммент месячной давности :)

Расслабься уже и посмотри список топ-обсуждений месяца. Что-то ты совсем поехал со своим ЧСВ :)

Расслабься уже и посмотри список топ-обсуждений месяца. Что-то ты совсем поехал со своим ЧСВ :)

Жыр.