Любая причина зашифрована /?

9

Я большой поклонник Linux и люблю пробовать новые дистрибутивы время от времени. У меня обычно есть домашние папки и корни в lvm поверх зашифрованного раздела, но это имеет тенденцию становиться громоздким, так как каждый процесс создания initramfs более чужой, чем предыдущий.

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

Таким образом, вопрос: стоит ли шифрование root и lvm-из "/", особенно со всеми ранними проблемами с пользовательским пространством, с которыми мне приходится иметь дело?

lvm encryption root-filesystem

— nikitautiu
источник

2

Возможно, что-то, что я должен был упомянуть, это обмен. Я работаю на ноутбуке, поэтому часто использую swap-to-disk. Это легко используемая функция, если раздел не зашифрован и поскольку монтирование такого свопа выполняется до монтирования root, это означает, что я мог бы с таким же успехом смонтировать / тоже, пока я там.

— nikitautiu

12

Прежде всего, проблемы с зашифрованным корневым и ранним пользовательским пространством обычно уже обрабатываются вашим дистрибутивом (насколько я знаю, Fedora, Debian, Ubuntu и OpenSUSE поддерживают зашифрованный корневой каталог из коробки). Это означает, что вам не нужно заботиться о самой настройке.

Одна из причин шифрования / состоит в том, чтобы быть уверенным, что вы не пропускаете никакой информации вообще. Подумайте о программах, записывающих временные данные в / tmp , файлах журналов, содержащих конфиденциальную информацию, таких как имя пользователя / пароли в / var / log, или файлах конфигурации, содержащих учетные данные, таких как пароль в / etc / fstab, или некоторых командах в истории оболочки пользователя root.

Использование LVM вместо разделов имеет одно большое преимущество: вы можете легко изменять размер / переименовывать / удалять логические тома без необходимости переразметки самого диска, это просто удобнее, чем использование разделов (GPT или MBR)

— Ульрих Дангел
источник

Для меня LVM всегда был стандартом де-факто, он предлагает большую гибкость по сравнению с традиционными разделами, особенно в мультизагрузочной среде. Кроме того, поскольку я уже научился использовать initramfs-tools и mkinitcpio, я мог бы просто изучить любой другой инструмент ramfs, который может предложить какой-нибудь экзотический дистрибутив. : D

— nikitautiu

1

@vitiv только для записи initramfs-tools имеют отличную интеграцию с cryptoroot, просто установите cryptsetup, создайте соответствующий файл / etc / crypttab, настройте / etc / fstab, и все готово.

— Ульрих Дангел

10

/etc, /varИ /tmpприходят на ум. Все может потенциально иметь чувствительное содержание. Всем может быть назначен отдельный том, но каждый из них обычно находится в той же файловой системе, что и корневой каталог. Может быть, вы переместили один или несколько в их собственные тома, но вы переместили их все?

/etc содержит:
- хешированные пароли; возможно несколько видов, таких как /etc/shadowи/etc/samba/smbpasswd
- закрытые ключи разных видов: SSL, SSH, Kerberos ...
/var содержит:
- /var/logмногие из которых предназначены для корневого доступа только для чтения, поскольку они могут содержать конфиденциальные данные; например, /var/log/httpd/access_logможет содержать данные GET, которые являются незашифрованными записями пользователей веб-сайта, и поэтому могут быть конфиденциальными.
- файлы базы данных; MySQL обычно хранит свои таблицы и индексные файлы /var/lib/mysql, например, в
/tmpсодержит временные файлы, которые могут не показаться чувствительными, но существует множество атак на программное обеспечение Unix, которые включают условия гонки из-за возможности изменить или снять временный файл, пока процесс пытается его использовать. Я знаю, что во многих случаях содержимое файла является чувствительным только в краткосрочной перспективе (т.е. не через перезагрузку), но я предполагаю, что некоторые программы могут зависеть от поведения липких битов и mkstemp (3) для временного кэширования долгоживущих чувствительных данные тоже.

— Уоррен Янг
источник

3

/ etc и / var - хороший момент. Что касается / tmp, почти всегда его устанавливают как tmpfs.

— nikitautiu

4

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

— peterph
источник

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

— infinite-etcetera