Как реализовать автоматическое монтирование и расшифровку LUKS диска без ввода пароля? (много букв)

Был какой-то плагин для PAM, позволяющий расшифровывать/монтировать LUKS разделы при логине, но я уже не помню как он называется и мне лень гуглить. Два ключевых слова уже есть.

Вот эта приблуда.

1. Использовать один пароль для обоих томов.
2. Спрашивать пароль из initrd при загрузке один раз, использовать ― дважды (пример).

1. Положить ключ на флешку.

Почему не токен (e.g. YubiKey)?

Был какой-то плагин для PAM, позволяющий расшифровывать/монтировать LUKS разделы при логине, но я уже не помню как он называется и мне лень гуглить. Два ключевых слова уже есть.

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

Использовать один пароль для обоих томов. Спрашивать пароль из initrd при загрузке один раз, использовать ― дважды (пример).

Положить ключ на флешку.

Почему не токен (e.g. YubiKey)?

1. И одинаковый пароль придется вводить 2 раза.
2. Тогда отключать пароль юзера на вход? Пароль от HDD будет открывать и хомяка? Плохо понимаю этот вариант.
Токены и все остальные варианты не рассматриваю. Хочется именно чтобы как из коробки было. Вход по одному паролю открывающему все остальное.

Использовать один пароль для обоих томов.

Так себе идея, если пароль к системному тому знают юзеры. Первым же делом подбирают из известных (с рассчётом на ленивого админа).

Есть у LUKS возможность установки нескольких пользовательских паролей?

Есть у LUKS возможность установки нескольких пользовательских паролей?

Разумеется. Если мне не изменяет память, там 5 слотов под ключи/пароли.

Так себе идея, если пароль к системному тому знают юзеры.

У меня большие сомнения, что речь идет о многопользовательской системе.

1. И одинаковый пароль придется вводить 2 раза.

В моем сообщение есть ссылка на пример из NixOS, каким образом там отрабатывается один пароль на несколько дисков.

Токены и все остальные варианты не рассматриваю.

Тогда остается TPM, если в железе присутствует.

У меня большие сомнения, что речь идет о многопользовательской системе.

Но у меня не возникает сомнения, что это пользовательская машина. И если это ноутбук, то не стоит пренебрегать элементарными мерами безопасности (топикстартеру: если твой ноут уведут, достаточно будет подобрать один пароль и получить доступ ко всем данным; безопасность обратно пропорциональна удобству).

Тогда админский пароль пусть будет нормальным, а пользовательский каким удобно. Но это всё равно фигня.

достаточно будет подобрать один пароль

Ты скорость перебора паролей для luks представляешь?

Ты скорость перебора паролей для luks представляешь?

А что тут представлять? Но мы никуда не торопимся.

А что тут представлять?

То, что он (перебор) для luks весьма медленный. Всмысле, действительно медленный.

Но мы никуда не торопимся.

Безусловно, через 10 лет могут найти критическую уязвимость, которая позволит дешифровать все быстро и без проблем. Но тогда что один пароль на два винта, что по паролю на каждый ― сильной роли не сыграет.

То, что он (перебор) для luks весьма медленный. Всмысле, действительно медленный.

Я как бы в курсе теории, хоть на практике никогда этим не занимался.

Топик не о том как положить ключ в какую нибудь папку и указать путь к нему в crypttab.

Топик сведётся к этому. Либо вводишь пароль, либо кидаешь ключ в файл.

Вся система на SSD, диск не разбит, один раздел, хомяк зашифрован eCryptfs.

Зачем eCryptfs?

Если ключ от HDD кладу в любое другое место, в /etc например, то все работает как надо. Но какой смысл в шифровании если ключ в открытом доступе лежит.

Сделай права на чтения файла-ключа для рута. Нельзя одновременно сделать так, чтобы был файл-ключ для прочтения при расшифровавании диска и чтобы его не было на диске для предотвращения утечки (если взломают root).

