Используем encfs для "прозрачного" шифрования данных в облаках

[oermolaev]

Облачные хранилища становятся всё доступней, однако многие, в т.ч. и я справедливо опасаются держать в них приватные данные.
Провёл изыскания на эту тему в интернете и испытал на себе. Вроде всё получилось так как хотел, поэтому запишу пока не забыл:
Используем encfs для "прозрачного" шифрования данных в облаках
1.

Код: [Выделить]

sudo apt-get install encfs libpam-encfs2.

Код: [Выделить]

cd; mkdir ~/<cloud>/.private ~/private3.

Код: [Выделить]

encfs ~/<cloud>.private ~/private- выбираем режим эксперта: "x"
- выбираем алгоритм шифрования имен "Null"
- пароль равный паролю логина юзера в системе
4. В /etc/security/pam_encfs.conf:
комментируем строку "encfs_default --idle=1"
раскомментируем строку
"* .private private -v allow_other"
и редактируем её до вида:
"* <cloud>/.private private -v allow_other"
5. В /etc/fuse.conf
раскомментируем строку "user_allow_other"
6. Добавляем юзера в группу fuse

Код: [Выделить]

usermod -a username -G fuse
Теперь всякий раз при запуске системы должны монтироваться в ~/private в расшифрованном виде данные из ~/<cloud>/.private
Остается только сим-линком связать ~/.private c приватным каталогом облачного хранилища
Надо добавить что на локальной машине эти данные теперь также хранятся в зашифрованном виде - о чем надо помнить при выходе юзера из системы, а также при смене пароля.
Настройка синхронизации с другими компьютерами описана в статье в wiki

[Spect]

oermolaev,
это для  которого из облаков? Яндекс, дропбокс?
Или я с дропбоксом влез не в ту тему?

[ArcFi]

oermolaev, https://help.ubuntu.ru/wiki/encfs+cloud

[oermolaev]

Spect,
вообще для любого, но я проверял на cloud@mail.ru. Яндекс же мне интересен сервисом webdav - без синхронизации.
Пользователь решил продолжить мысль 15 Ноября 2013, 04:52:53:ArcFi,
попробую
Пользователь решил продолжить мысль 15 Ноября 2013, 15:55:19:ArcFi,
попробовал.

[Spect]

Какова реакция на "обрыв соединения"? Если открыты на редактирование несколько файлов - что с ними происходит?
Или в разных облаках "по-разному".. Варианты - 1. Получаем в облаке файл 0-длины 2. Получаем в облаке файл "содержимое от последнего сохранения".
Рассматриваю случай "текстовой файл, открыт в редакторе" на момент обрыва.

(Нажмите, чтобы показать/скрыть)

Сейчас использую схему - дропбокс, криптоконтейнер, отключение синхронизации, открытие контейнера - действия, закрытие всех файлов - закрытие контейнера, включение синхронизации. Причем при открытых файлах в контейнере - закрытие контейнера не происходит.
"Не додумал" еще полностью.Мышляю.

[oermolaev]

Какова реакция на "обрыв соединения"? Если открыты на редактирование несколько файлов - что с ними происходит?

А что нам связь? Мы же "в танке" - работаем локально. Не так ли? Связь восстановится - данные синхронизируются.

[Spect]

Теперь, всякий раз при запуске системы, данные из ~/.private должны монтироваться в ~/private в расшифрованном виде. Остается только симлинком связать ~/.private c приватным каталогом облачного хранилища

моск сонный, никак не переварю.. То есть данные хранятся на локале (~/.private) а симлинк обеспечивает синхронизацию? Я полагал что симлинк создает ссылку, не более того, но как при этом определяется условие синхронизации? Не вкурю, надо будет "потыкать", пожалуй.
Пользователь решил продолжить мысль 16 Ноября 2013, 02:46:10:

ln -s /home/<username>/.private /home/<username>/<cloud>/.private

