LINUXTALKS.CO

Леннарт Поттеринг предложил новую архитектуру верифицированной загрузки Linux

 

L


0

0

Леннарт Поттеринг (Lennart Poettering) опубликовал предложение по модернизации процесса загрузки Linux-дистрибутивов, нацеленное на решение имеющихся проблем и упрощение организации полноценной верифицированной загрузки, подтверждающей достоверность ядра и базового системного окружения. Необходимые для применения новой архитектуры изменения уже включены в кодовую базу systemd и затрагивают такие компоненты, как systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase и systemd-creds.

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

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

В настоящее время в большинстве дистрибутивов Linux в процессе инициализации используется цепочка "прошивка → заверенная цифровой подписью Microsoft shim-прослойка → заверенный цифровой подписью дистрибутива загрузчик GRUB → заверенное цифровой подписью дистрибутива ядро Linux → не заверенное окружение initrd → корневая ФС". Отсутствие верификации initrd в традиционных дистрибутивах создаёт проблемы с безопасностью, так как среди прочего в данном окружении осуществляется извлечение ключей для расшифровки корневой ФС.

Верификация образа initrd не поддерживается так как данный файл формируется на локальной системе пользователя и не может быть заверен цифровой подписью дистрибутива, что сильно усложняет организацию проверки при использовании режима SecureBoot (для заверения initrd пользователю необходимо сгенерировать свои ключи и загрузить их в прошивку UEFI). Кроме того, существующая организация загрузки не позволяет применять информацию из регистров TPM PCR (Platform Configuration Register) для контроля целостности компонентов пространства пользователя, помимо shim, grub и ядра.Из имеющихся проблем также упоминается усложнение обновления загрузчика и отсутствие возможности ограничения доступа к ключам в TPM для старых версий ОС, ставших неактуальными после установки обновления.

Основные цели внедрения новой архитектуры загрузки:

  • Предоставление полностью верифицированного процесса загрузки, охватывающего все этапы от прошивки до пространства пользователя, и подтверждающего достоверность и целостность загружаемых компонентов.
  • Привязка контролируемых ресурсов к регистрам TPM PCR с разделением по владельцам.
  • Возможность предварительного расчёта значений PCR на основе используемых при загрузке ядра, initrd, конфигурации и локального идентификатора системы.
  • Защита от Rollback-атак, связанных с откатом на прошлую уязвимую версию системы.
  • Упрощение и повышение надёжности обновлений.
  • Поддержка обновлений ОС, не требующих повторного применения или локальной подготовки ресурсов, защищённых TPM.
  • Готовность системы для проведения удалённой аттестации для подтверждения корректности загружаемой ОС и настроек.
  • Возможность прикрепления конфиденциальных данных к определённым стадиям загрузки, например, извлечение из TPM ключей шифрования для корневой ФС.
  • Предоставление безопасного, автоматического и работающего без участия пользователя процесса разблокировки ключей для расшифровки диска с корневым разделом.
  • Использование чипов, поддерживающих спецификацию TPM 2.0, с возможностью отката на системы без TPM.

// cc-by opennet.ru
// converted with crypt’s opennet autoreposter

>>> Подробности

★★★☆☆
Ответ на: комментарий от alexferman

Только вот несмотря на эти анальные огораживания безопасности сильно не прибавляется

TheAnonymous    
★★★★★★★★★★★
Linux / Firefox
Ответ на: комментарий от Shulman

Бля, ну это пол года, не меньше.

deep-purple    
★★★★★★★★★★
Android / Firefox
Ответ на: комментарий от deep-purple

Полномочия всё

sorrow    
★★★★★★★★★★★★
Linux / Firefox
Ответ на: комментарий от crypt

У TPM нет возможности что-то запретить загружать. Он может только не отдать какой-нибудь секрет, если грузят «что-то не то» или ответить на вопрос «а то, что загрузилось, точно хорошее?».

Теоретически, можно сделать такой сервис, который бы удалённо проверял, что на клиентском компьютере установлено «хорошее ПО» под управлением «хорошей ОС», и отказывать в обслуживании, если это не так. На практике такой достаточно универсальной системы построить пока не удалось, хотя попытки были.