Задача: научить систему открывать все по одному паролю как из коробки.

При загрузке вводишь пароль на ssd, ключ для hdd кидаешь на sdd.

Единственный дельный мануал который нашел по этой теме не осилил. Буду признателен если кто нибудь разжует пошагово мне как и что тут делать.

А что там такого, что нельзя осилить?

Я сделал так - загрузчик grub расшифровывает по введенному паролю системный раздел, оттуда читается vmlinux и initrd с внедренным ключом. Груб грузит ядро, в initramfs указан ключ. В итоге ключ на диске есть, но внутри зашифрованного раздела (без расшифрования диска паролем файл-ключ не вытащить).

Я как бы в курсе теории

Тогда почему пишешь о «достаточно будет подобрать один пароль»?

Там даже при настройках по умолчанию будет PBKDF2 с sha256, пара миллионов итераций и соль.

Тогда почему пишешь о «достаточно будет подобрать один пароль»?

Словари!

Там даже при настройках по умолчанию будет PBKDF2 с sha256, пара миллионов итераций и соль.

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

Но если на компьютере хратинся действительно ценная информация, то и взлом будет производиться не на тостере (да и проще внедрить вирус и слить информацию не получая физического доступа к устройству).

Словари!

Но если на компьютере хратинся действительно ценная информация, то и взлом будет производиться не на тостере (да и проще внедрить вирус и слить информацию не получая физического доступа к устройству).

Вам пишут, что с настройками по умолчанию LUKS (PBKDF2 с sha256) перебор медленный, Вы отвечаете про словари и про внедрение вируса.

Но если на компьютере хратинся действительно ценная информация, то и взлом будет производиться не на тостере

Да и с не тостерами ситуация не сильно лучше.

AntMiner S9 за $2400 может вычислять 14 TH/s. При 4 миллионах итераций PBKDF2 это будет значить 3500000 паролей в секунду без учета времени на попытки непосредственной расшифровки (только вычисление PBKDF2).

Для относительно короткого пароля из 10 латинских символов и цифр это ~7599 лет перебора на одной железке. Или же 18 миллионов долларов вложений для перебора за год.

$18kk и год времени для короткого пароля. И то при условии, что человек не задумывается о настройках шифрования.

Значит, возможность (при острой необходимости) ты не отрицаешь. :3

Значит, возможность (при острой необходимости) ты не отрицаешь.

Для 20-символьного пароля стоимость перебора будет выше гос. долга США.

В практическом смысле это означает скорее (условную) невозможность.

Топик сведётся к этому. Либо вводишь пароль, либо кидаешь ключ в файл.

Это понятно. Я так и хочу сделать. Только куда положить ключ чтобы все работало нормально.

Зачем eCryptfs?

Вот как разберусь как зашифровать весь диск с системой так сразу и избавлюсь от eCryptfs. Дело то не долгое.

Сделай права на чтения файла-ключа для рута. Нельзя одновременно сделать так, чтобы был файл-ключ для прочтения при расшифровавании диска и чтобы его не было на диске для предотвращения утечки (если взломают root).

В случае физического доступа это никак не поможет. Я это на ноуте делаю, не на стационарном пк.

При загрузке вводишь пароль на ssd, ключ для hdd кидаешь на sdd.

Так и собираюсь сделать. Но ключ нужно положить в недоступное место, иначе нет смысла в шифровании.

А что там такого, что нельзя осилить?

Я сделал так - загрузчик grub расшифровывает по введенному паролю системный раздел, оттуда читается vmlinux и initrd с внедренным ключом. Груб грузит ядро, в initramfs указан ключ. В итоге ключ на диске есть, но внутри зашифрованного раздела (без расшифрования диска паролем файл-ключ не вытащить).

Так и хочу сделать. Но не могу осилить этот мануал. Туплю и все. Копирую систему в новый LUKS раздел. boot и груб оставляю на старом открытом. Что и кому прописывать чтобы груб открывал LUKS раздел не могу понять. Строчка GRUB_ENABLE_CRYPTODISK=y не решает проблему.

