Работа с crypt-luks в Gparted

Скажите, пожалуйста - разве не должен существовать отдельный файл устройства для ext4-раздела внутри шифрованного тома?

это и есть /dev/mapper/sda2_crypt

Раздел sda2 - это у меня шифрованный том. Если я правильно понимаю, то по sda2_crypt я получаю доступ к «диску», а не к разделу внутри него. Или, если бы там у меня было два раздела, присутствовали бы два /dev/mapper/sda2_что-то-там?

диск - sda, раздел - sda2

Диск у меня sda (не шифрован), раздел - sda2, на этом разделе - crypt-luks, внутри этого раздела - ещё один раздел с ФС ext4. В моём представлении, конечное наименование этого раздела с ext4 должно состоять из трёх переменных - обозначение диска, номер раздела c crypt-luks, номер раздела внутри crypt-luks.

В моём представлении, конечное наименование этого раздела с ext4 должно состоять из трёх переменных - обозначение диска, номер раздела c crypt-luks, номер раздела внутри crypt-luks.

все немного не так. У тебя зашифрован раздел sda2, грубо говоря при его «дешифрации» создается виртуальное блочное устройство при помощи device mapper - /dev/mapper/sda2_crypt. В один зашифрованный раздел нельзя запихнуть два

То есть, в зашифрованный /dev/sda2 нельзя рассматривать как пространство для создания нескольких разделов, так?

Правильно ли я понимаю, что если я желаю зашифровать несколько разделов, то я либо шифрую их по-отдельности (создаю несколько crypt-разделов и в каждом из них создаю по ФС), либо создаю LVM внутри шифрованного раздела, либо шифрую весь диск целиком?

Да, отдельно шифруешь каждый раздел. По поводу LVM внутри luks не подскажу, вроде как по феншую шифрованный LVM делается каким то иным способом

Большое спасибо за ответ.

Правильно ли я понимаю

Да, правильно. Правда непонятно, зачем нужна лишняя прослойка в виде gparted.

Это я просто смотрел, что получилось.

Предыдущие ораторы ( JB, early_britney_fun) неправы.

Повторю то, что сказал JB:

/dev/sda2 - это раздел, который ты шифруешь.

/dev/mapper/sda2_crypt - это блочное устройство.

А теперь внимание:

Ты можешь на блочном устройстве сделать таблицу разделов msdos или gpt и создать столько разделов на зашифрованном разделе, сколько тебе надо. Без использования LVM и без шифрования всего диска.

И у тебя разделы будут вида /dev/mapper/sda2_cryptN.

Если разделы не появились, и partprobe не помогает, то можно заюзать команду

kpartx -a /dev/mapper/sda2_crypt

Вообще это делает multipath, и ручного ввода команд можно избежать.

Вот демонстрация, как я на /dev/mapper/mbr_test создал несколько разделов:

sdc                       8:32   0   2,7T  0 disk  
└─crypttrash            253:10   0   2,7T  0 crypt 
  ├─vg_crypttrash-trash 253:11   0     2T  0 lvm   /media/trash
  └─vg_crypttrash-test  253:12   0     2G  0 lvm   
    └─mbr_test          253:13   0     2G  0 crypt 
      ├─mbr_test1       253:14   0   200M  0 part  
      ├─mbr_test2       253:15   0   200M  0 part  
      ├─mbr_test3       253:16   0     1K  0 part  
      └─mbr_test5       253:17   0   200M  0 part

# LANG=C fdisk -l /dev/mapper/mbr_test

Disk /dev/mapper/mbr_test: 2 GiB, 2145386496 bytes, 4190208 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x18bebd54

Device                Boot  Start     End Sectors  Size Id Type
/dev/mapper/mbr_test1        2048  411647  409600  200M 83 Linux
/dev/mapper/mbr_test2      411648  821247  409600  200M 83 Linux
/dev/mapper/mbr_test3      821248 4190207 3368960  1.6G  5 Extended
/dev/mapper/mbr_test5      823296 1232895  409600  200M 83 Linux

Скажите, пожалуйста - разве не должен существовать отдельный файл устройства для ext4-раздела внутри шифрованного тома?

Просто установщик не создал таблицу разделов внутри шифрованного тома, вот и всё. Это не баг и не фича.

Спасибо за разъяснение. Я просто придерживаюсь стандартной практики, когда /dev/sdaX -> /dev/mapper/sdaX_crypt

Оффтоп: всё же я предпочитаю использовать LVM, так проще управлять разделами, делать бэкапы через снапшоты, переносить и т.д.

Большое спасибо! Чтобы протестировать всё это я вот что сделал: создал отдельный жёсткий диск (VirtualBox), на нём создал раздел типа unformatted, скомандовал cryptsetup luksFormat /dev/sdb1, после чего установил пароль.

cryptsetup open /dev/sdb1 testcrypt

создал мне /dev/mapper/testcrypt. После этого я сделал gparted /dev/mapper/testcrypt, создал внутри 3 раздела и теперь имею честь лицезреть /dev/mapper/testcrypt{,1,2,3}, с которыми могу работатЬ, как с обычными дисками/разделами.

