Как шифрование /home раздел с помощью ecryptfs в linux останавливает вредоносное изменение /boot или /(root)?

Question

Это страница, где разработчик ecryptfs объясняет разницу между ecryptfs и dm-crypt: https://stackoverflow.com/questions/18230784/what-is-difference-between-linux-kernel-subsystem-dm-crypt-and -ecryptfs/18234635 # 18234635. Однако у меня возник вопрос: если ecryptfs только шифрует раздел /home , что мешает злонамеренному хакеру изменить раздел / /boot чтобы, возможно, перехватить пароль шифрования или модифицировать программу и т. Д ...

Короче говоря, как я могу быть уверен, что не только данные моего компьютера не могут быть прочитаны неуполномоченным лицом, но и как я могу быть уверен, что на моем компьютере ничего не будет изменено без моего ведома об этом?

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

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

Answer 1

Короткий ответ "очень мало" останавливает хакера от изменения / загрузки - на самом деле это только время, необнаруженный физический доступ и возможность перекомпилировать initrd с помощью регистратора ключей.

Ничто не останавливает злонамеренный хакер, модифицирующий ecryptfs на основе / или / boot, если у них есть физический доступ к системе - но посмотрим позже - дело не в этом.

«/» можно защитить с помощью полного шифрования диска, такого как LUKS (но, насколько мне известно, для каждого шифрования файла)- поскольку система изначально загружается из /boot, initrd может запросить фразу-пароль, необходимую для разблокировки тома перед монтированием /

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

Вы не можете защитить свою систему от неавторизованных людей с локальным доступом к ней, поэтому решение этой проблемы - предотвратить физический доступ. Вы можете пойти некоторым путем, чтобы гарантировать, что вещи не будут изменены без вашего ведома, проверив контрольные суммы всех ваших системных файлов и выполнив сравнение с автономным резервным копированием - это не является полной защитой, так как вам нужно убедиться, что вы используете немодифицированную программу контрольной суммы - и ту, которая делает коллизию хешей практически невозможной для воссоздания. [Вы можете упростить это, если разделите свои файловые системы и сделаете некоторые из них доступными только для чтения, а затем сохраните один хеш для каждого раздела только для чтения]. Хотя весь этот процесс громоздок.

При использовании полного шифрования диска "/" Обычно вы не используете компьютер в качестве "root", за исключением обновлений и т.д. - это обеспечивает достаточную степень