Инструкция по отрицаемому хранению данных на носителе с Tails
Цель
Иметь на одном и том же носителе как загрузочный Tails, так и хранилище для дополнительных данных, которое не будет вычищаться перезагрузкой, причём это хранилище должно быть отрицаемым.
Общая идея
На носитель устанавливается Tails, а на оставшемся свободном месте диска (в хвосте) делается бессигнатурный шифрованный раздел для хранения данных.
Легенда
Затёрли флэшку/диск/SD-карточку рандомом, потом записали стандартный Tails по инструкции с сайта, и всё на том. Больше ничего не делали, никаких скрытых данных нет.
Подводные камни
- В ядре 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
- По умолчанию Tails не грузит все файлы в память, а каждый раз запрашивает их с диска/флешки, т.е. файловая система с диска будет всегда подмонтирована. Из-за предыдущего пункта это блокирует возможность использовать неразбитое дисковое пространство для хранения данных. Можно, конечно, загрузить Tails, потом на лету менять MBR, добавляя и убирая нужные разделы, но это геморройно, грязно и может испортить легенду.
Недокументированные возможности
С помощью реверс-инжиниринга можно выяснить, что в Tails есть тайная недокументированная опция загрузки, которая держится в строжайшем секрете — toram («to RAM»). Она позволяет вэйпонизировать Tails в нужном направлении: в самом начале загрузки, когда выводится меню isolinux с двумя вариантами (обычный и fail-safe), выбираем нам нужный, нажимаем tab, дописываем toram к опциям загрузки и грузим. После этого Tails будет загружен в память, а файловые системы на носителе, с которого он был загружен, не будут подмонтированы — носитель можно будет даже отключить, и Tails продолжит работать из RAM.
Семь шагов на пути к успеху
- Следуя инструкциям на сайте Tails, с помощью isohybrid преобразовываем iso в образ, нужный для записи на флешку/диск.2 (Примечание: возможно, в этом уже нет необходимости).
- Записываем получившийся образ с помощью команды(предполагаем, что запись идёт на /dev/sdb). Это создаёт на устройстве MBR и таблицу разделов, в первом разделе (/dev/sdb1) будет находиться Tails.
# dd if=/path/to/file.iso of=/dev/sdb
- Создаём бессигнатурный шифрованный раздел на неразбитом пространстве диска:3Оффсет (задается в секторах) можно не запоминать, потому что его легко посмотреть fdisk-ом — это последний сектор первого раздела + 1. В данном случае мы используем вариант «выделяем всё пространство до конца диска». Однако, лучше сделать иначе: если размер носителя позволяет, взять какой-то фиксированный offset побольше, чтобы при последующем обновлении Tails и его записи на этот же носитель через dd (размер может увеличиться) наш бессигнатурный раздел не был затёрт.
# cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -o оффсет create NAME /dev/sdb
Вышеприведённая команда cryptsetup создаёт устройство /dev/mapper/NAME с несменяемым паролем на шифрование. Внутри него лучше создать LVM с LUKS-шифрованными логическими томами или просто один LUKS-раздел на всё устройство, чтобы не терять возможность менять пароль, убивать слоты и т.д. Как это сделать технически — уже обсуждалось [3], [4].
- Если работаем c SD-карточки, имеющей физический переключатель для блокировки записи, включаем его: на этапе загрузки запись на носитель нам не понадобится.
- Грузимся, включая опцию загрузчика toram (см. выше).
- При поставленном локе на адаптере (см. п.5, этот комментарий только на случай, если он используется) и dmsetup и cryptsetup позволяют создавать только read only mappings, причем cryptsetup умный и сам догадывается включить режимр r/o, а вот dmsetup'у надо указывать опцию -r явно. В предположении, что нужный раздел с данными уже заранее создан на свободном дисковом пространстве, монтируется он так же:(остальные опции подключения LUKS/LVM добавляем по вкусу, если нужны). Если же нужно сделать r/w-доступ к скрытому разделу на SD-карте, надо:
# cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -o оффсет create NAME DEVICE
- Достать SD-карту (предполагаем, что она не подмонтирована).
- Объяснить ядру, что мы её достали (бывают «умные» адаптеры, которые usb disconnect не ловят, пока к SD-карте не обратишься).
- Cнять лок и перевставить SD-карточку.
- Подключить скрытый раздел и смонтировать его в режиме r/w.
1Уже давно пора разделы диска делать принудительно через dm, тогда бы такой проблемы не возникло вообще. Некоторые пояснения:
2) Дело не в том, что раздел открыт на запись; дело в том, что при монтировании ФС ядро делает bd_claim. Таким образом, никакая другая компонента ядра не может сделать bd_claim на подраздел и блочное устройство (диск) в целом (т.е. дело не в том, где физически находится монтируемый подраздел, а в том, логической частью какого блочного устройства он является — bd_claim делается именно на блочное устройство; из-за этого можно без проблем подмонтировать mapping и это ни на что не повлияет — каждый mapping сам по себе блочное устройство).
3) Это проблемы Linux, а точнее — интерференция системы подразделов и системы dm. Во имя консистентности был забит костыль, дабы эти подсистемы не мешали друг другу. В общем, как всегда, проблема legacy и эволюционного проектирования.
Монтирование ФС — это частный случай bd_claim. Важно то, что
b) Одна и та же компонента ядра может это делать без ограничений. Например, всё, что делается через dm (это и dmsetup linear, и dm-crypt, и LVM) совместимо друг с другом.
Т.е. dm внутри себя поддерживает консистентность маппингов, а костыль с bd_claim сделан, чтобы не заморачиваться консистентностью разных подсистем ядра для доступа к одним и тем же блочным устройствам.
2Обычные iso'шки не поддерживают загрузки с флэшек хотя бы потому, что там нет MBR нет и т.п. Гибридные iso когда делаются, а когда нет — это от авторов зависит. Не исключаю, что в Debian iso гибридные по умолчанию.
3Поскольку по умолчанию TRIM отключен, микроконтроллер не знает, какие сектора диска ОС считает свободными. Для нашего случая это хорошо, т.к. неиспользуемое место не будет обнуляться в случае флэшек и SD-карточек.
Раньше я так записывал Tails, грузился, и всё работало, но это было давно и на моём свежем железе. Было ли бы всё так на другом железе — не знаю. Авторский пример (OP) подразумевал использование isohybrid.
Добавил.
комментариев: 64 документов: 0 редакций: 4
Грешным делом подумалось... Нет-ли в самой флешке системы логирования операций, откуда было бы можно узнать, что ее неразмеченная область с рандомом активно используется?комментариев: 64 документов: 0 редакций: 4
Корректируем неправильно заданный вопрос.
Исходим из первоначальной легенды "затер носитель рандомом, записал на него Tails Live-CD (иными словами, затертая рандомом часть флешки не используется)".
Данная легенда выглядит убедительной с технической точки зрения только в том случае, если противник не может получить доказательство использования неразмеченной части флешки в каком-то релевантном промежутке времени.
Возможность получения указанного доказательства возникает, в первом приближении, если
Здесь все понятно: только уникальный и единичный пароль для контейнера, контейнер только в единственном числе, TRIM выключен по умолчанию (действительно ли?) тыц.
Теперь, наверное, можно задать вопрос правильно.
Есть ли на флешке, кроме TRIM, еще какая-либо функция, регистрирующая обращения/операции с флешкой, с помощью которой можно было бы доказать, что неразмеченная часть флешки используется вопреки легенде?
комментариев: 511 документов: 2 редакций: 70
Самое важное то, что Tails — Live-образ, он не оставляет логов, поэтому нельзя никаким простым образом сказать, сколько раз его грузили, сколько времени он был загружен и т.д. Даже если такие функции, о которых вы говорите, есть, сами по себе они ни о чём не будут говорить, кроме как о том, что Tails (какое-то время) использовался. О таком, чтобы можно было дифференцировать, к каким ячейкам флешки доступ был, а к каким не был, не слышал. Если есть сомнения, можно брать обычный HDD, он более предсказуем, хотя и там могут быть сюрпризы.
Вопрос сам по себе интересный, важный и непростой, но полный ответ на него пока выходит за рамки того, что может быть публично озвучено на форуме.
Возьмите флэшку без файловой системны на ней, заполните её рандомом, потом этот рандом прочитайте и убедитесь, что ничего не зануляется и не затирается.
В целом всё правильно написали.
комментариев: 64 документов: 0 редакций: 4
Спасибо.
Решилась проблема с работой в консоли с остановленным gdm3.
Правильные действия
Теперь можно выполнять в консоли желаемые действия и после этого снова запустить gdm3. (В консоли потом, наверное, лучше разлогиниться, дважды выполнив exit.)
комментариев: 511 документов: 2 редакций: 70
С точки зрения работы системы это ни на что не влияет, хотя с позиции блокирования экрана (когда нужно отойти куда-то) чем меньше залогиненных сессий, тем лучше.
комментариев: 64 документов: 0 редакций: 4
По ссылке, в разделе "Оптимизация дискового пространства" (для Ext4) предлагается уменьшить до нуля
процент зарезервированных блоков для нужд суперпользователя
и число зарезервированных под служебные нужды блоков
Есть флешка, с бессигнатурно шифрованной поверхностью, под ней LUKS, в ее начале Tails, как описано в начале ветки. Подскажите, пожалуйста, можно ли безопасно воспользоваться вышеуказанными способами увеличения свободного пространства внутри неразмеченной области флешки на файловой системе внутри LUKS?
комментариев: 511 документов: 2 редакций: 70
Да. Количество свободных блоков — это внутреннее дело ФС. На чём эта ФС находится (тип блочного устройства, LUKS, LVM, ещё что-то) — файловой системы не касается. Только учтите, что, возможно, процедуру надо будет проделывать над неподмонтированной ФС, что в некоторых случаях (изменение корневой ФС) требует загрузки с посторонней ОС.
комментариев: 64 документов: 0 редакций: 4
комментариев: 511 документов: 2 редакций: 70