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

[Christoph Anton Mitterer]

On Fri, 2008-06-20 at 00:34 +0200, Jonas Meurer wrote:
> > Did you get my last eMail (see below).
> Yes, sorry for not responding to it yet. I suggest that you contact us at
> pkg-cryptsetup at lists.alioth.debian.org in the future. That's the
> official maintainer address and that way others have the opportunity to
> answer to your questions as well.
Ok,.. sorry,.. should have done that before, as I was already
subscribed, too.


> > I'm setting up a system that is completely encrypted with dmcrypt, even
> > the root partition.
> > The boot loader, kernel and initramdisk is on an USB-stick, which is
> > used to boot the system. grub2 is used for booting.
> sounds like an interesting setup. Do you plan do document that publically
> somewhere? others might be interested in how to setup such a system as
> well.
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.


> Yes, the root= parameter is provided to the initrd. In case of an
> encrypted root filesystem, the cryptroot hook detects the encrypted
> source device and saves that one in
... in what? ;)
Does it set up the mapping,.. and give the mapped device
(e.g. /dev/mapper/root) to the remaining debian scripts/hooks?


> cryptsetup luks devices do have an own UUID, which is different from the
> one of the decrypted filesystem. but see below.
Yeah,.. I found this out in the meantime, too.
So in crypttab,.. I need to specify the LUKS UUID, while in fstab I need
to use the filesystems UUID (or LABEL), right?
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?


> Both UUID and LABEL in /etc/fstab are the ones from the encrypted
> filesystem.
Ok... I've assumed that (in the meantime),.. but this reminds two some
new questions:
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,...)?

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?


> The initramfs cryptroot scripts detect the underlaying
> source device at initramfs creation time.
That way,.. in my setup where /-partition is also encrypted,... I must
already be in an state where / is decrpyted&mounted, right?
Wouldn't it be better to just take the values from crypttab and fstab,
in order to avoid that it-must-be-live-mounted-issue, or is this even
done that way? ;)


> When you boot, the initramfs
> first starts the dm-crypt device that holds your root filesystem,
ahhh,... and this is the information taken by initramfs-tools from the
crypttab, during creation time, right?

> and
> then the rootfs is mounted as specified in /etc/fstab.
This is also copied into the initramdisk, by initramfs-tools, right? But
it should no longer be managed by cryptsetups
initramfs-tools-hooks/scripts, right?



> > 3) Can I use UUID or labels with crypttab and if so how?
> > I assume it's not possible to use UUID with dmcrypt, as the UUID is
> > encrypted.
> This works due to the disks being available at /dev/disk/by-uuid and
> /dev/disk/by-label.
I don't think that this is true.
It works with UUID, as LUKS-partitions have their own UUID (luksDump) as
you told before.
But they don't have a LABEL, and the LABEL from the encrypted filesystem
is not available at that point,..
This is probably a bug in cryptsetup (don't just copy stuff from
Ubuntu ;-P)
At least I wasn't able to find a way to specify a LABEL for a LUKS
device.


> mount and /etc/fstab don't know anything about cryptsetup/dm-crypt
> devices. If you use UUID or LABEL in /etc/fstab, this works exactly as
> if the device would be unencrypted.
Ok... as I've asked abouve,.. I assume they simply look
into /proc/partitions where they also find the "decrypted"
dmcrypt-devices.


> The tool vol_id from udev (/lib/udev/vol_id) is of great help when you
> need to find out uuid, label etc from different devices. Try the tool
> with different source and target dm-crypt devices to get a better
> picture.
Did that already in the meantime:
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).


> > 5) When I use UUID to specify the root-filesstem,... who do the
> > initrd-scripts/cryptsetup scripts find the filesystem?
> As already mentioned, the cryptroot initramfs hook script detects the
> source device at initramfs creation time.
Does this mean that the root= parameter is completely ignored? This is
probably connected to my question above, wheter root= should have the
LUKS UUID or filesystem UUID/LABEL.


> > 6) In the initrd I need only the dm-crypt key for the root partition,
> > right? swap and all other partitions are enabled by the normal
> > sysvinit-scripts?
> 
> Exactly, the initramfs starts only the root device at normal boot. If
> you use some resume-from-disk or resume-from-ram features, the situation
> is different.
Ok I see,.. but in my security-sensitive setup at least resume-from-ram
is critical and should not be used at all.
And for resume-from-disk I haven't enough knowledge yet, about how this
works in general and how it is supported by debian's initrd and
cryptsetup's scripts.
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've forwarded your script to the pkg-cryptsetup mailinglist. We'll see
> whether we add it to the package. We plan to add some documentation
> regarding LUKS header/masterkey backup&restore anyway. If you feel like
> writing a small README, that would really be appreciated :-)
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.


Ok the GPG support issue is still floating around,... I remembered, that
I wrote this to David,.. and not to you ;)

1) First of all there SHOULD be gpg support for the decrypt scripts.
2) All these decrypt scripts should use the retry/timeout settings from
the crypttab,.. IIRC this is statically set at the moment?
3) It would be great if the following would be supported:
As soon as I have e.g. one crypttab entry with the decrypt_gpg script,..
gpg should be automatically added to the initrd. This has to be done
manully right now (of course one could create manually a hook for this).

4) While it would be nice for my "special" (where I boot from
USB-stick,.. and the disks are completely encrypted (no boot-partition
or so)) to have the key for the root-partition also included in the
initrd automatically,... this shouldn't be done,... because this is
probably not the default setup.

=> But I think we should warn people in the Readme's, that even when the
have an encrypted root-partition but a unencrypted boot-partition with
the kernel/initrd,.. they're vulnerable....
They're even vulnerable when the bootloader is on disk.

But perhaps crypttabs syntax can be expanded,.. to specify that the keys
should be included in the inird,... (e.g. a keyword internal-key or so)
or that they come from an external medium (e.g. external-key).
An the initrd should wait until this medium (e.g. a CD, USB-stick or
even a network mountpoint) is available.
Of course this is not easy to implement.
So take it just as ideas ;)

5. A further vision (which applies only to my setup where one boots from
USB stick) is the following:
When the kernel/initrd/bootloader is on an usb-stick or so,... this will
always include some manual work,...
e.g. one doesn't want to have the key inserted all the time,... and this
I use it only for booting,.. but there is a separate /boot/-directory in
the encrypted root-partition (which is not used, at least for booting).
The problem now is, that e.g. kernel updates will just change update the
(unused) encrypted /boot/ directory, but not the actual used kernel on
the USB-stick.
The same is true for most of the update-scripts like update-grub and so
on.
One (at least partial) solution would be,.. to put only a dummy kernel
on the boot script that has enought knowledge and drivers to mount the
root-fs and then via kexec, boot the kernel from inside the encrypted
partition in the (right now unused) /boot/ directory.

Of course this doesn't solve all problems (update-grub still won't work)
and there arise even some more problems from this scenario.

And I don't even know if it would work at all,.. because I don't know if
after kexec the inird from inside the
encrypted-partitions /boot-directory is already loaded (which whould
have to contain a copy of the key for the root partition,.. to decrypt
it (again).


Hope I wrote not too much unclear stuff.. ;) (it's already late here and
I'm tired) ^^



Best wishes,
Chris.