"PGP Disk под Linux" / системы шифрования


Существует простая и замечательная программка – PGP Disk, я использую версию 6.0.2i. Знает ли кто-нибудь способы монтирования *.pgd -файлов под Linux ? (хоть под какую-нибудь версию). Сейчас живу на 98-й винде, но про Линукс не раз задумывался. Переезду мешает отсутствие ряда программ, и PGP Disk в их числе. Кто что думает по этому поводу ?


Комментарии
— paranoid ant (22/09/2005 16:35)   
монтировать *.pgd файлы в linux нельзя

В линух эта задача решается с помощью использования шифрованных фаловых систем, есть большой набор средств для этого – сryptoloop, dm-crypt.
Проект http://www.freeotfe.org/ позволяете работать с такими данными из windows, на их сайте заявлена совместимость с dm-crypt и кажется cryptoloop тоже.
— paranoid ant (22/09/2005 16:36)   
хороший обзор средств "прозрачного" криптования данных на диске
http://www.infoanarchy.org/wik..... Hard_Disk_Encryption[link1]
— unknown (22/09/2005 19:52)   


Сейчас живу на 98-й винде, но про Линукс не раз задумывался. Переезду мешает отсутствие ряда программ, и PGP Disk в их числе. Кто что думает по этому поводу ?



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


Функции шифрования встроены непосредственно в само ядро ОС Linux и обычные утилиты, которые работают с файлами, дисками, разделами и свопом и позволяют задавать шифрование как дополнительный параметр. Нужно один раз разобраться как это работает, настроить как вам удобно и все.
Когда вы будете подключать диск или входить в свой домашний каталог у вас будет спрашиваться пароль или ключ. Никакой специальной программы для шифрования запускать не надо. Возможность шифрования встроена в систему и по мнению многих превосходит то, что можно сделать в Win.

Правда, совместимости с PGP-диск Вы скорее всего не дождетесь. Проще будет перенести данные через gpg-архив в Linux и распаковать там.
— unknown (23/09/2005 22:34)   
Поскольку общий вопрос про шифрование в Linux возник в другой ветке, переношу его сюда:




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



Из "программ" только bestcrypt, но это коммерческий продукт "для чайников" или для тех, кому нужна кроссплатформенность.

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

Основные три варианта:
1) cryptoloop+cryptoAPI (он устарел и больше не поддерживается, но в ядрах ветки 2.4 его будут еще долго использовать). Его криптографические уязвимости пока некритичны, но от него следует отказываться.

2) dm-crypt+cryptoAPI+cryptsetup. Это "мэйнстрим". В новых ядрах 2.6 и новых дистрибутивах он дает готовое шифрование "из коробки".

2b) LUKS – Linux unified key setup – продолжение и расширение проекта dm-crypt. Новые подходы в шифровании, использование слотов с системой менеджмента ключей.

3) loop-aes. Альтернативная реализация cryptoAPI для ядер 2.4 и 2.6. Интеграция с GPG.

GPG ключ с загрузчиком системы может быть вынесен на внешний (в т.ч. легкоуничтожаемый носитель). Т.о. и получается полностью зашифрованный диск. При этом можно скрыть даже таблицу разбиения диска на разделы.
Возможно многоключевое шифрование секторов. Устанавливается как набор модулей к ядру без необходимости накладывать патч.
— Гость (11/10/2005 19:45)   
а на freebsd что посоветуете, кроме geom?
— Гость (12/10/2005 10:15)   
Встроенное никсовое шифрование это конечно замечательно, но вот такой вопрос – поскольку это шифрование файловой системы, то можно ли будет _УДОБНО_ и _БЫСТРО_ делать полный бэкап такого каталога ?
PGP Disk '-и резервируются тупым копированием контейнера по [F5], a можно ли будет также легко копировать криптованный каталог из никсов, не расшифровывая его? Я правильно понял, что такое никсовое криптование возможно только на ext2/ext3/reiser ?
(сразу скажу – концепция маздайного EFS мне _ОЧЕНЬ_ НЕ ПОНРАВИЛАСЬ)
— paranoid ant (12/10/2005 12:35)   
Amin, шифрованная фаловая система "живет" в обычном файле (можете называть его контейнером), ведь в unix почти все – файл.

Для быстрого и удобного бекапирования необходимо лишь размонтировать шифрованную fs, скопировать файл и можно продолжать работу. Если использовать volume manager (LVM, EVMS) и механизм snapshots то время простоя сократиться до долей секунды.
— Гость (28/10/2005 15:55)   
Спасибо за помощь, буду потихоньку RTFM-ить...
Главное, что сделать аналог вполне реально.
— Гость (21/11/2005 22:47)   
Кто-нибудь собирал сабж из исходников?
Т.к. для АСПа у них нет ничего подходящего( подходит федора 3, но у 4ка), взял исходники, почитал мануал\реадме.
Build.sh останавливается на первом пункте теста ядра – версии.
Т.е. выводит версию ядра, путь (к нему) – и на этом все останавливается. В мануале про подобное ничего не сказано. Фктически выдается строка, соответсвующая в build.sh:
[ "$V" ] && error "TrueCrypt requires Linux kernel 2.6.5 or later" && exit 1

[ ! -d $KERNEL_SRC ] && KERNEL_SRC=/usr/src/linux
При этом у меня последнее обновление.
Где может быть "зарыта собака"?
— unknown (22/11/2005 08:51)   
А исходники ядра в /usr/src/linux распакованы с kernel.org или дистрибутивные?
С дистрибутивным ядром обычно такие штуки не проходят и если вам нужны какие-то крипто- или security патчи или модули, то с дистрибутивным ядром обычно можно попрощаться и собирать с kernel.org все самому.

Потому как в Fedore ядра очень перелопаченные и не рассчитаны на то, что их всерьез будут трогать.

