Можно ли открыть криптоконтейнеры FreeOTFE под Linux?


Во времена, когда я был заядлым виндузятником я юзал FreeOTFE http://www.pgpru.com/soft/freeotf
Сейчас задаюсь вопросом, можно ли открыть криптоконтейнеры FreeOTFE под Линукс?!



Комментарии
— SATtva (23/10/2009 22:16)   
Насколько понимаю, FreeOTFE создаёт контейнеры в формате loop-устройств cryptsetup-LUKS. Соответственно, последним и нужно пытаться открывать.
Гость (23/10/2009 22:23)   
То – не то?

— SATtva (23/10/2009 22:26)   
Оно самое.
Гость (23/10/2009 22:28)   


а в этом нет ничего зловредного со стороны этого пакета?!
— SATtva (23/10/2009 22:55)   
Пакет ставится из официального репозитория? GPG-подпись верна? Мейнтейнеры же не ССЗБ.

Если Вы про initramfs, то это на случай, если захотите шифровать всю систему, включая корневой раздел.
Гость (23/10/2009 23:29)   
Пакет ставится из официального репозитория? GPG-подпись верна? Мейнтейнеры же не ССЗБ.

Из официального, руками подпись не проверял, аптитуда не орет на то, что подписано не той подписью.

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

Спасибо, понял, именно про это.

P. S. А чем Вы рекомендуете шифровать существующие разделы под Linux?!
— SATtva (24/10/2009 00:04)   
Тем же dmcrypt-cryptsetup-LUKS. Это типа как стандартное решение.
— unknown (24/10/2009 13:27)   
Из официального, руками подпись не проверял, аптитуда не орет на то, что подписано не той подписью.

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

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

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

Кроме того, шифрование тесно интегрировано в систему, так чтобы можно было шифровать физические тома и RAID-массивы, которые могут цепляться при старте, так что пароль или ключ с флэшки могут вводиться до старта init (когда утилиты недоступны с корневого раздела), для этого вносятся все необходимые компоненты в рамдиск, который соответственно и перепаковывается.
Гость (15/01/2010 23:55)   
Установил cryptsetup, прочитал ман, совершенно туплю и не могу понять – как открывать файл криптоконтейнера, созданный под FreeOTFE?! Ман какой-то совершенно лапидарный и не дает никакого представления...
— SATtva (16/01/2010 00:04)   
Видимо, как-то так:

Гость (16/01/2010 14:15, исправлен 16/01/2010 14:20)   

У меня в /dev/mapper есть только:


Надо создать руками соответствующие девайсов?

— SATtva (16/01/2010 14:21)   
Когда выполните третью команду, появится всё, что нужно.
Гость (16/01/2010 15:20)   
А обратно размонтировать таким образом?

— SATtva (16/01/2010 15:28)   
Проще:

Гость (17/01/2010 13:04)   
SATtva, на базе того, что ты написал, создал скриптик loset :


Запускаю, такая фигня:


Пароль точно правильный, только что грузился в винду, все открывалось.
А устройство получается надо создавать все-таки?
Ничего не создалось, несмотря на то, что ты написал...
Гость (17/01/2010 13:09)   
Когда просто выполняю команды в комстроке выходит только что нет ключа для парольной фразы.


Под FreeOTFE я создавал файлы криптоконтейнеров (расширение у них .vol) без отдельного файла ключа, т.е. ключ храниться также в этом файле.
Получается, что линукс по какой-то причине не читает этот ключ, или как это понимать?
— unknown (17/01/2010 13:33, исправлен 17/01/2010 13:36)   

Кидайте сюда распечатку (дамп) того, что выведет такой набор комманд:

Гость (17/01/2010 13:55)   
— unknown (17/01/2010 14:31, исправлен 17/01/2010 14:32)   

Извиняюсь, в последней строке просто:


Но скорее всего результат будет таким же плачевным: устройство не распознается как LUKS-рздел и /dev/mapper/somename не создастся (вручную его создавать не нужно, оно должно возникать и исчезать только автоматом при правильной работе соотв. комманд — это принципиально). Тогда значит FreeOTFe создало несовместимый контейнер (как вариант). А в самом Линуксе с помощью cryptsetup у вас контейнеры создаются и открываются?

Гость (18/01/2010 02:40, исправлен 18/01/2010 09:08)   
Но скорее всего результат будет таким же плачевным: устройство не распознается как LUKS-рздел и /dev/mapper/somename не создастся (вручную его создавать не нужно, оно должно возникать и исчезать только автоматом при правильной работе соотв. комманд — это принципиально). Тогда значит FreeOTFe создало несовместимый контейнер (как вариант).

