LINUX.ORG.RU

systemd-boot+LUKS+ESP on /efi. Когда?

 ,


0

0

Собственно, сабж. Почему до сих пор невозможно сделать следующую связку?

  • systemd-boot.

  • Незашифрованый ESP-раздел, примонтированный в /efi.

  • LUKS-шифрование разделов / и /home (/boot не отдельно).

Что им мешает сделать то, что с GRUB2 давно работает?

★★★★★

Последнее исправление: Korchevatel (всего исправлений: 2)

Потому что у них нет желания реализовавывать luks-шифрование, очевидно же.

Либо используй grub, либо отдельный /boot, в чем проблема?

systemd-boot хорош легковесностью, от некоторого количества незашифрованного кода тебе все равно не избавиться.

derlafff ★★★★★
()
Последнее исправление: derlafff (всего исправлений: 1)
Ответ на: комментарий от derlafff

в чем проблема?

Интересует сама возможность. Так-то в /boot образы ядер хранятся, и мне кажется, что если кто, к примеру, ноутбук украдёт, то сможет над ними пошаманить и внедрить вредоносный код, что поможет обойти шифрование. КМК, с /efi шансов на такое меньше – там только grubx64.efi.

Возможно, что я ошибаюсь, и это всё из разряда фантастики, но приходится «по долгу службы» по всяким учреждениям шататься, мало ли.

от некоторого количества незашифрованного кода тебе все равно не избавиться

Главное, чтобы на его основе не смогли расшифровать зашифрованное.

Korchevatel ★★★★★
() автор топика

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

intelfx ★★★★★
()
Ответ на: комментарий от Korchevatel

там только grubx64.efi.

Этого вполне достаточно.

Эта проблема решается только подписыванием кода, никак не его шифрованием.

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

Таскай /boot на флешке, а флешку в анусе.

derlafff ★★★★★
()
Последнее исправление: derlafff (всего исправлений: 1)
Ответ на: комментарий от X512

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

anonymous
()
Ответ на: комментарий от X512

Модули ядра подписать нельзя?

Что это меняет?

anonymous
()
Ответ на: комментарий от intelfx

initrd тоже замечательно подписывается.

Только если ты используешь свои ключи. Дистрибутивный initrd подписывать будет некому.

anonymous
()
Ответ на: комментарий от anonymous

Только если ты используешь свои ключи.

А разве есть какой-то другой вменяемый способ использовать Secure Boot?

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

А разве есть какой-то другой вменяемый способ использовать Secure Boot?

Поставщики сами подписывают ядро, модули и загрузчик. Как минимум Debian, Canonical, RedHat.

anonymous
()
Ответ на: комментарий от anonymous

Поставщики сами подписывают ядро, модули и загрузчик

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

И кстати нет, насколько я помню, в Secure Boot можно добавлять в хранилище ключей отдельные хэши бинарников. Не помню подробностей, но казалось бы, для загрузки локально генерируемых initcpio — самое то.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Ну так это невменяемый способ.

Специалисты по вменяемости ITT, все в дурку!

И не сами, а идут на поклон к негрософту.

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

И кстати нет, насколько я помню, в Secure Boot можно добавлять в хранилище ключей отдельные хэши бинарников. Не помню подробностей, но казалось бы, для загрузки локально генерируемых initcpio — самое то.

Звучит знакомо, надо ознакомиться для общего развития.

anonymous
()
Ответ на: комментарий от InterVi

Для некоторых есть сервисные коды, развинчивать не надо. Без самоподписанного загрузчика и полнодискового шифрования дырка остается. Помимо встроенных

anonymous
()
Ответ на: комментарий от X512

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

InterVi ★★★★★
()
Ответ на: комментарий от anonymous

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

InterVi ★★★★★
()

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

WitcherGeralt ★★
()
Ответ на: комментарий от X512

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

ЗЫ md5sum /boot/* и /boot/*/* в кроне тоже неплохо выполнять и хранить на шифрованном руте.

s-o
()
Последнее исправление: s-o (всего исправлений: 1)
Ответ на: комментарий от Korchevatel

Так-то в /boot образы ядер хранятся, и мне кажется, что если кто, к примеру, ноутбук украдёт, то сможет над ними пошаманить и внедрить вредоносный код, что поможет обойти шифрование.

Если ты настолько этого боишься - используй secure boot и подписанные ядра.

Pinkbyte ★★★★★
()
Ответ на: комментарий от s-o

Зачем это все, если есть прямой доступ к насителю пароля? Шантаж, запугивание… Средств столько, что нет смысла их все перечислять.

anonymous
()
Ответ на: комментарий от anonymous

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

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

s-o
()
Последнее исправление: s-o (всего исправлений: 1)
Ответ на: комментарий от anonymous

так ты прояви фантазию, купи лак, что продается не везде, - со звездочками какими-нибудь :D

s-o
()
Ответ на: комментарий от s-o

Отличная идея сравнивать не сравнимое.

Что у тебя имеется секретного на разделе под luks?

Пароли, как правило, спрятаны в менеджерах паролей. Адекватные люди не хранят фото-, видеоматериалы из коллекции «толстый питон душит мокрую киску» с остальными подобными материалами с отпуска, дня рождения. Для этого есть отдельный носитель. Сверх секретного кода у тебя нет. Игры, музыку и т.п. тоже нет смысла шифровать.

Так чтоб у тебя есть?

anonymous
()
Ответ на: комментарий от anonymous

сразу «несравнимое» и перевод темы пошел.

давай поиграем дальше про квартиру - тебе ведь дверь не нужна, потому как деньги^W «Пароли, как правило, спрятаны в менеджерах паролей. Адекватные люди не хранят фото-, видеоматериалы из коллекции «толстый питон душит мокрую киску» с остальными подобными материалами с отпуска, дня рождения. Для этого есть отдельный» сейф в банке. Так зачем тебе дверь?

s-o
()
Ответ на: комментарий от s-o

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

Возможно, боишься, что узнают твою историю похождения на pornhub? Так анонимный режим нужно использовать)

anonymous
()
Ответ на: комментарий от anonymous

Ты на вопрос ответь.

разрешите исполнять? много хочешь, мало получишь.

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

s-o
()
Последнее исправление: s-o (всего исправлений: 1)
Ответ на: комментарий от s-o

разрешите исполнять?

Разрешаю тебе сохранять историю с pornhub, но только на разделе с luks, а то одноклассники при случае засмеют.

anonymous
()

Что им мешает сделать то, что с GRUB2 давно работает?

Отсутствие желания? Отсутствие финансирования? Отсутствие мозгов?

В FreeBSD искаропки поддерживается шифрование / (/boot является частью rootfs), пароль предлагает ввести ещё до меню выбора ядра.

mord0d ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.