Правда, это только мои догадки, как конкретно работает truecrypt я не проверял.
— unknown (23/11/2005 08:38)   
А чему равна переменная [ "$V" ] ?
Она случаем не из dmesg или uname -a берется?

А правильно ли определилась $KERNEL_SRC?
А в /usr/src/linux что распаковано?
— Гость (23/11/2005 22:22)   
Вот вырезка из файла build.sh:
case "$(uname -r)" in
[01].*) V=1 ;;
  1. [0-5].*) V=1 ;;
  2. 6.[0-4]) V=1 ;;
  3. 6.[0-4][.-]*) V=1 ;;
esac
[ "$V" ] && error "TrueCrypt requires Linux kernel 2.6.5 or later" && exit 1

[ ! -d $KERNEL_SRC ] && KERNEL_SRC=/usr/src/linux
if [ ! -d $KERNEL_SRC ] ||! Check_kernel_version "$KERNEL_SRC"
then
echo -n "Linux kernel ($(uname -r)) source directory [$KERNEL_SRC]: "
read A
[ "$A" ] && KERNEL_SRC="$A"
[ ! -d $KERNEL_SRC ] && error "$KERNEL_SRC does not exit" && exit 1
fi

Хм...
В /usr/src/linux вообще ничего нет. Т.е. даже нет папки linux. /usr/src/ – пусто.
Т.е. там должны быть исходники ядра? Хм.. поспрашиваю еще раз (на общий вопрсо не ответили) насчет установки TC в рассылке суппорта АСПа (если ответят) на данную тему....
— Гость (23/11/2005 22:23)   
Версия ядра определилась правильно.
— unknown (24/11/2005 17:22)   


Эта строка означает, что если директории с исходниками ядра не существует, то вылетать с кодом ошибки 1.

Что там дальше в скрипте, я не знаю, но наверное скрипт не просто так лезет в каталог с исходниками ядра? Наверное модули к ядру попытается собрать или еще чего сделать.

Но до это дело даже не дошло.
В переменной $V у вас определилась неправильная версия ядра.
Что выводит команда uname -r ?
— Constantine (25/11/2005 01:04)   
Вот: 2.6.12-1.1381asp
Кроме этого в мануале пишется следующее:

Requirements for Running Truecrypt on Linux

– Linux kernel version 2.6.5 or any higher/compatible version
– Device mapper (dmsetup, http://sources.redhat.com/dm) and loop device
(losetup) infrastructure, which are available in all major Linux
distributions.

При том, что указанное по команде ядро – последний апдейт АСПа. Как можно "обмануть"\выдать другой результат команде? Или какие-либо иные действия?
Напишу поддержке – посмотрю на реакцию :)
— unknown (25/11/2005 09:01)   
А, ну конечно. Последние пунктики в названии ядра это так называемая EXTRAVERSION. Эта переменная задается при компиляции ядра в Makefile.

В 2.4 это было так:

KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)

У вас два варианта: или взять исходники дистрибутивного ядра подправить Makefile и пересобрать его с полной поддержкой крипто или переходить на ядро с kernel.org.

Если скрипту не требуются исходники (в чем я сомневаюсь) можете удалить кусок проверки версии ядра.

Также я откровенно говоря сомневаюсь, что программа будет корректно работать на вашем "ванильном" аэспэшном ядре.

Мне лично кажется использование Truecrypt под Linux неоправданным решением.
Можно использовать стандартные средства монтирования с шифрованием через dmcrypt/losetup, а Truecrypt, как я понимаю, только служит оболочкой к ним.

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

Проще один раз и надолго выучить синтаксис пары комманд, зато все будет надежнее. А то в один не очень прекрасный день окажется, что ядро или sysutils у вас изменились, а truecrypt с новыми версиями временно не работает.

А я ведь предупреждал!
— unknown (25/11/2005 09:10)   
:-) Предлагаю грязный хак с закомментариванием строчек: :P



И положите исходники ядра в /usr/src/linux, а то что у вас эта директория девственно чистая, как будто в ней ядро еще ни разу не компиляли?

Или ASP рекомендует исходники для этого дела засовывать в более нестандартное место? ;-)
— Constantine (27/11/2005 19:17)   
Как оказалось, исходники хранятся в ином месте. Сменил путь на правильный, но все равно не помгло – теперь просто не захотело устанвливаться.
В конце концов мне порекомендовали запостить описание своей проблемы на http://asplinux.net/modules/ne.....opic_id=654&forum=54[link2], что и было сделано (увидите там пост от Constаntine). Сказали, что будут пинать по этому поводу разработчиков. Ждем-с :))
Насчет целесообразности использования TC под Линух: если бы не приходилось работать под форточками, рабтоал бы с зашифрованными разделами. Но, т.к., похоже, нет под Вынь средств работы с крипторазделами Линуха, ТС – самый подходящий выбор.
Если такие средства есть (нормальные, адекватные) – плз ссылки.
М.б. кто-нибудь пнет разработчиков ТС на этот счет? Чтобы встроили также и поддержку подобного? Я не смогу (пока :)), т.к. не знаю аглицкий, да и не программер (вдруг предложат самому реализовать этот модуль :).
— unknown (27/11/2005 20:48)   
Еще раз. Кто-то из нас двоих чего-то не понял. Если я, то поправьте.
В Linux вы можете работь с контейнерами и разделами средствами самой ОС (crypto-ядро+sysutils+FAT32).
TrueCrypt под Linux для этого вам не нужен. Он, насколько я понимаю, лишь оболочка для всего этого
(или дает какие-то дополнительные сомнительные возможности?)

А то что вы насоздаете в шифрованном виде под Linux, то можете открывать в Windows при
помощи виндового Truecrypt или FreeOTFE.

Так надежнее. И по-моему даже проще.

В вашем дистрибутиве в ядре включена по умолчанию поддержка crypto? Что у вас показывает комманда cat /proc/crypto ?
— Constantine (27/11/2005 20:53)   
Вот что выдает:
[root@localhost /]# cat /proc/crypto
name: sha1
module: kernel
type: digest
blocksize: 64
digestsize: 20