Если верить SATtva (см. выше), оно вроде так не должно было сделать.


А в самом Линуксе с помощью cryptsetup у вас контейнеры создаются и открываются?

Еще не пробовал. У cryptsetup man очень лапидарный, никак не могу его вкурить.

Гость (18/01/2010 05:29)   
Гость (18/01/2010 02:40), цитаты выделяются так[link1]: <[ Цитируемый текст ]>
— SATtva (18/01/2010 20:16)   
Если верить SATtva (см. выше), оно вроде так не должно было сделать.

По крайней мере, так заявляют сами разработчики FreeOTFE. Может оно по умолчанию несовместимо, а для совместимости надо создавать как-то по-особому?

У cryptsetup man очень лапидарный, никак не могу его вкурить.

В Сети тонны howto по его использованию, воспользуйтесь гуглом. google:cryptsetup+howto[link2]
— unknown (18/01/2010 21:38)   
Хочу вступиться за cryptsetup, его специально делали как очень простую и доступную систему шифрования. В man важно обратить основное внимание на часть, касающуюся LUKS, она очень ясно изложена, большинство опций на первых порах можно оставлять по умолчанию.
— SATtva (18/01/2010 21:50)   
Наверное, нюанс в том, что без понимания loop-устройств, создания и монтирования файловой системы в файле сделать что-то одним cryptsetup'ом довольно трудно. Философия GNU: каждая программа — отдельный узкоспециализированный кирпичик в единой цельной системе.
Гость (21/01/2010 00:57)   
Изучил вот этот howto : http://feraga.com/library/howt....._with_luks_support_0[link3]
Пытаюсь создать криптоконтейнер:


Не хочет создаваться.

По тому же хауту пытаюсь открыть криптоконтейней, созданный под FreeOTFE:
– не хочет воспринимать пароль.
— SATtva (21/01/2010 01:03)   
Не хочет создаваться.

Посмотрите внимательно, о чём Вас просит cryptsetup:

Are you sure? (Type uppercase yes):

Из-за критичности операции, которая способна повлечь уничтожение данных на целевом разделе, нужно ввести "YES" заглавными буквами.
Гость (22/01/2010 00:06)   
SATtva, благодарю, все работает. Прошу прощения за тупость :)
Единственно что не получается открыть FreeOTFE, видимо, попробовать написать им?
P. S. А как мне зашифровать, скажем, /home? Я так понимаю, что если я натравлю на /dev/cdaX, на котором /home, cryptsetup, то он сотрет все данные. Я так понимаю, что никак по-другому, кроме как скопировав или заархивировав их, потом зашифровав раздел с утерей всех данных, и записью на него из созданной копии/архива, вариантов нет?
А что касается создания шифрованных разделов на стадии установки Linux, скажем, с дебиановских дисков, так скорее всего именно LUKS и применяется?
И в чем принципиальная разница между LUKS и, скажем, Truecrypt? Чем последняя лучше или хуже?
— unknown (22/01/2010 11:12, исправлен 22/01/2010 11:18)   

Там всё-таки много чего, что лучше читать по манам и статьям.


Общая картина такова.


Рекомендуется отказаться от разбиения на разделы /dev/sda1, /dev/sda2 и т.д. Разделы как-бы теперь устарели и используются только для размещения разных ОС на одном винчестере или в экономных встраиваемых системах.


Остаётся только раздел под /boot и под всё остальное. Всё остальное форматируется в LVM. Вместо разделов, внутри физического тома LVM используются логические тома, которые можно двигать, изменять размеры вместе с данными (даже когда используется шифрование тома), делать снэпшоты не останавливая сервер.


При инсталляции Debian всё по такой схеме с томами и предлагает ставиться, при этом LUKS интегрирован в LVM и вы можете зашифровать любой физический том со всеми логическими или отдельно логические тома.


Альтернатива LUKS — loop-aes, его лучше не выбирать, он по ряду причин считается тупиковым направлением.


Truecrypt — не GPL-лицензия, а какая-то самопальная (в Debian её обозвали юридической миной замедленного действия и TC в дистр не включили).


Плюсы у него только в создании контейнеров без заголовков (чистый рэндом), что производит большое впечатление на новичков — "теперь они ничего не поймут и не докажут!" (в большинстве случаев такая защита — "страус спрятался в детской песочнице").


