[Pkg-cryptsetup-devel] Questions about cryptsetup/initramfs

[Christoph Anton Mitterer]

sry: the first mail missed the -devel in the mailinglists-address

On Tue, 2008-06-24 at 14:58 +0200, Jonas Meurer wrote:
> > I could send you some really extensive, very paranoid and pedantic
> > logs,... you could cut out what you don't like and publish the
> > remaining.
> Sorry, I doubt that i have the time to write a documentation out of your
> logs. I just thought that you maybe plan to publish a howto/tutorial
> anyway.
Eventually I will find the time to do this,.. but this also depends on
how long it takes to include everything I've planned in the upstream
(your) sources (see the discussion thread with David).
My time is limited, too, and I won't this to become an endless project
for me ;)


> exactly, in crypttab you use the UUID of the LUKS device.
I'm not sure if I've already bug-reported this,.. but there is no LABEL
for LUKS devices,... and thus only UUID works,... but there seems to be
some code in cryptsetup,.. that thinks that LABEL would work, too.

The problems with this go even further:
1) while grub-pc (grub2) detects that it mus set root=
to /dev/mapper/sda2 it seems not to be able to use it's UUID (as it does
per default with non-dm-crypt-devices).
2) When I e.g. use LABEL= in fstab, but device-names (/dev/sda or so) in
crypttab,.. cryptsetup was not able to detect root and didn't write
this /conf/conf.d/cryptroot (in the initrd).
Perhaps there might be other problems,... any idea here?


> > What about the kernel-root=-parameter,... is it LUKS's UUID or the plain
> > decrypted-fs UUID/LABEL ?
> > Or should one use something like /dev/ram0 or so?
> I'm not sure about that one, but I guess that the kernel root parameter
> is used by the initrd for mounting the root device _after_ the dm-crypt
> mapping has been setup.
I think so too,.. perhaps David is able to clear this.

However,.. in the meantime I've read in the kernel docs
(Documentation/inird.txt or so) that in the "new way" this should be set
to /dev/ram0 ... so I assume Debian's initrd still use the "old way".
Is this going to be changed, David?


> > 1) The UUID/LABEL in /etc/fstab and what mount/fsck and so on look
> > for,...
> > Is this done by simply searching to all partitions that appear
> > in /proc/partitions (where also dm-crypt partitions appear as dm-0,...)?
> I guess that is searches for both in /dev/disk/by-{label|path}/
You think? I didn't check it but I would have thought, that udev itself
(which creates those /dev/disk-symlinks) would look at the kernel
provided /proc/partitions, because this information can probably not
resolved in user-space,.. or can it?


> > 2) How does this generally work: I mean the initrd already mounts the
> > root filesystem, right?
> > But then in /etc/fstab it's listed again, e.g. as /dev/mapper/sda1 or as
> > LABEL=root,...
> > Why isn't it "mounted twice" ... is this catched by the init.d-scripts?
> mount ignores already mounted devices.
Ah,.. *G* ok....


> > What is that
> > ID_FS_UUID_ENC and ID_FS_LABEL_ENC and ID_FS_LABEL_SAFE? In my case it's
> > always the same as the base-property (ID_FS_UUID and ID_FS_LABEL).
> It is indeed always the same. I don't know what the exact difference is
> and in which situations there is a different value. But i've never seen
> such a situation anyway.
David,... do you have any idea perhaps?


> > I mean in my setup the resumed system whould have to get the key again
> > from the USB-stick,... e.g. wait for the correct one to be inserted,
> > mount it and so on,.. does cryptsetup's script support this?
> i guess that's not how suspend/resume works. if you suspend a system,
> the ram/swap is saved, and if you resume, it is reloaded. and the ram
> contains keys of all active encrypted disk.
I meant suspend to disk and not to ram,... (the later is pretty unsecure
one can get the unencrypted key from the RAM)

AFAIK if you suspend to disk this is stored to the swap partition, which
should be encrypted, right?
Thus one would need a valid key (for swap, not necessary for root) in
order to resume-from-disk.


> > Readme for my script or for the issue in general?
> > I know that Clemens has strong objections against making backups of the
> > master-key,... but I don't share his arguments in this issue, because I
> > think they have a (small) touch like security by obscurity.
> I mean a README regarding backup and restore of the LUKS header/masterkey.
Ok,.. I'll write such a readme (please remember me if I should forget
it, as I'm really busy these days :-/ )... hopefully you can include it
then in the package.


> The idea of autmatic inclusion of prerequirements in the initramfs is
> indeed a nice one. I think that David already gave information about how
> to best implement that (i.e. make the keyscripts print their prereqs
> when invoked without any cmd-line argument).
Yeah,... let's move this to the other thread...	


> Please provide a patch. In most cases people who fear that their kernel
> and/or initrd becomes compromised will know how to deal with the issue.
I think the best way would be to write a security-paranoid.howto where
all this is inclued.


> And I really see no way to implement preventions against that within the
> debian package. all that we can do is advice such people to load
> bootloader, kernel and initrd from a readonly device (i.e. cdrom) and
> check md5sum/sha1sum frequently.
Of course there is no way for Debian to do anything.... the only way is
that people fully encrypt their systems,... and take the kernel/etc on
an USB/etc. always with them.


> I really object against yet more random crypttab options. and I also
> object against providing a simple solution to include the keyfile into
> the initramfs. People would add uncrypted keyfiles to the initramfs.
As you can see from the other thread,... I have a beta-solution where
the key is not inclued in the initrd itself ;)
So let's move this discussion to that thread too.


> simply mount your usbstick to /boot and configure grub correctly. then
> upgrades of bootloader/kernel/initrd should work again.
Interesting,.. I'll try that.


Best wishes,
Chris.