LINUX.ORG.RU

Реализация поддержки универсальных образов ядра в fedora 38

 , uki,


0

2

В выпуске Fedora 38 предложено реализовать первую стадию перехода на модернизированный процесс загрузки, ранее предложенный Леннартом Поттерингом для организации полноценной верифицированной загрузки, охватывающей все этапы от прошивки до пространства пользователя, а не только ядра и загрузчика. Предложение пока не рассмотрено комитетом FESCo (Fedora Engineering Steering Committee), отвечающим за техническую часть разработки дистрибутива Fedora.

Компоненты для реализации предложенной идеи уже интегрированы в systemd 252 и сводятся к использованию вместо образа initrd, формируемого на локальной системе при установке пакета с ядром, унифицированного образа ядра UKI (Unified Kernel Image), генерируемого в инфраструкуре дистрибутива и заверенного цифровой подписью дистрибутива. UKI объединяет в одном файле обработчик для загрузки ядра из UEFI (UEFI boot stub), образ ядра Linux и загружаемое в память системное окружение initrd. При вызове образа UKI из UEFI предоставляется возможность проверки целостности и достоверности по цифровой подписи не только ядра, но и содержимого initrd, проверка достоверности которого важна так как в данном окружении осуществляется извлечение ключей для расшифровки корневой ФС.

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

>>> Подробности (OpenNet)

★★★

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

Ответ на: комментарий от t184256

Если федорасты так сказали, значит так и будет.

Чот рановато я списал фряху в утиль.

Придется или жрат кактус или жрат кактус.

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

Как автор как принятого, так и отвергнутого Fedora Change Proposal, я не очень понимаю, что ты хотел сказать. Всё будет как пойдёт.

t184256 ★★★★★
()

походу все идет к тому, что раздел boot уйдет в небытие.

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

Желаю неудачи в достижении вредной цели.

И в чем вред-то? Как раз более чем трезвая идея.

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

Я плюс-минус так делал на арче уже достаточно давно.

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

А чего только фряху-то :) Есть еще OpenBSD, как минимум.

А если есть деньги - есть нормальный юникс aka macOS, до которого Леннарты не добрались.

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

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

И на таких системах не будет загружаться оффтоп! (надеюсь)

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от DrRulez

Театр безопасности (от чего защищает secure boot и все эти measured buzwords?), желание юзать механизмы просто потому, что они есть, упрощение чего попало ценой усложнения жизни пользователям с потерей гибкости. Как по мне, троллейбус из буханки.

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

Secure boot и прочие технологии измерения всего защищают от злоумышленника, получившего временный рут на машине (например с помощью 0-day exploit) и желающего оставить себе доступ после того, как дыра будет закрыта обновлением. И от злоумышленника, который хочет расшифровать диск или как-то ещё повлиять на дальнейшую работу систем, имея ограниченный физический доступ (может менять содержимое диска, по-быстрому воткнув его в свой ноут, но не может перепаять флешку на плате).

Да, можно решить все эти проблемы физической перемычкой read-only на загрузочном носителе, но такое решение не масштабируется.

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

есть нормальный юникс aka macOS, до которого Леннарты не добрались

лол, ничего, что macOS и есть главное вдохновение для Леннарта (он сам про это говорил)? популяризация EFI с них и началась, а systemd на ранних этапах просто копировал launchd

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

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

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

от чего защищает secure boot и все эти measured buzwords?

От использования пользователем. Резко повышается нужность самого разработчика.

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

Мне кажется руткиты уже ушли в область прошивок, самого эфи и криптоанклава/ чипа удалённого управления (это же всё ещё 2 независимых подсистемы?). А если ещё не ушли, то кто это гарантирует?

kirill_rrr ★★★★★
()

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

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

защищают от злоумышленника, получившего временный рут на машине

Выражаясь цензурно, поздно пить боржоми. Это помимо того, что не защищает.

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

Значит может и материнку перекрутить. Или записать видео процесса загрузки, и подменить ноут ноутом-кейлоггером.

