add support to ecryptfs-setup-swap for keyed hibernation

Approach #1 might be less inconvenient than it first seems, since people that like to hibernate might not be doing normal boots and are therefore not inconvenienced by the extra password prompt during normal boot.

Here is a bzr patch for approach #1. It's really a new file, not a patch for the existing swap setup script. I think it's a good stop-gap measure until #2 or #3 are implemented. The patch does not affect existing flows and can be optionally run by people that care about hibernation.

Here is a design for #2 - https://wiki.ubuntu.com/EncryptedSwapWithHibernationSupport

My suggestion is the second option.

Is it possible to have this done before Lucid's finale release?

On Wed, Feb 24, 2010 at 9:41 AM, papukaija <email address hidden> wrote:
> Is it possible to have this done before Lucid's finale release?

Sorry, no, it's not possible. Feature Freeze was last week, and
unfortunately, the amount of code that would be required to do this
would definitely be considered feature development.

Then please update the suggested bug text at https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume#Failure%20due%20to%20encrypted%20swap

Hi!

I upgraded from 9.04 to 10.04 and hit this, using a vanilla kernel (2.6.34) and
a luks-encrypted swap.

I'm using the following workaround, which seems to work. I thought I should
paste it here in case anyone is in a similar situation and wants to give it a try.

 - Put the contents below in /etc/initramfs-tools/scripts/local-top/encrypted_swap,
   replacing /dev/sda2 with the disk your swap is on, and swap-crypt with the
   device-mapper name of your swap disk (must match the one used in
   /etc/crypttab and /etc/fstab):

---------- 8< ---------- 8< ---------- 8< ---------- 8< ---------- 8< ---------- 8< ----------
#!/bin/sh

PREREQ=""

prereqs()
{
        echo "$PREREQ"
}

case $1 in
# get pre-requisites
prereqs)
        prereqs
        exit 0
        ;;
esac

# extracted from cryptroot
udev_settle()
{
        # Wait for udev to be ready, see https://launchpad.net/bugs/85640
        if [ -x /sbin/udevadm ]; then
                /sbin/udevadm settle --timeout=30
        elif [ -x /sbin/udevsettle ]; then
                /sbin/udevsettle --timeout=30
        fi
        return 0
}

udev_settle

# Replace "/dev/sda2" with your device, and "swap-crypt" with the
# device-mapper name, which can be found in /etc/crypttab or /etc/fstab

/sbin/cryptsetup luksOpen /dev/sda2 swap-crypt

---------- 8< ---------- 8< ---------- 8< ---------- 8< ---------- 8< ---------- 8< ----------

 - chmod +x /etc/initramfs-tools/scripts/local-top/encrypted_swap
 - Rebuild your initramfs using update-initramfs

Thanks,
    Alberto

I forgot to mention that you have to enter the password in tty1, which is not the one where the message is shown, at least here. It's hackish but it does the trick.

Thanks,
    Alberto

Just a comment:

