Pull to refresh

Comments 53

Вот бы кто ещё придумал как сделать туда внутрь раздел с загружаемой виндой
qemu/kvm? В принципе, можно заморочиться и сделать pci-passthrough видеокарты. А блочное и сетевое IO — через хост-систему. Общаться с ней можно будет либо по сети (с другой машины), либо через последовательный порт.
Ды что то сложно. Речь про вторую ос для поиграть, в основном. Это к тому что ей бы полноценно загружаться, а не внутри виртуальной машины.

Причём, принципиально проблем нет, я так понял — был же fde в том же truecrypt.

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

— Windows может быть зашифрована до уровня «запрос пароля на уровне загрузчика» при помощи truecrypt
— Linux может быть зашифрован до уровня «запрос пароля на уровне загрузчика» десятком (наверное) способов

Если я правильно помню про truecrypt, оно там чуть ли не в роли прослойки между ос и оборудованием должно было выступать.

Просто реально неудобно что с какой то одной ос ты себе можешь fde организовать, а на две — неа
Весь диск шифровать LUKS — это оверкилл…
Как правило, /home выносят на отдельный раздел и шифруют только его, тк всё остальное обычно не представляет особого интереса с точки зрения утечки данных.
Всё-таки, обычно, если учесть массовость использования коробочных решений, шифруют весь диск кроме /boot.

Что же касается излишества — зависит от того, что и где вы храните и как сильно у вас развита паранойя. Я вот даже /etc/wpa_supplicant.conf отдавать никому не хочу.

Кроме того, подобный подход позволяет вводить пароль только один раз, без ущерба для безопасности (конечно, если с данным ноутом работает только один человек) так, как если кто-то сможет обойти luks, остальные пароли его даже не затормозят.
> Я вот даже /etc/wpa_supplicant.conf отдавать никому не хочу.
Если у вас паранойя, это еще не значит, что за вами никто не следит)))
Если у вас развита паранойя, то вы должны понимать, что нет разницы между «нешифрованным /usr» и «нешифрованным /boot».

Алсо, отдельные пароли на ssh и gpg-ключи и менеджер паролей — must have.
Вы совершенно не правы. Если вы опасаетесь не только случайного разглашения данных, но и [зло-]умышленного, то вам следует защитить не только домашнюю директорию, но и всю систему, в которую злоумышленник может попытаться установить считыватель клавиатурных нажатий или ещё какой-нибудь зловред.

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

Мы тут говорим про установку кейлоггера при физическом доступе к устройству, так?
От удаленной установки через уязвимость описанное в статье шифрование не спасёт.
А при физическом доступе они поставят физический кейлоггер.
Бла-бла-бла, сколько раз уже обсуждалось, что все эти пароли на разделы, на вход просто сходят на нет, когда достают паяльник…
Если действительно возможна ситуация, что к тебе придут и будут тебя трясти, то тебя расколют (если ты конечно не крепкий орех). А если такая ситуация не возможна, то зачем напрягаться к таким сложностям?
/var/www тоже не хотелось бы потерять) да и бдшки) или у вас всё в /home?)
UFO just landed and posted this here
На незашифрованный бук могут еще и подкинуть веществ, ой, я хотел сказать анимэ или порнографии в школьной униформе. Или по мелочи напакостят — пару фоток с «фошыстами» загрузят — так, на административку. Причем их даже распространять не надо, достаточно во время обыска (по любой другой причине) найти их на харде.
> я не использую UEFI
Имелось в виду GPT?
Имелось в виду UEFI. Для загрузки с использованием UEFI создаётся отдельный небольшой раздел.
Этот раздел необходим исключительно для GPT разметки. И я бы не рекомендовал его удалять. В сети ходят слухи (сам лично не проверял), что после удаления EFI раздела невозможно зайти в настройки BIOS/UEFI.
Этот раздел не имеет ничего общего с GPT. Монтируется он в /boot/efi.
Что касается слухов — это только слухи. Я уже проверил на своём ноуте.
Я тоже так один раз «проверил» :) Винт вообще пропадает как вариант загрузки из биоса) Клёво было ещё то что на моём N56VZ вообще убрали отключение UEFI, т.е. в принципе ноут превращался в кирпич до перенакатывания oem recovery с DVD носителей.
Если нет возможности отключить UEFI, грузимся с другого носителя (флешка или cdrom) и возвращаем (создаём заново) раздел и пишем загрузчик. Никаких проблем с этим не вижу. Стандартный установочный образ Slackware вполне UEFI-бутабелен.
Вроде и статью прочитал, но не могу понять, как это работает.
Сначала grub загружается из mbr, это ок.
Но дальше для расшифровки раздела ему нужно получить initrd, который лежит на этом же зашифрованном разделе.
Подскажите, пожалуйста, что я пропустил?
> Я не особо долго искал, но из того, что попалось под руку, загрузку с шифрованного диска поддерживает только Grub2.

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

Далее, Grub загружает ядро и передаёт ему управление. После этого, система так же должна подключить необходимые разделы. В штатном режиме, она так же попросит пароль. Для того, чтобы она не просила пароль, используется luks-ключ, который хранится в initrd.
GRUB_ENABLE_CRYPTODISK=y — правильный вариант.
Правильный, но не всегда работающий.

[user@HOST /tmp/grub-2.00] grep -rE '(GRUB_ENABLE_CRYPTODISK|GRUB_CRYPTODISK_ENABLE)' .
./util/grub-install.in:    if [ x$GRUB_CRYPTODISK_ENABLE = xy ]; then
./util/grub-mkconfig.in:  GRUB_ENABLE_CRYPTODISK \
./util/grub-mkconfig_lib.in:  if [ x$GRUB_CRYPTODISK_ENABLE = xy ]; then
./util/grub-mkconfig_lib.in:  if [ x$GRUB_CRYPTODISK_ENABLE = xy ]; then
./ChangeLog:    * util/grub-mkconfig.in: Export GRUB_ENABLE_CRYPTODISK.
Похоже, что GRUB_CRYPTODISK_ENABLE — это внутренняя переменная, используемая для генерации конфигов компиляции.