Серьёзно, measured boot «от прошивки до пространства пользователя» — классная штука для proof of concept в research paper, одиноко торчащая секция забора на въезде в пустыню. Пока не придумают, как её расширить, деплоить её как-то странно и нелепо.

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

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

Как вариант, могу предположить следующее:

  1. Через Secure boot загружается этот самый UKI.
  2. Сам UKI ключи шифрования root-раздела естественно не имеет, поскольку ключи могут быть известны только пользователю, иначе это была бы дыра эпических масштабов, и любой нормальный человек на такое естественно не пойдёт.
  3. UKI должен содержать средства позволяющие смонтировать зашифрованный root-раздел, и похоже поэтому эти средства впихнули в этот самый образ, вроде как для их верификации ещё до запуска.
  4. UKI загружается, получает от пользователя набор ключей для расшифровывания root-раздела, после чего монтирует его, и передаёт управление загруженному с root-раздела пользовательскому ядру.

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

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

Чот рановато я списал фряху в утиль.

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

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

если развитие пойдёт по самому зловещему сценарию

Хорошо бы не дожить.

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

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

AVL2 ★★★★★
()

Звучит как загрузка строго специфических ядер.

Shadow ★★★★★
()

Тео вся надежда на тебя.

Жду линукслятора и бхайв на опенок. И нафиг этот ваш цирк

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

В том, что поддержка secure boot становится все важнее и это хорошо, что в федоре это понимают.

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

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

Из текста новости создаётся впечатление, что именно туда их и засунули.

И вообще, в предложенной схеме гипертрофированного загрузчика оно действительно выглядит как то страно, сложно и гипертрофировано. С другой стороны, это именно то, что любит РэдХат и лично Поттеринг.

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

Ну вот как раз параметры загрузки ядра можно передавать через конфиг загрузчика.

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

Если UKI подписывается ключом дистрибутива, то как тогда будут существовать ядра собираемые пользователем? Да и сильно сомневаюсь что получится без проблем отказаться от параметров загрузки ядра.

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

Из текста новости создаётся впечатление, что именно туда их и засунули.

То есть как засунули? O_o

Если ключи шифрования дисков будут одни на всех, и при этом их ещё и можно будет извлечь из UKI, то в чём тогда смысл шифрования?!

Да и в новости, насколько я понял, говорится что в UKI попадают только средства для расшифровывания, но не ключи. Или, возможно, речь идёт о ключах шифрования initrd? Но какой смысл в шифровании initrd? Тем более что ключи для расшифровывания будут в том же UKI…

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

Свои ядра - своим ключом.

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

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

Так никогда не было. Сначала подписывали загрузчик, потом ядро, теперь подписывают ядро, модули, в том числе и модули дкмс, а теперь предлагают объеденить и подписывать всю среду загрузки - ядро, инитрд и опции загрузки, чтобы исключить загрузку неавторизированного кода.

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

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

Тогда и secure boot нет и весь разговор теряет смысл. Подходи кто хочешь, бери, чего хочешь…

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

Компу пора на свалку?

Хорошее серверное оборудование. Стоит в стойке в датацентре. Свои задачи выполняет на сто процентов. И лет десять ещё нормально проработает. Срочно бежать выкидывать? Что предложете взамен?

qwe ★★★
()
Последнее исправление: qwe (всего исправлений: 1)

Это не ответ, а просто мысль-ответ-мысль-предположение: ощущение, что редхат будет реализовывать бесшовную централизованно-управляемую реализацию шифрованых клиентов аля виндоклиенты с битлоком на винтах, которые терять нестрашно. Да , наколхозить это можно руками и сейчас - но это хэнд-мэйд-колхоз…. А тут все потестят-попробуют-обкатают…

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

Как автор как принятого, так и отвергнутого Fedora Change Proposal, я не очень понимаю, что ты хотел сказать. Всё будет как пойдёт.

Сравнил себя с Поттерингом.

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

В текущей убогой реализации в линуксе - не защищает. Именно это systemd планирует исправить.

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