LINUX.ORG.RU

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

 , ,


0

1

Если я запускаю Gparted, то вижу раздел /dev/sda2 с ФС crypt-luks, возможности с ним взаимодействовать нет, а в списке дисков присутствует только /dev/sda. Если же я запущу gparted /dev/mapper/sda2_crypt, то получу возможность работать со всем пространством внутри зашифрованного тома (при этом, sda2_crypt отображается как жёсткий диск в меню Gparted. Всё так и должно быть? Мне кажется, в Gparted имело бы смысл добавить возможность работы с шифрованными томами и без указания пути к /dev/mapper/*.

P.S. У меня внутри этого шифрованного тома находится единственный раздел - корень. В fstab это отражено так:

/dev/mapper/sda2_crypt / ext4 и так далее

Дистрибутив - Debian (размечал через его установщик). Скажите, пожалуйста - разве не должен существовать отдельный файл устройства для ext4-раздела внутри шифрованного тома? Заранее спасибо

★★

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

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

JB ★★★★★ ()
Ответ на: комментарий от JB

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

Valdor ★★ ()
Ответ на: комментарий от JB

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

Valdor ★★ ()
Ответ на: комментарий от Valdor

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

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

JB ★★★★★ ()
Последнее исправление: JB (всего исправлений: 1)
Ответ на: комментарий от JB

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

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

Valdor ★★ ()
Ответ на: комментарий от Valdor

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

JB ★★★★★ ()
Ответ на: комментарий от Valdor

Предыдущие ораторы ( 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
Chaser_Andrey ★★★★★ ()

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

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

Chaser_Andrey ★★★★★ ()
Ответ на: комментарий от Chaser_Andrey

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

JB ★★★★★ ()

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

Chaser_Andrey ★★★★★ ()
Ответ на: комментарий от Chaser_Andrey

Большое спасибо! Чтобы протестировать всё это я вот что сделал: создал отдельный жёсткий диск (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.) Если мне надо получить два зашифрованных раздела на двух разных физических дисках, есть ли возможность разблокировать их по вводу ключа единожды (т.е. установить для них один общий ключ)?

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

Valdor ★★ ()
Ответ на: комментарий от Valdor

Правильно ли я понимаю, что вся работа с шифрованными томами будет осуществляться сугубо через 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
dmsetup - low level logical volume management. Для админов замысловатых схем может быть полезно, для разработчиков, для тестеров... В общем, «low level» само за себя говорит.

сугубо через 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
Главное, чтобы не сохранять пароль на ненадежные носители. А лучше добавить ещё строку, которая перезатирает pwfile рандомными данными, чтобы исключить потом случайное выделение памяти (как в RAM, так и на HDD) для непривилегированных программ.

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

Chaser_Andrey ★★★★★ ()
Ответ на: комментарий от Valdor

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

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

Chaser_Andrey ★★★★★ ()
Ответ на: комментарий от Chaser_Andrey

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

Valdor ★★ ()

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

anonymous_sama ★★★★★ ()
Ответ на: комментарий от Valdor

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

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

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

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

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

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

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

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

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

Chaser_Andrey ★★★★★ ()
Ответ на: комментарий от Chaser_Andrey

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

Valdor ★★ ()
Ответ на: комментарий от Chaser_Andrey

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

Valdor ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.