Breaking unattend boot really is bad. I may eventually want to hibernate (actually I don't... ubuntu boots much faster than wakes up from hybernation), but still that will be really ackward if even after a non-hibernating poweroff my friends can't just grab my laptop and turn it on, or if my remote server can't restart after an energy cut.

I would like to say that this whole encryption setting is really badly documented on Ubuntu official pages. I digged a bit before finding tiny comments for instance about what sudo ecryptfs-setup-swap really does (indeed it does what I thought, generates a random key at boog, I'm not sure I found it on the documentations but I think it also changes the /etc/fstab properly, right?), hibernate being automatically disabled for encrypted swaps, etc. One of the reasons for using FOSS is that even being newbie, ignorant, or naïve, I keep control of what is going on behind the scenes. Confusing documentation generates FUD.

You may post links proving that I am wrong, but please try to reproduce the whole way through the documentation linking labyrinths: it is not that accessible. I found much better information on Dustin's blogs and interviews than on official documentation. I think this should all be explained in short, clear, transparent pages in ubuntu's official documentation. I won't volunteer for that myself, because I don't understand it deeply enough.

Alberto Bertogli : What is the exact setup of your encrypted swap? Is it in an LVM? Has it been encrypted with a random key? Because the script that you gave doesn't work with me.

On Thu, Jul 01, 2010 at 01:08:22PM -0000, LA wrote:
> Alberto Bertogli : What is the exact setup of your encrypted swap? Is
> it in an LVM? Has it been encrypted with a random key? Because the
> script that you gave doesn't work with me.

It's encrypted with dm-crypt (that is, using cryptsetup) directly over the
partition and without an LVM layer in between.

There is no random key, that's the whole point: I do NOT want an unattended
boot/resume, that's why I encrypted the swap with a non-random key in the
first place.

About the script not working, it depends on a lot of things in your
environment, so I think it's normal for it not to work if your setup is
different than mine.

Thanks,
  Alberto

On Thu, Jun 24, 2010 at 02:20:01PM -0000, Leo wrote:
> Breaking unattend boot really is bad. I may eventually want to hibernate
> (actually I don't... ubuntu boots much faster than wakes up from
> hybernation), but still that will be really ackward if even after a non-
> hibernating poweroff my friends can't just grab my laptop and turn it
> on, or if my remote server can't restart after an energy cut.

That depends on your setup.

I don't think it's a good policy to place unattended boot above all things.

For example, I have an encrypted swap device, using a manual key, and I
absolutely do NOT want an unattended boot, that's why I set up a manual key: I
want to get asked each boot/resume.

I believe this is not a weird scenario and the default initramfs should be
able to cope with it, along with the unattended ones.

I'm not saying that Ubuntu should default to such things, or even offer them
in the installer, just that the default initramfs should be able to handle
them.

Thanks a lot,
  Alberto

> I don't think it's a good policy to place unattended boot above all things.

To clarify, I'm not saying unattended boot should be above all things.

I'm saying that any change to be implemented should not affect the average user priving that user from this possibility.

Preventing unattended boot is already possible with Ubuntu. You don't want unattended boot, fine. There are many solutions for you. The simplest one is to encrypt the whole disk, and you can also set up a password at the BIOS menu.

The point is not to enfoce that on every user.

For me (and I guess for many people) it's important to be able to let my friends use my computer wihtout me having to jump over them saying "wait wait, I need to type the password", or even in my abscence. I'm fine having only my home and swap encrypted.

Approach #2 is nice because it does not break every single boot, just hibernate-resume ones. For securty I would add the restriction that only certain users are able to resume (with the admin choices of setting up a warning message to the non-resuming users before they hibernate, or deactivating hibernation for them, or nothing).

On Thu, Jul 01, 2010 at 04:45:31PM -0000, Leo wrote:
> > I don't think it's a good policy to place unattended boot above all
> things.
>
> To clarify, I'm not saying unattended boot should be above all things.
>
> I'm saying that any change to be implemented should not affect the
> average user priving that user from this possibility.
>
> Preventing unattended boot is already possible with Ubuntu. You don't

That's not quite true: the default initrd does not work with dm-crypted
swap, just like mine.

> want unattended boot, fine. There are many solutions for you. The
> simplest one is to encrypt the whole disk, and you can also set up a
> password at the BIOS menu.

Neither is an option in my case. I just think dm-crypted swap should be
supported, along the other schemes.

> The point is not to enfoce that on every user.

Of course not. I'm just referring to the possibility of Ubuntu supporting
a standard Linux feature out of the box. Not to enforce it, or to prevent
other alternatives; quite the contrary.

> For me (and I guess for many people) it's important to be able to let my
> friends use my computer wihtout me having to jump over them saying "wait
> wait, I need to type the password", or even in my abscence. I'm fine

I completely agree, and I never said otherwise. I just think it's
important to support _both_ boot/resume schemes: unattended if possible,
and requiring manual intervention if not.

Which one should be used depends on the encryption setup.

Thanks,
  Alberto

Well,

I am pretty sure that resume from hibernation did originally work for my fresh 10.10 install on a HP625 using an encrypted home directory (which in turn caused cryptswap to be set up as well).

At some stage that stopped working, though (I suspect it coincided with the installation of kvm but have no way to corroborate that), and I had to disable swap encryption as root, as requested in bug #484373:
1. Disable swapping to cryptswap1 using swapoff
2. Comment out the cryptswap1 line in /etc/crypttab
3. mkswap -L Swap -U e5bb547a-5b28-4c3d-bb00-fb3c94d4870f /dev/sda4
4. Change /dev/mapper/cryptswap1 in /ect/fstab to UUID=e5bb547a-5b28-4c3d-bb00-fb3c94d4870f
5. Change /etc/initramfs-tools/conf.d/resume to RESUME=UUID=e5bb547a-5b28-4c3d-bb00-fb3c94d4870f
6. update-initramfs -c -k all

Hope this helps.
Cheers,
 Lars

Ah,

and anybody following those steps should be aware that this approach may cause data to leak out from the encrypted home directory into the swap area during runtime and most certainly during hibernation...

Just a word of warning,
 Lars

Why is this only Wishlist importance? Ubuntu presents the Hibernate option, and will hibernate automatically by default if the battery runs low, but if encrypted swap is enabled (this and encrypted homedirs are both recommended by the installer) then it will fail to resume from hibernation, potentially causing DATA CORRUPTION or at least an OS CRASH. Fixing that is not a Wishlist in my view.

@gcc: Feature requests always have a wishlist importance.

I think he meant that not loosing data is not a feature, but a requirment. Thus when it happens it's not a missing feature, but a bug;)

At least, until this bug (yes, it's a bug, you loose data when you hibernate) is fixed, the Hibernate option should be removed / grayed out from the menu.

@papukaija: since when is "not crashing" a feature request?

I've kept this bug open for a very long time because I think it would
be a reasonable feature. Alas, I don't have time to work on it.
Patches accepted...

I think, given the severity of the bug and the apparent difficulty of producing an elegant fix, that for the time being the harm be limited by implementing TomaszChmielewski's suggestion from #20. I'd also suggest that the text be changed on the installer explaining that encrypting home directories will break hybernation.

I was happy to note that on the 11.10 beta1 alternate installer the home directory encryption is no longer the recommended option.

It was never the recommended option.

Can it be stressed in the installer that choosing encrypted home option will make hibernation unavailable? If I knew this at the installation time I'd had to think twice if I really wanted it. And now I will have to disable encrypted swap anyway since hibernation is more essential for me than encryption.

Adding task for Ubiquity, as the "stressing" of this would need to come in the graphical installer, one way or another.

The possibility for LVM & LUKS encryption from Ubiquity is discussed at https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-ubiquity-lvm-luks

I unlinked this bug from ubiquity-lvm-luks as this is not entirely related. That spec deals with cryptsetup (dm-crypt/LUKS) as currently supported by d-i. There is no scope in that spec for encryptfs.

Also I am not sure if this is needed. Users can simply do cryptsetup with passphrase for their swap if they want encrypted swap & hibernation.

As ubiquity now has support for:
- auto full disk encryption (that includes swap as well)
- manual partitioning (to e.g. setup just some parts encrypted) (in a branch will be commited soon)

I am closing ubiquity task. If ecryptfs gains additional features and ubiquity/d-i integration is wanted, please open a new bug.

I'm marking this bug won't fix. This is not something that we're going to solve in ecryptfs-setup-swap. Sorry.

Dustin Kirkland, according to https://wiki.ubuntu.com/DebuggingKernelHibernate this is the master/meta report scoped to having hibernate work with an encrypted swap, a feature that other encryption implementations (ex. Windows+BitLocker) have been able to accomplish for some time now.

Hence, just to clarify, is it that you don't intend to implement this ever, don't intend to implement this anytime soon, or the implementation would need to occur in a different package?

Dustin Kirkland, could you please advise to https://bugs.launchpad.net/ecryptfs/+bug/432785/comments/31 ?