On 08/23/2011 03:05 PM, Arno Wagner wrote:
Quite frankly, I doubt this increses security significantly. An attacker could just manipulate the grub image and pretend to do decryption while really loading a compromised kernel. It would also be possible to patch grub so that it runs a kernel-patcher after decryption and before starting the kernel. I think both options are not really more difficult than patching a not encrypted kernel. The bottom line is still that if an attacker has access and then you continue to use your computer, you are screwed. Disk encryption only protects you if you know that the attacker had access, e.g. when your laptop is stolen. If you do not realize an attacker had access, anything is possible.
from a theoretical point of view I agree with you. However, given that the attacker does not yet know which kernel is going to be started, has very limited space for attack code, and has to change something (grub) that needs to change the next thing (kernel) instead of directly changing the kernel, it's really more difficult in my opinion. It's beyond the level of a regular good C programmer I would say, while changing the kernel is something any good C programmer should be capable of.
Given that this is the most common setup (kernel in unencrypted /boot and the rest of the OS in dm-crypt volume) I think it would be worthwhile to make this setup work in a smooth way (but I can understand it is a lot of work and people don't have the time to do it).
Olivier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