Более серьёзный плюс — отрицаемое шифрование, скрытые вложенные контейнеры.


Всё это неплохо, надо просто понимать ограниченность этих плюсов.


Зато связка "{kernel-cryptoAPI-cryptsetup-LUKS} over LVM" — чисто линукс-ориентированный продукт с хорошим теоретическим обоснованием того, что касается шифрования, с лучше всего изученным и аккуратным открытым кодом.

Гость (24/01/2010 21:01)   
Рекомендуется отказаться от разбиения на разделы /dev/sda1, /dev/sda2 и т.д. Разделы как-бы теперь устарели и используются только для размещения разных ОС на одном винчестере или в экономных встраиваемых системах.

При инсталляции Debian всё по такой схеме с томами и предлагает ставиться, при этом LUKS интегрирован в LVM и вы можете зашифровать любой физический том со всеми логическими или отдельно логические тома.

Не хотелось бы мне переинсталлироваться, а желание зашифровать данные, которые могут быть интересны врагу в случае всяких нехороших против меня действий (не дай Бог!) есть.
Что в этой ситуации лучше сделать – закриптовать /home? Что еще может быть критическим?
Файловые системы у меня выглядят так:


Кстати, а раздел в fat32, оставшийся мне в наследство от винды, я смогу закриптовать с помощью LUKS?

P. S. И все-таки, можно закриптовать существующий раздел, или только сносить его, предварительно скопировав инфу, перезаписывать после создания криптораздела?
— SATtva (24/01/2010 21:12)   
И все-таки, можно закриптовать существующий раздел, или только сносить его, предварительно скопировав инфу, перезаписывать после создания криптораздела?

Только так. Вот как это делается: http://vladmiller.info/blog/index.php?comment=113
Гость (30/01/2010 20:32)   
SATtva, большое спасибо, попробую применить на практике, как только появиться время.

Хотел бы задать несколько еще вопросов, можно?
1) Обязательно ли создавать файл, который будет использован для создания криптоконтейнера, именно с помощью dd, как в вышеприведенном howto? Или можно создавать также и с помощью cat, touch и т.п. команд?
2) какие файловые системы можно в принципе и какие лучше использовать для криптоконтейнеров? (В howto предлагается создавать в ext2, это обязательно, или просто пример?)
— SATtva (30/01/2010 21:15)   
Обязательно ли создавать файл, который будет использован для создания криптоконтейнера, именно с помощью dd, как в вышеприведенном howto? Или можно создавать также и с помощью cat, touch и т.п. команд?

Конкретно для создания контейнера cat и touch не подходят, т.к. создают пустой файл. Для контейнера необходим файл определённого объёма, который и будет определять ёмкость контейнера (учтите, нужно создавать контейнер большего объёма, чем Вы рассчитываете получить доступного места внутри, поскольку некоторую долю отъест структура файловой системы и неполные блоки).

какие файловые системы можно в принципе и какие лучше использовать для криптоконтейнеров? (В howto предлагается создавать в ext2, это обязательно, или просто пример?)

Можно — любые. Для долгосрочного хранения больших объёмов данных лучше подойдут журналируемые ФС. Лично меня raiserfs и ext4 устраивают.
Гость (31/01/2010 00:05)   
А размер блоков имеет значение? В привиденном примере, я так понял, он равен 1 Кб. Почему его не сделать, скажем, стандартным 512?
— SATtva (31/01/2010 00:51)   
Чем меньше блок, тем ниже производительность, но и меньше издержки на незаполненные блоки. Если предполагается хранить в ФС огромное количество мелких файлов, лучше выбрать небольшой блок. Напротив, если будут храниться в основном большие файлы, блок должен быть большим.
Гость (31/01/2010 11:52)   
SATtva, прошу прощения за несколько оффтопичный вопрос, Вы написали, что юзаете для этих целей ext4. Вроде бы совсем недавно, в конце 2009 года, народ писал, что она еще нестабильна, и кто-то терял на ней данные, разрабы ее уже докурили?
И такой уже не оффтопичный вопрос, как-то под содержимому файла враг может понять, что он – криптоконтейнер, созданный с помощью LUKS?
Гость (31/01/2010 12:14)   
как-то под содержимому файла враг может понять, что он – криптоконтейнер
Если у криптоконтейнера нет сигнатур, то он может видеть только много высокоэнтропийных данных. С точки зрения постороннего лица есть некоторая вероятность, что эти данные появились не из-за криптоконтейнера, а из-за затирания диска случайными данными, или же там находился большой архив, или кусок длинного фильма...
— unknown (31/01/2010 19:52)   


