Автоматические mount/umount шифрованного $HOME на OpenBSD

ВНИМАНИЕ:
В нижеприведенном тексте и коде могут содержаться ошибки, описанное следует рассматривать как концепцию.

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

Для исполнения первого (расшифровка и монтирование) мы модифицируем оригинальный login_passwd.

Вторую часть мы исполним с помощью sudo и .bash_logout.

Итак, приступим:

1. Загружаем, make , make install

2. Добавляем login class в login.conf

vnd:\

:auth=-vnd:\

:tc=default:

3. Создаем шифрованный образ и добавляем пользователя в систему

touch /home/.en (после точки "."- имя пользователя username, под которым он зарегистрирован в системе. В данном случае это "en")

dd if=/dev/zero of=/home/.en bs=1024 count=10000 (получим файл размером примерно 10M)

/sbin/vnconfig -ck -v svnd0 /home/.en (vnd setup)

Замечание: пароль должен соответствовать паролю пользователя в системе. Благодаря этому для расшифровки будет использоваться тот же пароль, что и для входа в систему.

Подготавливаем диск и создаем файловую систему.

fdisk -i svnd0

disklabel -E svnd0 (создаем один раздел - "a")

newfs /dev/rsvnd0a

Не помешает проверить монтирование mount /dev/svnd0a /mnt/vnd_test. После теста не забудьте отмонтировать umount /mnt/vnd_test и vnconfig -u svnd0

Подошло время добавить пользователя.

useradd -d /home/en -L vnd (добавляем user ‘en’ используя login-class ‘vnd’. Не забыли внести изменения в login.conf?)

passwd en (вводим тот же пароль, что и для шифрования образа)

4. Вносим изменения в sudoers

Надо изменить sudoers, чтобы позволить пользователю исполнить кое-что с правами суперпользователя.

# Cmnd alias specification

Cmnd_Alias      DROP_HOME= /sbin/umount /home/en

Cmnd_Alias      DROP_VND= /sbin/vnconfig -u svnd0

# User privilege specification

root    ALL=(ALL) SETENV: ALL

en      ALL=(root) NOPASSWD: DROP_HOME

en      ALL=(root) NOPASSWD: DROP_VND

5. Устанавливаем bash (стандартная инсталляция OpenBSD не содержит bash)

Вы сами знаете, как это сделать. Не забудьте только.

6. Входим в систему пользователем user и создаем .bash_logout

Перед тем, как войти пользователем "en", мы должны еще немного кое-что подготовить:

mkdir /home/en; chown en /home/en

vnconfig -ck svnd0 /home/.en

mount -t ffs /dev/svnd0a /home/en

Теперь мы уже можем залогиниться пользователем "en" и создать .bash_logout

touch .bash_logout

vi .bash_logout и добавляем следующее:

cd /tmp

sudo /sbin/umount $HOME

sudo /sbin/vnconfig -u svnd0

Выходим из системы.

7. Попробуем выйти и зайти вновь

Если все выполнено правильно пользователь "en" после входа в систему сможет работать с шифрованным $HOME, а при выходе из системы bash "вернет все обратно".

Ну и немного напоследок:

Все это тесно связано с работой login_-vnd-code. Будет замечательно, если вы уделите некоторое время изучению оного.

К примеру, svnd0a is expected to be and hardcoded in the code as well as path and name of the encrypted image, e.g. /home/.username .

Ну вот и все, удачи!

Буду рад замечаниям и комментариям. (Куда их присылать - умеете пользоваться Google?)

Аватар пользователя ENcrypted

Оригинал

оригинальный текст

http://en.roolz.org/Blog/Entries/2009/4/27_Auto_mount_umount_of_encrypte...

Спасибо Виктору за перевод!

Аватар пользователя test00

Обычно при

Обычно при разлогинивании все процессы, запущенные от пользователя не убиваются, а значит и FS не отмонтируется ибо in use. Если автомаунт делать, он должен это учитывать.

Более важно, что всем понятно, что есть файл с криптофс. Хорошо, когда система позволяет избегать этого. Например, "неиспользуемое место на диске" выглядит более отрицаемо, чем "файлы на n мегов/гигов с мусором". И да, у файла, с нарезанной на нём криптоФС ещё поди и опозновательные сигнатуры есть?

Аватар пользователя ENcrypted

in use

По поводу "in use" согласен, но не надо забывать что это всего лиш концепт, а не готовое "блюдо" которое надо седать как оно есть.

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

btw, TrueCrypt не open source.

Аватар пользователя test00

Нет, я имел в

Нет, я имел в виду не криптоанализ, а стеганографический способ защиты данных, см. например: http://ru.wikipedia.org/wiki/Стеганография  Смысл как раз в том, чтобы снизить вероятность принуждения к выдаче пароля - раз, и снизить вероятность того, что будут ставиться в вину наличие скрытой информации на машине (например, в суде) - два. Естественно, стеганографией в прямом смысле это являться не будет, скорее security via obscurity, но хотя бы что-то. Если бы славная система OpenBSD позволяла шифровать дисковые разделы напрямую, то можно было бы их и использовать. А когда не используются - удалять посредством записи нового disklabel на диск. Когда они удалены, всегда можно сказать, что "на компе раньше что-то было, не знаю что,  а теперь поставил другую ОС, неиспользуемое место отвёл под ещё одну ОС но руки пока не дошли её поставить". Такой аргумент будет звучать хоть сколько-нибудь правдоподобно. Когда же на диске случайно завалялся, допустим, гиговый файл без сигнатур с какими-то случайными данными внутри, отрицать наличие зашифрованных данных будет куда сложнее. PS: это я не как руководство к действию, а как поясняющий пример: почему очень плохо, когда нет шифрования разделов напрямую. Более того, большинство существующих криптографических систем как раз позволяют шифровать разделы напрямую (cgd, geli, dmcrypt, loop-aes, и т.д.).

TC как раз opensource (его исходники открыты) но не free source (в смысле Столлмана). Более того, отрицаемость TC вроде бы последнее время ставили под вопрос (не слежу за темой). Были ещё идеи со "скрытыми ОС", например, запускаемыми в виртуальных машинах, которые можно реализовать не только под Linux.