Re: [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)

[Arno Wagner <arno@wagner.name>]

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.

> > 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.
 
Gr"usse,
Arno

> > 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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier