Linux: LUKS и несколько жестких дисков

Что относительно того, чтобы использовать управление конфигурацией как марионетка или шеф-повар? Это - возможно, немногим более, чем вершина только для одного сценария, но если Вам нужны несколько таких сценариев, это могло бы стоить для рассмотрения.

11
25.02.2012, 01:25
2 ответа

Можно использовать /lib/cryptsetup/scripts/decrypt_derived в Вашем crypttab автоматически использовать ключ от одного диска для другого.

decrypt_derived сценарий является частью cryptsetup пакета Debian.

Небольшой пример для добавления ключа от sda6crypt до sda5:

/lib/cryptsetup/scripts/decrypt_derived sda6crypt > /path/to/mykeyfile
cryptsetup luksAddKey /dev/sda5 /path/to/mykeyfile
ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab
shred -u /path/to/mykeyfile # remove the keyfile

Поскольку в наше время очень трудно действительно удалить файл, гарантировать, что/path/to/mykeyfile находится на зашифрованном диске (sda6crypt было бы в моем примере хорошее решение).

В целом можно добавить дополнительный уровень безопасности при помощи шифрования файловой системы пространства пользователя, например, через encfs.

7
27.01.2020, 19:59
  • 1
    Тем путем я не должен должен быть хранить файл ключей на диске. Это было бы хорошо. Однако Вы думаете, что это стоит проблемы (т.е. хранение файла ключей на зашифрованном корневом устройстве "достаточно безопасно")? Я спрашиваю мнение, так как у меня есть некоторые сомнения. Спасибо за предложение. –  user51166 24.02.2012, 10:38
  • 2
    Решение с decrypt_derived имеет единственное преимущество, что нет никакого файла ключей. Если кто-то может получить корневой доступ, Вы обычно теряетесь так или иначе. Чтение файлы ключей могло быть немного легче для злоумышленника, чем запущение скрипта. Для получения большей безопасности можно укрепить систему при помощи, например, Linux TOMOYO, AppAmor, ВКУС, SELinux, grsecurity... но это требует дополнительных усилий. И вопрос, если это стоит, затем более важен. Не забывайте иметь резервное копирование ключа или отдельного ключа для случая, который разрушает диск, где ключ получен из на. –  jofel 24.02.2012, 11:19
  • 3
    , который я запланировал на использовании grsecurity или подобном программном обеспечении также (не в запуске, но когда у меня будет время, я защитил бы его). Я думаю об использовании только паролей и не файлов ключей, если это возможно. Хорошо пароль будет сохранен в RAM, таким образом, я предположу, что можно спорить об этом также. –  user51166 24.02.2012, 20:02
  • 4
    Нет никакого хорошего способа удалить файл ключей где угодно, за исключением перезаписи целой файловой системы (и возможно даже затем, если диск перестал работать). Файловая система журналирования не делает вещи заметно хуже. –  Gilles 'SO- stop being evil' 25.02.2012, 01:27
  • 5
    @Gilles, Так как я не эксперт безопасного удаления файла, я отредактировал свой ответ. Я рекомендую теперь сохранить файл ключей на зашифрованном диске. –  jofel 25.02.2012, 11:56

Основываясь на ответе Джофеля, вот тот же пример, но без сохранения ключа в файле. Ключ передается в именованном канале, который ничего не сохраняет на диск.

Вы можете использовать /lib/cryptsetup/scripts/decrypt_derivedв своем crypttab, чтобы автоматически использовать ключ с одного диска для другого. Скрипт decrypt_derivedявляется частью пакета cryptsetup Debian.

Измененный пример для добавления ключа из sda6crypt в sda5:

mkfifo fifo
/lib/cryptsetup/scripts/decrypt_derived sda6crypt > fifo &
cryptsetup luksAddKey /dev/sda5 fifo
rm fifo

ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,initramfs,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab

Параметр keyscriptработает только в том случае, если crypttabобрабатывается оригинальными инструментами cryptsetup Debian, повторная реализация systemd в настоящее время не поддерживает его. Если ваша система использует systemd (, то есть большинство систем ), вам нужна опция initramfs, чтобы принудительно выполнить обработку в initrd с помощью инструментов cryptsetup перед запуском systemd.

1
27.01.2020, 19:59

Теги

Похожие вопросы