У пользователя по-прежнему есть свобода как не использовать TPM, так и не пользоваться сервисами, требующих удалённую аттестацию окружения.

FSF когда-то пытался бороться с trusted computing в целом (и TPM в частности), но перестал этим заниматься, так как никакой угрозы свободе пользователя в текущем виде эти технологии не несут.

kmeaw    
★★★
Linux / Chrome
Ответ на: комментарий от kmeaw

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

crypt    
★★★☆☆
FreeBSD / Chrome
Ответ на: комментарий от crypt

На телефонах и хромбуках целостность ОС проверяется не с помощью TPM - для этого есть отдельные механизмы защиты от модификаций. На телефонах они реализуются загрузчиком, часть которого работает в ARM TrustZone, на хромбуках - чипом Titan M2.

Поддержка TPM в systemd никак не помогает использованию TrustZone и Titan M2 производителем платформы. Я пока не могу придумать, как TPM можно использовать во вред пользователю, если он владеет (законно купил компьютер в магазине) машиной. А полезно для себя использовать TPM я умею - например, с его помощью могу проверить, не подменил ли кто-то /boot на удалённом сервере с зашифрованным диском, желая перехватить парольную фразу в момент её ввода.

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

С другой стороны - это защищает незаинтересованного (а таких большинство) в ковырянии в системном ПО пользователя от злоумышленника, желающего закрепиться на сломанной системе. Действительно полного контроля у нас всё равно не будет, пока нет возможности производить чипы самостоятельно, а виртуальные машины (которые контролировать пользователю сильно проще) пока никто (кроме Apple в App Store для мобильных устройств; но на это есть sideloading) не запрещал. Внутри виртуальной машины можно применять любые модификации софта. Плата за такую свободу частью оплаченной мной производительности железа мне не кажется большой.

kmeaw    
★★★
Linux / Chrome
Ответ на: комментарий от kmeaw

ты всевремя пишешь про TPM, но в новости про TPM речи не идет. в новости речь о «Предложенные изменения сводятся к созданию единого универсального образа … может быть упакована и вся система, что позволяет создавать полностью верифицированные системные окружения, загружаемые в оперативную память.»

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

crypt    
★★★☆☆
FreeBSD / Chrome
Ответ на: комментарий от crypt

Я пока не вижу в новой версии systemd никаких изменений, связанных с верификацией окружений не через TPM.

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

Пока предпосылок к появлению таких десктопов и ноутбуков нет - ведь они тогда перестанут быть компьютерами общего назначения. На UEFI, AMT/vPro, SecureBoot, BootGuard, TPM, TXT, SGX и другие похожие технологии есть заказ у корпораций, которые кормят производителей - им нужно, чтобы компьютеры, используемые на предприятии можно было удобно контролировать и обслуживать, при выходе из строя заменять компоненты, а софт безопасно и быстро обновлять. Если очередной производитель подсунет им компьютер, на котором нельзя запустить нужный им софт, они просто не купят его.

kmeaw    
★★★
Linux / Chrome
Ответ на: комментарий от kmeaw

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

Они то между собой договорятся, это ТЫ будешь жрать то, что дают.

torvn77    
★★★
Android / Chrome
Ответ на: комментарий от kmeaw

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

Это ни чем не обоснованное предположение.

torvn77    
★★★
Android / Chrome
Ответ на: комментарий от torvn77

Пока что на компьютерах работает довольно много софта, напоминающего машину Тьюринга. Уже даже в браузере можно пускать эмулятор PC/x86. Экосистемы мобильных устройств (Android, iOS) дальше всех продвинулись в отгораживании, и даже для них есть виртуальные машины.

kmeaw    
★★★
Linux / Chrome
Ответ на: комментарий от torvn77

Сомневаюсь, что, например, Apple и Google договорятся с Dell и HP, что на десктопах и ноутбуках, которые они закупают себе в офисы будет запускаться только софт от Apple и Google. Dell и HP гораздо проще сделать это настраиваемым параметром. А я просто куплю себе точно такой же ноут.

kmeaw    
★★★
Linux / Chrome
Ограничение на отправку комментариев: только для зарегистрированных пользователей, score>=90