name: md5
module: md5
type: digest
blocksize: 64
digestsize: 16

Из-под форточек с помощью ТС можно открывать зашифрованные (crypto-ядро) разделы? Есди да, то в таком случае ТС действительно не нужен...
— Constantine (30/11/2005 20:48)   
Все, разобрался. Спасибо.
— paranoid ant (01/12/2005 13:42)   
unknown:
Е
...
А то что вы насоздаете в шифрованном виде под Linux, то можете открывать в Windows при
помощи виндового Truecrypt или FreeOTFE.
...


Замечу что TC работает только с собственными контейнерами, FreeOTFE понимает как контейнеры в своем формате так и dm-crypt/LUKS

FreeOTFE имеет модульную архитектуру и создан на основе библиотеки компонет. В документации упомянут компонент OTFETrueCrypt, возможно планируется реализация поддержка TC (кто разбирается в Delphi ?)
— unknown (03/12/2005 19:22)   
Все, разобрался. Спасибо.

Я просто не знал, что в ядре конкретно вашего дистра по умолчанию поддержка шифров отключена, включены только хэши, хотя и предполагал, что это так. Все-таки для экспериментов с криптографией советую пользоваться оригинальным ядром и самому компилировать с поддержкой нужных опций.
— Constantine (03/12/2005 20:05)   
Скорее всего буду пользоваться встроенным шифрованием, а под фыорточками соответственно FreeOTFE, например.
:)) Теперь надо разбираться со встроенным. Но это уже к саппорту...
— Гость (20/04/2006 18:12)   
Разве в Linux для крипто до сих пор используется md5?
Скажите, при управлении правами доступа для разных пользователей какой хеш используется? Насколько мне известно для этих целей используется gpg или нет?
Где тогда используется md5, который уже основательно взломан?
— unknown (21/04/2006 09:20)   
Где тогда используется md5, который уже основательно взломан?

Почти везде. В /etc/shadow например, а в управлении в пакетах совместно с SHA-1. И в ближайшее время менять никто ничего не собирается.

Для вычисления HMAC для IPSEC – а именно для этого он включен в ядре его тоже менять в ближайшее время не будут.

В большинстве случаев атаки на нахождение коллизий здесь не практичны, проверенных альтернатив нет.
— Гость (22/04/2006 09:15)   
Скажите, при входе в систему для определения владельца учетной записи используется GnuPG или иная система?
В большинстве случаев атаки на нахождение коллизий здесь не практичны, проверенных альтернатив нет.

Вы хотите сказать, что использование md5 в Linux в большинстве случаев не угрожает безопасности?
— unknown (22/04/2006 18:11)   
Для входа в вистему сравнивается MD5-хэш пароля с MD5-хэшем из /etc/shadow. Поскольку найти инверсию хэша MD5 маловероятно (нынешние достижени в нахождении коллизий, но никак не инверсий или прообразов MD5 пока не дают повод ещё так думать), то можно спокойно использовать MD5. Есть схема с использованием BLOWFISH вместо MD5, но она предназначена только для замедления атак перебора паролей. В принципе можно использовать модули PAM, которые будут авторизовывать пользователя хоть через gpg, хоть через openssl, хоть с использованием смарт-кард.

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

Единственное, что потенциально опасно – это md5 суммы пакетов. Но они заносятся в список определенного формата, от списков считается md5 и sha-1 и это подписывается ключом gpg. Пока неизвестен способ подменить что-то так, чтобы не нарушить эту схему, хотя здесь уже следовало бы отказаться от md5 побыстрее.
— spinore (29/09/2006 23:50)   

а на freebsd что посоветуете, кроме geom?

Однозначно посоветуем GELI. Оно более здоровое, более функциональное, и содержит меньше _потенциальных_ уязвимостей. Для надёжности от некоторых потенциально возможных со стороны АНБ атак рекомендуется пользоваться двойной аутентификацией в GELI (там надо ещё шифровать "соль пароля" или некоторые спецфайлы для раздела – не помню) отдельным gpg-ключом, котолрый хранить раздельно с самой шифруемой информацией, например, на флэшке.

В NetBSD не плохая система – CGD.