/home/<username>/.private  - ага, это "каталог-оригинал" где есть наши реальные файлы (криптованые)
/home/<username>/<cloud>/.private - символическая ссылка. Если бы это было не-облако, то никаких файлов при этом бы не создавалось.. Пойду читать как работает механизм ссылок "в облаке".
Пользователь решил продолжить мысль 16 Ноября 2013, 02:54:38:Допер. Это локал, да. Это полностью аналогично дропбоксу и я точно так же работаю со своим "контейнером". Меня сбило с толку что пришли сюда мы из темы по davfs, где все начиналось с обсуждения яндекс-диска, который монтируется как "сетевой диск" и файлы на нем копии на локале могут не иметь (могут и иметь). В ЯД, wuala - там, собственно где-то так.
Возможно, имеет смысл указать как-то на это.

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

[oermolaev]

Где-то рядом с этой могу написать статью "Используем LUKS-контейнер для "прозрачного" шифрования данных в облаках".

1. Синхронизация контейнера целиком может оказаться тяжелее чем отдельных шифрованых файлов.
2. В случае с EncFS данные как бы существуют одновременно в открытом и в зашифрованном виде, а мы синхронизируем именно зашифрованное "состояние" данных. А в случае с LUKS как будет?
3. Написав "прозрачно" я имел ввиду что пользователю специально не нужно вводить никаких паролей дополнительно, задумываться о монтировании/размонтировании. А с LUKS для этого пришлось бы использовать ключи, что менее безопасно чем ввод пароля при логине.
Хотя про авторазблокировку LUKS с помощью ключей я бы с удовольствием почитал что то внятное, так как на практике сделать подобное у меня не получилось.
Пользователь решил продолжить мысль 16 Ноября 2013, 07:08:15:После ответа Spect-у, наткнулся на тему созданную пользователем zhart ещё в 2010 году: https://forum.ubuntu.ru/index.php?topic=101296.msg766747#msg766747 и его статью Безопасность при использовании сервиса Dropbox в Ubuntu Linux. В этой статье, в отличие от статьи в wiki, вместо пакета libpam-encfs используется пакет libpam-mount. В самой статье и в комментариях к ней как раз обсуждается преимущество использования в облаках виртуальной файловой системы EncFS перед криптоконтейнерами .

[ArcFi]

попробовал

Молодец.

***
Поправил/добавил теги.
Упростил некоторые команды:
/home/<username> == $HOME == ~
<username>  == $USER

[Spect]

Где-то рядом с этой могу написать статью "Используем LUKS-контейнер для "прозрачного" шифрования данных в облаках".

1. Синхронизация контейнера целиком может оказаться тяжелее чем отдельных шифрованых файлов.
2. В случае с EncFS данные как бы существуют одновременно в открытом и в зашифрованном виде, а мы синхронизируем именно зашифрованное "состояние" данных. А в случае с LUKS как будет?
3. Написав "прозрачно" я имел ввиду что пользователю специально не нужно вводить никаких паролей дополнительно, задумываться о монтировании/размонтировании. А с LUKS для этого пришлось бы использовать ключи, что менее безопасно чем ввод пароля при логине.
Хотя про авторазблокировку LUKS с помощью ключей я бы с удовольствием почитал что то внятное, так как на практике сделать подобное у меня не получилось.

