id: Гость   вход   регистрация
текущее время 00:35 29/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 След.
Комментарии [скрыть комментарии/форму]
— Гость (01/04/2015 13:51)   <#>
понятно. Не понятно другое, кто-то пытался просто в лоб записывать образ через dd?
— Гость (01/04/2015 14:25)   <#>
Раньше так и делал, все работало, но в вышеуказанном развернутом ответе разъяснены возможные, при этом, затыки.
— Гость (07/04/2015 09:32)   <#>

Раньше я так записывал Tails, грузился, и всё работало, но это было давно и на моём свежем железе. Было ли бы всё так на другом железе — не знаю. Авторский пример (OP) подразумевал использование isohybrid.


Добавил.
— Yellow (24/06/2015 20:44, исправлен 25/06/2015 12:02)   профиль/связь   <#>
комментариев: 64   документов: 0   редакций: 4

Грешным делом подумалось... Нет-ли в самой флешке системы логирования операций, откуда было бы можно узнать, что ее неразмеченная область с рандомом активно используется?

— Yellow (25/06/2015 12:37, исправлен 25/06/2015 12:46)   профиль/связь   <#>
комментариев: 64   документов: 0   редакций: 4

Корректируем неправильно заданный вопрос.


Исходим из первоначальной легенды "затер носитель рандомом, записал на него Tails Live-CD (иными словами, затертая рандомом часть флешки не используется)".


Данная легенда выглядит убедительной с технической точки зрения только в том случае, если противник не может получить доказательство использования неразмеченной части флешки в каком-то релевантном промежутке времени.


Возможность получения указанного доказательства возникает, в первом приближении, если


  1. Парольная фраза для внешнего слоя бессигнатурного шифрования используется для другого бессигнатурного контейнера, доступного противнику
  2. Существует полная копия флешки, которую противник может сравнить с последним актуальным состоянием флешки
  3. Противник может исследовать TRIM

Здесь все понятно: только уникальный и единичный пароль для контейнера, контейнер только в единственном числе, TRIM выключен по умолчанию (действительно ли?) тыц.


Теперь, наверное, можно задать вопрос правильно.


Есть ли на флешке, кроме TRIM, еще какая-либо функция, регистрирующая обращения/операции с флешкой, с помощью которой можно было бы доказать, что неразмеченная часть флешки используется вопреки легенде?

— pgprubot (26/06/2015 02:43)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Самое важное то, что Tails — Live-образ, он не оставляет логов, поэтому нельзя никаким простым образом сказать, сколько раз его грузили, сколько времени он был загружен и т.д. Даже если такие функции, о которых вы говорите, есть, сами по себе они ни о чём не будут говорить, кроме как о том, что Tails (какое-то время) использовался. О таком, чтобы можно было дифференцировать, к каким ячейкам флешки доступ был, а к каким не был, не слышал. Если есть сомнения, можно брать обычный HDD, он более предсказуем, хотя и там могут быть сюрпризы.

Вопрос сам по себе интересный, важный и непростой, но полный ответ на него пока выходит за рамки того, что может быть публично озвучено на форуме.


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


В целом всё правильно написали.
— Yellow (20/07/2015 11:41, исправлен 20/07/2015 12:00)   профиль/связь   <#>
комментариев: 64   документов: 0   редакций: 4

Спасибо.


Решилась проблема с работой в консоли с остановленным gdm3.



Правильные действия



Теперь можно выполнять в консоли желаемые действия и после этого снова запустить gdm3. (В консоли потом, наверное, лучше разлогиниться, дважды выполнив exit.)

— pgprubot (20/07/2015 18:03)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

С точки зрения работы системы это ни на что не влияет, хотя с позиции блокирования экрана (когда нужно отойти куда-то) чем меньше залогиненных сессий, тем лучше.
— Yellow (18/11/2015 12:36, исправлен 18/11/2015 13:40)   профиль/связь   <#>
комментариев: 64   документов: 0   редакций: 4

По ссылке, в разделе "Оптимизация дискового пространства" (для Ext4) предлагается уменьшить до нуля


процент зарезервированных блоков для нужд суперпользователя


и число зарезервированных под служебные нужды блоков


Есть флешка, с бессигнатурно шифрованной поверхностью, под ней LUKS, в ее начале Tails, как описано в начале ветки. Подскажите, пожалуйста, можно ли безопасно воспользоваться вышеуказанными способами увеличения свободного пространства внутри неразмеченной области флешки на файловой системе внутри LUKS?

— pgprubot (20/11/2015 15:09, исправлен 20/11/2015 15:09)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Да. Количество свободных блоков — это внутреннее дело ФС. На чём эта ФС находится (тип блочного устройства, LUKS, LVM, ещё что-то) — файловой системы не касается. Только учтите, что, возможно, процедуру надо будет проделывать над неподмонтированной ФС, что в некоторых случаях (изменение корневой ФС) требует загрузки с посторонней ОС.

— Yellow (29/11/2015 16:07)   профиль/связь   <#>
комментариев: 64   документов: 0   редакций: 4
Спасибо, воспользуюсь только для увеличения некорневого раздела. Для корневого как-то боязно, из-за возможности краха системы при недостатке свободного места.
— pgprubot (04/12/2015 15:54)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70
Вообще, я не думаю, что стоит крутить такие настройки. Если эти несколько процентов действительно начинают играют роль, нужно менять носитель или расширять раздел, на котором нарезана ФС. В некоторых случаях возможность записать что-то важное от рута полезна. Не знаю, касается ли это, в том числе, метаданных ФС и сохранения информации о крэшах и потеряных файлах (в случае аварийного отключения ФС).
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3