OpenBSD пока в сильном пролёте по алгоритмамв шифровании дисков – они уязвимы для ряда потенциальных атак и очень негибки. Аналога CGD в современных версиях open нет :(((
— spinore (30/09/2006 00:02)   
Denis_S:
Разве в Linux для крипто до сих пор используется md5?
Скажите, при управлении правами доступа для разных пользователей какой хеш используется? Насколько мне известно для этих целей используется gpg или нет?
Где тогда используется md5, который уже основательно взломан?

1. Вопрос про использовании md5 зависит от дистрибутива. В Gentoo Linux, как одном из наиболее профессиональных, никаких дефолтов в этом плане нет, насколько мнеизвестно: выбираете сами какой хеширующий алгоритм вам лучше использовать. В частности, у меня при установке NetBSD также предлагался выбор для master.passwd. Я выбрал sha-1.

2. А какая разница собственно что там стоит? Обычный пользователь не имеет прав рута. И прочитать тот файл не сможет. Если же пользователь получит эскалацию прав до рута, то единственной целью декодинг passwd будет иметь атаку с помощью узнанных паролй на другие серверы. Если же ваш диск изымут, то права доступа не имеют никакого смысла, как и то что там в passwd. Вопрос будет только в одном: что у вас лежит на криптофс, в чём при условии разных паролей passwd не помощник.

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

4. gpg используется для шифрования отдельных файлов и сообщений, особенно пересылаемых кому-либо, где и проявляется вся суть идеологии с _асимметричным_ шифрованием.
— Вий (29/05/2009 17:04, исправлен 29/05/2009 17:13)   
Команда cat /proc/crypto в моей системе дает следующий вывод:



система Ubuntu 9.04 (jaunty)

В папке /usr/scr/ лежат следующие папки:
linux-headers-2.6.28-11 размером 33,7 Мб
linux-headers-2.6.28-11-generic размером 1,7 Мб

Команда uname -r дает вывод:
2.6.28-11-generic

Насколько я понимаю в моем ядре то же включена поддержка только хешей и от ключена поддержка шифров? Могу ли я использовать какой-либо способ шифрования средствами файловой системы без перекомпиляции ядра?
— unknown (29/05/2009 17:46)   
Поддержка скорее всего включена, просто модули незагружены, т.к. не используются:



Установите пакеты, связанные с dm-crypt и LUKS и всё практически само настроится.
— peergynt (11/06/2009 17:57)   
Добрый день.
У меня вопрос по алгоритмам шифрования cryptsetup/LUKS.
По умолчанию LUKS шифрует aes-cbc-essiv:sha256, и рекомендует именно такую связку.
Достаточно ли надежен такой вариант?
Возможен ли вариант twofish-xts-essiv:sha256 или twofish-xts-essiv:sha512?
Предпочтительнее ли режим шифрования XTS перед CBC для шифрования всего диска?
Какие Best practices и рекомендации в этой области?
— SATtva (11/06/2009 19:38)   
peergynt, то, что Вам нужно, называется twofish-xts-benbi. XTS и ESSIV — два различных режима. Использование голого CBC для дискового шифрования опасно; подробности — в /faq/защитадиска[link3]. XTS более предпочтителен перед другими режимами, как с точки зрения теоретической базы, так и скорости и универсальности.
— peergynt (12/06/2009 14:02)   
Спасибо.
Внятных описаний допустимых комбинаций алгоритмов и режимов шифрования я не нашел, кроме разве что вот этого:
http://hightechsorcery.com/200.....24-and-later-kernels[link4]
Встречал варианты с экзотическими длинами ключей "-s 384", "-s 512":
http://www.linuxposts.com/linu.....thod-best-speed.html[link5]
, это лажа?
— SATtva (12/06/2009 14:57)   
Нет, это значит, что используется 256-битовый ключ и 128- или 256-битовый твик.
— peergynt (13/06/2009 02:49)   
Для начала я попытался зашифровать swap-раздел.

Содержимое файла /etc/crypttab:


При загрузке в лог /var/log/dmesg пишет:


Если вместо twofish взять aes:


, то в логе:


swap-раздел подключается нормально.
Насколько критичны эти сообщения?

ОС Ubuntu 9.04, поставленная через wubi[link6] поверх винды.
— SATtva (13/06/2009 12:23, исправлен 13/06/2009 12:26)   
Первое, если не ошибаюсь, означает, что в ядре нет тестового набора для проверки корректности алгоритма. Для работы это некритично... если модуль алгоритма реализован корректно (а это так, если Canonical там ничего не допиливала).

Второе означает, что в ядре включена поддержка аппаратных криптоускорителей, но в Вашей системе таких устройств нет. Это простое информационное сообщение.

Кстати, использовать в качестве источника ключевого материала /dev/random не обязательно, подойдёт и /dev/urandom, к тому же он не будет расходовать ценную чистую энтропию, собранную системой.

Кстати-2, помимо свопа желательно шифровать эфемерным ключом и раздел /tmp, там тоже за время работы скапливается немало интересного мусора.
— unknown (13/06/2009 14:22)   
...и при этом не пользоваться такой модной, но небезопасной штукой, как гибернация системы.
— peergynt (27/06/2009 01:43)   
Итак, я зашифровал swap и поместил /tmp и /var/tmp в tmpfs.
Теперь задача максимум – шифрование корневого раздела.
Напомню, что я использую wubi[link6]-инсталляцию Ubuntu 9.04, т.е. корневой раздел лежит в файле C:\ubuntu\disks\root.disk на ntfs-разделе под виндой.
После загрузки виндовый раздел монтируется в каталог /host, т.е. корневой раздел виден как /host/ubuntu/disks/root.disk

Я использовал следующие источники:
http://blog.uptimebox.ru/2007/05/debian-gnulinux-4.html
http://wiki.eeeuser.com/ru:get.....ие_корневого_раздела[link7]
http://www.c3l.de/linux/howto-.....u-6.10-edgy-eft.html[link8]

Вопрос: что писать в /etc/crypttab, чтобы после сборки update-initramfs initramfs увидел файл /host/ubuntu/disks/root.disk как loopback-устройство на этапе загрузки?

Я пробовал писать



, а также



, но при загрузке пишет, что устройство не найдено.

Для незашифрованной системы синтаксис grub в menu.lst такой:



Возможны ли в принципе такие выкрутасы?
Я понимаю, что достаточно зашифровать только раздел /home, и я скорее всего так и сделаю, просто интересна принципиальная возможность.
— SATtva (27/06/2009 18:51)   
Я в своё время кое-что писал[link9] о шифровании корневого раздела действующей системы, но это инструкция для менее мутировавших систем, чем wubi. В принципе, в initrd реализовать можно любой функционал. Ваша ситуация отличается от чаще рассматриваемых лишь тем, что до того как подмонтировать зашифрованный корневой раздел, Вам необходимо монтировать виндовой ntfs-раздел, где лежит образ.

Посмотрите это[link10] монстроподобное руководство. Там есть инструкции для создания достаточно универсального образа initramfs именно для системы с зашифрованным корнем. Возможно, с некоторыми адаптациями найдёте её для себя полезной.
— ГОСТЬ (28/02/2010 07:59)   
2 вопроса.


1. В системе Ubuntu 9.10, при установке, предусмотрен режим шифрования домашней папки. Данный режим устанавливается на стадии установки системы, включением опции шифрования паролем входа в систему.
Однако при дальнейшем создании дополнительных пользователей, в уже установленной системе, их домашние папки оказываются не защищенными. В меню создания пользователей опции шифрования просто нет. Есть ли способ решить данную проблему – сделать домашние папки других пользователей зашифрованными таким же образом?

2. Для Ubuntu есть пакет ecryptfs-utils, создающий шифрованную папку Private в домашнем каталоге. Но не могу понять, можно ли сделать управление шифровкой/расшифрокой этого каталога независимо от пароля пользователя. Пока добился только работы автоматической расшифровки при входе в систему и соответственно зашифровки при выходе. А вот как сделать независимо, по моей отдельной команде?
— SATtva (28/02/2010 10:14)   
1. Разве шифруется только /home/user, а не весь /home? Смею предположить, что всё-таки второе.
— ГОСТЬ (28/02/2010 14:28)   
В том и дело, что /home/user. Это проверено. Для проверки была создана отдельная учетная запись (пусть она будет /home/user2). После при загрузке компьютера с live дистрибутива /home/user2 созданного пользователя была доступна для просмотра, домашняя папка первого пользователя /home/user была не доступна.
С другой же стороны другие пользователи имеют свои уникальные пароли на вход в свои учетные записи, поэтому если бы шифровался весь /home с помощью пароля первой учетной записи, то другие пользователи просто не могли бы пользоваться машиной.
Вот такое наблюдение. Как быть, что нужно сделать, что бы паролем вторичного пользователя можно было шифровать свою /home/user2?
— SATtva (28/02/2010 15:41)   
Как быть, что нужно сделать, что бы паролем вторичного пользователя можно было шифровать свою /home/user2?

Как сделать это кошерно с точки зрения дистрибутива, Вам только другие пользователи Ubuntu подскажут. Я бы покопался в стартовых скриптах и поспрашивал гугл.

Как более универсальное решение, можно сделать файл-контейнер (или LVM slice, если он используется для управления разделами) под /home/user2, а в самой /home/user2 создать .bashrc, который будет монтировать зашифрованный контейнер/раздел в этот каталог при каждом логине пользователя.
— unknown (28/02/2010 20:40)   
ecryptfs-utils, создающий шифрованную папку Private в домашнем каталоге. Но не могу понять, можно ли сделать управление шифровкой/расшифрокой этого каталога независимо от пароля пользователя.

Изначально эта система шифрования (прозрачно-пофайлово поверх обычной ФС) это позволяет, то что она определённым образом заскриптована в Ubuntu — другой вопрос.
— Вий (29/05/2010 06:09)   
В системе Ubuntu 9.10, при установке, предусмотрен режим шифрования домашней папки. Данный режим устанавливается на стадии установки системы, включением опции шифрования паролем входа в систему. Однако при дальнейшем создании дополнительных пользователей, в уже установленной системе, их домашние папки оказываются не защищенными. В меню создания пользователей опции шифрования просто нет

В версии Ubuntu 10.04 все сделано как положено. При создании пользователя предлагается выбрать опцию "Шифрование домашней папки". Если опция будет отмечена, то домашняя папка будет зашифрована.
— Вий (11/07/2010 21:12)   
Каким алгоритмом шифруются домашние папки в Linux? Шифрование системными средствами по умолчанию, системы Ubuntu/Debian.
— Гость (11/07/2010 22:00)   
Должно быть, AES.
— Гость_OpenPGP (01/05/2013 18:57)   
Установил Ubuntu 13.04 с использованием LVM и шифрованием всех разделов с использованием cryptsetup (из коробки по умолчанию). Теперь при включении компьютера выводится меню GRUB, несмотря на то, что система на компе единственная, далее запрашивается пароль/фраза. Получился загрузочный раздел /boot, все остальное закриптовано.
Скажите, может ли злоумышленник каким-то образом извлечь пароль и получить доступ к системе? Хранится ли пароль или хеш от него в разделе /boot?
— Гость (01/05/2013 22:00)   
при включении компьютера выводится меню GRUB, несмотря на то, что система на компе единственная, далее запрашивается пароль/фраза.

Кажется, в предыдущих версиях убунты было что-то подобное.

может ли злоумышленник каким-то образом извлечь пароль и получить доступ к системе?

Никто удалённо не сможет проанализировать чужую систему, тем более, если она — убунта. Главная уязвимость всех таких систем — короткий ломаемый пароль. Самый короткий из надёжно неломаемых паролей (128 бит) может быть получен выводом команды
$ pwgen -s -y 20 1
Хранится ли пароль или хеш от него в разделе /boot?

Нет.

При желании можно поиграться с настройками grub'а так, чтобы загрузка по умолчанию шла с незагрузочного раздела, и потому выводилась ошибка; для правильной же загрузки требовалось загрузиться с LiveCD, войти в меню grub'а и поменять раздел, с которого грузиться, руками. Это может помочь от таможня-кидди при пересечении границы, а то как-то палевно, когда при загрузке сразу пароль требуется.
— Гость (02/05/2013 05:14)   
Кажется, в предыдущих версиях убунты было что-то подобное.

Это есть во всех Убунтах, но меню это при старте появляется только если на компе установлено минимум 2 системы. Предполагаю, что здесь появление меню связано с применением LVM и/или шифрования.

Никто удалённо не сможет проанализировать чужую систему, тем более, если она — убунта.

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

Самый короткий из надёжно неломаемых паролей (128 бит) может быть получен выводом команды

Не знал о такой утилитке. Но есть еще вариант:


или генератором паролей из KeePassX
— Гость (02/05/2013 09:29)   
Почему Вы говорите именно об удаленном анализе?

Потому, что трудно судить о том, кто как что настроил, если лично не присутствовал при настройке и не контролировал процесс.

Поэтому меня и интересует, не сохраняется ли какая-либо идентифицирующая ключ шифрования информация в boot...

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

Кстати, полный hibernate (не путать с suspend в ОЗУ) работает? Проверьте. :)
— котенок (02/05/2013 09:47)   
Кстати, полный hibernate (не путать с suspend в ОЗУ) работает? Проверьте. :)


Не встречался с hibernate. Что это значит?
— Гость_OpenPGP (02/05/2013 10:13)   
Вот что в boot лежит
— Гость (02/05/2013 17:55)   
Не встречался с hibernate. Что это значит?

Гибернация, как её некоторые кличут — ввод компьютера в спящий режим, когда всё содержимое ОЗУ выгружается на диск, а питание отключается. Не слышали? :)
— unknown (02/05/2013 18:19, исправлен 02/05/2013 18:27)   

