ecryptfs + pam_mount

Мало хомяк шифровать, нужно ещё swap и var/log как минимум. Если в федоре на эти разделы ставишь один и тот же пароль, система запрашивает его только один раз.

Спасибо, покурю!

Придется логи на отдельный раздел выносить :( Я юзаю Debian, надо будет поэкспериментировать. А при выходе из гибернации какая картина с паролями?

Проще физический диск целиком. Грузиться с мини-дистра на флешке через kexec.

Впрочем, с «проще» - это я погорячился. Но архитектурно более Ъ.

Ну /boot и загрузчик выносишь на флешку, а корень зишифрованный на ноуте.
Делается элементарно и в Debian и в Ubuntu (через alternate установщик).

Мало хомяк шифровать, нужно ещё swap и var/log как минимум

И как живется параноикам?

Если у тебя параноя, то:
0 - Переносишь ценные данные на другой комп/винт.
1 - Формитируешь винт ноутбука и ОБЯЗАТЕЛЬНО затираешь его 1-3 раза.
2 - Устанавливаешь чистый debian с шифрованным корнем и шифрованным swap, grub и /boot на флешку.
3 - Загружаешься в систему и переносишь /tmp в tmpfs, c /var/tmp симлинк на /tmp
4 - ?????
5 - PROFIT!

Переустанавливать надо по любому, т.к если у тебя на винте были не шифрованные данные, то они там и останутся даже после настройки ecryptfs.

Отлично живется.
Даже на старых машинах никаких тормозов, все работает идеально.

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

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

 load Module: «nvidia»
 loading /usr/lib64/xorg/modules/drivers/nvidia_drv.so

А swap то зачем шифровать?

и вар,

Логи openvpn например по дефолту туда пишутся.
Так же пишутся все системные логи устройств (что когда ты куда пихал, с id устройств).
Так же там хранится база пакетного менеджера.
Ну а ещё шифровать систему хорошо для того, чтобы нельзя было туда закатать какую нибудь гадость или что то поломать (не поломав всю ФС).

А ещё в /var пишут TOR, i2p и вообще все уважающие себя системные демоны.

свапа

Один юзер с ЛОРа месяца 4 назад обнаружил, что например gnome-terminal (и вроде не только он) пишет в /tmp (а значит на hdd) весь вывод вообще
https://bugs.launchpad.net/ubuntu/ source/vte/ bug/865082
И что бы ты не делал в терминале, все останется в «удаленных» файлах на твоем hdd.
Поэтому лучше перебздесь, т.к криворукие девелоперы не часто думают об правильности действий их софта.

В свап на машине где мало памяти вообще что угодно может попасть.

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

В /var по сути хранится больше данных о пользовательской активности, чем в хомяке.

Так же пишутся все системные логи устройств (что когда ты куда пихал, с id устройств).
Так же там хранится база пакетного менеджера.

Думаю этой информацией я могу поделиться с людьми.

Один юзер с ЛОРа месяца 4 назад обнаружил, что например gnome-terminal (и вроде не только он) пишет в /tmp (а значит на hdd) весь вывод вообще

И этой тоже

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

Таки до 10-15кк$ оборота (для гемблинга очень маленькая сумма), из них наших денег только 2-4%

Ну как информация об установленных пакетах и логи оборудования могут открыть сокровенные тайны вашего бизнеса?

Я собственно уже написал: там логи активности, там логи openvpn, и моих личных интересов вроде i2p, tor.
К тому же мне удобнее оставлять веб сервер для тестов кода в /var, а не тащить его в хомяк.

Зашифровать весь диск целиком намного проще, чем думать о том что и куда записано и «как бы не тупануть».
Можно скажем случайно скачать бекап в /root сидя в шелле или вообще в какую нибудь папку.
Кучу раз посещая чужие серваки ;) находил давно забытые ценные данные (типа дамнов БД годичной давности) в совершенно неожиданных местах.
Все мы люди и никто не застрахован от ошибки.
А зашифрованный корень гарантирует, что нигде ничего важного не окажется.

С настройкой разобрался, помогла вот эта статья http://linuxconfig.org/partition-encryption

Мне нужно зашифровать вполне конкретные данные, хранящиеся в /home, это почта, фотки, может какое то файло, сохраненные пароли в браузере (хотя я их там не сохраняю).

Полное шифрование значительно снижает производительность, а мой ноут достаточно старенький. Да и носить с собой флешку для загрузки не всегда удобно, ее можно потерять или сломать. Хотя идея мне нравится. Еще в далеком 1999 году я ставил lilo на дискету, что бы при ее отсутствии грузилась венда, в которой можно было поиграть в Quake2 ))) Такая защита от дурака получалась.

А как можно реализовать, автоматическое монтирование зашифрованной флешки, или файла на ней? И еще интересует вопрос шифрованных носителей, которые можно монтировать и в венде и в линухах? Truecrypt не рассматривается.

5 год - полет нормальный.

Truecrypt не рассматривается.

why?

Остальное будет намного хуже.

Т.е. в данной сфере нет достойной альтернативы TrueCrypt?

И еще интересует вопрос шифрованных носителей, которые можно монтировать и в венде и в линухах?

Это автоматически означает, что венда получает пароли от твоих данных. Я бы ей их не доверил. Лучше храни всё на отдельной железке с доверенным линуксом, например на ноуте, а нужное файло передавай/шарь по сети.

cryptsetup+pam_mount

Ну а флешки в наше время мрут как мухи сами по себе.

Сколько у меня было флешек - ни одна не сдохла ещё сама по себе.
Даже 8G экземпляр 2005-7 года есть который до сих пор живой.

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

