Encrypted root, LUKS and uresume do not work together

gst · 2009-01-14 17:45:35

I just encrypted my root and swap partitions with LUKS (which works fine), and now I'm trying to get uswsusp to work (again).

The problem is that /lib/initcpio/hooks/encrypt only takes care of the root partition (/dev/mapper/root), but the uswsusp hook (/lib/initcpio/hooks/uresume) needs access to the swap partition.

I found some existing postings in the forums, but they don't provide a solution to the problem. E.g. http://bbs.archlinux.org/viewtopic.php?pid=333326 suggest to use a "cryptdevice=/dev/sdb2:swap" parameter, in order to instruct the encrypt hook to decrypt the swap instead. But doing so prevents the hook from decrypting the root filesystem and booting. Furthermore I'd also like to avoid swapping/suspending to a file.

I see the following two possibilities to get uswsusp to work with LUKS devices:

* Wait until the root filesystem is mounted, then read crypttab, mount swap, and try to resume. The disadvantage is that the resume would occur at a rather late point during the boot process.

* Change the encrypt hook to allow an array of devices in the cryptdevice parameter. Additionally, the password would need to be read by the shell (instead directly by cryptsetup) and provided to cryptsetup via STDIN. This would allow to decrypt two devices (e.g. root and swap) with a single password prompt.

Are there any other (easier and/or existing) solutions to the problem?

Odd-rationale · 2009-01-14 18:56:41

I was wondering whether getting rid of the swap partition, and just using a non-encrypted swap file like in /mnt/swap might work. After all, the root partition is unlocked before it tries to resume.

I haven't got a chance to try whether it works or not, yet... Too lazy to reinstall and encrypt again...

Here was my original thread: http://bbs.archlinux.org/viewtopic.php?id=62672

Last edited by Odd-rationale (2009-01-14 18:57:02)

gst · 2009-01-14 22:10:57

I've now temporarily solved the problem in the following way:

Commented this code out in the encryption hook:

                loop until we get a real password
                while ! eval /bin/cryptsetup luksOpen ${cryptdev} ${cryptname} ${CSQUIET}; do
                    sleep 2;
                done

And replaced it by:

                while true; do
                    echo -n "Enter LUKS password: " 
                    # /bin/stty -echo
                    read KBDPWD
                    # /bin/stty echo

                    echo -n $KBDPWD |/bin/cryptsetup --key-file - luksOpen ${cryptdev} ${cryptname} ${CSQUIET}
                    if [ $? -eq 0 ]; then
                        break
                    fi
                    sleep 2
                done

                echo -n $KBDPWD |/bin/cryptsetup --key-file - luksOpen /dev/sda6 swap ${CSQUIET}

It seems that "stty" is currently not compiled into the busybox initcpio image, therefore the password is locally echoed on the terminal. Besides this, the solution seems to work fine.

If there is interest (and the chance to get this merged into the official sources), I can implement a cleaner solution to the problem that allows to specify an array of devices in the cryptdevice parameter (as suggested in my first posting).

kludge · 2009-01-15 03:02:35

i'm *hella* interested. feature request it with yr patch, and i'll definitely vote for the request.

edit: on second thought, your method will only work if the swap is encrypted with a peristent key, won't it? my system uses a random key, so i can't think how it could be brought back up on resume. hmmm....

Last edited by kludge (2009-01-15 05:21:24)

gst · 2009-01-15 07:02:39

Yes, you would need to use a persistent key if you want to resume from the device.

The idea is to loop through a "cryptdevice" array and to try to re-use the password obtained by the user (for the first device) for all remaining devices too. If this password fails for one of the devices, prompt the user again and continue iterating through the rest of the devices. So if the password is always the same you only have to enter it once. If the passwords differ booting is still possible, but you have to enter each password individually. (This only affects partitions that you need during the initcpio stage, any other partitions can be later "decrypted" via the /etc/crypttab file). If you don't use the "cryptdevice" parameter at all, or if you only supply a single device, the behaviour will be exactly the same as in the current version.

Maybe there is another easier solution. I'll need to check how it is done in Debian, as it is possible there to decrypt root and swap with a single password prompt too.