В полностью шифрованной системе с двумя вариантами шифрования свопа (нешифрованный LV на шифрованном PV или шифрованный LV, но не urandom-ключом, а опцией decrypt_derived, выводящей ключ от расшифрованного корневого раздела) давно работает в Debian. Глюки если связаны, то с железом.



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

— Гость (02/05/2013 18:47)   
Если у Гостя искоробки заработает гибернация, значит, ключи в boot, предположу, таки сохраняются. :) Вряд ли в убунту это до ума довели, хотя кто его знает. В более старых версиях при просыпании после гибернации система тупо уходила в ребут.
— unknown (02/05/2013 20:15, исправлен 02/05/2013 20:22)   
Если у Гостя искоробки заработает гибернация, значит, ключи в boot, предположу, таки сохраняются. :)

При корректной реализации такой связи быть не должно.


Если всё на LVM, то никаких сложностей. В grub.cfg прописан UID корневого раздела. В рамдиске упакован кусок /etc/crypttab, кажется тоже с UID'ами и каким-то опциями, указывающими на параметры шифрования, но никаких ключей.


На старте GRUB → ядро → рамдиск, в рамдиске будет спрошен пароль от корневого раздела или физического тома, дальше расшифруется том со свопом и корневым разделом или расшифруется только корневой раздел, а через него по цепочке — своп, через decrypt_derived. Своп проверится на корректность и всё стартует из гибернации.


