Make-initrd development discussion
 help / color / mirror / Atom feed
* [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