[19.04 FEAT] LUKS2 support for pam_mount
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu on IBM z Systems |
Fix Released
|
High
|
Canonical Server | ||
libpam-mount (Ubuntu) |
Fix Released
|
Undecided
|
Skipper Bug Screeners | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
Cosmic |
Fix Released
|
Undecided
|
Unassigned | ||
Disco |
Fix Released
|
Undecided
|
Skipper Bug Screeners |
Bug Description
[Impact]
* Cryptsetup 2.0 with LUKS2 support was already released back in 2017,
but plugins exploiting it came sluggish.
A popular way to automatically make use of LUKS2 (of course while still
retaining support for LUKS1) is via the pluggable authentication module
system (PAM) - especially pam_mount supports the automated mount of
(encrypted) volumes at user login, but the current version supports
open plain mode encrypted volumes and LUKS1 encrypted volumes only,
hence it currently lacks support for LUKS2.
The updated version that is discussed here adds support for mounting
LUKS2 volumes with pam_mount on top and therefore allows to exploit
LUKS2 funtionality also via pam_mount.
This version already landed in disco, but should also end up in the
current long term supported Ubuntu (18.04, via cosmic).
* The means to get that is by backporting not the patch that was added on
top of Debian which is very similar (supports more types) to what was
accepted upstream.
[1]: https:/
[2]: https:/
[Test Case]
* Test using clear key and KVM (to be doable without special HW):
- Spawn a KVM guest (you can use any system which has extra disks and can mount)
- I used uvt-kvm to get a guest quickly and then added two extra disks like:
# shut down the guest
# create disks
$ sudo qemu-img create -f qcow2 /var/lib/
$ sudo qemu-img create -f qcow2 /var/lib/
$ virsh edit
# added
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/
<target dev='vdc' bus='virtio'/>
</disk>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/
<target dev='vdd' bus='virtio'/>
</disk>
- start the guest(s) again (all following actions are in the guest)
- create partitions on the disk spanning the full disk
$ sudo fdisk /dev/vdc
$ sudo fdisk /dev/vdd
$ sudo fdisk /dev/vde
- Bionic had no "cryptsetup" option in zkey yet, so lets use alternative commands on all tested releases
- Install the required tools
- Bionic: sudo apt install s390-tools libpam-mount
- later: sudo apt install s390-tools-zkey libpam-mount
- add a user for the test
$ sudo useradd -G users -m -s /bin/bash alice
$ sudo passwd alice
Enter new UNIX password: alice
Retype new UNIX password: alice
passwd: password updated successfully
- set a trivial password matching the user and setup a PLAIN, LUKS1 and LUKS2 container with it
$ echo -n alice > /home/ubuntu/
$ sudo cryptsetup luksFormat --batch-mode --verbose --force-password --key-file=
$ sudo cryptsetup luksFormat --batch-mode --verbose --force-password --key-file=
- open the devices
$ sudo cryptsetup open --type luks --batch-mode --verbose --key-file=
$ sudo cryptsetup open --type luks2 --batch-mode --verbose --key-file=
- format decrypted devices
$ sudo mkfs.ext4 -L ENC-LUKS1 /dev/mapper/
$ sudo mkfs.ext4 -L ENC-LUKS2 /dev/mapper/
- close devices again
$ sudo cryptsetup close enc-luks1
$ sudo cryptsetup close enc-luks2
- prep mountpoints
$ sudo mkdir /home/alice/luks1 /home/alice/luks2
$ sudo chown -R alice:users /home/alice/luks1 /home/alice/luks2
- setup pam_mount (use the mode where disk passphrase=user-PW - no key file needed)
$ sudo vim /etc/security/
# add there under Volume definitions
<volume user="alice" path="/
<volume user="alice" path="/
<volume user="alice" path="/dev/vdc1" mountpoint=
<volume user="alice" path="/dev/vdd1" mountpoint=
- log in and check if the devices are opened and mounted
It seems in the (far) past ssh was flaky with pam_mount but in all my tests it was fine.
Use `virsh console <guestname>` if you are concerned of ssh.
$ ssh alice@localhost
- mount will show entries like this
/dev/
/dev/
- once the user unlogged the mounts have to be gone again
Without the fix luks2 partition will fail to mount:
on mount the type is missing:
bionic-luks sshd[2547]: (mount.c:72): Messages from underlying mount program:
bionic-luks sshd[2547]: (mount.c:76): /sbin/mount.crypt: No dmcrypt cipher specified (use -o cipher=xxx)
bionic-luks sshd[2547]: (pam_mount.c:522): mount of /dev/vdd1 failed
on unmount it stumbles again since the expected to be mounted path isn't
bionic-luks sshd[2547]: (mount.c:72): umount messages:
bionic-luks sshd[2547]: (mount.c:76): umount: /home/alice/luks2: not mounted.
bionic-luks sshd[2547]: (mount.c:892): unmount of /dev/vdd1 failed
With the fix the luks2 partition mounts fine on login and unmounts as intended on logoff
[Regression Potential]
* The former initialization was locked onto LUKS1, in theory I see one
potential regression - that would be if crypt_get_type(cd) fails to
detect a special LUKS1 as LUKS1 and therefore fails to initialize
correctly after the update.
We will test for LUKS1 as well in the verification to be more sure on
that.
[Other Info]
* IMHO this fits under the SRU (https:/
----
LUKS2 support for pam_mount.
pam_mount support to automatically mount volumes at user login. This includes mounting of encrypted volumes. pam_mount supports to open plain mode encrypted volumes as well as LUKS encrypted volumes.
As of today, pam_mount 2.16 only supports LUKS1 volumes. LUKS2 was introduced with cryptsetup 2.0. This feature adds support for LUKS2 to pam_mount.
Following merge request was provided
https:/
Now upstream available
https:/
Related branches
- Andreas Hasenack: Approve
- Canonical Server: Pending requested
- git-ubuntu developers: Pending requested
-
Diff: 157 lines (+123/-0)5 files modifieddebian/changelog (+9/-0)
debian/patches/0015-Use-crypt_get_type-to-get-type-and-support-CRYPT_LUK.patch (+49/-0)
debian/patches/series (+1/-0)
debian/tests/control (+3/-0)
debian/tests/local-luks (+61/-0)
- Andreas Hasenack: Approve
- Canonical Server: Pending requested
- git-ubuntu developers: Pending requested
-
Diff: 157 lines (+123/-0)5 files modifieddebian/changelog (+9/-0)
debian/patches/0015-Use-crypt_get_type-to-get-type-and-support-CRYPT_LUK.patch (+49/-0)
debian/patches/series (+1/-0)
debian/tests/control (+3/-0)
debian/tests/local-luks (+61/-0)
tags: | added: architecture-s39064 bugnameltc-173439 severity-high targetmilestone-inin1904 |
Changed in ubuntu: | |
assignee: | nobody → Skipper Bug Screeners (skipper-screen-team) |
affects: | ubuntu → libpam-mount (Ubuntu) |
Changed in ubuntu-z-systems: | |
status: | New → Fix Committed |
information type: | Private → Public |
Changed in ubuntu-z-systems: | |
status: | Fix Committed → In Progress |
Changed in ubuntu-z-systems: | |
assignee: | nobody → Canonical Server Team (canonical-server) |
status: | In Progress → Triaged |
importance: | Undecided → High |
tags: | added: server-triage-discuss |
tags: | removed: server-triage-discuss |
description: | updated |
Changed in libpam-mount (Ubuntu Cosmic): | |
status: | New → In Progress |
Changed in libpam-mount (Ubuntu Bionic): | |
status: | New → In Progress |
description: | updated |
tags: | added: server-next |
Changed in ubuntu-z-systems: | |
status: | In Progress → Fix Committed |
Changed in ubuntu-z-systems: | |
status: | Fix Committed → Fix Released |
------- Comment From <email address hidden> 2018-11-21 05:36 EDT-------
This request is launched 19.04, but need also be applied for Cosmic and Bionic.
Many thx in advance