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

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

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

1) Если я не ввожу пароль в указанное гуевое окошко, а делаю что-то типа cryptsetup luksOpen /dev/sdb1 flesh флешке, сразу после этого флешка автомонтируется hal'ом в /media/disk-X. Причем монитируется не с устройства /dev/mapper/flesh, которое создается указанной командой и присутствует в системе, а с какого-то устройства /dev/dm-1:
mount ................................ /dev/dm-1 on /media/disk-1 type ext2 (rw,nosuid,nodev,uhelper=hal)
Что это за устройство такое и насколько безопасно такое монтирование критоустройства? (При том, что LUKS-партиция открывалась родным cryptsetup)
Кстати сказать, когда также руками монтируется криптованный раздел с HDD, hal не может его автосмонтировать, появляется окошко наутилуса где сказано, что смонитровать не удалось (mount ессно монтирует).
2)

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

В man'е pmount написано, что утилита только для съемных устройств. При этом не хочет даже монтировать флешки из файлов LUKS-девайсов:
$ sudo cryptsetup luksOpen /dev/sdb1 ddd Enter LUKS passphrase: Enter LUKS passphrase: key slot 0 unlocked. Command successful. pmount /dev/mapper/ddd Ошибка: /dev/mapper/ddd - не является съемным устройством

В соответствии с требованиями man'а pmount'а, юзер включен в группу plugdev.

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 и наутилус может кто-то другой подскажет, могу только посоветовать попробовать всё это отключить и попробовать решить проблему без них — возможно эти лишние для шифрования навороты вносят свои собственные глюки.

При монтировании криптораздела получается такой вывод :
[ 141.501220] Intel AES-NI instructions are not detected. key slot 0 unlocked.

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

При монтировании криптораздела получаю такой вывод об ошибках:
sudo mount /dev/mapper/crypto /mnt/crypto [ 345.979074] kjournald starting. Commit interval 5 seconds [ 345.980600] EXT3 FS on dm-0, internal journal [ 345.980700] EXT3-fs: mounted filesystem with ordered data mode.


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

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

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

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

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

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

То есть, если мне на ноуте надо монтировать крипторазделы – ничего страшного нет, что нет криптоускорителя? Он криптоустойчивость не повышает? Только ускоряет обработку процессором шифрованной информации?
А где можно по устройствам /dev почитать что-нибудь интересное и достаточно полное?

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

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

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

Насколько я понял из манов и статей в инете, имеется возможность закриптовать linux-swap.
SatTVA тут помниться не раз высказывался вообще против свопа (учитывая что в настоящее время обычно достаточно RAM).
В связи с этим такой вопрос, если я закриптую своп, смогу ли я безопасно гибернироваться на этот криптованный своп? Или не получиться корректно загрузить систему с образа системы на таком свопе?

Насколько первое может быть безопаснее второго и стоит ли заморачиваться по этому поводу?

Сугубо теоретически – безопаснее, но если уже словил троян, то это не спасёт. Не стоит заморачиваться.

В связи с этим такой вопрос, если я закриптую своп, смогу ли я безопасно гибернироваться на этот криптованный своп? Или не получиться корректно загрузить систему с образа системы на таком свопе?

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

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

Уважаемый unknown, я юзаю ленни с ядром 30кой с бэкпортов. Под стандартным ядром, 26-м, я обнаружил, при открытии лукс-раздела указанное сообщение об ошибке не появляется. М.б. в процессоре есть криптоускоритель, просто новые версии ядра недокручены?
Какой флаг должен указывать на его наличие в /proc/cpuinfo?
У меня там такие:
fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm

В обычной версии Lenny скорее всего вообще нет этого криптомодуля, наберите под разными ядрами:
lsmod | grep aesni-intel ls /lib/modules/2.6.xx.<что там у вас>./kernel/crypto/ | grep aesni-intel.ko
Или если ядро сами компилите — посмотрите в config, можно ли включить сборку этого модуля.

Обратил внимание что файлы LUKS-криптоконтейнеров, несмотря на создание, удаление и изменение файлов и директорий в этих криптоконтейнерах, сораняют одни и те же реквизиты времени их изменения по времени их создания; это нормально?
И просто тупое копирование такого файла приводит ли к созданию точной копии содержимого криптоконтейнера (если эту копию файла открывать через cryptsetup) или же нет? Т.е. достаточно для бэкапа просто такой файл скопировать или забэкапить с другими файлами в ФС, или надо обязательно его инициализировать, подмонтировать и делать бэкап уже со смонтированной на его основе ФС?

Всё так, но на всякий случай:
FAQ: Криптоконтейнеры и защита диска: Очень удобно создавать криптоконтейнер в виде файла, ведь это даёт возможность легко делать резервные копии на различных носителях, просто скопировав этот файл. Также его легко отправить на сервер для пересылки или хранения. Почему однако не рекомендуется делать копии контейнеров таким образом?