On Mon, September 22, 2014 12:02, Arno Wagner wrote: > On Mon, Sep 22, 2014 at 07:41:39 CEST, Heiko Rosemann wrote: >> On 09/22/2014 12:50 AM, vaskez@xxxxxxxxxx wrote: >> > Several times I have set up virtual machines to test the cryptsetup >> > software. I can create and remove the encrypted volumes just fine >> > and mount them, however whenever I am finished setting up my system >> > and reboot, my kernel panics, ends, then says that it cannot mount >> > root fs on unknown block (hd0,0). I am sure that it is not a >> > misconfiguration with the kernel, as I have built kernels for >> > unencrypted systems and they have booted fine. Some information: >> >> You will need to setup an initramfs or modify the one provided with >> the gentoo install to open your encrypted volumes (at least the root >> volume). I do not remember how it is "supposed to be done" in gentoo, >> but I do remember it's not as simple as installing software in the >> right order. > > The thing is that the kernel cannot open LUKS encrypted partitions > by itself. It needs user-space tools (cryptsetup) for that. That > means the system must be running and have a working root filesystem. > The initrd mechanism provides a temporary root filesystem for that > use. I think in his case is is plain dmcrypt which does not invalidate your point of course. > > As I do not like initrds on my systems (too much hassle changing > anything), I use a different approach: Non-encrypted root and > anything I consider security-critical on encrypted partition(s). Which is not hassle free either, esp. on headless systems. On one hand local mounts and fscking is done early, so cryptsetup should be even before that point, then again it can be difficult to provide the key remotely that early during boot. (I know KVMoIP is your friend here ;-) ). > > A common criticism of that set-up is that it allows an attacker > to change things on the root partition, but the same applies to > the initrd (and the kernel!) as well and hence the initrd approach > does not really offer better security. If you want to prevent that, > you have to use some variant of secure boot, for example placing > bootloader, kernel and initrd on an encrypted memory-stick with > keypad or the like. And you better verify the BIOS checksum as > well, although that may not be enough if somebody put a blue-pill > in there. Fortunately such attacks are expensive and come with a > high risk of detection, so unless you are a known terrorist or > crimnal master-mind, don't worry about these. I agree, but pulling parts of /etc or /var onto crypto targets, while leaving parts unencrypted is quite ugly. So many people would just encrypt / alltogether to save them from that hassle. > > Second thing is that a running system is far easier to attack and > as soon as it is opened, disk-encryption does not offer any > protection anymore.... > Indeed > > Arno > > Regards -Sven _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