В более старых версиях при просыпании после гибернации система тупо уходила в ребут.

Может по-умолчанию своп шифровался на /dev/urandom, если он не находится на шифрованном физическом томе, общим с корневым разделом.


Не знаю, что там могли разрабы не осилить из коробки, это сейчас и руками сравнительно легко допиливается, если не было выбрано (или некорректно выбрано) при инсталляции.



Пароль в открытом виде нигде храниться не должен, но PBKDF-от него хранится внутри каждого шифрованного раздела в LUKS-слотах.

— Гость (03/05/2013 05:30)   
Провел эксперимент.
Исходные условия:
1. Кнопок спящего режима не обнаружил (используется не бук, а простой комп), есть только кнопка ждущего режима.
2. Открыт браузер с множеством открытых вкладок.

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

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



И еще вопрос у меня. Система при установке сделала все сама. Я лишь указал, что нужно использовать LVM и шифрование. В результате как я понял у меня терперь файловая система на тома не разбита (за исключением отдельного /boot на физическом уровне), а мне бы хотелось иметь как минимум /home на отдельном разделе. Использован весь диск.


Есть ли сейчас возможность выделить под /home (и может быть еще что-то) отдельный том? Если нет, какова последовательность действий?
— Гость (03/05/2013 14:16)   

Если на красную кнопку нажать, вылезет меню, там есть штуки 4 опции. Одна из них suspend, другая — hibernate. Судя по вами пописанной ситуации, вы использовали suspend.


Есть, но рисковано и геморройно :)


Это не для новичков. :) Например, лично я с этим серьёзно не разбирался, было дешевле попросить сделать того, кто знает.

Логика примерно такова: уменьшается файловая система (shrink file system),* уменьшается логический том, создаётся другой логический том, туда переносятся данные. Это если вы хотите отедльную файловую систему для /home. Если есть желание сделать её отдельным DOS-разделом на диске — это уже другое, там надо будет ещё с физическим томом поиграться.

Иерархия примерно такова: физический диск → физический криптотом → группа логических томов lvm (в т.ч. своп там обычно), причём шифрование происходит на уровне физического криптотома вроде бы. Смотреть, что куда смонтировано и как — man lvdisplay, man pvdisplay.

*Команда наподобие resize2fs -p /dev/mapper/УСТРОЙСТВО
— Гость (03/05/2013 14:31)   

>Судя по вами пописанной ситуации
Извиняюсь, пост пал жертвой собственных многократных исправлений. :(
— Гость (04/05/2013 01:00)   
не факт что получится без потерь изменить корень и выделенное пространство отправить под home в новый lvm-том.
есть пакет gui для работы с lvm2.
нужно запустить систему и воспользоваться этим пакетом изнутри.
— Гость (04/05/2013 04:28)   

Что концептуальное может, по-вашему, помешать? Кривизна рук разве что?
— Гость (04/05/2013 13:50)   
Что концептуальное может, по-вашему, помешать?
теоретически ничего. но бэкап важной инфы лучше сделать.
— Гость (04/05/2013 19:22)   
бэкап важной инфы лучше сделать.
Это всегда рекомендуется делать, при любой процедуре. :)
— unknown (04/05/2013 22:15)   
По повоту гибернации. Если стоит стандартный пакет hibernate, то имеются соответственно /usr/sbin/hibernate-disk и /usr/sbin/hibernate-ram. Смотрите их вывод, syslog, dmesg. Возможны варианты. В т.ч. гибернация нестандартным способом TuxOnIce со своим шифрованием. Таким шифрованием пользоваться не рекомендуется.

По поводу переразбивки LVM. Если шифрован физический том, а логические на нём — нет (а по дефолту скорее всего так), то можно делать resize2fs, вот только не знаю, делает ли она усечение (shrink) на работающем смонтированном корне. В любом случае, корень лучше сбэкапить (на другой шифрованый носитель).