gst · 2009-01-15 09:10:42

It seems that Debian solves this problem by encrypting a single partition on which / and swap resides on LVM volumes.

gst · 2009-01-15 21:24:57

I've changed my setup back to the original "encrypt" hook. As it seems that there is no overhead when using swapfiles (as access does not go through the filesystem layer), I've changed my swap partition to a swap file on the root partition. Now everything works fine.

Odd-rationale · 2009-01-16 02:18:18

How were you able to suspend to the swap file? Can you document your steps? I just tried, and it didn't work. It said something like "invalid resume device."

Thanks!

gst · 2009-01-16 06:45:57

1) In your suspend.conf use:

snapshot device = /dev/snapshot
resume device = /dev/mapper/root
resume offset = 129024
compress = y

The required "resume offset" value can be obtained with the command "swap-offset /swapfile".

2) Check that the "uresume" hook in /etc/mkinitcpio.conf is listed after the "encrypt" hook.

3) Regenerate the initcpio image with "mkinitcpio -p kernel26" (in order to install the new suspend.conf and/or hooks).

4) Reboot.

Odd-rationale · 2009-01-16 18:37:40

What are you using to hibernate? pm-hibernate ?

gst · 2009-01-17 00:29:38

I'm using the uswsusp package from AUR together with the hibernate-script package.

Schumbi · 2009-04-13 00:09:52

gst wrote:

1) In your suspend.conf use:
snapshot device = /dev/snapshot
resume device = /dev/mapper/root
resume offset = 129024
compress = y
The required "resume offset" value can be obtained with the command "swap-offset /swapfile".
2) Check that the "uresume" hook in /etc/mkinitcpio.conf is listed after the "encrypt" hook.
3) Regenerate the initcpio image with "mkinitcpio -p kernel26" (in order to install the new suspend.conf and/or hooks).
4) Reboot.

Thanks a lot :-) it really works :-)
1. copied my encrypted swap to a file on my root partition (/ets/suspend.swp) (ls -la | grep suspend.swp to get the size of the file)
2. have done a mkswap /etc/suspend.swp <size of suspend.swp>
3. write the uresume hook to my /etc/mkinitcpio.conf after encrypt and before filesystems
4. write in /etc/fstab the entry for the new swap file(/etc/suspend.swp none swap sw 0 0)
5. changed suspend.conf in the way mentioned by gst
6. have done a mkinitcpio -p kernel26

stabele · 2009-04-18 18:44:15

Edit I am sorry, just found out my solution is stupid actually - this way key to swap (keyfile) is stored inside kernel image (which is on unencrypted partition).

I am using other solution. I have encrypted root and swap (on LVM volumes), swap is using keyfile /etc/swapkey . I am using uswsusp and hibernate-script. My /etc/suspend.conf

snapshot device = /dev/snapshot
resume device = /dev/mapper/swap

I added custom hook to mkinitcpio:

/lib/initcpio/install/openswap

# vim: set ft=sh:

install ()
{
    MODULES=""
    BINARIES=""
    FILES=""
    SCRIPT="openswap"
    
    add_file "/etc/swapkey" "/etc/swapkey"
}

help ()
{
cat<<HELPEOF
  This is my private hook-hack to open encrypted swap before
  uresume hook.
HELPEOF
}

/lib/initcpio/hook/openswap

# vim:set ft=sh:
run_hook ()
{
   msg "Trying to unlock encrypted swap..."
   eval /bin/cryptsetup -d /etc/swapkey luksOpen /dev/group1/swap swap
}

than insert it into /etc/mkinicpio.conf into HOOKS section

HOOKS="base udev autodetect pata scsi sata lvm2 encrypt openswap uresume filesystems"

...and regenerated initframs:

mkinitcpio -p kernel26

Last edited by stabele (2009-04-18 19:01:39)

brain0 · 2009-04-19 00:44:02

Okay, I have read horrible things here, so just some pointers on what you should never do:

1) If you hibernate to unencrypted swap, all the memory contents will be stored UNENCRYPTED in the swap partition, including all encryption keys. You can resume the system without entering the passphrase for the other volumes again.
2) If you save the key to the swap partition in the initramfs, you can still resume without having to enter the passphrase for the root (or any other) volume.