Гость, мы же с вами (?) это уже обсудили на предыдущей странице — есть комманда luksDump[link4], которая всё показывает. Сигнатуры LUKS открытые. Реально сокрытие сигнатур мало что даёт на практике.
— SATtva (31/01/2010 20:35)   
ext4. Вроде бы совсем недавно, в конце 2009 года, народ писал, что она еще нестабильна, и кто-то терял на ней данные, разрабы ее уже докурили?

Исправлено[link5] в ядрах от .30 и выше.
Гость (31/01/2010 22:50)   
или же там находился большой архив, или кусок длинного фильма.
А что, их фрагменты действительно неотличимы?
— unknown (31/01/2010 23:30, исправлен 31/01/2010 23:32)   

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

Гость (14/02/2010 13:44)   
Если я хочу создать шифрованные lvm-разделы на уже установленном Debian, это возможно? (В настоящее время разделы в нем нешифрованные и не-lvm).
Как я понимаю, логические диски lvm – это тоже устройства в /dev/mapper, как и криптованные, и, видимо, и те и другие как то связаны с dm? Как это "скомпоновать"?
Соответственно, еще такие вопросы:
1) Что касается самого закрпитования дисков, нашел два хауту:
http://www.saout.de/tikiwiki/tiki-index.php?page=HOWTO
http://feraga.com/library/howt....._with_luks_support_0[link3]
Хотел бы уточнить, если я криптую раздел посредством команды cryptsetup -y create home /dev/hda9 типа как в первом хауту – это не LUKS?
И чем этот формат хуже или лучше LUKS?
2) Правила второго хауту для создания в лукс-формате применимы не только к криптоконтейнерам в виде файлов, но и к разделам? (Вроде бы там написано, что к файлам и разделам, но в примерах везде речь идет о файлах).
3) Если я захочу поставить еще одну ОС, но чтобы она имела доступ к закриптованному под первой ОС хомяку, что надо делать?
— unknown (14/02/2010 23:52)   
Если я хочу создать шифрованные lvm-разделы на уже установленном Debian, это возможно? (В настоящее время разделы в нем нешифрованные и не-lvm).

Это не рекомендуется делать. вам придётся уменьшить размер какого-либо раздела программой parted. При этом существует риск потери данных. LVM был придуман как-раз в том числе для того, чтобы изменение разделов было естественной и более безопасной процедурой. Свободное место, созданное программой parted можно отформатировать как физический том, а внутри него создавать логические.

Как я понимаю, логические диски lvm – это тоже устройства в /dev/mapper, как и криптованные, и, видимо, и те и другие как то связаны с dm? Как это "скомпоновать"?

Криптованный логический том — это двойник шифрованного логического тома, только выглядещий в расшифрованном виде, после того как его открыли. Он отличается именем, которое вы задали в коммандной строке. Его можно смонтировать как если бы это был loop-device. Если его закрыть — он исчезает, остаётся имя, отображающее исходный шифрованный логический том.

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

1) Используйте LUKS, если не уверены в том, что делаете. Простой криптформат более низкоуровневый и требует ввода множества параметров. Кроме того, в LUKS предусмотрены множественные слоты ключей для шифровки главного мастер-ключа, "размазанное" хранение битов ключа для более безопасного удаления, лучше предусмотрена сама процедура удаления и другие опции безопасности.
2) Использование файлов в качестве контейнеров вместо использования разделов возможно, но менее безопасно. У нас об этом написано в FAQ[link6] в разделе "криптография: практика".
3) Если есть доступ на этот раздел какая разница откуда его монтировать?
Гость (16/02/2010 00:39)   
1) Нужно ли писать специальные скрипты размонтирования криптованных разделов, созданных по методу, предложенному SATtva, в уже функционирующей системе?
2) Если у меня в линуксе смонтирован файл криптоконтейнера, и я не выполнив umount – cryptsetup luksClose – losetup -d начну делать shutdown, это чем-то грозит целостности ФС и файлов в этом устройстве?
Гость (16/02/2010 03:06)   
это чем-то грозит целостности ФС и файлов в этом устройстве?
Нет, при условии что ошибок в ФС и ядре нет. Система сама корректно размонтирует разделы при перезагрузке.
Гость (16/02/2010 14:44)   
Нет, при условии что ошибок в ФС и ядре нет. Система сама корректно размонтирует разделы при перезагрузке.


