LINUX.ORG.RU

Скрытый раздел (losetup + luks)

 ,


0

1

Приветствую, камрады!

Использую внешний hdd, на нем два раздела, первый в ntfs (win/lin) файлопомойка, второй раздел luks шифрован для личных бекапов.

При подключении харда в винде, винда предлагает форматнуть luks раздел, что не есть красиво.

Попробовал новый способ:

1. Создается раздел с ntfs для файлопомойки определенного размера.

2. Не размеченное место монтируется как loop device.

3. loop device форматируется в luks.

Для примера:

root@opx:~# fdisk -l
Disk /dev/sdb: 504,51 MiB, 529006592 bytes, 1033216 sectors
Disk model: Udisk 2.0       
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x366c1abd

Device     Boot Start    End Sectors  Size Id Type
/dev/sdb1        2048 206847  204800  100M 83 Linux

206847 - конец раздела, дальше - не размечено.

root@opx:~# losetup -o $((206847 * 512)) /dev/loop0 /dev/sdb
root@opx:~# cryptsetup luksFormat --force-password /dev/loop0
Дальше работаем с luks как обычно.

Вопрос:

1. Применим ли данный метод, возможны ли проблемы если исключить создание разделов или расширение существующего раздела в не размеченной области?

2. Нужно ли указывать --sizelimit для losetup если не размеченная область всегда в конце?

Это у тебя получается не скрытый раздел, а просто неразмеченный. Соответственно никаких проблем, ибо случай идентичен установке Linux + оффтопик.

Я советую не пытаться изобрести велосипед таким способом и использовать встроенные инструменты, с которыми ошибиться сложнее.

Если нужен именно скрытый раздел(то есть его существование можно будет отрицать при угрозе разводным ключом), то действовать надо иначе.

Могу подсказать как именно, если не страшно экспериментировать с квотами файловой системы и «голым» dm-crypt.

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

Я советую не пытаться изобрести велосипед таким способом и использовать встроенные инструменты, с которыми ошибиться сложнее.

О каких инструментах идет речь?

Если нужен именно скрытый раздел(то есть его существование можно будет отрицать при угрозе разводным ключом), то действовать надо иначе.

Нет, скорее защита на случай кражи / потери.

«голым» dm-crypt.

В общих чертах представляю как это работает, при голом dm-crypt нет никаких сигнатур, а просто набор рандомных данных. В целях интереса почитаю про dm-crypt, но для бекапа старых фотографий это будет лишним :)

wheelman
() автор топика
Ответ на: комментарий от wheelman

О каких инструментах идет речь?

Fdisk, GNU parted. Мы создаём в неразмеченной области раздел(без файловой системы) до конца устройства, далее просто используем на этом разделе cryptsetup.

Нет, скорее защита на случай кражи / потери.

Тогда ОК, обычный LUKS именно для этого подходит отлично.

но для бекапа старых фотографий это будет лишним :)

И даже потенциально опасным — нужно ещё запоминать точную команду для монтирования такого раздела, иначе данные не получится прочесть(но никаких признаков ошибки не будет), но раздел откроется на чтение-запись, так что есть риск повредить данные.

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

Fdisk, GNU parted.

Я подумал, что есть ещё какие-то инструменты, возможно гибриды loop + luks.

И даже потенциально опасным — нужно ещё запоминать точную команду

Просто умножить конец раздела на размер страницы (сектора) и скормить её losetup. Если ошибиться в значении конца раздела, тогда не выйдет смонтировать в cryptsetup, разве не так?

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

Я подумал, что есть ещё какие-то инструменты, возможно гибриды loop + luks.

Не вполне понимаю, зачем нужно монтировать неразмеченную область. После luksFormat система с поддержкой LUKS всё равно увидит зашифрованный раздел.

Так-то loop тут вообще не нужен, поскольку есть --align-payload(--offset при plainOpen), нужно лишь учитывать, что «сектор» там имеет размер 512 байт по умолчанию, впрочем изменить можно параметром --sector-size(до 4096, дальше только считать умножением).

