On Mon, September 22, 2014 22:59, Arno Wagner wrote: > On Mon, Sep 22, 2014 at 21:07:58 CEST, Sven Eschenberg wrote: >> On Mon, September 22, 2014 12:02, Arno Wagner wrote: > [...] >> I think in his case is is plain dmcrypt which does not invalidate your >> point of course. > > Possibly. As it does nit make much difference, I did nt make sure I\ > got that right. > >> > >> > 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 ;-) >> ). > > Tell me about it. I have a headless firewall/fileserver in my > kitchen, and I got really fed up withhaving to carry it to > my desk whenever something stuck during boot. I finally > installed a serial interface to be able to debug it with a > laptop and minicom. I have given up on encryption during boot > for it, it just has an encrypted data partition that I mount > manually over ssh. > You are lucky in a way, still physical access ;-). In this case having a usb device with the key(s) is a viable option. Stick it in during boot and pull it when the system is up. Works out of the box on some distros. Well, maybe manually will win over laziness for me too. I am somewhat fiddling on something like that currently. BTW: Remeber the classic VT-10x Terminals? A modern portable variant would be neat, I think. Like a netbook, but just a display controller+serial chip, could be really flat and lightweight. >> > 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. > > I have only data encrypted. Nothing in /etc/ or /var/ needs extra > protection IMO. The only thing besides data that I see as worthwhile > protecting are ssh private keys. Your needs may differ and I do > understand the argument. It is just important to remember that an > initrd is just as juicy a target for an attacker as a root > partition and if you do it manually, the initrd is more > complicated. Of course I also have non-module kernels tailored > for my systems, so that removes another reason for an initrd. Of course all depends on your setup and need. Unfortunately configuration data can be sensitive. Some daemons used to store credentials in /etc (pppd ?, network filesystems?). If you run an MTA, you'd probably want to secure the mailspool and maildirs (both usually in /var). With ssh private keys you meant the host keys, I guess? > > Gr"usse, > Arno > Regards -Sven _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