Т.е. портить незакрытые криптоконтейнеры, созданные FreeOTFE под виндами, особенность г-новенды?!
Гость (16/02/2010 14:51)   
unknown, кстати я попробовал натравить cryptsetup luksDump на файл криптоконтейнера, и он меня послал, написав что не найдено признаков LUKS-формата.
Соответственно, когда я его инициализировал через luksOpen в loop-девайсом, и натравил на loop-девайс, тогда luksDump сказал мне, что да, это лукс.
Соответственно, получается что враг чтобы проверить должен все инициализирует luksOpen, который потребует пароля, который он не знает, и только потом проверять luksDump.
А поскольку не зная пароля он не сможет инициализировать, как он узнает, контейнер это или нет?
Вот, я ему расширение MP3 дал, так гном вообще его воспринимает как звуковой файл, тока воспроизводить не хочет :)
Так это может быть поврежденный звуковой файл просто, или я в чем-то неправ?
— SATtva (16/02/2010 15:06)   
Так это может быть поврежденный звуковой файл просто, или я в чем-то неправ?

Это просто файл с расширением mp3. У реального mp3 должны быть уйма метаданных, а у сжатого звука — вполне определённая структура. Это ж как надо было повредить файл, чтобы не осталось ни того, ни другого?
Гость (16/02/2010 15:58)   
Не, вру, luksDump надо натправливать на инициализированный с файлом losetup устройство loop, тогда он кажет, есть или нет формат лукс.
Паролем не надо открывать.
Но не на сам файл, поэтому гипотетически можно конечно написать скрипт, который будет инициализировать устройства и потом проверять есть ли лукс-формат или нет.
Но вопрос, а что делать потом с этим? Только для того, чтобы пытать потом владельца, совать ему во всякие интересные отверстия паяльники, чтобы он открыл контейнер?
— unknown (16/02/2010 16:02)   
поэтому гипотетически можно конечно написать скрипт, который будет инициализировать устройства и потом проверять есть ли лукс-формат или нет.

Достаточно искать строку LUKS в первых байтах бинарника.
Гость (16/02/2010 20:22)   
Оупенсорс позволяет полностью автоматизировать эту работу. Можно так:
поэтому гипотетически можно конечно написать скрипт, который будет искать строку LUKS в первых байтах бинарника, а потом [автоматически] пытать владельца, совать ему во всякие интересные отверстия паяльники, чтобы он открыл контейнер
Вот такая программа, брут-форс подборка паролей :)
— SATtva (16/02/2010 20:26)   
А мужики-то не знают![link7]
Гость (10/03/2010 21:18)   
Прошу прощения за тупость. Какой командной можно определить какое устройство /dev/loopX используется для данного контейнера?
Для инициализации криптоконтейнеров юзаю такой пользовательский скриптец (на основе того, что в начале топика рекомендовал SATtva):


Теперь хочу сделать скрипт, который одной командой его бы отмонтировал-разынициализировал:


А вот как написать последнюю строчку – тупости не хватает :)