Далее возможны варианты. Даже если resizefs shrink пройдёт нормально, то после этого надо уменьшить логический том корневого раздела. lvresize для этого подходит, но разница с lvreduce не очень ясна. Нельзя уменьшить до размера, меньшего, чем усечённая ФС — иначе потеря данных. Но если урезать сам том недостаточно, то может возникнуть ошибка при загрузке с предложением запустить filesystemcheck, который услужливо снесёт всю систему, правда показав перед этим кучу предупреждений и ошибок. Тогда нужно отказаться от исправлений filesystemcheck и сделать опять resize2fs, но с расширением до нового размера корневого тома, это делается точно и без ошибок, нужно только указать том в качестве устройства, а размер не задавать, он подгонится сам.

Если что-то из этого не работает, возможно придёться поднимать расшифрованный физический том cryptsetup luksOpen /dev/sd[x]2 /dev/mapper/root[name], затем pvscan, затем lvchange -a y, проделывая нечто из предыдущего абзаца, но уже с live-CD/live-USB на отмонтированной корневой системе.

После того как успешно создан уменьшенный логический том корня, на свободном пространстве физического тома создаётся том под /home посредством lvcreate, mkfs и прописывается в /etc/fstab.

Если логический том корня всё-таки повредили, то его придёться пересоздать, сделать mkfs и накатить систему из бэкапа.

pvchange -a n [name] – отцепление томов, тоже бывает полезно при закрытии раздела. При зависании томов есть жестокие команды dmsetup ls, dmsetup remove -f -j [number_1] -m [number_2] — это если у вас отвалился какой-нибудь usb-носитель с бэкапом, например: чтобы не ребутиться, а просто его переткнуть.

При более сложных конфигурациях возможны приключения с перепаковкой рамдиска, внесением туда, в новый корень в /etc/cryptab, /boot/grub.cfg новых UID, но вроде это не ваш случай. Т.е. выкрутиться можно практически из любой ситуации, если самому не сделать какой-то фатальный шаг, хотя при наличии бэкапа можно хоть весь винчестер стереть, только затем будет больше геморроя с ручной настройкой конфигов, UID, GRUB, LVM, dm-crypt. Опять же, зависит от желания и возможности разобраться, как это всё работает.
— Гость (04/05/2013 23:09)   

Такое впечатление, что пособие для самоубийц пишете. :) Естественно, все операции с корнем нужно выполнять, загрузившись
с live-CD/live-USB

С живой подмонтированной файловой системы даже бэкап посредством dd выполнять не рекомендуется по вполне понятным причинам. Я подозреваю, что система и не даст сделать shrink для подмонтированной файловой системы (то же самое, возможно, касается и ряда операций с lvm).
— Гость (04/05/2013 23:09)   
иногда бывает проще переустановить систему в нужной конфигурации разделов, чем краить и "резайзить". тем более, когда речь идет о зашифрованных разделах.
— unknown (04/05/2013 23:21, исправлен 04/05/2013 23:40)   

Ладно, в форуме можно написать неточно вспоминая, не до конца вникая, второпях и несвязно. Но хотя бы предупредив о возможных неточностях. Но в man только путём некоторого логического предположения можно понять, что налету можно делать expand, а не shrink:


If the filesystem is mounted, it can be used to expand the size of the mounted filesystem, assuming the kernel supports on-line resizing. (As of this writing, the Linux 2.6 kernel supports on-line resize for filesystems mounted using ext3 and ext4.).

kernel supports on-line resize for filesystems

Даже если не выдирать эту фразу из контекста, по ману про shrink просто умалчивается: либо пользователь сам догадается, что on-line resize не относится к shrink, а только к expand; либо какой-то другой вариант.


Но явного однозначного толкования не дано.



Но можно делать LVM-снэпшоты :) Бэкап лучше делать таром, сделав
А ещё есть cpio и rsync. Главное переносить файлы на другую ФС, зачем dd? Причём при bind-монтировании получим корректный бэкап без мусора, с которого можно обратно накатить рабочую систему. Проверено неоднократно, только в таких вещах много чего может вылезти, с чем придёться разбираться по ходу дела. Поэтому трудно советовать на все случаи жизни и у многих есть некоторые отличия в выборе методик.



Зависит от ситуации, от опыта таких низкоуровневых ковыряний. Как-то что-то подобное приходилось делать, но с мотивацией: если не получится, то тогда можно и заново переустановить. Получилось, какой-то дополнительный опыт появился :)

— Гость (05/05/2013 01:33)   

За тем, что в dd думать не надо, и получим полный валидный клон диска.1 Не надо думать о наличествующих файловых системах, разделах и пр. В конце концов, не надо монтировать критические данные на длительный по времени срок только для того, чтобы их сбэкапить.2 Тем не менее, всё, конечно же, зависит от задачи и ситуации. Я бы сделал rdiff-backup и потом восстановил из него. Можно играться с cpio и архивами, но это минное поле. Могут побиться права, неправильно раскрыться симлинки и т.д. Учтите, что в корне много спецфайлов, типа тех, что в директории /dev, и все их надо корректо обработать. Когда-то делал бэкапы каких-то директорий методом
# find / -xdev -depth -path /path/to\* -o -print0 | cpio -pvd0m /mnt
и что-то не сработало, потому что в конкретно моей версии cpio был один непофиксенный баг. Грабли раскиданы повсюду, и надо с этим играться постоянно, чтобы знать, что работает, а что нет. Если никогда ранее подобные операции не проводились, вероятность того, что блин будет комом, стремится к единице.


А при dd не придётся, если не будете пытаться смонтировать одновременно старую и новую файловые системы (это вызовет конфлит идентичных uuid'ов).

1Это если битых секторов нет. Если же они есть, то имеются другие тулзы, производные от dd, которые всё равно автоматически всё сделают.
2Первый бэкап для дисков современной ёмкости — это очень не быстро.
— unknown (05/05/2013 14:12)   
Раньше были баги в cpio и tar. Обычно, они возникали из-за того, что на исходной ФС были неполадки и из-за неправильного чтения файла, tar или cpio вываливался с ошибкой. Поскольку — это очень древние и широко используемые утилиты, то их регулярно фиксят. Метод бэкапа и переразвёртывания из-под работающей системы tar'ом, rsync'om, cpio многократно опробован. Особенно полезно, когда надо переносить данные на другое железо, на винты или разделы других размеров, копировать по сети через ssh.


А dd бэкапит много лишнего, в т.ч. возможно дефекты ФС. Опять же, в поставленной задаче после бэкапа dd, снятый образ как-то придётся примонтировать, чтобы тем же таром из-него переносить данные на новый LV с другим размером.
— Гость (05/05/2013 21:59)   

На системе, релизнутой в 2010-ом году, наткнулся позже на какой-то баг в cpio, связанный то ли с сохранением permission'ов на файлы, то ли ещё чем, уже не помню. Но в целом с вами согласен. Метод dd — скорее экстренное снятие копии с диска в момент, когда понимаешь, что он умирает и счёт его жизни, возможно, пошёл уже на часы или минуты, а разбираться с другими тулзами некогда, т.к. инфраструктура для нормальных бэкапов не была сделана. Для всех других случаев хватает тех же, например, rdiff-backup, rsync и пр.
— Гость (09/05/2013 19:42)   

resize2fs делается, естественно, не на лету, и до ресайза лог. тома с корнем. Я всегда делал так: уменьшал с запасом, потом ресайзил лог. том, потом делал еще один ресайз ФС с автоподгонкой под том.
— pgprubot (26/09/2015 22:59, исправлен 13/10/2015 20:24)   

Скрипт для случая «expand»:

#!/bin/sh
 
# Enlarging encrypted LVM
# The device must be already mounted
 
LUKS_NAME=$1   # (without path ``/dev/mapper/'' and ``_crypt'')
SIZE=$2        # Size of enlarging. E.g. 10G.
 
LUKS_DEVICE=${LUKS_NAME}_crypt && \
echo LUKS device is: $LUKS_DEVICE && \
DIR=$(mount |grep $LUKS_DEVICE |cut -d ' ' -f3) && \
echo It is mounted on: $DIR && \
LVM_DEVICE=$(cryptsetup status $LUKS_DEVICE \
            |grep 'device:' |sed 's/^.*\/dev/\/dev/') && \
echo It is on LV: $LVM_DEVICE
 
set -x
umount /dev/mapper/$LUKS_DEVICE && \
fsck -C0 -f /dev/mapper/$LUKS_DEVICE && \
sync; sleep 1 && \
cryptsetup luksClose $LUKS_DEVICE && \
sync; sleep 1 && \
lvextend -L +$SIZE $LVM_DEVICE && \
cryptsetup luksOpen $LVM_DEVICE $LUKS_DEVICE && \
cryptsetup -v resize $LUKS_DEVICE && \
mount /dev/mapper/$LUKS_DEVICE $DIR && \
umount $DIR && \
e2fsck -C0 -f /dev/mapper/$LUKS_DEVICE && \
resize2fs /dev/mapper/$LUKS_DEVICE && \
mount /dev/mapper/$LUKS_DEVICE $DIR
Предполагается, что увеличивается размер LUKS-шифрованного логического тома LVM, который на момент запуска скрипта уже куда-то подмонтирован, но вы увидели, что там недостаточно места. Скрипт сам определяет, куда подмонтирована файловая система (ФС) с LUKS'а, и с каким LV ассоциирован данный LUKS. Скрипт сам отмонтирует ФС, увеличивает размер файловой системы и снова монтирует её туда же — вы получаете ровно то же состояние системы (mount'ы, открытые LUKS'ы), какое было до скрипта, но с увеличенным размером ФС. Для тех ФС, которые не ext<N>, скрипт из коробки не заработает, его придётся редактировать.


Пример метода запуска:



Эта команда увеличила на 20M LUKS-том, который в тот момент был подмонтирован и открыт как /dev/mapper/LUKSNAME_crypt.** Учтите, что скрипт не проверяет, используется ли в данный момент эта ФС какими-то процессами, т.е., если нужно, вы должны вручную завершить все нужные процессы до запуска скрипта. Предупреждение «WARNING: This metadata update is NOT backed up», вероятно, вызвано тем, что в /etc/lvm/ не сохраняются логи с информацией обо всех когда-либо подключавшихся LVM-устройствах.


P.S. Когда тестировал, при первом запуске скрипт почему-то поругался на luksClose, что блочное устройство кем-то используется, хотя это было не так. Само устройство скриптом при этом всё-таки было успешно отключено. На будущее поставил для гарантии (и без понимания) sync и sleep в двух местах, и больше такая ошибка не писалась. Может быть, это излишне, а первый раз просто случился какой-то глюк.


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


** Концовку «_crypt» при запуске скрипта указывать не надо. Если у вас приняты другие именования расшифрованных блочных устройств, исправьте скрипт до его запуска под свой случай.


Ссылки
[link1] http://www.infoanarchy.org/wiki/index.php/Hard_Disk_Encryption

[link2] http://asplinux.net/modules/newbb_plus/viewtopic.php?topic_id=654&forum=54

[link3] http://www.pgpru.com/faq/zaschitadiska

[link4] http://hightechsorcery.com/2008/08/linux-crypto-options-2624-and-later-kernels

[link5] http://www.linuxposts.com/linux-security/86624-encryption-method-best-speed.html

[link6] http://wubi-installer.org/

[link7] http://wiki.eeeuser.com/ru:getting_ubuntu_8.04_to_work_perfectly#шифрование_корневого_раздела

[link8] http://www.c3l.de/linux/howto-completly-encrypted-harddisk-including-suspend-to-encrypted-disk-with-ubuntu-6.10-edgy-eft.html

[link9] http://vladmiller.info/blog/index.php?comment=113

[link10] http://en.gentoo-wiki.com/wiki/DM-Crypt_with_LUKS