ecryptfs-setup-swap leaves swap unencrypted with GPT partitioning + NVMe/MMC drives

Bug Description

CVE Request: http://openwall.com/lists/oss-security/2016/07/13/2

When GPT swap partitions are located on NVMe or MMC drives, ecryptfs-setup-swap fails to mark these swap partitions as "no-auto".

As a consequence, when using encrypted home directory with an NVMe or MMC drive, the swap is left unencrypted. There's also a usability issue in that users are erroneously prompted to enter a pass-phrase to unlock their swap partition at boot.

I have a patch that I'll propose for merging shortly.

==
Aside:

Although not necessarily related, there's another issue System76 encountered when investigating this for a customer using encrypted home directory with an NVMe drive and the proprietary NVDIA driver.

After doing a fresh install of 16.04.1 (choosing "Encrypt my home directory") and then installing the proprietary NVDIA driver with:

sudo apt-get install nvidia-361

During the package installs, we were twice prompted to enter a pass-phrase to unlock the encrypted swap partition. This seemed to happen when installing dkms modules. We know this doesn't happen when the swap partition is correctly marked as "no-auto", but it's still very curious behavior.

Re the curious "Aside" I mentioned in the bug description, we've narrowed it down a bit: in this scenario, it seems installing/upgrading/reinstalling any packages that have systemd services will result in the user getting prompted for a passphrase to unlock their cryptoswap partition. I filed a bug against systemd for this:

https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1597876

Because this effects such a large number of System76 customers, we're now delivering a patched ecryptfs-utils package in our Stable PPA (which is pre-installed and up-to-date in our golden images):

https://launchpad.net/~system76-dev/+archive/ubuntu/stable

In case it helps facilitates more quickly getting a fix for this into xenial-updates, I've attached a debian patch ready to be applied against ecryptfs-utils 111-0ubuntu1.

For what it's worth, System76 is extremely keen on getting a fix for this into the 16.04.1 ISO as our customers are still faced with this problem when doing a re-install.

Please let me know if there's anything we can do to help facilitate this!

Does the problem remain if you change the GPT partition type of the encrypted swap partition to 8300 or 0700 instead of 8200?

I suspect systemd is mounting the swap partition as an unencrypted swap before cryptsetup does its magic.

Re: Comment #3 above.

The partition type numbers I described are those using gdisk.

Ontologically, an encrypted swap partition is not the same thing as a regular swap partition, at least from the partition table's view. They perform the same function from the viewpoint of the system, but the partition table is concerned with the way the partitions are formatted.

Consequently, systemd is currently performing as it should, IMHO. The problem more fundamentally is that the partition is mislabeled.

I have installed a fresh 16.04.
I have these partitions

Device Start End Sectors Size Type
/dev/nvme0n1p1 6 76805 76800 300M EFI System
/dev/nvme0n1p2 76806 19691128 19614323 74,8G Apple Core storage
/dev/nvme0n1p3 19691129 19849820 158692 619,9M Apple boot
/dev/nvme0n1p4 19849984 20850687 1000704 3,8G Linux swap
/dev/nvme0n1p5 20850688 61279231 40428544 154,2G Linux filesystem

During the install/update process, I add to enter the password for the swap partition about 10 times.
After this tedious process, the system is still asking for the password for the swap at each boot. I have patched ecryptfs-setup-swap as mentioned above but I still have to enter the password at each boot. Should I relaunch/update something having patched ecryptfs-setup-swap?? Should I try to change the swap GPT partition type??

@Xavier: this patched ecryptfs-utils package can only help you correctly create a new setup, wont help when trying to fix existing setups. So it's basically only useful once there's a new 16.04.1 (daily) ISO that incorporates the fix, or likewise for an up-to-date OEM mode install (where this patched ecryptfs-utils package is installed prior to clicking "Prepare for shipping to end user").

To fix an existing setup, you might try this script that I added to the system76-driver:
http://bazaar.launchpad.net/~system76-dev/system76-driver/trunk/view/head:/system76-fix-ecryptfs-swap

Download it locally then:

sudo python3 system76-fix-ecryptfs-swap

Fair warning: when needed this script does something fairly invasive, but it likewise went through obsessive enough testing to make me feel comfortable pushing it out to all System76 customers. So in theory everything should be a-okay if you run this script :)

No blue smoke :) but:

root@macaron:~# python3 ./system76-fix-ecryptfs-swap
A hybrid GPT was detected. You have to sync the hybrid MBR manually (expert command 'M').
system76-fix-swap: INFO: toggling no-auto bit on partition '4' of '/dev/nvme0n1'
A hybrid GPT was detected. You have to sync the hybrid MBR manually (expert command 'M').
The device contains hybrid MBR -- writing GPT only. You have to sync the MBR manually.
Re-reading the partition table failed.: Device or resource busy

It's a dual boot on a fresh macbook air. I used the macOS command lineto resize the macOS partition and then installed kubuntu in a very standard way.
What do you recommand?

but...it works thanks to your script!
I haven't understood why setting it to no_auto helps but it works :)

@Xavier: glad it worked!

@Jason: your script worked for me too, many thanks!

@Rocko: awesome, so glad to hear my script helped you!

http://www.ubuntu.com/usn/usn-3032-1