id: Гость   вход   регистрация
текущее время 16:44 28/03/2024
создать
просмотр
редакции
ссылки

Инструкция по отрицаемому хранению данных на носителе с Tails

Цель


Иметь на одном и том же носителе как загрузочный Tails, так и хранилище для дополнительных данных, которое не будет вычищаться перезагрузкой, причём это хранилище должно быть отрицаемым.

Общая идея


На носитель устанавливается Tails, а на оставшемся свободном месте диска (в хвосте) делается бессигнатурный шифрованный раздел для хранения данных.

Легенда


Затёрли флэшку/диск/SD-карточку рандомом, потом записали стандартный Tails по инструкции с сайта, и всё на том. Больше ничего не делали, никаких скрытых данных нет.

Подводные камни


  1. В ядре Linux решили не заморачиваться консистентностью разных компонент ядра, просто запретив их взаимодействие. Итог: всё dm-based (dmsetup, cryptsetup, LVM) совместимо между собой, но несовместимо с монтированием файловой системы. В частности, если на диске /dev/sda есть файловая система на /dev/sda<N>, и она подмонтирована, нельзя адресовать свободное (неразбитое) дисковое пространство на /dev/sda с помощью dmsetup или cryptsetup (ядро ставит bd_claim на блочное устройство /dev/sda, запрещая его использование dm'у; задаваемые оффсеты и размеры при этом совершенно неважны). Однако, если файловая система находится на ином блочном устройстве (важен логический, а не физический уровень) — к примеру, на /dev/mapper/name, который зацеплен на /dev/sda<N>, монтирование этой ФС не будет препятствовать использованию dm/cryptsetup на /dev/sda.1

  1. По умолчанию Tails не грузит все файлы в память, а каждый раз запрашивает их с диска/флешки, т.е. файловая система с диска будет всегда подмонтирована. Из-за предыдущего пункта это блокирует возможность использовать неразбитое дисковое пространство для хранения данных. Можно, конечно, загрузить Tails, потом на лету менять MBR, добавляя и убирая нужные разделы, но это геморройно, грязно и может испортить легенду.

Недокументированные возможности


С помощью реверс-инжиниринга можно выяснить, что в Tails есть тайная недокументированная опция загрузки, которая держится в строжайшем секрете — toram («to RAM»). Она позволяет вэйпонизировать Tails в нужном направлении: в самом начале загрузки, когда выводится меню isolinux с двумя вариантами (обычный и fail-safe), выбираем нам нужный, нажимаем tab, дописываем toram к опциям загрузки и грузим. После этого Tails будет загружен в память, а файловые системы на носителе, с которого он был загружен, не будут подмонтированы — носитель можно будет даже отключить, и Tails продолжит работать из RAM.

Семь шагов на пути к успеху


  1. Затираем весь диск/флешку [1], [2].

  1. Следуя инструкциям на сайте Tails, с помощью isohybrid преобразовываем iso в образ, нужный для записи на флешку/диск.2 (Примечание: возможно, в этом уже нет необходимости).

  1. Записываем получившийся образ с помощью команды
    # dd if=/path/to/file.iso of=/dev/sdb
    (предполагаем, что запись идёт на /dev/sdb). Это создаёт на устройстве MBR и таблицу разделов, в первом разделе (/dev/sdb1) будет находиться Tails.

  1. Создаём бессигнатурный шифрованный раздел на неразбитом пространстве диска:3
    # cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -o оффсет create NAME /dev/sdb
    Оффсет (задается в секторах) можно не запоминать, потому что его легко посмотреть fdisk-ом — это последний сектор первого раздела + 1. В данном случае мы используем вариант «выделяем всё пространство до конца диска». Однако, лучше сделать иначе: если размер носителя позволяет, взять какой-то фиксированный offset побольше, чтобы при последующем обновлении Tails и его записи на этот же носитель через dd (размер может увеличиться) наш бессигнатурный раздел не был затёрт.

    Вышеприведённая команда cryptsetup создаёт устройство /dev/mapper/NAME с несменяемым паролем на шифрование. Внутри него лучше создать LVM с LUKS-шифрованными логическими томами или просто один LUKS-раздел на всё устройство, чтобы не терять возможность менять пароль, убивать слоты и т.д. Как это сделать технически — уже обсуждалось [3], [4].

  1. Если работаем c SD-карточки, имеющей физический переключатель для блокировки записи, включаем его: на этапе загрузки запись на носитель нам не понадобится.

  1. Грузимся, включая опцию загрузчика toram (см. выше).

  1. При поставленном локе на адаптере (см. п.5, этот комментарий только на случай, если он используется) и dmsetup и cryptsetup позволяют создавать только read only mappings, причем cryptsetup умный и сам догадывается включить режимр r/o, а вот dmsetup'у надо указывать опцию -r явно. В предположении, что нужный раздел с данными уже заранее создан на свободном дисковом пространстве, монтируется он так же:
    # cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -o оффсет create NAME DEVICE
    (остальные опции подключения LUKS/LVM добавляем по вкусу, если нужны). Если же нужно сделать r/w-доступ к скрытому разделу на SD-карте, надо:

    1. Достать SD-карту (предполагаем, что она не подмонтирована).
    2. Объяснить ядру, что мы её достали (бывают «умные» адаптеры, которые usb disconnect не ловят, пока к SD-карте не обратишься).
    3. Cнять лок и перевставить SD-карточку.
    4. Подключить скрытый раздел и смонтировать его в режиме r/w.

    Потом аналогичным образом можно вернуть носитель в состояние r/o и снова поставить лок (и всё это делается без перезагрузки Tails!). Понятно, что загрузка с r/o-носителя, а также физическое отключение записи на время, когда она ненужна, повышают безопасность (Вдруг Tails будет взломан? Атакующему будет тяжелее поменять загрузочный образ).


1Уже давно пора разделы диска делать принудительно через dm, тогда бы такой проблемы не возникло вообще. Некоторые пояснения:

1) fdisk (а равно dd и т.п. проги) не делают так называемый bd_claim — это обращение к ядру с заявкой на использование, а dmsetup его делает, и именно на этой стадии его обламывают. Судя по всему, авторов Linux заботит консистентность ядра самого с собой, а не ядра и юзерленда.
2) Дело не в том, что раздел открыт на запись; дело в том, что при монтировании ФС ядро делает bd_claim. Таким образом, никакая другая компонента ядра не может сделать bd_claim на подраздел и блочное устройство (диск) в целом (т.е. дело не в том, где физически находится монтируемый подраздел, а в том, логической частью какого блочного устройства он является — bd_claim делается именно на блочное устройство; из-за этого можно без проблем подмонтировать mapping и это ни на что не повлияет — каждый mapping сам по себе блочное устройство).
3) Это проблемы Linux, а точнее — интерференция системы подразделов и системы dm. Во имя консистентности был забит костыль, дабы эти подсистемы не мешали друг другу. В общем, как всегда, проблема legacy и эволюционного проектирования.

