| 2016-06-29 01:21:32 |
Jason Gerard DeRose |
bug |
|
|
added bug |
| 2016-06-29 01:21:48 |
Jason Gerard DeRose |
ecryptfs: assignee |
|
Jason Gerard DeRose (jderose) |
|
| 2016-06-29 01:24:29 |
Jason Gerard DeRose |
branch linked |
|
lp:~jderose/ecryptfs/fix-1597154 |
|
| 2016-06-29 01:37:15 |
Jason Gerard DeRose |
bug task added |
|
system76 |
|
| 2016-06-29 01:37:24 |
Jason Gerard DeRose |
system76: status |
New |
In Progress |
|
| 2016-06-29 01:37:27 |
Jason Gerard DeRose |
system76: importance |
Undecided |
Critical |
|
| 2016-06-29 01:37:42 |
Jason Gerard DeRose |
system76: assignee |
|
Jason Gerard DeRose (jderose) |
|
| 2016-06-29 04:43:50 |
Jason Gerard DeRose |
description |
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, 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
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. |
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, 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. |
|
| 2016-06-30 20:19:41 |
Jason Gerard DeRose |
attachment added |
|
fix-1597154.patch https://bugs.launchpad.net/ecryptfs/+bug/1597154/+attachment/4693058/+files/fix-1597154.patch |
|
| 2016-07-02 00:27:24 |
Tyler Hicks |
ecryptfs: status |
New |
Triaged |
|
| 2016-07-02 00:27:30 |
Tyler Hicks |
ecryptfs: importance |
Undecided |
Critical |
|
| 2016-07-02 00:56:52 |
Tyler Hicks |
description |
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, 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. |
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. |
|
| 2016-07-02 00:57:20 |
Tyler Hicks |
summary |
ecryptfs-setup-swap fails with GPT partitioning + NVMe/MMC drives |
ecryptfs-setup-swap leaves swap unencrypted with GPT partitioning + NVMe/MMC drives |
|
| 2016-07-02 23:06:38 |
Loye Young |
bug |
|
|
added subscriber Loye Young |
| 2016-07-04 12:57:52 |
Rocko |
bug |
|
|
added subscriber Rocko |
| 2016-07-07 00:06:34 |
Launchpad Janitor |
branch linked |
|
lp:ecryptfs |
|
| 2016-07-07 00:33:14 |
Jason Gerard DeRose |
ecryptfs: status |
Triaged |
Fix Committed |
|
| 2016-07-07 00:33:21 |
Jason Gerard DeRose |
system76: status |
In Progress |
Fix Committed |
|
| 2016-07-08 21:32:48 |
Launchpad Janitor |
branch linked |
|
lp:~tyhicks/ecryptfs/lp1597154-packaging |
|
| 2016-07-14 14:56:40 |
Tyler Hicks |
description |
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. |
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. |
|
| 2016-07-14 16:10:22 |
Jason Gerard DeRose |
system76: status |
Fix Committed |
Fix Released |
|
| 2016-07-14 16:42:56 |
Tyler Hicks |
ecryptfs: status |
Fix Committed |
Fix Released |
|
| 2016-07-14 16:43:15 |
Tyler Hicks |
ecryptfs: status |
Fix Released |
Fix Committed |
|
| 2016-07-14 16:43:31 |
Tyler Hicks |
bug task added |
|
ecryptfs-utils (Ubuntu) |
|
| 2016-07-14 16:43:51 |
Tyler Hicks |
ecryptfs-utils (Ubuntu): importance |
Undecided |
Critical |
|
| 2016-07-14 16:43:51 |
Tyler Hicks |
ecryptfs-utils (Ubuntu): status |
New |
Fix Released |
|
| 2016-07-14 16:43:51 |
Tyler Hicks |
ecryptfs-utils (Ubuntu): assignee |
|
Tyler Hicks (tyhicks) |
|