Просто умножить конец раздела на размер страницы (сектора) и скормить её losetup. Если ошибиться в значении конца раздела, тогда не выйдет смонтировать в cryptsetup, разве не так?

Если мы работаем с «голым» dm-crypt через cryptsetup напрямую с неразмеченной областью, то никаких ошибок не будет. plainOpen преспокойно откроет даже устройство целиком со всеми данными на нём, что приведёт к уничтожению данных при попытке записи(по принципу КСГПСЧ). Этот принцип используется для быстрого уничтожения данных на целом устройстве, например так:

# cryptsetup plainOpen /dev/sdb test --key-file /dev/urandom
# dd if=/dev/zero of=/dev/mapper/test bs=1M status=progress
# cryptsetup close test

*предупрежу читателей — не надо выполнять эти команды*

cryptsetup plainOpen чувствителен ко всем заданным параметрам, т.е. нужно точно знать шифр(пример: aes-xts-plain64), хэш, размер сектора, пароль и/или ключевые файлы, ну ещё начало скрытого криптоконтейнера.

losetup не даст «съесть» существующие разделы, это да.

Но тогда раздел с dm-crypt станет видимым, это не то, что нам нужно. Вообще создавать отдельно тайный раздел в неразмеченной области — не лучшая идея. Лучше было бы создать тот же LUKS, а уже внутри него(в размеченной, но незанятой области) обычный dm-crypt. Так шум на диске не вызовет подозрений, а доказать наличие скрытого криптоконтейнера будет сложно.

Но для столь хитрого подхода нужно использовать «снаружи» нежурналируемую ФС(ext2 подходит) и дисковые квоты(файлы квот удаляем как только закончили заполнять/обновлять внешний раздел. Потом можно заново создать). ФС внутреннего контейнера может быть любой.
_____

А вот теперь до меня дошло, какая именно проблема волновала изначально, так что попробую подсказать по ней.

Насколько я понимаю, Windows предлагает форматировать именно зашифрованный раздел сразу после загрузки, при этом в таблице этот зашифрованный раздел отчётливо видно, но файловая система не распознана.

Сделаю смелое предположение — это, по-видимому, происходит из-за наличия этого раздела в таблице MBR/GPT. Но почему такого не происходит с семейством файловых систем ext? Вероятно, Windows имеет минимальную «поддержку» этих ФС, что позволяет их распознавать по «отпечатку» на накопителе и не пытаться форматировать. LUKS же не распознаётся совсем и выглядит как случайный мусор.

Я несколько раз подключал диски с LUSK, отформатированные как было задумано, и Windows никогда на них не жаловался, а сама область с разделом была видна как неразмеченная.

Предлагаю вот как попробовать: удаляем второй шифрованный раздел целиком(чтобы из таблицы разделов тоже удалился), после чего, не создавая новых разделов, используем luksFormat на неразмеченной области. Проверяем работоспособность, после перезагружаемся в Windows. Должно сработать.

Чтобы не мучаться с командной строкой, можно использовать программы с графическим интерфейсом: GParted, GNOME Disks(оно же Диски). С ними ошибиться совсем сложно.

В итоге должно быть видно именно неразмеченную область, а не раздел без ФС. Заголовок LUKS не должен мешать, зато любое ПО с его поддержкой сразу увидит раздел.

А plainOpen вообще не оставляет следов на диске, так что его точно никто не увидит.

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

Предлагаю вот как попробовать: удаляем второй шифрованный раздел целиком(чтобы из таблицы разделов тоже удалился), после чего, не создавая новых разделов, используем luksFormat на неразмеченной области. Проверяем работоспособность, после перезагружаемся в Windows. Должно сработать.

Собственно я так и сделал. Вот только как указать cryptsetup на эту не размеченную область средствами самого cryptsetup, я не нашел. Возможно я был не внимателен при RTFM. Поэтому я пришел к losetup.

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