Монтирование ФС — это частный случай bd_claim. Важно то, что

a) Никакие две раздельные компоненты ядра не могут одновременно делать bd_claim на блочные устройства и подразделы в них.
b) Одна и та же компонента ядра может это делать без ограничений. Например, всё, что делается через dm (это и dmsetup linear, и dm-crypt, и LVM) совместимо друг с другом.

Т.е. dm внутри себя поддерживает консистентность маппингов, а костыль с bd_claim сделан, чтобы не заморачиваться консистентностью разных подсистем ядра для доступа к одним и тем же блочным устройствам.
2Обычные iso'шки не поддерживают загрузки с флэшек хотя бы потому, что там нет MBR нет и т.п. Гибридные iso когда делаются, а когда нет — это от авторов зависит. Не исключаю, что в Debian iso гибридные по умолчанию.
3Поскольку по умолчанию TRIM отключен, микроконтроллер не знает, какие сектора диска ОС считает свободными. Для нашего случая это хорошо, т.к. неиспользуемое место не будет обнуляться в случае флэшек и SD-карточек.


 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Комментарии [скрыть комментарии/форму]
— Гость (19/03/2015 03:51)   <#>
ЗЫ: После работы отключаем раздел:

# umount /NAME

# cryptsetup luksClose /dev/mapper/NAME NAME
— Гость (19/03/2015 03:53)   <#>
ЗЫЫ: Только вот папка NAME из корня не исчезла :( Баг или что-то неправильно?
— Гость (19/03/2015 04:00)   <#>

Проигнорировали важную ошибку. NAME осталось зацепеленным на старую пассфразу, а не на ту, которую только что ввели. Надо было сделать remove (см. выше), а потом повторить команду.


Нельзя так делать! В общем случае должно быть:
# cryptsetup luksOpen /dev/mapper/NAME1 NAME2
где NAME1NAME2. Фактически вы LUKS-контейнер внутри создали, но не открыли. NAME осталось зацепеленным на внешний бессигнатурный слой шифрования.


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


Всё сделано неправильно как будто нарочно. Всё-таки постарайтесь для начала матчасть по LUKS'у изучить, прежде чем лезть в такие тонкие нюансы его использования. Если даже сейчас вашими руками кто-то сделает всё правильно, другой раз вы всё равно найдёте способ выстрелить себе в ногу, это неминуемо.
— Гость (19/03/2015 04:04)   <#>

Неверная команда. Надо писать
# cryptsetup luksClose NAME


Она и не должна исчезать, должно исчезать её содержимое. При повторном подключении контейнера mkdir делать, конечно, не надо. Если сомневаетесь, выполните
# ls -la /NAME
чтобы увидеть, что там внутри.
— Гость (19/03/2015 04:11)   <#>

Спасибо. Я понял. Потом с gparted взял первый сектор.

Понял.

Не очень понял почему это разные имена.

Эта команда не выполняется у меня без указания точки монтирования.
И я понял почему в корень папка попала. Спасибо.

Отсюда – # cryptsetup luksOpen /dev/ (2-е команды пропускаем).

Только вот папка в корне зависла. Просто так она не удаляется.
— Гость (19/03/2015 04:30)   <#>

Это я уже понял.

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

Пока тренируюсь на чистом диске, но суть ясна.

Согласен. Но если б не посматривал в чужие советы и help по cryptsetup, то не знаю получилось бы вообще что-то. За 4 часа изучения что-то.
Ваши советы так же пролили свет. Спасибо.

Уже сейчас не буду проверять, но что-то у меня с этой командой не прошло. Догадываюсь что это связано с допущенными ошибками.
— Гость (19/03/2015 04:54)   <#>

NAMELUKS_DEVICE_NAME. Вместо NAME и NAME LUKS_DEVICE_NAME можете подставить любые имена, какие хотите, но они должны быть разными. Команда LuksOpen создаёт виртуальное отображение (или маппинг) (блочного) устройства (device) /dev/mapper/NAME на другое (блочное) устройство (device) /dev/mapper/LUKS_DEVICE_NAME таким образом, что когда вы что-то пишете на /dev/mapper/LUKS_DEVICE_NAME, оно автоматически преобразуется (шифруется) при записи на устройство /dev/mapper/NAME [1].


Точка монтирования (/media/mnt) перед выполнением этой команды должна уже существовать. Если её нет, создайте. Вместо /media/mnt можно подставить полный путь к любой другой директории, куда хотите подцепить шифрованный контейнер.


При повторном монтировании следование команд:
  1. create
  2. luksOpen
  3. mkdir (если нужно)
  4. mount


Если к ней что-то подмонтировано, система не даст её удалить. Проверьте по выводу команд mount и df -h.


Пожалуйста. Здесь 7 страниц комментариев, почитайте предыдущие, они могут вам оказаться полезными. Всё синее кликабельно.
— Гость (20/03/2015 02:31)   <#>

Папка была создана под правами root, поэтому не удалялась простым пользователем.

Попробовал все снова создать, прошло нормально.
При повторном запуске 1-й команды в Наутилусе появляется том с замком. При клике по нему предлагается ввести пароль. После ввода пароля зашифрованного раздела в дериктории /media появляется папка с рандомным именем, в которой видно содержимое зашифрованного раздела.
— Гость (20/03/2015 02:48)   <#>

Система автодетектит наличие появившегося LUKS-тома в системе, поэтому всё так. Можно было бы отключить всю автоматику и всё делать, как описано, в консоли, а то рано или поздно автоматика начинает глючить. Впрочем, раз в вашем случае пока работает, рад за вас.


Да, автомонтирование внешних подключаемых дисков и блочных устройств делаются в рандомные директории, создаваемые динамически. Не всегда это удобно.
— Гость (30/03/2015 00:22)   <#>
В одной из инструкций вычитал предложение использовать следующий шифр: "aes-cbc-essi"
Аргумент – https://en.wikipedia.org/wiki/Watermarking_attack
В это есть что-то рациональное?

И еще небольшой вопрос-просьба:
1. "Замусориваю" Swap
# dd if=/dev/urandom of=/dev/sda5 bs=1M

2. Добавляю запись:
# gedit /etc/crypttab
swap_crypt UUID=XXXXXXXXXXXX /dev/urandom cipher=aes-xts-plain64,size=256,swap

3. Изменяею запись swap на:
# gedit /etc/fstab
/dev/mapper/swap_crypt none swap sw 0 0

4. Перезагружаюсь и.. Раздел становиться нечитаемым. Все танцы с "cryptsetup status swap_crypt", "ls -l /dev/mapper/" подтверждают отсутствие информации.

Коментирую приведенные выше строки в fstab и crypttab. Удаляю раздел. Создаю заново. Форматирую. Перезагружаюсь.
Создаю раздел и форматирую как swap. Разкомментирую строку в crypttab. Перезагружаюсь и получаю в наличии "swap_crypt -> ../dm-1".
Разкомментирую строку в fstab и получаю нечитаемы swap-раздел.
Шайтан (!)
Что делать? Голову сломал.
— Гость (30/03/2015 00:51)   <#>

Там же написано: «например, ESSIV». Unknown в комментариях к документу указал, что самым лучшим на данный момент является XTS.


Медленно будет. См. ссылки к первому пункту «Затираем весь диск/флешку».

Про остальное: не заставляйте других гадать, что вы делаете. Нужно перед действиями объяснить смысл. Откуда взялся swap в вашей задаче, и что вам от него нужно? Что хочется сделать? Причём тут Tails? Имеет ли ваш вопрос отношение к теме топика, или вы его решили задать просто потому, что тут LUKS обсуждается? И т.д.
swap_crypt UUID=XXXXXXXXXXXX /dev/urandom cipher=aes-xts-plain64,size=256,swap
#to
/dev/mapper/swap_crypt none swap sw 0 0
Есть у меня сомнения, что так писать правильно, но синтаксис я сам навскидку не помню. Почему именно crypttab? Правится ли fstab ещё?
— unknown (30/03/2015 09:46)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Ещё полезно cat /proc/swap, swapon -a, mkswap.
— Гость (01/04/2015 11:00)   <#>
Начиная с Tails 1.3 от 24 февраля, более не требуется пользоваться isohybrid для мануальной установки Tails на USB/SD. Из новостной ленты tails.boum.org:

The Mac and Linux manual installation processes no longer require the isohybrid command. Removing the isohybrid command simplifies the installation.

Может быть стоило бы добавить актуальную инфу в сноски первого сообщения?
— Гость (01/04/2015 13:15)   <#>

Как понять пользовался или нет этим isohybrid?
— Гость (01/04/2015 13:36)   <#>
Развернутый ответ начиная с пятого абзаца.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3