Добрый день! Обнаружил, что в некоторых случаях, при выполнении make-initrd прописанные в /etc/crypttab файлы ключей luks, доступные на момент выполнения make-initrd, копируются в образ initrd. В моем случае, такое поведение не является правильным, так как ключ копируется с зашифрованного раздела в незашифрованный /boot Вопрос - каким образом такое копирование ключей можно штатно отключить? Подробности изложил в задаче https://bugzilla.altlinux.org/45803 -- С уважением, Александр
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
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
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 осознанно понимая
зачем он это делает.
--
С уважением, Александр
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
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