%3F.png)
Это страница, на которой разработчик ecryptfs объясняет разницу между ecryptfs и dm-crypt:https://stackoverflow.com/questions/18230784/какая-разница-между-linux-kernel-subsystem-dm-crypt-and-ecryptfs/18234635#18234635. Однако это оставило меня с вопросом: если ecryptfs шифрует только раздел /home, что мешает злонамеренному хакеру изменить /раздел /boot, чтобы, возможно, узнать пароль шифрования или изменить программу и т. д.
Короче говоря, как я могу быть уверен, что данные на моем компьютере не только не смогут быть прочитаны посторонним лицом, но и как я могу быть уверен, что никакие данные на моем компьютере не будут изменены без моего ведома?
И где же это заканчивается, ведь в какой-то момент загрузочный код должен быть расшифрован, чтобы процессор мог его понять? (Если только вы не используете какое-то аппаратное дешифрование) Но по определению все, что не зашифровано, может быть изменено?
(В качестве побочного замечания, я вижу способ определения целостности последовательности загрузки, сохраняя хэш незашифрованной части кода загрузки в зашифрованной части и при расшифровке сравнивая предварительно вычисленный хэш с хешем незашифрованной части последовательности загрузки во время выполнения. Однако это не решает проблему наличия незашифрованных областей, а просто позволяет узнать постфактум, было ли что-то изменено.)
решение1
Короткий ответ: «очень мало что» останавливает хакера от изменения /boot — на самом деле только время, необнаруженный физический доступ и возможность перекомпилировать initrd с помощью кейлоггера.
Ничто не останавливает злонамеренного хакера от изменения файлов / или /boot на основе ecryptfs, если у него есть физический доступ к системе, но об этом позже — речь не об этом.
«/» можно защитить с помощью полного шифрования диска, например LUKS (но, насколько мне известно, не с помощью пофайлового шифрования). Поскольку система изначально загружается из /boot, initrd может запросить парольную фразу, необходимую для разблокировки тома перед монтированием /
Я думаю, вы переоцениваете возможности полного шифрования диска. Я говорю вам, что оно предназначено для того, чтобы перестать защищать людей от непостоянных угроз, таких как кража ноутбука или когда вы хотите вернуть жесткий диск с личной информацией. В обоих случаях данные вам больше не нужны, но вы хотите предотвратить доступ к ним неизвестной третьей стороны. И очень часто для этого достаточно шифрования ваших документов на уровне файлов. Кому какое дело, есть ли у них незашифрованная копия двоичных файлов системы? Они в любом случае имеют открытый исходный код.
Вы не можете защитить свою систему от несанкционированных лиц с локальным доступом к ней, поэтому решение этой проблемы — предотвратить физический доступ. Вы можете предпринять некоторые шаги для обеспечения того, чтобы ничего не было изменено без вашего ведома, путем контрольной суммы всех ваших системных файлов и сравнения с автономной резервной копией — это не полная защита, так как вам нужно убедиться, что вы используете неизмененную программу контрольной суммы — и она делает хэши коллизий практически невозможными для воссоздания. [Вы можете упростить это, если разделите свои файловые системы и сделаете некоторые из них доступными только для чтения, а затем сохраните один хэш для каждого раздела только для чтения]. Однако весь этот процесс громоздкий.
При использовании полного шифрования диска "/" вы, как правило, не будете использовать компьютер как "root", за исключением обновлений и т.п. - это обеспечивает достаточную степень защиты.