Для 20-символьного пароля стоимость перебора будет выше гос. долга США.

В практическом смысле это означает скорее (условную) невозможность.

Но теоретически (то есть количество мощностей на планете позволяет, финансовая часть — это уже немного другой вопрос) существует возможность подбора в течение обозримого времени.

Получение данных через вредоносное ПО дешевле и быстрее. И в случае с гостайной (в частности в условиях противостояния, когда важны не только данные, но и действие на упреждение) долгий подбор себя не окупит.

финансовая часть — это уже немного другой вопрос

Как раз затраты атакующего (не только финансовые) ― это основной вопрос. В здравом уме только из теоретической возможности что-либо взломать никто не исходит.

В здравом уме только из теоретической возможности что-либо взломать никто не исходит.

Поэтому я уже не в первый раз привожу в пример цель в виде гостайны (в этом случае затраты чаще всего оправданы).

Зачем шифровать саму ОС - там нет ничего представляющего интерес. Шифровать надо данные представляющие интерес для кого-то и их лучше хранить в контейнере. Ключ на флешке или ввод пароля вот и весь выбор - остальное фантазии.

И одинаковый пароль придется вводить 2 раза

Бред.

У меня 5 дисков с luks с одинаковым паролем. При загрузке ввожу пароль один раз.

Это понятно. Я так и хочу сделать. Только куда положить ключ чтобы все работало нормально.

В зашифрованный раздел, который открывается по паролю.

Вот как разберусь как зашифровать весь диск с системой так сразу и избавлюсь от eCryptfs. Дело то не долгое.

Есть много информации и статей в вики на эту тему.

В случае физического доступа это никак не поможет. Я это на ноуте делаю, не на стационарном пк.

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

Кстати, даже если вводить пароль, то при доступе к root аккаунту можно считать ключ из памяти. Инфа 100%, лично эксперимент проводил.

Так и собираюсь сделать. Но ключ нужно положить в недоступное место, иначе нет смысла в шифровании.

См. выше.

Что и кому прописывать чтобы груб открывал LUKS раздел не могу понять.

Это должен делать grub-mkconfig. Нужно прописать путь к разделу для команды cryptomount (если вручную править grub.cfg).

ключ на диске есть, но внутри зашифрованного раздела

в этом нет логического смысла.

См. контекст обсуждения.

Пароль вводится при загрузке на системный раздел, где находится ключ. На стадии initramfs ключ становится доступен для чтения, и вводить пароль не нужно. Можно в зашифрованном разделе хранить несколько ключей для разных разделов или дисков - тогда понадобится вводить пароль один раз.

В здравом уме только из теоретической возможности что-либо взломать никто не исходит.

Поэтому я уже не в первый раз привожу в пример цель в виде гостайны (в этом случае затраты чаще всего оправданы).

Для гостайны работает точно такой же принцип (защита соответствует ценности, а не абстрактной возможности взлома чего-либо), что и для коммерческой.

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

а не абстрактной возможности взлома чего-либо

Я не про абстрактную возможность взлома. Если имеется техническая возможность и если взлом оправдывает затраты, то вероятность атаки выше.

защита соответствует ценности

До тех пор, пока не вмешивается человеческий фактор:

• глупость: стикер с паролем на видном месте;
• беспечность: пин-код типа 1234 или 0000 на токене с ключом от информации;
• лень: при переносе в незашифрованном виде временная условная флэшка/дискета не была очищена должным образом (или вообще не была очищена).

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

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

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

Вернемся к изначальному ― в чем проблема с использованием ТС одного пароля шифрования (luks) для обоих дисков?

Тоже не совсем понял. ТС имхо слишком усложняет. Есть два диска\раздела неважно, один system второй data. Если так то шифруем оба в LUKS2. System расшифровываем при загрузке вводом пароля, data расшифровывается сам через crypttab. Чем такой вариант не устраивает? Используя загрузку UEFI, раздел EFI будет на fat не зашифрован, но это не опасно если к компу на постоянной основе не имеют физ. доступа. Иначе можно держать EFI раздел на флешке.

