klink0v (klink0v) wrote,
klink0v
klink0v

Размышления на тему eCryptfs

... Для предотвращения ситуации, когда некто может воспользоваться информацией с дисков потерянного / украденного ноутбука, привык пользоваться LUKS-ом. Но в нашу эру постепенного отмирания магнитных носителей и распространения флешек и SSDшек приходится потихоньку перебираться на eCryptFS. Потому как применение сплошного блочного шифрования по отношению к SSDшкам сразу говорит "до свидания" TRIM-у и приводит к существенному уменьшению скорости записи, а мы ведь этого не хотим. Кроме того, попытка засунуть образ блочного устройства на какой-нибудь Яндекс.Диск и иже с ними не приведёт ни к чему хорошему. То есть чисто формально взлетит, но пользоваться этим будет некомфортно / невозможно. А вот залить туда копию eCryptFS — вполне себе годный вариант.

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


  1. Всякие гипервизоры типа QEMU/KVM, VirtualBox и иже с ними не смогут запустить виртуальную машину, если образ её диска зашифрован при помощи eCryptfs. Почему — не знаю. А вот с LUKS-раздела вполне себе работает. Видимо, это какое-то принципиальное ограничение.

  2. В случае с LUKS-разделом создается специальная область с метаданными, где хранятся параметры шифрования, симметричный ключ для доступа непосредственно к блокам с payload и так называемые KeySlot-ы, в которых хранится оный ключ, зашифрованный пользовательскими PassPhrase-ами / паролями (их может быть несколько) плюс хеши для его верификации (а правильно ли пользователь ввёл пресловутый пароль али очепятался где-то). В eCryptfs ничего подобного не предусмотрено, из чего следует необходимость в наличии целого ряда костылей, см. далее.

  3. В случае с LUKS-ом можно в любой момент поменять passphrase. В этом случае просто добавляется / подменяется соответствующий keyslot в области метаданных и работаем дальше. Если хочется поменять passphrase для eCryptfs, придется создавать новый экземпляр (копию) оной и переносить (т.е. фактически перешифровывать) все данные (всю payload).

  4. Чтобы не страдать неприятностями из предыдущего пункта, во всех популярных дистрибутивах предусмотрена возможность создания специального файлика под названием "wrapped-passphrase", где хранится пароль от файловой системы (обычно 32 символа), зашифрованный паролем пользователя (как правило, совпадает с паролем от входа в систему). Но есть нюанс, да. Случайно безвозвратно потерять/удалить этот волшебный файлик означает лишиться всей своей информации. Кроме того, если мы шифруем переносное устройство (например, флешку) или контейнер в облаке, то пресловутый "wrapped-passphrase" нам придётся таскать с собой всюду, откуда хочется иметь доступ к нашим данным. Неудобно.

  5. В момент ввода пользователем пароля изначально нет возможности проверить, ввёл ли он его верно. Поэтому в параметрах монтирования помимо прочего приходится явно указывать хеши / сигнатуры этого самого пароля.

  6. Да и вообще, в параметрах монтирования ecryptfs приходится указывать всё подряд. Потому что больше ядру эту информацию взять просто неоткуда. Из-за этого команда монтирования и/или строка в fstab-е распухает до весьма внушительных размеров.

  7. Создать eCryptfs означает просто смонтировать её в какую-нибудь пустую папку. Как таковой никакой процедуры инициализации не требуется.

  8. Место хранения "сырых" зашифрованных данных не может располагаться внутри поддерева директории, в которую происходит монтирование. Но это вполне логично.

  9. Папку, которая будет играть роль точки монтирования для [будущей] eCryptfs, имеет смысл создавать с правами 500 (dr-x------). Такой подход предотвратит возникновение ситуации, когда вы что-то запишите внутрь приватного каталога, забыв предварительно смонтировать eCryptfs. То есть на диске случайно / по_ошибке / по_невнимательности не окажется незашифрованных данных.

  10. В комплекте с большинством популярных дистрибутивов идёт набор скриптов, который позволяет без прикладывания особых умственных усилий просто нажатием пары кнопок зашифровать свой "/home". Однако не всем оно придётся по душе. Об этом ниже.

... Некоторым условным недостатком eCryptfs можно считать то, что довольно затруднительно скрыть сам факт её наличия. То есть, например, размонтированный LUKS-овый раздел ничем не отличается от белого шума. И обнаружить его можно только по наличию заголовка с метаданными, а для этого придётся на низком уровне анализировать содержимое жёсткого диска, что требует определённой квалификации исследователя. В случае с eCryptfs всё сильно проще. Достаточно просто обратить внимание на папочку "/home/.ecryptfs", либо внимательно прошерстить файловые системы на всех доступных разделах. Кроме того, при использовании "изкоробочных" скриптов (см. пункт 10) по умолчанию wrapping passphrase совпадает с паролем от входа в систему. Что открывает широкие возможности для терморектального криптоанализа и сужает перспективы подопытного пациента отмазаться либо прикинуться шлагом.

... Частично вышеобозначенную неприятность можно обойти, если положить в папку "/home/.ecryptfs/<username>/.ecryptfs/" пустой файл с именем "wrapping-independent". В этом случае в момент логина у вас будут спрашивать два пароля: от входа в систему отдельно, от файловой системы отдельно. Но мне лично такой вариант тоже не нравится. К тому же, всё равно придётся как минимум не забывать бэкапить, а как максимум везде носить с собой содержимое упомянутой "/home/.ecryptfs/". Поэтому я предпочитаю не пользоваться wrapping-ом, а самому ручками вводить каждый раз "ту самую" длинную-длинную passphrase непосредственно от самой файловой системы. Чаще используешь — меньше риск забыть. Кроме того, имеет смысл "сырые" (шифрованные) данные складывать на отдельный раздел, который монтировать по мере надобности, чтобы не отсвечивал. Но этого "изкоробочные" скрипты уже не умеют, придётся писать свои.

... Как один из возможных вариантов, можно складывать подобные вещи куда-нибудь в "/etc/systemd/system/ecryptfs.service":

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

Tags: linux, администрирование, безопасность
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 21 comments