1. При использовании LUKS - синхрится не весь объем, а только измененные блоки. Проверено на dropbox - юзаю с ноутом 5-летний по возрасту модем CCU-550 с оплатой "за мегабайт" - нормально, объем трафика мониторю, синхра занимает мизер.
2. Синхрится исключительно "файл-контейнер". В открытом виде монтирую куда-то "в иное место"
3. Использую файл-ключ в закрытом подкаталоге хомяка, никаких паролей не ввожу. Описано в Создание и использование в облаке криптоконтейнера LUKS (dm-crypt), дописал вплоть до "создать кнопку и вывесить в ланчер" для юнити.
---------
Там же привел отличия от encfs. Мне как-то "не нравится" что есть список файлов, известен их размер и часто и имена.
Контейнер - именую, к примеру *.avi или *.rar - мелочь, но при грубом скане облака "по именам"... Лежит среди роликов или архивов инсталлях и кушать не просит
Статью хочу довести до ума, приложить пяток картинок и примеров вывода команд. Сейчас некогда. Все собираюсь создать отдельного юзера и прогнать "всю цепочку" под ним, може где-то описался. Не додумал схему организации "несколько контейнеров", вообще-то я мало что шифрую и 2-3 мелких мне хватает . То есть, на уровне "себе использую" - это делаю, на более полный обзор пока никак не дотягиваю.
Еще все думаю более детально ЯДиск и вуалу заюзать.. По идее, для нормального сохранения данных в облаке - 3 копии контейнера в 3 разных облаках - и на локале можно и не хранить. В "пользовательском соглашении" всюду стоит дежурная фраза, что "твой аккаунт имеют право в любой момент грохнуть и ты пойдешь на фиг без объяснения причин" Это перекроет любое шифрование
А так - описание схемы 1. Синхры в 3-4 облачных сервиса  2. Метод "контейнер" (LUKS) и метод "каталог" (encfs) 3. Организация нескольких вариантов монтирования - ключ, пароль, авто- при логине, ручное по кнопке (кнопка для юнити, кнопка для гнома) 4. Сохранение самой схемы и ключей на случай потери/повреждения компа - так, собственно, весь план статьи, в сторону которого копаю.. пару часов в неделю.

Пользователь решил продолжить мысль 17 Ноября 2013, 00:26:19:Открыл тему  Создание и использование в облаке криптоконтейнера LUKS (dm-crypt)
https://forum.ubuntu.ru/index.php?topic=233759.0 и далее страничку вики

[oermolaev]

Spect,
в пользу EncFS надо добавить более рациональное использование ограниченного пространства в облаке.

[Spect]

oermolaev,
Я написал "отличия", но что из них является "более рациональным" - это еще тот вопрос! Не согласен.
Экономия места, которую мы имеем при использовании encfs(только необходимое место) в отличие от контейнера, где "выделен кусок, и неважно, файлы в нем или пустота, он выделен весь" - это мне кажется весьма сомнительной "рациональностью". Например, в виртуалбоксе я всегда использую диск "фиксированного размера" - мне так представляется существенно удобнее, чем "изменяемый по размеру диск". Самый лучший способ криптования связан с как раз с "захламлением" и многократным увеличением объема "фрагмента информации" и известен с древних времен. Например - вы готовите 5 одинаковых по форме и взаимоисключающих по содержанию документов, и кроме вас, никто ж не знает, что "истинный вариант номер 3". Вспомните прекрасный фильм "Вариант Омега" с Олегом Далем .
Существуют многие устойчивые заблуждения - "трудно найти иголку в стоге сена". Это фигня. Рота солдат, вооруженных магнитами, сделает это быстрее чем за 1 час. Но попробуйте найти лист - в летнем лиственном лесу.
При использовании криптования не имеет смысла рассматривать "размер". Как и является "опасным" увлечься "супералгоритмами".
Другое дело - трафик Ну, зависит от схемы синхронизации конкретного "облака". Для дропбокса - трафик экономится.

[oermolaev]

Spect,
теперь у нас в wiki есть оба варианта и есть возможность выбирать. Каждому своё, по потребностям. Так у меня в стогиговом облаке майл.ру заброшены в шифрованном виде три фотки - ради эксперимента. И большой вопрос какой размер криптоконтейнера мне пришлось бы выбрать для моих задач.

[Spect]

oermolaev,
согласен.

[oermolaev]

Добавил практические замечания по вопросам с которыми столкнулся при настройке синхронизации со вторым компьютером