В UEFI можно запиндюрить драйвера которые будут видеть EFI раздел не только на fat, но и на других ФС. Насчет того чтобы UEFI сам открывал LUKS о таком не слышал.

Сейчас LUKS поддерживает алгоритм формирования ключа Argon2 который позволяет указать степень параллелизма и объем занимаемой ОЗУ. То есть как я понял можно сделать пароль в 4 цифры например, но с указанием памяти (например) в 128Гб и степень параллелизма тоже что то из разряда 512 потоков. И попробуй взломай потом такой пароль, когда для одной итерации подбора нужны такие ресурсы.

Но UEFI может грузить ядро GNU\Linux напрямую, работает сам пробовал

в чем проблема с использованием ТС одного пароля шифрования (luks) для обоих дисков?

Да ни в чём, собственно. Кому нужны его данные?

Ну вот не скажи, в связи с известными событиями в РФ, хранить свои чатики, порнушки да и просто своё прайваси зашифрованным - это скорее соблюдение гигиены, чем что то из разряда паранойи. Особенно если какой нибудь фильмец скачанный с торрентов может прибавить к штрафу за участие в митинге неиллюзорный срок за нарушение авторского права. Весьма и весьма недальновидно относиться так к своему прайваси. Сколько уже на эту тем написано и сказано, но все равно #мненечегоскрыватели наступают на одни и те же грабли.

ИМХО первое что начинающий GNU\Linux’оид должен уметь так это ставить систему в LUKS, и только потом драйвера и все остальное.

GNU\Linux’оид

Фу таким быть!

Это должен делать grub-mkconfig. Нужно прописать путь к разделу для команды cryptomount (если вручную править grub.cfg).

Прописал GRUB_ENABLE_CRYPTODISK=y. Обновил ГРУБ. Создал на SSD второй раздел LUKS. Упаковал всю систему в tar архив и распаковал на LUKS разделе. Или командой dd. На первом остался только загрузчик и boot. И тут у меня затык наступает. Загрузчик не открывает LUKS раздел с системой. Что еще нужно сделать?

Для начала можно настроить по арчевики или по гентувики.

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

GRUB умеет luks версии 1.
Делай шифрованный /boot и клади все ключи в initramfs.

Для начала можно настроить по арчевики или по гентувики.

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

А выставлять путь до криптораздела нужно? Вот как тут написано

GRUB_ENABLE_CRYPTODISK=y
GRUB_PRELOAD_MODULES="luks cryptodisk"
GRUB_CMDLINE_LINUX="luks enc_root=/dev/nvme0n1p3 root=/dev/mapper/enc_root"

Тред не читал, но, КМК, TPM + detached LUKS header делает то, что ты хочешь.

В Linux с TPM есть проблемы.

Самый оптимальный вариант /boot на флешке, lukskey.bin тоже на ней же, но не в чистом виде, а под защитой gpg. Настройка простая, гайдов для дебов полно в сети. При таком раскладе потеря флешки ничем не страшна.

Если grub-mkconfig генерит конфиг и он не содержит этих параметров (по идее он должен содержать), тогда их можно добавить как ты пишешь.

Но параметры должны соответствовать используемому initramfs. По той ссылке один из параметров называется enc_root, но это зависит от дистрибутива. Какой используется initramfs?

Кстати, конфига grub.cfg в теме нет, и результата команды cryptomount тоже.

В Linux с TPM есть проблемы.

Во всём со всем есть проблемы.

Если grub-mkconfig генерит конфиг и он не содержит этих параметров (по идее он должен содержать), тогда их можно добавить как ты пишешь.

Делаю так. Пишу в груб

GRUB_ENABLE_CRYPTODISK=y
GRUB_PRELOAD_MODULES="luks cryptodisk"
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:luks"