Удобный просмотр фото по сети

man cryptsetup?

Наверное, рано мне еще по манам лазить, реальность общей концепции в деталях хочется обсудить

Так может стоит для начала решить, чего именно хочется добиться? Каковы угрозы и риски? Если цель только в том, чтобы сложить картинки в криптоконтейнер и открывать его через сеть с последующим просмотром файлов, то в помощь Вам SSH X11 Forwarding, cryptsetup, bash и любой просмотрщик типа gqview.

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

Для тех же юзеров, кто внутри локальной сети – позволен доступ ко всем фото на сервере, т.е. они доверенные лица.

Прочел следующее:

Подумайте, действительно ли Вам нужны разделы dm-crypt. В
ряде случаев вполне можно обойтись шифрованием файлов (архивов)
с использованием GnuPG или подобных систем. Возможно, Вам стоит
взглянуть на EncFS. Решение на базе dm-crypt достаточно ресурсоёмкие
с точки зрения процессорного времени и плохо подходят для слабых машин.

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

В линуксе нет разницы между файлом и дисковым разделом: и то, и другое можно монтировать как блочное устройство (только файл нужно вначале представить как блочное устройство с помощью losetup). Хотя в данном случае EncFS действительно может быть более предпочтительно.

и любой просмотрщик типа gqview

Для trueъ-аскетов есть feh :)

Возможно, Вам стоит взглянуть на EncFS.

Вот-вот. На сервере будут лежать фото в зашифрованном виде, на локальной машине вы их будете монтировать как расшифрованные. Какой гибкости не хватает? Это даже гибче, чем создавать файл-контейнер – все файлы лежат по-отдельности и шифруются на лету прозрачно поверх обычной FS. Хотите сделать архив – забэкапьте таром директорию.

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

Да и проверьте стабильность работы encFS, в отличие от dm-crypt.

В линуксе нет разницы между файлом и дисковым разделом: и то, и другое можно монтировать как блочное устройство (только файл нужно вначале представить как блочное устройство с помощью losetup).

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

Всё что касается криптоконтейнеров, касается любых программ и операционных систем. Может добавить это в FAQ? Вот только в какой раздел, чтобы относился ко всему дисковому шифрованию, а не к конкретной ОС или программе?

Поясню, почему мне не очень подходит идея криптоконтейнера в виде раздела целиком.
Как уже отмечал, этому решению не хватает гибкости. Например, на сервере есть винчестер объемом 1 Тб. Допустим, разбиваю его пополам – 500 Гб уйдет на обычные данные, еще 500 Гб на шифрованный раздел.
Через полгодика окажется, что промахнулся – фотографий оказалось больше, чем ожидалось, и надо отвести под криптораздел больше места. Переразбивка раздела занятие проблематичное и небезопасное, хотя и есть решения, позволяющие это делать на лету, но все же.... в-общем, не нравится.
Файловый же контейнер гораздо удобнее – перекинул его на другое место, удалил на прежнем, и завел новый большего размера, и затем скопировал в него данные со старого.
Сколько раз так делал в винде – очень удобно. Хотелось бы и здесь также реализовать, без крипторазделов.

Всё что касается криптоконтейнеров, касается любых программ и операционных систем. Может добавить это в FAQ? Вот только в какой раздел, чтобы относился ко всему дисковому шифрованию, а не к конкретной ОС или программе?

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

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

И в чём проблема? Создаёте ещё один, второй, криптораздел и монтируете его в один из каталогов первого криптораздела (ещё про логические симлинки ln -s почитайте, man ln) – будет выглядеть как будто объём первого вырос. Если вам уж слишком нужно, чтобы и физически системой несколько разделов воспринимались как один – есть стандартная штука, называемся concatenated disk driver (CCD). А вообще, про управление большими объёмами данных можно почитать здесь.

dmcrypt в Linux специально интегрировался с системой томов LVM, что позволяет изменять разделы данных с файловой системой или зашифрованные разделы.

Использование гибкой системы томов позволяет избежать традиционного разбиения диска на разделы вообще типа: /dev/sda1 – это у нас /boot, /dev/sda2 – это /, /dev/sda3 – это /home.

Предполагается, что это уже несколько устарело и предлагается (уже кажется даже инсталляторами по-умолчанию) вместо этого пользоваться томами. А логические тома в отличие от физических абстрагированы от носителя.

Ненавязчиво предлагаю оставить "удобные" виндовые привычки с устаревшей системой "контейнер – это файл поверх ФС" и попробовать даже не разделы шифровать, а перейти на использование LVM.

Использование гибкой системы томов позволяет избежать традиционного разбиения диска на разделы вообще

Например, в BSD рекомендуется разбивать на разделы не потому что "иначе нельзя", а чтобы в случае сбоя файловой системы, таковая поросла лишь на проблемном разделе, а не на всём диске (в конце концов, на разных разделах могут стоять вообще разные ФС, смонтированные с разными параметрами безопасности). Если ФС вдруг слетает в Linux, проблема затронет весь диск, на котором использовался LVM?

Spinore (или кто-там :), почитайте где-нибудь про различие между физическими и логическими томами и группами томов. Примитивно – логический том – для системы как раздел, пожалуйста, создавайте на нём любые системы и задавайте параметры монтирования, разносите на несколько дисков, размещайте поверх RAID или без него, изменяйте его размеры в зашифрованном или открытом виде вместе с содержимым, делайте снэпшоты и копии содержимого, не останавливая работы сервера.

LVM разщработан и подарен сообществу IBM'ом. Проблемы у LVM были, но сейчас он относительно стабилен. Если побъётся заголовок физического тома, тогда могут полететь все логические тома, но это малореально.

Может полететь отдельно логический том, в котором смонтировано /что_то также как и обычный раздел, другие логические тома, где смонтировано /что_то_другое будут работать. Есть проблемы с восстановлением информации после глобальных повреждений, но при использовании шифрования это не актуально само по себе.

Spinore (или кто-там :)

:-D Ясно, спасибо. Я итак понимаю, что это некий уровень абстракции к реальным разделам и интерфейсам, но вот в контексте устойчивости к сбоям ничего не слышал про. CCD тоже не изучал и не настраивал.