Защита .buntu

[ArcFi]

а если / зашифрован?

Тогда значительно сложнее — придётся модифицировать загрузчик/ядро.
А там может быть цифровая подпись, и оно грузится через какой-нибудь UEFI.
Или вообще /boot на съёмном носителе.

[Kernel ops]

>> Или вообще /boot на съёмном носителе.
но можно создать /boot раздел на hdd, засунуть туда поддельное ядро и поставить туда grub, отключив загрузку с флэшки
>> А там может быть цифровая подпись, и оно грузится через какой-нибудь UEFI
а вот это не знаю. хотя можно сделать полный бэкап разделов, переделать все в MS-DOS вместо GPT и засунуть в mbr grub. Только:
1) нужно много времени
2) нужно иметь долгосрочный доступ к компу
3) если Windows в дуалбуте, кража быстро спалится

[Sly_tom_cat]

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

 

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

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

[myr4ik07]

Так интересно, по https://help.ubuntu.ru/wiki/%D1%88%D0%B8%D1%84%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B2%D1%81%D0%B5%D0%B3%D0%BE_%D0%B4%D0%B8%D1%81%D0%BA%D0%B0 понятно все очень хорошо, но что помешает злоумышленнику в таком случаи без каких либо проблем создать новый ключ для слота и старый удалить? Или ключ возможно создать только при знании старого ключа (пароля) ?
А так, очень привлекательно.
Друзья, подскажите пожалуйста, а почему же нельзя шифровать таким способом dual-boot режим (windows & linux) в большинстве случаев? Ведь в чем преграда?
Просто вывели раздел /boot отдельно, после этого отрезали для win & linux по лог. тому и выбрали в качестве lvm пустой раздел для linux, или я в чем то ошибаюсь?

[thing]

так с помощью livecd я тоже смогу загрузиться и спокойно изменить пароль, что в итоге тоже даст результат открытия и / & /home

Измененный пароль пользователя не позволит получить доступ к "зашифрованному домашнему разделу". Когда менял truecrypt на eCryptfs (это чем Ubuntu шифрует /home), менял пользователя - создавал такого же, но с другим паролем. Потом сменил пароль пользователя штатными средствами и в итоге не смог получить доступ к зашифрованной домашней директории. Получается, у нее своя ключевая фраза (пароль) на дешифрацию, не зависящая от пароля пользователя.

[Sly_tom_cat]

Получается, у нее своя ключевая фраза (пароль) на дешифрацию, не зависящая от пароля пользователя.

Именно! Парольная фраза ecryptfs хранится в кейринге, который открывается при логине пользователя, открывается он либо отдельным паролем (если он не совпадает с паролем пользователя) либо паролем пользователя (что он ввел при логине).

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

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

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

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

Но и это не 100% - против паяльника - средств нет
Хотя и в этом случае (выдача пароля под давлением) есть решение на truecrypt - скрытый раздел в криптотоме - от внешнего контейнера - пароль можно сообщать под давлением и держать в нем нечто персональное, но ни противозаконное, тогда все противозаконное - только в скрытом. Обнаружить скрытый открыв внешний - не возможно (по крайней мере в теории)...

[ArcFi]

Или ключ возможно создать только при знании старого ключа (пароля) ?

Так и есть.

Друзья, подскажите пожалуйста, а почему же нельзя шифровать таким способом dual-boot режим (windows & linux) в большинстве случаев? Ведь в чем преграда?

Венды не умеют грузиться с линуксового LVM.

[myr4ik07]

Или ключ возможно создать только при знании старого ключа (пароля) ?

Так и есть.

Друзья, подскажите пожалуйста, а почему же нельзя шифровать таким способом dual-boot режим (windows & linux) в большинстве случаев? Ведь в чем преграда?

Венды не умеют грузиться с линуксового LVM.

Очень замечательно, что нужно знать старый ключ, что бы создать новый, вот это действительно защита.
А на счет lvm и не способности работы windows в нем это я читал, но а если без windows обойтись, но все же таки нужно оставить определенное место под ФС ntfs хотя и windows на ней не будет, так будет работать и возможно ли это, что я говорю? Мне главное этих три вопроса. Спасибо.
Пользователь решил продолжить мысль 29 Октября 2012, 16:59:34:

так с помощью livecd я тоже смогу загрузиться и спокойно изменить пароль, что в итоге тоже даст результат открытия и / & /home

Измененный пароль пользователя не позволит получить доступ к "зашифрованному домашнему разделу". Когда менял truecrypt на eCryptfs (это чем Ubuntu шифрует /home), менял пользователя - создавал такого же, но с другим паролем. Потом сменил пароль пользователя штатными средствами и в итоге не смог получить доступ к зашифрованной домашней директории. Получается, у нее своя ключевая фраза (пароль) на дешифрацию, не зависящая от пароля пользователя.

На сколько я правильно понял, значит, имея зашифрованный домашний каталог с разрешенным для входа пользователя 1 злоумышленник не зная пароль от пользователя 1 зайдя с livecd или через grub изменит пароль пользователя 1 и не сможет зайти в домашнюю директорию которая была шифрована, так получается?

[thing]

На сколько я правильно понял, значит, имея зашифрованный домашний каталог с разрешенным для входа пользователя 1 злоумышленник не зная пароль от пользователя 1 зайдя с livecd или через grub изменит пароль пользователя 1 и не сможет зайти в домашнюю директорию которая была шифрована, так получается?

Я не знаю, как меняют пароли пользователей с live cd, но, если даже штатное изменения пароля пользователя не влияет на пароль к шифрованному разделу - то да. Должно быть по идее так.

[ArcFi]

Очень замечательно, что нужно знать старый ключ, что бы создать новый, вот это действительно защита.
А на счет lvm и не способности работы windows в нем это я читал, но а если без windows обойтись, но все же таки нужно оставить определенное место под ФС ntfs хотя и windows на ней не будет, так будет работать и возможно ли это, что я говорю? Мне главное этих три вопроса. Спасибо.

Если вы это дело собираетесь каким-то боком скрещивать с Windowsми, то лучше у дуалбутчиков узнавать.
Тем не менее, быстренько погуглил на тему реализации LUKS для окон, и вот: FreeOTFE.

На сколько я правильно понял, значит, имея зашифрованный домашний каталог с разрешенным для входа пользователя 1 злоумышленник не зная пароль от пользователя 1 зайдя с livecd или через grub изменит пароль пользователя 1 и не сможет зайти в домашнюю директорию которая была шифрована, так получается?

Да.

Я не знаю, как меняют пароли пользователей с live cd, но, если даже штатное изменения пароля пользователя не влияет на пароль к шифрованному разделу...

passwd от имени юзера меняет.

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

[Sly_tom_cat]

На сколько я правильно понял, значит, имея зашифрованный домашний каталог с разрешенным для входа пользователя 1 злоумышленник не зная пароль от пользователя 1 зайдя с livecd или через grub изменит пароль пользователя 1 и не сможет зайти в домашнюю директорию которая была шифрована, так получается?

Да.

[myr4ik07]

Отлично, мне вполне этого хватит.

А на счет создания в lvm ntfs раздела, то это возможно? Или под "не будет работать Windows" этим и сказано, что не будет работать ntfs файловая система?!

Хотелось бы, что то такое как, отдельно бут раздел отдельно lvm том в котором уже будет / & /home & ntfs раздел, без каких либо двойных загрузок.

Кстати, на сколько я понял, что, что бы использовать lvm нужно только целый носитель использовать?! А не кусок не размеченного пространства и какой то отформатированный раздел, на пример с ntfs?!

[Sly_tom_cat]

вам уже ответили:

Венды не умеют грузиться с линуксового LVM.

т.е. ntfs - тут не причем - не поймет загрузчик - как грузится.

[ArcFi]

myr4ik07, LUKS — это просто тип раздела.
В рассматриваемом выше руководстве LVM используется для того, чтобы на одном LUKS-разделе уместить сразу несколько "виртуальных" разделов, на каждом из которых может быть своя ФС.

[myr4ik07]

myr4ik07, LUKS — это просто тип раздела.
В рассматриваемом выше руководстве LVM используется для того, чтобы на одном LUKS-разделе уместить сразу несколько "виртуальных" разделов, на каждом из которых может быть своя ФС.

Ааа, спасибо, что "на пальцах", а то если не знаешь то тяжело догнать мысль.