А вот с hdd у меня все печально, поэтому стараюсь везде держать рейды.

Если говорить про опенсорц (именно с открытым кодом, а не свободной лицензией), то нет, как минимум раньше не было.

Т.е есть вроде это:
http://freeotfe.org/
Но несколько лет назад я бы ему свои данные не доверил.
Да и нет там автомонтирования вроде.

Понятно. Спасибо за разъяснения!

Я сделал ключ-файл:

cryptsetup luksAddKey /root/bigger.keyfile

а в конфиге (/etc/crypttab) прописал:

# <target name>	<source device>		<key file>	<options>
pvsys			/dev/sda2		none				luks,retry=1
pvbigger	/dev/sdb1		/root/bigger.keyfile	luks

На системный раздел спрашивает пароль, открывает его, монтирует корень, а потом в корневой папочке root смотрит ключи для других разделов/дисков, которые тоже открывает уже не спрашивая пароль.

обрати внимание, что если ты пользуешься locate, то база хранится в /var/lib. Ты же не хочешь, чтобы имена тоже утекали? Ну и т.п.

Я бы зашифровал весь диск, LUKS, а разделы бы, если такие нужны, делал бы через LVM.

Хорошая идея! А как это привязать к pam?

А как это привязать к pam?

Тут нужен эксперт. Я только хомячок.

Шифрую весь корень на рабочем ноутбуке через LUKS

К слову, скорость компиляции в такой системе по сравнению с нешифрованным вариантом медленнее всего на 6% (аппаратной поддержки в процессоре нет).

Расскажите пожалуйста подробнее!

история успеха

Зашифруй весь диск. Загрузчик можно выпихнуть на sd-карту, если это ноут и носить с собой.

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

Ситуацию «всё стало колом» я видел только при тестах над sqlite'ом с кучей insert'ов и неотстроенными транзакциями.

В моем ноуте нет SD-карт :(

Dell Latitude D630

А swap то зачем шифровать?

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

Ну выпихни на флешку или выдели метров 100 под /boot на отдельном разделе, а второй зашифруй

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

С нынешними железяками, которые умеют AES-NI, да и даже без него, заморачиваться чем-то, кроме шифрования всего диска целиком вообще не целесообразно. Я так шифрую как линуксовые компы, так и винду(трукрипт) и макось. Проблем не имею и даже вопросов подобных не возникало.

Все шифруют либо хомяка либо юзают внешний носитель.

И правильно делают. При использовании только диска, у тебя всё равно останется какая-то часть кода, которая будет незашифрована. Кто-то же должен пароль спросить и расшифровать всё остальное.

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

Теоретически, это можно решить, подписывая этот код ключом «изнутри» системы, проверяя его при загрузке. В случае несовпадения - впадать в отчаянье и панику. Но я не слышал, что такое применяется в каком-либо дистрибутиве.

А инструкцию я тебе не дам, нету, я методом тыка в установщике настраивал. Так что гугли сам.

1. Зашифровать home 2. Зашифровать остальное, пароли положить в файл на home 3. Включить автологин + запуск DE (опционально)

Итого: пароль один - разблокировать home.

А swap то зачем шифровать?

Чтобы хибернейт перестал работать.

Замутил шифрование хомяка средствами cryptsetup и pam_mount. Вроде бы все ок, все зашифровано монтируется при входе юзера, отмонтируется при выходе. Но выводит вот такую беду:

(mount.c:72): Messages from underlying mount program:
(mount.c:76): NOTE: mount.crypt does not support utab (systems with no mtab or read-only mtab) yet. This means that you will temporarily need to call umount.crypt(8) rather than umount(8) to get crypto volumes unmounted.

Вот ознакомься что это такое http://en.wikipedia.org/wiki/AES_instruction_set там же список процессоров

Хотя ты можешь просто на сайте производителя твоего процессора узнать, умеет ли AES

Процессор у меня Intel Core 2 Duo CPU T8300 2.40GHz, вроде как поддерживает AES.

cat /proc/crypto 
name         : sha256
driver       : sha256-generic
module       : sha256_generic
priority     : 0
refcnt       : 3
selftest     : passed
type         : shash
blocksize    : 64
digestsize   : 32

name         : sha224
driver       : sha224-generic
module       : sha256_generic
priority     : 0
refcnt       : 1
selftest     : passed
type         : shash
blocksize    : 64
digestsize   : 28

name         : cbc(aes)
driver       : cbc(aes-asm)
module       : kernel
priority     : 200
refcnt       : 3
selftest     : passed
type         : givcipher
async        : no
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : eseqiv

name         : cbc(aes)
driver       : cbc(aes-asm)
module       : cbc
priority     : 200
refcnt       : 3
selftest     : passed
type         : blkcipher
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : <default>

name         : aes
driver       : aes-asm
module       : aes_x86_64
priority     : 200
refcnt       : 5
selftest     : passed
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : aes
driver       : aes-generic
module       : aes_generic
priority     : 100
refcnt       : 1
selftest     : passed
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : arc4
driver       : arc4-generic
module       : arc4
priority     : 0
refcnt       : 3
selftest     : passed
type         : cipher
blocksize    : 1
min keysize  : 1
max keysize  : 256

name         : stdrng
driver       : krng
module       : kernel
priority     : 200
refcnt       : 2
selftest     : passed
type         : rng
seedsize     : 0

name         : md5
driver       : md5-generic
module       : kernel
priority     : 0
refcnt       : 1
selftest     : passed
type         : shash
blocksize    : 64
digestsize   : 16

Может я не там смотрю?

Aes поддерживается начиная с ядра нехалем, т.е. первые коре и7, и5