По крайней мере, в грабе Арча GRUB_ENABLE_CRYPTODISK=y.

И вот ещё ссылка на всякий случай, тоже полезная:

http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/
В Slackware, по крайней мере, в моём конкретном случае, ожидаемый результат дало только добавление GRUB_CRYPTODISK_ENABLE

> И вот ещё ссылка на всякий случай, тоже полезная:

Эта ссылка приведена у меня в источниках:
> Full disk encryption with LUKS (including /boot) — Pavel Kogan
Упс, а ссылку проморгал.

ОК, добавлю тогда, что для себя именно по ней я всё и настраивал.
фигня всё это и игрушки. лучше бы ктонить рассказал о готовой схеме, чтото типа — гдето в сети лежит зашифрованный файл, который монтируется на моём компе и я работаю с ним как с диском. скорость работы… срать! главное, чтоб оно записывало/читало _В РЕАЛЬНОМ_ времени, а не как яндексдиск — создал мне папку и синхронизирует её с облаком. нахера оно такое нада??? почему сразу не монтировать облако в папку????
NBD (Network Block Device) + LUKS вполне решают эту задачу.
https://github.com/yoe/nbd оно? если да, то опять фигня )) или предлагаете микрософт попросить чтоб на вандрайв сервере нбд запустили? ;) webdav вроде и оно, но нет шифрования нифига (
С webdav можно использовать шифрование на уровне файлов типа encFS.
Блочное устройство — пожалуйста, буквально три строчки. Можно ceph, можно iscsi/nbd для чего попало.

С файловой системой сложнее — адекватно-шаренных multitenant FS не существует до сих пор, слишком сложно.
Можно попробовать EncFS. А каталог с зашифрованными файлами монтировать каким-нибудь стандартным способом.
Немалая часть дистрибутивов спрашивает «а не зашифровать ли вам диск?» сразу при установке.

И я даже говорил про это:

> На данный момент во многих дистрибутивах уже из коробки предоставляется возможность создавать шифрованные разделы. Однако, все те варианты, что мне попадались, предусматривают не шифрованный /boot.
Я просто оставлю это здесь: https://github.com/hummelchen/notes/blob/master/full_disk_encryption.md
Если этот вопрос стоит остро, почему бы не вынести все нужное для загрузки на флешку? Ведь могут подменить код, который запрашивает пароль, пока вы не рядом с ноутбуком.
Флешку могут забрать (не всегда спрашивая согласия), её можно потерять, она может сломаться… а если вопрос стоит на столько остро, чтобы привлечь спецалистов, которые за короткий промежуток времени внедрят в код загрузчика кейлогер, чтобы узнать пароль от люкса то… терморектальный криптоанализ (паяльник, утюг и т.д.) позволяет обойти любые пароли куда дешевле и быстрее.

Единственный способ защитить информацию — сделать затраты на её получение несоразмерными с получаемой выгодой.
нужно мнение знающих людей: что скажете о программе DiskCryptor, как способе зашифровать винт с виндовсом на борту? (хорошо/плохо/альтернативы)

Спасибо
Diskcryptor умеет грузиться с флешки, храня там же ключ (удобно — загрузил машину с флешки, унёс до ребута, никаких паролей). Может грузить левую ОС (пароль под принуждением).

По теме топика —
Вообще, сейчас многие, скажем, SSD (Intel/Samsung) имеют AES шифрование на уровне диска. Что мешает воспользоваться им?
видимо то, что о таком не слышал. Для этого какая то софтина фирменная нужна будет?
Включается установкой пароля в CMOS Setup для защиты диска. Не путаем с паролем на вход в сам CMOS setup («BIOS»).
Обоснованные сомнения в отсутствии вполне легального «чёрного хода» для «людей в чёрном»? Тоже «на уровне диска».
Поэтому изначально и спрашиваю за софтину, которая вроде как свободная и с открытым исходным кодом)
Я бы посоветовал VeraCrypt.

DiskCryptor (как и TrueCrypt) не зашифруют вам системный раздел с операционной системой на диске с GPT-разметкой (только с MBR). А вот следующая версия VeraCrypt — сможет (сейчас эта функция обкатывается в тестовых выпусках).
Надо будет потестить. Спасибо! :)

Если ли возможность задать т. н. «пароль под принуждением», с загрузкой совершенно другой системы? Если нет, то и смысла возиться нет — вежливо попросят, сами пароль введете.

Возможность есть, но имеются ньюансы. Обсуждения на тему plausible deniability в LUKS можно почитать например здесь.
Самая, на мой взгляд, большая трудность с «загрузкой совершенно другой системы» заключается в том, что вам придётся этой «подложной» системой регулярно пользоваться, чтобы создать впечатление, что это и есть основная система. Иначе, у товарища майора к вам возникнет совершенно закономерный вопрос, отчего она у вас последний раз запускалась месяц или неделю назад, когда есть свидетельства того, что вы активно пользуетесь ПК.

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

Вопросы сокрытия хостовой или основной системы — тема абсолютно другая и подобные задачи решаются абсолютно иными средствами. Для решения подобных задач, правда, с серьёзной потерей производительности, как мне кажется, могла бы подойти VMware ESX(i?)… особенно, если её удастся скрестить с тем же LUKS-ом. Но данной темой я не занимался и потому, не могу сказать чего-либо конкретного.
Sign up to leave a comment.

Articles