Liberte Linux (Hardened Gentoo)
Ох, зарекался не создавать эту тему...Так что простите заранее.
Форум автора перечитал от и до – ответа там не нашел (топиков с вопросами много, но автор отвечает везде, кроме них), в Википедии тоже обсуждают только косяки при сборке.
В общем никак не получается собрать.. Rsync установил, компилятор тоже(Пробовал из под Убунты). Но увы – слетает и все.
Очень прошу помочь, если есть гентушники или просто те счастливчики, кто осилил собрать его.
У автора все просто:
http://dee.su/liberte-build
Но увы, у меня не то что просто, но и сложно не получается(
Ссылка на git:
https://github.com/mkdesu/liberte
Если можно – укажите в двух словах, что не так и какие тонкости при сборке Hardened Gentoo.
Заранее благодарен.
– шифрование при первоначальной установке системы на раздел, на диск.
– полное шифрование УЖЕ установленной системы (?).
– шифрование отдельных разделов уже установленной системы..
ну и т.д. а если еще не знаешь что лучше шифровать (исключение избыточности действий), тут вопросов еще больше становится.
Не в копипасте вопрос, а в том, что тратить своё время на комментирование всех высеров в интернете на предмет здравого зерна и бреда в них мало кому интересно. На narod.ru тоже много статеек есть, можно каждую из них копировать сюда и спрашивать «а правда ли это?» Освойте азы, тогда многие вопросы сами пропадут, будете уметь и сами отделять чушь от разумных вещей.
комментариев: 9796 документов: 488 редакций: 5664
Надёжнее и проще всего сбэкапить её на шифрованный внешний винт, а затем развернуть из бэкапа поверх заново установленной шифрованной системы. Да, вручную перепаковать рамдиск, поправить grub.cfg (или menu?), /etc/fstab и /etc/cryptab при этом тоже придёться.
При гибернейте в шифрованный своп есть ещё один интересный вариант: когда он перестаёт быть нужен, можно стереть ключ свопа перед выключением, не тратя время на отмонтирование свопа (которое может исчисляться минутами). Система поработает на старом ключе из памяти, а после ребута все данные, накопившиеся в свопе на старом ключе, исчезнут.
Только в дополнение к полному шифрованию. Благо, двойное шифрование (логических томов внутри физического) практически не отнимает никаких ресурсов ни в плане скорости, ни в плане надёжности. За много лет использования ничего такого замечено не было.
А ещё можно вынести /home на рейд и его тоже пошифровать на уровне как физических, так и логических томов. Причём рекомендуется и то и другое одновременно (двойное шифрование).
Упрёки принимаются в плане того, что это только комментарии, заметки на полях с реализуемыми идеями, а не готовые пошаговые руководства.
А я могу придумать ещё десятки сценариев и ситуаций прикручивания шифрования. Уверен, что многие можно корректно настроить и кому-то это, возможно будет полезно и интересно, но времени проверять и подробно излагать всё это нет.
Как пример: цепочечные и иерархические расшифрования контейнеров без использования хранимых на них промежуточных ключей; использование шифрованной флэшки для обмена данными между открытыми шифрованными контейнерами на разных компьютерах (курьерский способ передачи), при этом пароля для флэшки не существует: она расшифровывается по факту открытия самих этих контейнеров (используются ключи, висящие в памяти после открытия этих контейнеров), использование промежуточных ключей для доступа к контейнеру (OpenPGP, OpenSSL), с возможностью асимметричного шифрования, разделения доступа и пр. Всё это автоматизируется, скриптуется и прописывается в /etc/cryptab.
Зная технологию и общие принципы можно (осторожно) делать решения под множество разных ситуаций. Не зная технологию и общие принципы, лучше использовать только стандартные, универсальные, проверенные и относительно простые решения и не лезть в экзотику.
Поэтому больше смысла вникать в теорию и общие принципы, а конкретные решения обсуждать, по мере того, как человек созрел и уже может больше половины сам сделать, грамотно сформулировав и задачу, и предполагаемое решение.
Пароль то всё равно над вводить. Другое дело про опасения, что саму флэшку протроянят. Можно иметь копию флэшки на случай сбоя или нарушения правил её использования.
Насчёт поведения сотрудников во время раб. дня. Информационной безопасности в коммерческих и обычных государственных организациях не существует. Они сами существуют не для этого. Там это бесполезно, да. Как говорили какие-то сотрудники АНБ — те, для кого безопасность является конечным, основным и самым важным продуктом деятельности организации (а не получение прибыли, к примеру), те будут мириться с любыми неудобствами и изучать спец. методы работы. Остальным этого подхода не понять.
Для бизнеса — это неприменимо ни коммерчески, ни психологически. Для большинства обычных незаинтересованных индивидуальных пользователей — тоже.
комментариев: 1079 документов: 58 редакций: 59
В этой OS так и сделано, но как сделать тоже самое с другим дистрибутивом и TrueCrypt?
комментариев: 11558 документов: 1036 редакций: 4118
лично мое мнение, после кучи потраченного времени на linux+truecrypt, лучше потратить это время на изучения средств самого Linux, а именно, cryptsetup, lvm. я далеко не специалист в этом вопросе, но именно такое создалось впечатление. да и материала "реального" побольше. в инете много разглагольствований болтунов на тему "а зачем вам это надо" и "это все равно не поможет", но либо изучить самому или доверится "слепо" преложенному кем-то варианту. (( быстрого пути, как в Винде, нет.
есть решение с VHD, но и то для Ubuntu при помощи Vmlite VBoot не совсем то, но совместить можно.
вообщем чудес не бывает ))).
зашифрован весь диск. что должно произойти, чтобы загрузился Linux? В случае с Виндой, загрузчик ТС прописан в MBR. вводишь пароль в загрузчике ТС и он передает загрузку Винде. там так реализовано. здесь как сказал SatVA без initrd ничего не получится. сами разработчики даже не пытаются создать рабочий вариант "linux+truecrypt=полное шифрование системного диска (раздела)" почему? может этот вариант не конкурентен в сравнении со встроенным?
комментариев: 1079 документов: 58 редакций: 59
Вот это меня и интересует. Хочу Debian засунуть в контейнер и сделать LiveUSB.
В Гите этого анимешника ничего не нашел:
https://github.com/mkdesu/liberte/
Кто собирал это, может разбирались?
Кеша, напиши в ЛС, поделись опытом.
Я хочу использовать настроенный Debian, находящийся в криптоконтейнере, а в качестве загрузчика – PloP, есть негативный опыт работы с ним?
Если речь про линукс, то был вот такой топик.
Вообще, шифрование загрузчика не слишком осмысленно ввиду /comment39761 и /comment41369. Умеет ли grub грузить ядро винды непосредственно? Сомневаюсь, но по chainlader +1 с уже подмонтированного шифрованного раздела — может быть...
P.S. Параною можно всегда апскейлить, вплоть до чего-то такого.
комментариев: 1079 документов: 58 редакций: 59
А нужно это? Я просто не знаю. Мне кажется, что дешифрация проходит же изначально, а потом уже грузится сама система, находившаяся в контейнере.
Вроде бы нет. Загрузчик грузится с первого сектора (нулевая дорожка) и потом передаёт управление ядру. Чтобы передать это управление, загрузчик должен распознать разделы диска, найти среди них тот, который является загрузочным (или спросить пользователя напрямую), после чего управление передаётся на найденный загрузочный раздел. В последнем, я так понимаю, есть что-то типа своего загрузчика, который передаёт управление ядру, там лежащему. Примерно так, по моим представлениям, работает технология загрузки по chainloader +1 в grub.
Если же grub распознаёт файловые системы и умеет грузить ядра (это — ситуация для, например, Linux и BSD) напрямую, ему можно в лоб указать, с какого раздела и какое именно ядро грузить.
Более опытные приглашаются исправить неточности в этом изложении. :)