Обновить
2
0
Андрей Белич@Innominatus

Администратор Linux

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

Вопросы сокрытия хостовой или основной системы — тема абсолютно другая и подобные задачи решаются абсолютно иными средствами. Для решения подобных задач, правда, с серьёзной потерей производительности, как мне кажется, могла бы подойти VMware ESX(i?)… особенно, если её удастся скрестить с тем же LUKS-ом. Но данной темой я не занимался и потому, не могу сказать чего-либо конкретного.
Если нет возможности отключить UEFI, грузимся с другого носителя (флешка или cdrom) и возвращаем (создаём заново) раздел и пишем загрузчик. Никаких проблем с этим не вижу. Стандартный установочный образ Slackware вполне UEFI-бутабелен.
Флешку могут забрать (не всегда спрашивая согласия), её можно потерять, она может сломаться… а если вопрос стоит на столько остро, чтобы привлечь спецалистов, которые за короткий промежуток времени внедрят в код загрузчика кейлогер, чтобы узнать пароль от люкса то… терморектальный криптоанализ (паяльник, утюг и т.д.) позволяет обойти любые пароли куда дешевле и быстрее.

Единственный способ защитить информацию — сделать затраты на её получение несоразмерными с получаемой выгодой.
В Slackware, по крайней мере, в моём конкретном случае, ожидаемый результат дало только добавление GRUB_CRYPTODISK_ENABLE

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

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

> На данный момент во многих дистрибутивах уже из коробки предоставляется возможность создавать шифрованные разделы. Однако, все те варианты, что мне попадались, предусматривают не шифрованный /boot.
NBD (Network Block Device) + LUKS вполне решают эту задачу.
Этот раздел не имеет ничего общего с GPT. Монтируется он в /boot/efi.
Что касается слухов — это только слухи. Я уже проверил на своём ноуте.
Правильный, но не всегда работающий.

[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.
> Я не особо долго искал, но из того, что попалось под руку, загрузку с шифрованного диска поддерживает только Grub2.

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

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

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

Кроме того, подобный подход позволяет вводить пароль только один раз, без ущерба для безопасности (конечно, если с данным ноутом работает только один человек) так, как если кто-то сможет обойти luks, остальные пароли его даже не затормозят.
Имелось в виду UEFI. Для загрузки с использованием UEFI создаётся отдельный небольшой раздел.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность