* [make-initrd] Каким образом штатно отключить копирование ключевых файлов luks в initrd? @ 2023-04-16 7:07 Alexander 2023-04-16 10:33 ` Alexey Gladkov 2023-04-17 13:35 ` Alexey Gladkov 0 siblings, 2 replies; 6+ messages in thread From: Alexander @ 2023-04-16 7:07 UTC (permalink / raw) To: make-initrd Добрый день! Обнаружил, что в некоторых случаях, при выполнении make-initrd прописанные в /etc/crypttab файлы ключей luks, доступные на момент выполнения make-initrd, копируются в образ initrd. В моем случае, такое поведение не является правильным, так как ключ копируется с зашифрованного раздела в незашифрованный /boot Вопрос - каким образом такое копирование ключей можно штатно отключить? Подробности изложил в задаче https://bugzilla.altlinux.org/45803 -- С уважением, Александр ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [make-initrd] Каким образом штатно отключить копирование ключевых файлов luks в initrd? 2023-04-16 7:07 [make-initrd] Каким образом штатно отключить копирование ключевых файлов luks в initrd? Alexander @ 2023-04-16 10:33 ` Alexey Gladkov 2023-04-16 10:45 ` Alexey Gladkov 2023-04-16 12:18 ` Alexander 2023-04-17 13:35 ` Alexey Gladkov 1 sibling, 2 replies; 6+ messages in thread From: Alexey Gladkov @ 2023-04-16 10:33 UTC (permalink / raw) To: make-initrd On Sun, Apr 16, 2023 at 10:07:28AM +0300, Alexander wrote: > Добрый день! > Обнаружил, что в некоторых случаях, при выполнении make-initrd > прописанные в /etc/crypttab файлы ключей luks, доступные на момент > выполнения make-initrd, копируются в образ initrd. > В моем случае, такое поведение не является правильным, так как ключ > копируется с зашифрованного раздела в незашифрованный /boot > > Вопрос - каким образом такое копирование ключей можно штатно отключить? > > > Подробности изложил в задаче https://bugzilla.altlinux.org/45803 Сейчас возможности проигнорировать запись нет. Я думаю нужно ввести опцию x-initrd.ignore для crypttab в противовес к x-initrd.attach. Чтобы можно было игнорировать запись в crypttab даже если make-initrd посчитает его необходимым. Добавлю в следующем релизе. -- Rgrds, legion ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [make-initrd] Каким образом штатно отключить копирование ключевых файлов luks в initrd? 2023-04-16 10:33 ` Alexey Gladkov @ 2023-04-16 10:45 ` Alexey Gladkov 2023-04-16 12:18 ` Alexander 1 sibling, 0 replies; 6+ messages in thread From: Alexey Gladkov @ 2023-04-16 10:45 UTC (permalink / raw) To: make-initrd On Sun, Apr 16, 2023 at 12:33:56PM +0200, Alexey Gladkov wrote: > On Sun, Apr 16, 2023 at 10:07:28AM +0300, Alexander wrote: > > Добрый день! > > Обнаружил, что в некоторых случаях, при выполнении make-initrd > > прописанные в /etc/crypttab файлы ключей luks, доступные на момент > > выполнения make-initrd, копируются в образ initrd. > > В моем случае, такое поведение не является правильным, так как ключ > > копируется с зашифрованного раздела в незашифрованный /boot > > > > Вопрос - каким образом такое копирование ключей можно штатно отключить? > > > > > > Подробности изложил в задаче https://bugzilla.altlinux.org/45803 > > Сейчас возможности проигнорировать запись нет. Я думаю нужно ввести опцию > x-initrd.ignore для crypttab в противовес к x-initrd.attach. Чтобы можно > было игнорировать запись в crypttab даже если make-initrd посчитает его > необходимым. Добавлю в следующем релизе. То что есть сейчас это возможность выключить обработку crypttab вообще. -- Rgrds, legion ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [make-initrd] Каким образом штатно отключить копирование ключевых файлов luks в initrd? 2023-04-16 10:33 ` Alexey Gladkov 2023-04-16 10:45 ` Alexey Gladkov @ 2023-04-16 12:18 ` Alexander 2023-04-16 13:35 ` Alexey Gladkov 1 sibling, 1 reply; 6+ messages in thread From: Alexander @ 2023-04-16 12:18 UTC (permalink / raw) To: make-initrd 16.04.2023 13:33, Alexey Gladkov пишет: > > Сейчас возможности проигнорировать запись нет. Я думаю нужно ввести опцию > x-initrd.ignore для crypttab в противовес к x-initrd.attach. Чтобы можно > было игнорировать запись в crypttab даже если make-initrd посчитает его > необходимым. Добавлю в следующем релизе. > Лучше не совсем так...Наверное лучше сделать опцию x-initrd.ignore-key. При этом запись из crypttab используем, опции монтирования из нее используем, но именно сам ключ не копируем в initrd, хотя и запоминаем где он лежит. Потому как та схема какая есть сейчас, позволяет иметь шифрованные /home и /swap и работающий resume из шифрованного swap. При этом пароль запрашивается только один раз, а ключ от swap при загрузке берется из шифрованного /home (и недоступен без предварительной расшифровки /home или /swap по паролю). Если совсем проигнорировать строчку из crypttab то наверное уже не получится так сделать - без строчки из cryptatb разве получится расшифровать swap при resume их hibernate? В принципе, насколько я понял, достаточно обойти по какому-то условию/флажку только вот эти строки, которые я у себя пока просто закомментировал (нештатное решение проблемы): # if [ -z "$keydev" ] && [ -f "$keyfile" ]; then # mkdir -p -- "$DIR/${keyfile%/*}" # cp -- "$keyfile" "$DIR/$keyfile" # fi А зачем вообще нужно копировать ключ шифрования в initrd? Судя всему - раз так сделано специально - это зачем-то нужно, но я так и не смог смоделировать для себя ситуацию, когда скопированный в initrd ключевой файл не сводит все шифрование к фикции... Мне кажется, что логичнее при обработке cryptab вообще никаких ключей не копировать в initrd по умолчанию, если только пользователь не укажет явно какую нибудь опцию типа x-initrd.copy-keyfile осознанно понимая зачем он это делает. -- С уважением, Александр ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [make-initrd] Каким образом штатно отключить копирование ключевых файлов luks в initrd? 2023-04-16 12:18 ` Alexander @ 2023-04-16 13:35 ` Alexey Gladkov 0 siblings, 0 replies; 6+ messages in thread From: Alexey Gladkov @ 2023-04-16 13:35 UTC (permalink / raw) To: make-initrd On Sun, Apr 16, 2023 at 03:18:20PM +0300, Alexander wrote: > 16.04.2023 13:33, Alexey Gladkov пишет: > > > > Сейчас возможности проигнорировать запись нет. Я думаю нужно ввести опцию > > x-initrd.ignore для crypttab в противовес к x-initrd.attach. Чтобы можно > > было игнорировать запись в crypttab даже если make-initrd посчитает его > > необходимым. Добавлю в следующем релизе. > > > > > Лучше не совсем так...Наверное лучше сделать опцию x-initrd.ignore-key. > При этом запись из crypttab используем, опции монтирования из нее > используем, но именно сам ключ не копируем в initrd, хотя и запоминаем > где он лежит. Ok. Можно. > Потому как та схема какая есть сейчас, позволяет иметь шифрованные /home > и /swap и работающий resume из шифрованного swap. При этом пароль > запрашивается только один раз, а ключ от swap при загрузке берется из > шифрованного /home (и недоступен без предварительной расшифровки /home > или /swap по паролю). > Если совсем проигнорировать строчку из crypttab то наверное уже не > получится так сделать - без строчки из cryptatb разве получится > расшифровать swap при resume их hibernate? Если не будет информации о swap, то ничего конечно не расшифруется. > В принципе, насколько я понял, достаточно обойти по какому-то > условию/флажку только вот эти строки, которые я у себя пока просто > закомментировал (нештатное решение проблемы): > # if [ -z "$keydev" ] && [ -f "$keyfile" ]; then > # mkdir -p -- "$DIR/${keyfile%/*}" > # cp -- "$keyfile" "$DIR/$keyfile" > # fi > > > А зачем вообще нужно копировать ключ шифрования в initrd? Судя всему - > раз так сделано специально - это зачем-то нужно, но я так и не смог > смоделировать для себя ситуацию, когда скопированный в initrd ключевой > файл не сводит все шифрование к фикции... Ключи имеют смысл лишь если они находятся на отдельном устройстве, на смарткарте (не поддерживается через crypttab) или сам initrd лежит на отдельном устройстве. Остальные конфигурации будут фикцией, да. Генерация crypttab срабатывает только для разделов, которые необходимо обрабатывать в initrd. Если для рута нужен ключ, который лежит на диске, то его необходимо его скопировать, иначе мы просто не сможем загрузиться. Я не вижу других вариантов. Я понимаю, что в вашей конфигурации сначала расшифровывается /home по паролю, а оттуда берётся ключ для swap. Но я не знаю как можно отследить такую ситуацию. > Мне кажется, что логичнее при обработке cryptab вообще никаких ключей не > копировать в initrd по умолчанию, если только пользователь не укажет > явно какую нибудь опцию типа x-initrd.copy-keyfile осознанно понимая > зачем он это делает. К сожалению systemd-cryptsetup-generator(1) такого не умеет. Я могу лишь дать возможность сделать возможность сделать конфигурацию какую хочется. -- Rgrds, legion ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [make-initrd] Каким образом штатно отключить копирование ключевых файлов luks в initrd? 2023-04-16 7:07 [make-initrd] Каким образом штатно отключить копирование ключевых файлов luks в initrd? Alexander 2023-04-16 10:33 ` Alexey Gladkov @ 2023-04-17 13:35 ` Alexey Gladkov 1 sibling, 0 replies; 6+ messages in thread From: Alexey Gladkov @ 2023-04-17 13:35 UTC (permalink / raw) To: make-initrd On Sun, Apr 16, 2023 at 10:07:28AM +0300, Alexander wrote: > Добрый день! > Обнаружил, что в некоторых случаях, при выполнении make-initrd > прописанные в /etc/crypttab файлы ключей luks, доступные на момент > выполнения make-initrd, копируются в образ initrd. > В моем случае, такое поведение не является правильным, так как ключ > копируется с зашифрованного раздела в незашифрованный /boot > > Вопрос - каким образом такое копирование ключей можно штатно отключить? > > > Подробности изложил в задаче https://bugzilla.altlinux.org/45803 Я также хотел заметить, что ваша схема загрузки работает только из-за luks. В багзилле вы пишите: > И в fstab и в crypttab сначала прописаны настройки для /home, ниже > (после) для раздела swap. make-initrd не использует fstab из системы и генерирует себе свой. Он делает это потому что не использует приоритеты записей совсем. Он монтирует разделы по мере их инициализации. А работает всё как вы ожидаете, потому что до расшифровки /home расшифровать остальные разделы просто невозможно. Поэтому получается такая "сортировка". -- Rgrds, legion ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-04-17 13:35 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-04-16 7:07 [make-initrd] Каким образом штатно отключить копирование ключевых файлов luks в initrd? Alexander 2023-04-16 10:33 ` Alexey Gladkov 2023-04-16 10:45 ` Alexey Gladkov 2023-04-16 12:18 ` Alexander 2023-04-16 13:35 ` Alexey Gladkov 2023-04-17 13:35 ` Alexey Gladkov
Make-initrd development discussion This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/make-initrd/0 make-initrd/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 make-initrd make-initrd/ http://lore.altlinux.org/make-initrd \ make-initrd@lists.altlinux.org make-initrd@lists.altlinux.ru make-initrd@lists.altlinux.com public-inbox-index make-initrd Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.make-initrd AGPL code for this site: git clone https://public-inbox.org/public-inbox.git