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

Bug #1597154 reported by Jason Gerard DeRose
30
This bug affects 6 people
Affects Status Importance Assigned to Milestone
System76
Fix Released
Critical
Jason Gerard DeRose
eCryptfs
Fix Committed
Critical
Jason Gerard DeRose
ecryptfs-utils (Ubuntu)
Fix Released
Critical
Tyler Hicks

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.

Related branches

Changed in ecryptfs:
assignee: nobody → Jason Gerard DeRose (jderose)
Changed in system76:
status: New → In Progress
importance: Undecided → Critical
assignee: nobody → Jason Gerard DeRose (jderose)
description: updated
Revision history for this message
Jason Gerard DeRose (jderose) wrote :

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

Revision history for this message
Jason Gerard DeRose (jderose) wrote :

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!

Tyler Hicks (tyhicks)
Changed in ecryptfs:
status: New → Triaged
importance: Undecided → Critical
Tyler Hicks (tyhicks)
description: updated
summary: - ecryptfs-setup-swap fails with GPT partitioning + NVMe/MMC drives
+ ecryptfs-setup-swap leaves swap unencrypted with GPT partitioning +
+ NVMe/MMC drives
Revision history for this message
Loye Young (loyeyoung) wrote :

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.

Revision history for this message
Loye Young (loyeyoung) wrote :

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.

Revision history for this message
Xavier Gnata (xavier-gnata-gmail) wrote :

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??

Revision history for this message
Jason Gerard DeRose (jderose) wrote :

@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 :)

Revision history for this message
Xavier Gnata (xavier-gnata-gmail) wrote :

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?

Revision history for this message
Xavier Gnata (xavier-gnata-gmail) wrote :

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

Revision history for this message
Jason Gerard DeRose (jderose) wrote :

@Xavier: glad it worked!

Revision history for this message
Rocko (rockorequin) wrote :

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

Revision history for this message
Jason Gerard DeRose (jderose) wrote :

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

Changed in ecryptfs:
status: Triaged → Fix Committed
Changed in system76:
status: In Progress → Fix Committed
Tyler Hicks (tyhicks)
description: updated
Changed in system76:
status: Fix Committed → Fix Released
Revision history for this message
Tyler Hicks (tyhicks) wrote :
Changed in ecryptfs:
status: Fix Committed → Fix Released
status: Fix Released → Fix Committed
Changed in ecryptfs-utils (Ubuntu):
assignee: nobody → Tyler Hicks (tyhicks)
importance: Undecided → Critical
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.