– а вот какую команду туда вписать, туплю.
— SATtva (10/03/2010 21:25)   
Мне в своё время было лень разбираться, возможно ли это, поэтому просто пишу соответствия между /dev/loop/* и /dev/mapper/* в текстовый файлик в tmpfs, который и парсится скриптом при размонтировании.
Гость (28/03/2010 21:28)   
SATtva, начал по твоей инструкции перекриптовывать некриптованные разделы под действующей системой, благо диск у меня полтерабайта и позволяет и половина свободная.
Не подскажешь, а можно потом размер раздела увеличить? Вот у меня хомяк 350 ГБ, из них половина свободна.
Я отрезаю половину хомяка, создаю криптованный раздел, бросаю туда файлы с некриптованного, а потом я смогу увеличить размер криптованного раздела? И как?
Что-то мне в душе подсказывает, что если я просто изменю размер раздела с помощью gparted или fdisk'ом, то я не смогу его открыть... Или я неправ?
И еще такой вопрос. В твоей инструкции предлагается создать временный криптованный раздел, туда скопировать, потом на месте некриптованного создать криптованный и скопировать обратно.
А какой в этом практический смысл? Может тогда уже сразу скопировать в криптованный и монтировать его, а некриптованный грохнуть?
— SATtva (28/03/2010 22:10)   
Я отрезаю половину хомяка, создаю криптованный раздел, бросаю туда файлы с некриптованного, а потом я смогу увеличить размер криптованного раздела?

Только при использовании LVM.

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

Смысл только в экономии дискового пространства (я свои манипуляции проводил на ноутбуке с не очень большим диском). Если места дофига, то можно туда-сюда не таскать, конечно.
Гость (28/03/2010 22:49)   
То есть, без LVM никак? Кроме как копировать на съемные носители и оттуда возвращать на место?
P. S. А физический раздел на котором установлено LVM можно увеличивать без ущерба для LVM и с увеличением пространства, используемого LVM, или никак?
P. P. S. Я изначально сдуру установил без LVM и без шифрованного LVM, теперь мучаюсь...
Гость (29/03/2010 05:50)   
В Debian у меня по дефолту пустая директория /dm, есть файл /etc/crypttub.
Как я понимаю, править надо именно его, для настроек монтирования.
Файл такого формата (сейчас он пустой):

У САТтвыв мануале предусмотрено указание target и source. Как я понимаю, key file нужен когда будет использоваться keyfile, если же только парольная фраза – тогда оставлять пустым, или указывать нуль?
И что касается options, что там указывать?
Гость (29/03/2010 11:02, исправлен 29/03/2010 12:30)   

Повкуривал man crypttab, остались кое-какие вопросы (и появились новые):
1) Вроде с keyfile'ом разобрался, если его нет, надо писать none, в options если LUKS-формат, надо указать как-минимум luks.
А какие опции еще (по практике) нужно или желательно там указать?
2) Что касается target, в мане написано такое:

The first field, target, describes the mapped device name. It must be a plain filename without any directory components. A mapped device which encrypts/decrypts data to/from the source device will be created at /dev/mapper/target by cryptsetup.

Вроде понятно... и непонятно. Сейчас когда монтирую руками в /dev/mapper возникает устройство после команды cryptsetup luksOpen /dev/sdaX cryptpart с названием, заданным в последнем слове (в данном случае будет /dev/mapper/sryptpart).
После выполнения команды cryptsetup luksClose /dev/mapper/sryptpart это устройство удаляется.
Каким обрзаом оно должно быть создано? Надо чтоли какой-то скрипт в /etc/init.d для его создания положить?
3) В /etc/fstab все-таки что указывать, /dev/sdaX или /dev/mapper/cryptpart? Сначала crypttab читается чтоли при загрузке, а потом fstab?

— SATtva (29/03/2010 13:12)   
В /etc/fstab все-таки что указывать, /dev/sdaX или /dev/mapper/cryptpart?

Второе.

Сначала crypttab читается чтоли при загрузке, а потом fstab?

Да.
Гость (30/03/2010 06:53)   
Замечательно все получилось, это я сдруру неправильно перевел "will be created at /dev/mapper/target by cryptsetup" не как "будут созданы", а как "надо создать" (типа "you should need".
Так что сейчас буду все остальное криптовать. Враг не пройдет!!!

Однако при загрузке я получается в любом случае должен ее монтировать, даже если не хочу в данном случае? Я пробовал после предложения ввести пароль дать команду Crtl-C, система не реагирует никак.
— unknown (30/03/2010 09:10, исправлен 30/03/2010 09:10)   

По умолчанию загрузочный скрипт настроен так, что после трёх неправильных попыток ввода пароля и соотвествующих пауз, загрузка продолжается с монтированием других доступных файловых систем по порядку.


Если вас это раздражает, можете вообще удалить строку из crypttab и монтировать вручную через две команды
Или можете поставить утилиту pmount, она позволяет монтировать в том числе и LUKS-шифрованные устройства в одну команду и даже без рутовых прав (можно создать список прав доступа пользователям на монтирование).

Гость (31/03/2010 11:10)   
1) Если я не ввожу пароль в указанное гуевое окошко, а делаю что-то типа флешке, сразу после этого флешка автомонтируется hal'ом в /media/disk-X. Причем монитируется не с устройства /dev/mapper/flesh, которое создается указанной командой и присутствует в системе, а с какого-то устройства /dev/dm-1:

Что это за устройство такое и насколько безопасно такое монтирование критоустройства? (При том, что LUKS-партиция открывалась родным cryptsetup)
Кстати сказать, когда также руками монтируется криптованный раздел с HDD, hal не может его автосмонтировать, появляется окошко наутилуса где сказано, что смонитровать не удалось (mount ессно монтирует).
2)
Или можете поставить утилиту pmount, она позволяет монтировать в том числе и LUKS-шифрованные устройства в одну команду и даже без рутовых прав (можно создать список прав доступа пользователям на монтирование).

В man'е pmount написано, что утилита только для съемных устройств. При этом не хочет даже монтировать флешки из файлов LUKS-девайсов:


В соответствии с требованиями man'а pmount'а, юзер включен в группу plugdev.
— unknown (31/03/2010 13:17, исправлен 31/03/2010 13:24)   
POLICY:

The mount will succeed if all of the following conditions are met:


device is a block device in /dev/

device is not in /etc/fstab (if it is, pmount executes mount device as the calling user to handle this transparently). See below for more details.

device is not already mounted according to /etc/mtab and /proc/mounts

if the mount point already exists, there is no device already mounted at it and the directory is empty

device is removable (USB, FireWire, or MMC device, or /sys/block/drive/removable is 1) or whitelisted in /etc/pmount.allow.

device is not locked

Попробуйте исключить из fstab и включить в белый список.


Про hal, монтирование с GUI и наутилус может кто-то другой подскажет, могу только посоветовать попробовать всё это отключить и попробовать решить проблему без них — возможно эти лишние для шифрования навороты вносят свои собственные глюки.

Гость (07/04/2010 06:55)   
При монтировании криптораздела получается такой вывод :


Что за муйня и как лечить?!

При монтировании криптораздела получаю такой вывод об ошибках:



То есть опять, помимо устройств в /dev/mapper, еще и устройство /dev/dm-X. Что это за устройство?
— unknown (07/04/2010 10:18, исправлен 07/04/2010 10:19)   

У вас Intel-процессор без встроенного криптоускорителя.


Купить новый Intel-процессор, если хотите снизить наугрузку на процессор при шифровании скорее всего с 1% (на одно ядро) до 0.001%, если вы не обрабатываете гигабитные потоки шифрованных данных.


Всё нормально открылось без использования криптоускорителя.

То есть опять, помимо устройств в /dev/mapper, еще и устройство /dev/dm-X. Что это за устройство?

Это так называемый прямой путь к устройствам логических томов. В некоторых коммандах (например по удалению томов или изменению их размера) нужно указывать именно этот путь. А в /dev вообще много интересного. Есть пути для устройства по UID и по заводским серийным номерам (для монтирования флэшек удобно)

Гость (07/04/2010 13:09)   
То есть, если мне на ноуте надо монтировать крипторазделы – ничего страшного нет, что нет криптоускорителя? Он криптоустойчивость не повышает? Только ускоряет обработку процессором шифрованной информации?
А где можно по устройствам /dev почитать что-нибудь интересное и достаточно полное?
— unknown (07/04/2010 16:53, исправлен 07/04/2010 16:58)   

Делает AES более стойким что-ли? ;-))) Ну может против каких-то аппаратных или тайминг-атак, но не заморачивайтесь — шифрование винчестера на ноуте — это не тот случай. Как-то люди десятилетиями обходились без криптоускорителей и ничего. Их внедрили только в самые недавние версии процов.


В исходниках ядра, по-любому ;-)

Гость (11/04/2010 07:15)   
Есть принципиальная разница с точки зрения безопасности, если монтируешь крипторазделы из консоли и из эмулятора терминала под иксами? Насколько первое может быть безопаснее второго и стоит ли заморачиваться по этому поводу?
Гость (11/04/2010 07:18)   
Насколько я понял из манов и статей в инете, имеется возможность закриптовать linux-swap.
SatTVA тут помниться не раз высказывался вообще против свопа (учитывая что в настоящее время обычно достаточно RAM).
В связи с этим такой вопрос, если я закриптую своп, смогу ли я безопасно гибернироваться на этот криптованный своп? Или не получиться корректно загрузить систему с образа системы на таком свопе?
Гость (11/04/2010 07:47)   
Насколько первое может быть безопаснее второго и стоит ли заморачиваться по этому поводу?
Сугубо теоретически – безопаснее, но если уже словил троян, то это не спасёт. Не стоит заморачиваться.
— unknown (11/04/2010 22:04)   
В связи с этим такой вопрос, если я закриптую своп, смогу ли я безопасно гибернироваться на этот криптованный своп? Или не получиться корректно загрузить систему с образа системы на таком свопе?


Если использовать шифрование поверх LVM, то если шифровать персонально логический том swap одноразовым ключём из /dev/urandom, то гибернация невозможна.

Если шифровать физический том, на котором находятся нешифрованные нужные логические тома для системы, включая отдельный раздел swap, то тогда будет работать нормально.
Гость (13/04/2010 18:11)   
Уважаемый unknown, я юзаю ленни с ядром 30кой с бэкпортов. Под стандартным ядром, 26-м, я обнаружил, при открытии лукс-раздела указанное сообщение об ошибке не появляется. М.б. в процессоре есть криптоускоритель, просто новые версии ядра недокручены?
Какой флаг должен указывать на его наличие в /proc/cpuinfo?
У меня там такие:
— unknown (13/04/2010 21:52)   
В обычной версии Lenny скорее всего вообще нет этого криптомодуля, наберите под разными ядрами:

Или если ядро сами компилите — посмотрите в config, можно ли включить сборку этого модуля.
Гость (23/04/2010 01:39)   
Обратил внимание что файлы LUKS-криптоконтейнеров, несмотря на создание, удаление и изменение файлов и директорий в этих криптоконтейнерах, сораняют одни и те же реквизиты времени их изменения по времени их создания; это нормально?
И просто тупое копирование такого файла приводит ли к созданию точной копии содержимого криптоконтейнера (если эту копию файла открывать через cryptsetup) или же нет? Т.е. достаточно для бэкапа просто такой файл скопировать или забэкапить с другими файлами в ФС, или надо обязательно его инициализировать, подмонтировать и делать бэкап уже со смонтированной на его основе ФС?
Гость (28/04/2010 10:49)   
1. unknown, при загрузке под 30-м ядром после ввода пароля выдает следующую строку (к сожалению, раньше не успевал записать – а потом почему-то в логах ядра не находил):

Это как раз говорит о том, что процессор не поддерживает данную фичу? (нет соотв. девайса?).
Предложенные тобой команды под всеми установленными ядрами показали, что ничего этого нет.
2. Почему-то у меня после наверное 10-ти неправильных введений пароля на стадии загрузки не грузиться без раздела, а всякий раз возвращается к требованию luks-пароля.
— unknown (28/04/2010 11:31, исправлен 28/04/2010 11:32)   

  1. Значит у вас модуль лежит в /lib/modules/2.6.30-bpo.2-amd64/kernel/arch/x86/crypto/aesni-intel.ko. Можете туда зайти и попробовать получить ответ от modprobe, но скорее всего хотя модуль там есть, а проц этой фичи действительно не поддерживает.
  2. Обычно скрипт в рамдиске требует три попытки (это конфигурируется), после чего пытается найти незашифрованный раздел и грузиться с него, но если его нет, то что он должен делать? Рамдиск и скрипты в нём (раз спрашиваете) очевидно вы создавали не вручную, а это сделалось автоматом, можете поковыряться и посмотреть как там всё устроено, если вам это интересно.
Гость (29/04/2010 17:55)   
unknown? Ну вообще стандартный дистр дебиана ленни, ничего там специально я не переконфигурировал в этом отношении
— unknown (30/04/2010 08:54)   
Может зависит от того как выбирали параметры инсталлятора, разбивали на разделы, например:
после чего пытается найти незашифрованный раздел и грузиться с него, но если его нет, то что он должен делать?
Гость (01/05/2010 10:39)   
Может зависит от того как выбирали параметры инсталлятора, разбивали на разделы, например:


К сожалению, при инсталляции я еще был маленький и глупенький, поэтому не устновил сразу закриптованные разделы.
Сейчас у меня только один раздел для документов (даже не хомяк), типа /home1, который я создал впоследствии, с него ничего не грузиться.
P. S. Никак не заставлю себя найти время всю систему закриптовать. А переустанавливать совсем не хочется.

Ссылки
[link1] https://www.pgpru.com/proekt/wiki/rasshirennyjjsintaksis#h22-5

[link2] http://www.google.com/search?ie=windows-1251&oe=windows-1251&q=cryptsetup%2Bhowto

[link3] http://feraga.com/library/howto_use_cryptsetup_with_luks_support_0

[link4] https://www.pgpru.com/comment36260

[link5] http://en.wikipedia.org/wiki/Ext4#Disadvantages

[link6] https://www.pgpru.com/faq

[link7] https://www.pgpru.com/novosti/2008/vzlomgrubojjsilojjparoljvypytanizpodozrevaemogopoliciejj

[link8] https://www.pgpru.com/faq/zaschitadiska#h42-14