As soon as you are able to open the resume image, you have broken the entire encryption.

Now, how could you resume from hibernation with proper security? One way would be this:
1) Open the swap with a passphrase.
2) Try to resume from swap (if it succeeds, the following steps will not be executed).
3) Open root with a passphrase.
4) Mount root and boot

The problem here is, you have to enter a passphrase for encryption twice if you don't have an image in your swap. This is very ugly and thus not implemented. Another possibility:

1) Open a LUKS volume that contains a "key file storage"
2) Mount it
3) Use the keys in the key file storage to unlock swap and root
4) Unmount the storage
5) Try to resume
6) Mount root and boot

This is nicer, but would need a separate partition only for keyfiles. It is also not implemented. Now comes the solution I use.

I have only two partitions, sda1 (which contains /boot) and sda2. This is the boot process:
1) Open sda2 with the LUKS passphrase.
2) Open the LVM volume group that is contained in the (now accessible) encrypted container
3) Try to resume from the swap logical volume
4) Mount the root volume and boot

This is easily possible with mkinitcpio and also secure.

stabele · 2009-04-20 12:26:09

brain0 - is it so that your sda2 is LUKS encrypted partition and LVM physical space is inside? In that case your way is nice and clean (no hacking of mkinicpio hooks), but I have my encrypted partitions inside LVM (but it is true that advantage of this is limited, maybe next time I will do it your way).

I corrected my solution. My implementation as of now is dirty, but it is working and from cryptography safety point of view it is correct. In points similar to your descriptions (sda2 is fyzical volume for LVM):
1) Open LVM logical volume with root fs with passphrase
2) Temporary mount root fs
3) Unlock LVM volume with swap by keyfile stored at root fs
4) Unmount root fs
5) Try to resume from swap

If anybody is interested, here is my dirty custom mkinitcpio hook. If someone with more knowledge would rewrite it more properly, I will be first one eager to try (for example maybe it is easy to avoid temporary root fs mounting).

/lib/initcpio/install/openswap

# vim: set ft=sh:
install ()
{
    MODULES=""
    BINARIES=""
    FILES=""
    SCRIPT="openswap"
    
    add_dir "/tmproot"
    add_file "/bin/mount" "/bin/umount"
}

help ()
{
cat<<HELPEOF
  This is my private hook-hack to open encrypted swap before
  uresume hook.
HELPEOF
}

/lib/initcpio/hook/openswap

# vim:set ft=sh:
run_hook ()
{
   msg "Temporary mounting root"
   eval /bin/mount -t ext4 -n -r /dev/mapper/root /tmproot
   msg "Unlocking encrypted swap"
   eval /bin/cryptsetup -d /tmproot/etc/swapkey luksOpen /dev/group1/swap swap
   msg "Unmounting root"
   eval /bin/umount -i -n /tmproot
}

/etc/mkinicpio.conf HOOKS section

HOOKS="base udev autodetect pata scsi sata lvm2 encrypt openswap uresume filesystems"

Last edited by stabele (2009-04-20 15:21:19)

brain0 · 2009-04-20 22:57:44

A great warning for that: Mounting the filesystem -r might still play with the journal, and resuming will then lead to corruption. At least that is what happened with ext3. That is why I would use a small keyfile storage instead.

stabele · 2009-04-21 02:09:42

Mounting the filesystem -r might still play with the journal, and resuming will then lead to corruption.

I do not understand, could you please explain what risk you see?

brain0 · 2009-04-21 15:32:38

stabele wrote:

Mounting the filesystem -r might still play with the journal, and resuming will then lead to corruption.
I do not understand, could you please explain what risk you see?

An ext3 or ext4 filesystem will do a journal recovery even when mounted read-only! So if you first mount the filesystem, extract data from it and umount it, the state of the filesystem will have changed compared to what the kernel in the hibernation image expects - and the latter leads to filesystem corruption. In short: Never mount any filesystem that has been mounted in a system that is hibernated, not even read-only.

stabele · 2009-04-21 20:38:27

Thanks fo reply. Cannot this be prevented by noload mount option?

