LINUX.ORG.RU

По поводу шифрования /home раздела в ubuntu

 , , ,


1

1

Привет. В процессе переустановки системы столкнулся с фактом, что шифрование отдельного раздела с использованием ecryptfs убрали (по крайней мере, оно не доступно во время установки). Теперь предлагают шифровать весь диск, и то выбирается оно там неудобно.

This option was removed from the Ubuntu installer because it uses eCryptfs, which is considered "buggy, under-maintained"

Конечно, лучше вообще без шифрования, чем «buggy». С 10.04 пользовался этой фичей и не сталкивался с какими-то багами. Лучше сначала сделали бы альтернативу, а потом уже выпиливали.


В LUKS уже не моден? Про радел же идет речь?

Oleg_Iu
()

Ну да, типа того. И забалованного и сомнительной нужности.

С точки зрения безопасности ещё надо и SWAP чекать, /tmp. Ещё может, что забыл…

Короче, базовым средством обычно является полно дисковое шифрование. Так что всё правильно, что убрали.

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

Пользуюсь шифрованием /home где-то с 11.04 и по сей день, брат жив, багов не встречал

В процессе переустановки системы

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

Ставишь систему как обычно, загружаешься до окна логина, Alt+F1 и

sudo apt install ecryptfs-utils cryptsetup
Перезагружаешься и логинишься уже нормально.

Если же нужно зашифровать /home уже после установки, то шагов несколько больше, но тоже всё несложно

How To Encrypt The Home Folder In Ubuntu 18.04, 20.04 Or 20.10

Crocodoom ★★★★★
()

По поводу шифрования /home

А внесите systemd-позитивного, там же сделали нёх для управления хомяками, вроде с шифрованием в том числе

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

сделали нёх для управления хомяками

Там смысл в переносе домашней директории с машину на машину. Вряд ли имеет смысл для одного пользователя на одной машине.

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

Вряд ли имеет смысл для одного пользователя на одной машине

Ну если шифрование умеет, то выходит, для ОПа смысл имеется

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

Полнодисковое шифрование не исключает необходимость шифрования домашнего каталога!

И забалованного и сомнительной нужности.

Короче, базовым средством обычно является полно дисковое шифрование. Так что всё правильно, что убрали.

В идеале теория шифрования дисков требует:

  1. Полнодисковое шифрование жесткого диска с выносом заглавия диска в зашифрованный /boot раздел сьемного загрузочного диска (USB флеш). Надежная защита данных при воровстве ноута.

  2. Шифрование домашнего раздела пользователя, для защита данных пользователя от других пользователей включая пользователя root.

Понятно? Данные пользователя можно украсть прдсоеденив его диск к другому компу или удаленно закинув вирус с достаточными полномочиями для чтения домашнего каталога.

Наличие полнодискового шифрование не исключает необходимость шифрования домашнего каталога пользователя!

anonymous
()

Твой пример я не понял. root dm-устройства luks видит, и fuse у encryptfs не изолирован. а изолировать бесправных пользователей лучше не так. Это же не однопользовательская система, где пока пользователь подключил свой home, root ждет пока он отключит и выйдет.

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

fuse у encryptfs не изолирован

Это надо смотреть реализцию и использование в конкретном дистрибутиве GNU/Linux. В нормальных дистрах доступ root к шифрованым пользовательским каталогам ограничен.

К полнодисковому шифрованию свой пароль для расшифровки знают все пользователи. Если шифровать весь /home или даже целеком весь диск, то любой пользователь может прочесть содержимое домашнего каталога другого пользователя прдсоеденив диск к другому компу и ‘umask 077’ не поможет.

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

Теперь понятней. Случай не частый, но можно каждому выдать шифрованный home, отдельный от шифрованной системы. Та systemd-штука к этому близка, наверно. Но и самому можно накостылять, а lvm так и просится, только метаданные не хранить снаружи.

Ограничение root считаю другим делом. Там или всякие selinux. Или просто fuse без allow_other не обслуживает других, вроде, но это не предполагает ограничений root.

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

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/security/keys/ecryptfs.rst

DAC должен распространятся на оперативку для защиты ключей работающих процессов от ptrace: YAMA или GrSecurity:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/security/Yama.txt?h=v4.12

echo 3 > /proc/sys/kernel/yama

С этой опцией все антивирусники сканирующие рабочие процессы в памяти перестанут работать (это нормально). В остальном проблем не замечено.

anonymous
()
Ответ на: комментарий от boowai

Как минимум для защиты используемых ключей пользователя в процесах оперативки надо:

CONFIG_SECURITY_YAMA=y

echo 3 > /proc/sys/kernel/yama/ptrace_scope

Без этого все шифрование в GNU/Linux можно обозвать профанацией. Вашиключи украдут.

Если в новых версиях Ubuntu, Fedora eCryptfs сломали смотрите как реализована защита от root в старых версиях. У Ubuntu нет SELinux как у Fedora, а защита пользовательского домашнего каталога была заявлена.

Ограничения root можно достичь не только MAC, но и технологиями расширяющими GrSecurity, YAMA и подобные.. в этом деле очень преуспело правительство Франции. В Французской версии GNU/Linux есть строгие гарантии запрета root на чтение пользовательских файлов, изменения системных файлов (обновлений) и реализовано все это не на уровне MAC. Не использовали они и CAP для ограничения рута, а наваляли свои хуки в ядре Linux жестко обрезав права root.

anonymous
()
Ответ на: комментарий от fornlr

А если Вася не хочет чтобы Вова читал файлы с его домашнего каталога, даже если Вова имеет root-a?

Ты в этом примере тоже считаешь что Васи нормальная технология шифрования домашнего каталога не нужна?

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

fscrypt можно

А если не хочется всем показывать метаданные, например, наличие файла определенного размера, времени модификации, …?

anonymous
()

Можно через LUKS контейнер создать, в него установить систему, а потом этот файл записать на раздел, останется только bootctl install выполнить, смонтировав перед этим EFI раздел. так получишь полное шифрование

tz4678 ★★
()

а tomb я смотрю никто не посоветовал. Я за 8 лет накопал уже кучу могил, читай бэкапов

eco_dd
()

Но у LUKS есть фатальный недостаток - низкая скорость работы. Хотя современные процессоры поддерживают технлогию AES-NI, которая что-то должна там ускорять, аппаратное шифрование все равно быстрее (по-сути у SSD отдельный процессор, отдельная оперативная память). https://telegra.ph/Kak-vklyuchit-apparatnoe-shifrovanie-diska-06-05

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

s/в него установить систему/скопировать файлы/, поправить /etc/fstab, /etc/mkinitcpio.conf (добавить в хуки encrypt перед filesystem) и конфиг для systemd-boot, затем сгенерировать по новой initramfs.

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

Вместо eCryptfs redhat теперь на полном серьезе рекомендует для шифрования отдельных файлов/директорий создавать LUKS+XFS контейнер для кадого шифруемого файла/директории.

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