Есть ли какие-либо преимущества/недостатки (если таковые имеются?) в выполнении luksFormat на необработанном диске (sdx) по сравнению с разделом (sdx1)?

Я настраивал несколько зашифрованных дисков LUKS и заметил, что создавал зашифрованный диск непосредственно на 'необработанном' (?) диске, т.е./dev/sdb, в то время как много примеров через Google показывают, что он создал на/dev/sdb1

Пример с помощью/dev/sdb:

# cryptsetup luksFormat /dev/sdb
# cryptsetup luksOpen /dev/sdb lvm_backup

.. и затем следуя с созданием групп объема и логических томов как так:

# vgcreate vg_backup /dev/mapper/lvm_backup
# lvcreate -l +100%FREE lvm_backup -n backup
# mkfs.ext4 /dev/mapper/vg_backup-backup

и наконец монтирование дисков.

Это оставляет меня с lsblk выглядящим примерно так:

sdb                              8:16   0   2.7T  0 disk  
  lvm_backup (dm-3)            252:3    0   2.7T  0 crypt 
    vg_backup-backup (dm-5)    252:5    0     2T  0 lvm   /backup

Напротив, другой вывод lsblk похож:

sdb                              8:16   0   2.7T  0 disk  
  sdb1                           #:#     0    2.7T 0 part
    lvm_backup (dm-3)            252:3    0   2.7T  0 crypt 
      vg_backup-backup (dm-5)    252:5    0     2T  0 lvm   /backup

Каковы преимущества/недостатки работы непосредственно над диском (/dev/sdb) по сравнению с созданием раздела (/dev/sdb1) сначала?

Я предполагаю, что это, вероятно, несколько связано с: https://serverfault.com/questions/338937/differences-between-dev-sda-and-dev-sda1

5
задан 13 April 2017 в 05:14

1 ответ

Бесцеремонно, я думаю что, если Ваше использование всего устройства (/dev/sdb) и Ваш заголовок LUKS в начале диска, и если некоторый другой инструмент или ОС "услужливо" решают, что Ваш диск восстанавливается после форматирования без MBR или GPT, если бы это должно было перезаписать Ваш заголовок LUKS, который был бы плох . При использовании раздела для LUKS тогда, по крайней мере, новый MBR или GPT не были бы столь же разрушительными.

Вы всегда должны копировать заголовок LUKS так или иначе, как cryptsetup, страница справочника советует также.

И это - то, что cryptsetup FAQ говорит об использовании "2.2 LUKS на разделах или на неструктурированных дисках?" (это длинно, но я просто вставлю его, упоминает RAID & LVM может значительно усложнить вещи, можно хотеть заново продумать использование LVM сверху LUKS):

Это - сложный вопрос и сделало больше доступностью RAID и LVM. Я попытаюсь дать некоторые сценарии и обсудить преимущества и недостатки. Обратите внимание, что я говорю LUKS для простоты, но можно сделать все вещи, описанные с простым dm-склепом также. Также обратите внимание, что Ваш определенный сценарий может быть столь особенным, что большинство или даже все вещи, которые я говорю ниже, не применяются.

знать, что, если Вы добавляете LVM в соединение, вещи могут стать очень сложными. То же с RAID, но меньше. В частности, восстановление данных может стать чрезвычайно трудным. Только сделайте так, если Вы имеете действительно серьезное основание и всегда помните, что KISS - то, что разделяет инженера от любителя. Конечно, при реальной необходимости в добавленной сложности KISS удовлетворен. Но очень убедитесь, поскольку существует цена для оплаты за него. В разработке сложность всегда является врагом и должна бороться без милосердия, когда встречено.

Также рассматривают использование RAID вместо LVM, как, по крайней мере, со старым форматом 0.90 суперблока, суперблок RAID находится в месте (конец диска), где риск его постоянно разрушительный заголовок LUKS является наименьшим, и можно было собрать массив RAID-контроллер (т.е. ядро), как это должно быть. Используйте тип 0xfd раздела для этого. Я рекомендую избегать форматов 1.0, 1.1 и 1.2 суперблока, если Вам действительно не нужны они. Знайте, что Вы теряете автоматическое обнаружение с ними и должны отступить к некоторому сценарию пространства пользователя, чтобы сделать это.

Сценарии:

(1) Зашифрованный раздел: Просто сделайте раздел к своей симпатии и поместите LUKS сверху его и файловую систему в контейнер LUKS. Это дает Вам изоляцию по-другому определенных задачу областей данных, как обычное разделение делает. У Вас могут быть конфиденциальные данные, неконфиденциальные данные, данные для некоторых определенных приложений, пользовательских домов, корня, и т.д. Преимуществами является простота, поскольку существует 1:1 отображающийся между разделами и файловыми системами, ясной функциональностью безопасности и способностью разделить данные на различные, независимые (!) контейнеры.

Примечание, что Вы не можете сделать этого для зашифрованного корня, который требует initrd. С другой стороны, initrd почти так же уязвим для компетентного взломщика как незашифрованный корень, таким образом, действительно нет никакого преимущества безопасности для выполнения его тот путь. Взломщик, который хочет поставить под угрозу Вашу систему, просто поставит под угрозу initrd или само ядро. Лучший способ иметь дело с этим состоит в том, чтобы удостовериться, что корневой раздел не хранит критических данных и перемещения это к дополнительным зашифрованным разделам. Если бы Вы действительно обеспокоены, что Ваш корневой раздел может саботироваться кем-то с физическим доступом (который однако странно, скажем, не саботировал бы Ваш BIOS, клавиатуру, и т.д.), защитите его некоторым другим способом. ПК просто не, устанавливают для действительно безопасной цепочки начальной загрузки (независимо от того, что некоторые люди могут требовать).

(2) Полностью зашифрованное необработанное блочное устройство: Для этого, помещенного LUKS на неструктурированном устройстве (например,/dev/sdb) и помещенный файловая система в контейнер LUKS, никакое разделение, независимо от того, что включено. Это очень подходит для вещей как внешние диски USB, используемые для резервных копий или офлайнового хранения данных.

(3) Зашифрованный RAID: Создайте свой RAID из разделов и/или полных устройств. Помещенный LUKS сверху устройства RAID, просто если это было обычное блочное устройство. Приложения все равно как выше, но Вы получаете дублирование. (Примечание стороны как многие люди, кажется, не знает о нем: можно сделать RAID1 с произвольным числом компонентов в Linux.) См. также Объект 2.8.

(4) Теперь, некоторые люди рекомендуют делать шифрование ниже уровня RAID. Это имеет несколько серьезных проблем. Каждый - та внезапно отладка, проблемы RAID становятся намного более твердыми. Вы не можете больше делать автоматического блока RAID. Необходимо сохранить ключи шифрования для компонентов в синхронизации или управлять ими так или иначе. Единственное возможное преимущество состоит в том, что вещи могут работать немного быстрее, поскольку больше центральных процессоров делает шифрование, но если скорость является приоритетом над безопасностью и простотой, Вы делаете эту несправедливость так или иначе. Хороший способ смягчить проблему скорости состоит в том, чтобы получить ЦП, который делает аппаратные средства AES.

4
ответ дан 23 November 2019 в 09:33

Другие вопросы по тегам:

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