У меня осталось только несколько вопросов:

1.) Правильно ли я понимаю, что вся работа с шифрованными томами будет осуществляться сугубо через cryptsetup, а использование dmsetup напрямую в большинстве случаев не требуется? (кстати, когда оно требуется?)

2.) Получается, что после создания шифрованного тома я имею следующие возможности: создать там ФС напрямую, создать там таблицу разделов и заселить несколькими разделами и ФС, создать там LVM и работать уже с ним. Так? Все ли эти варианты одинаково работоспособны, нет ли скрытых возможных проблем?

3.) Если мне надо получить два зашифрованных раздела на двух разных физических дисках, есть ли возможность разблокировать их по вводу ключа единожды (т.е. установить для них один общий ключ)?

Заранее спасибо.

Правильно ли я понимаю, что вся работа с шифрованными томами будет осуществляться сугубо через cryptsetup, а использование dmsetup напрямую в большинстве случаев не требуется? (кстати, когда оно требуется?)

Вот тебе пример:

http://www.saout.de/pipermail/dm-crypt/2011-May/001732.html

Anyway,
cryptsetup -d /key -c aes-cbc-essiv:sha256 -s 256 create x /dev/sdb
is equivalent to
echo 0 $(blockdev --getsz /dev/sdb) crypt aes-cbc-essiv:sha256 $(xxd -p -c 32 </key) 0 /dev/sdb 0 | dmsetup create x

сугубо через cryptsetup

Можешь упростить себе жизнь. man crypttab

2.) Получается, что после создания шифрованного тома я имею следующие возможности: создать там ФС напрямую, создать там таблицу разделов и заселить несколькими разделами и ФС, создать там LVM и работать уже с ним. Так? Все ли эти варианты одинаково работоспособны, нет ли скрытых возможных проблем?

Скрытых проблем нет, блочное устройство - оно универсальное. Просто чем больший слой абстракций - тем порой геморройнее сделать такие простые операции, как уменьшение размера раздела (зашифрованного, например). И если LVM (в частности lvresize) умеет опцию --resizefs, то cryptsetup такого не умеет, gparted только пилит поддержку ресайза зашифрованных разделов, и в целом приходится очень внимательно делать всё вручную, с помощью fdisk и аналогов. Как тебе такой факт, что для ресайза LVM PV нужно удалить раздел, а потом создать на его месте новый каким-то fdisk, указав данные начала и конца с точностью до сектора, и ошибка чревата развалом LVM? Уменьшение зашифрованных разделов тоже тот ещё квест. Формально - ничего сложного, всё детерминировано. Но эти вещи не автоматизированы, и играет роль человеческий фактор и внимательность.

3.) Если мне надо получить два зашифрованных раздела на двух разных физических дисках, есть ли возможность разблокировать их по вводу ключа единожды (т.е. установить для них один общий ключ)?

Мне неизвестен способ, поддерживаемый апстримом. Но можно сделать враппер типа такого

echo -n password > pwfile
for luks in md1 md2 md3
do
    cryptsetup luksOpen --key-file=pwfile /dev/"$luks" luks"$luks"
done

А ещё лучше в скрипте сделать считывание пароля из стандартного ввода. А скрипт без самого пароля можно поместить в initramfs или в корень. Смотря, какие разделы у тебя зашифрованы.

нет ли скрытых возможных проблем?

Хотя таки могут быть скрытые проблемы, но дистроспецифичные. Дело в том, что если у дистрибутива (или каком-то LiveCD) не настроен multipath по-умолчанию, то при попытке «создать там таблицу разделов и заселить несколькими разделами и ФС» маппинг устройств тоже не будет работать.

Спасибо. И последний вопрос - по твоему опыту, как считаешь, есть ли необходимость шифровать /, если /home вынесен на отдельный раздел? Ясно, что в /home есть такие вещи, как сохранённые логины/пароли почтовых/IM клиентов, каталог .gpg, каталог браузера, документы и прочие ценности. А в /, вроде, нет ничего конфиденциального?

В рамках оффтопа, только относительно недавно узнал, что на luks можно повесить еще семь ключей или паролей к основному. Так что соорудить можно что-нибудь очень забавное.

по твоему опыту

А в /, вроде, нет ничего конфиденциального?

Я шифрую, потому что:

* можно подменить бинарники со всеми вытекающими (это не так сложно, как кажется, и может сделать любой студент-энтузиаст, если он получит комп/ноут на пару минут).

* ключи в /root/.ssh

* пароли в /etc/davfs2/secrets

* общесистемная MySQL БД для прикладного софта.

* I2P-нода с торрентами

ещё немного приватного барахла, которое работает в качестве демонов

Спасибо. Думаю, в моём случае необходимости в шифровании / нет.

Кстати, не подскажешь, что прочитать, чтобы понять, как настраивать multipath? А то в Debian Stable после luksOpen устройства требуется вручную kpartx -a чтобы увиделись разделы внутри шифрованного тома.

Никаких материалов на примете нет.