LINUXTALKS.CO

В Fedora рассматривают возможность применения шифрования ФС по умолчанию

 

L


0

1

Оуэн Тейлор (Owen Taylor), создатель GNOME Shell и библиотеки Pango, входящий в рабочую группу по развитию Fedora для рабочих станций, выставил на обсуждение план шифрования по умолчанию системных разделов и домашних каталогов пользователей в Fedora Workstation. Из плюсов перехода к шифрованию по умолчанию называется защита данных в случае кражи ноутбука, защита от атак на оставленные без присмотра устройства, поддержание конфиденциальности и целостности из коробки без необходимости совершения лишних манипуляций.

В соответствии с подготовленным черновым планом для шифрования планируют использовать Btrfs fscrypt. Для системных разделов ключи шифрования планируют хранить в TPM-модуле и использовать в привязке к цифровым подписям, применяемым для проверки целостности загрузчика, ядра и initrd (т.е. на этапе загрузки системы пользователю не нужно будет вводить пароль для расшифровки системных разделов). При шифровании домашних каталогов ключи планируют генерировать на основе логина и пароля пользователя (подключение зашифрованного домашнего каталога будет производиться во время входа пользователя в систему).

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

В текущем виде в инсталляторе Fedora имеется опция для шифрования разделов на блочном уровне при помощи dm-crypt, используя отдельную парольную фразу, не привязанную к учётной записи пользователя. В данном решении отмечаются такие проблемы, как непригодность для раздельного шифрования в многопользовательских системах, отсутствие поддержки интернационализации и средств для людей с ограниченными возможностями, возможность совершения атак через подмену загрузчика (установленный атакующим загрузчик может притвориться оригинальным загрузчиком и запросить пароль расшифровки), необходимость поддержки framebuffer в initrd для вывода запроса пароля.

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

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

★★☆☆☆

к слову о твоем вопросе про федору, @cocucka. видишь, как они все делают? btrfs официально не поддерживается RH на RHEL. это предложение ни в п****, ни в красную армию.

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