deltaecho · 2009-05-17 00:31:06

Sorry I missed this discussion earlier, but I've found a possible solution for suspending to SWAP with a randomly generated key at boot (you can find it here). Simply put, just before hibernation, the user will be asked to enter a key with which to re-encrypt his SWAP, and upon reboot, will be prompted to enter the key again, bypassing the usual random key generation and allowing his system to resume normally.

I'm not sure what the best approach to this would be, but believe I could write a couple initscripts to accomplish the task (such as with a little `sed' magic and swapping crypttab's). What do you think?

stabele · 2009-05-17 18:00:58

This approach have sense only if you want to hibernate using encrypted swap but you have not encrypted filesystem too. In case of encrypted filesystem I see this aproach not very practical - I allready have to enter long filesystem password at boot time anyway and I can store key to encrypted swap at encrypted filesystem - then why make it so I have to enter password every time I am going to hibernate (twice I presume to avoid errors)?

deltaecho · 2009-05-17 20:06:59

Now that I'm thinking about it (thanks to @stabele), there are a couple alternatives to my previous post:

1) If you wanted to (and aren't too paranoid about security), you could umount your SWAP partition, reformat and remount it, and comment out its entry in your crypttab to temporarily disable its encryption until the next time you shutdown normally.

2) You could unmount your normal SWAP partition and create an unencrypted SWAP file somewhere on your encrypted partition (via `dd'), which you would then use as your resume partition -- which shouldn't be too hard and is probably the best alternative.

3) You could do what I suggested previously.

I dunno' ... can anybody think of a better way?

Last edited by deltaecho (2009-05-17 20:07:38)

Profjim · 2009-07-31 08:07:11

I wrote a hook implementing brain0's proposal. It's here: http://bugs.archlinux.org/task/15738.

Last edited by Profjim (2009-07-31 08:07:35)

Arch Linux

#1 2009-01-14 17:45:35

Encrypted root, LUKS and uresume do not work together

#2 2009-01-14 18:56:41

Re: Encrypted root, LUKS and uresume do not work together

#3 2009-01-14 22:10:57

Re: Encrypted root, LUKS and uresume do not work together

#4 2009-01-15 03:02:35

Re: Encrypted root, LUKS and uresume do not work together

#5 2009-01-15 07:02:39

Re: Encrypted root, LUKS and uresume do not work together

#6 2009-01-15 09:10:42

Re: Encrypted root, LUKS and uresume do not work together

#7 2009-01-15 21:24:57

Re: Encrypted root, LUKS and uresume do not work together

#8 2009-01-16 02:18:18

Re: Encrypted root, LUKS and uresume do not work together

#9 2009-01-16 06:45:57

Re: Encrypted root, LUKS and uresume do not work together

#10 2009-01-16 18:37:40

Re: Encrypted root, LUKS and uresume do not work together

#11 2009-01-17 00:29:38

Re: Encrypted root, LUKS and uresume do not work together

#12 2009-04-13 00:09:52

Re: Encrypted root, LUKS and uresume do not work together

#13 2009-04-18 18:44:15

Re: Encrypted root, LUKS and uresume do not work together

#14 2009-04-19 00:44:02

Re: Encrypted root, LUKS and uresume do not work together

#15 2009-04-20 12:26:09

Re: Encrypted root, LUKS and uresume do not work together

#16 2009-04-20 22:57:44

Re: Encrypted root, LUKS and uresume do not work together

#17 2009-04-21 02:09:42

Re: Encrypted root, LUKS and uresume do not work together

#18 2009-04-21 15:32:38

Re: Encrypted root, LUKS and uresume do not work together

#19 2009-04-21 20:38:27

Re: Encrypted root, LUKS and uresume do not work together

#20 2009-05-17 00:31:06

Re: Encrypted root, LUKS and uresume do not work together

#21 2009-05-17 18:00:58

Re: Encrypted root, LUKS and uresume do not work together

#22 2009-05-17 20:06:59

Re: Encrypted root, LUKS and uresume do not work together

#23 2009-07-31 08:07:11

Re: Encrypted root, LUKS and uresume do not work together

Board footer