What I documented in the test steps is clear-key approach as it is what will work on all platforms.
@ifranzki - could you test the PPA [1] against your setup ? @jfh - could you test the PPA [1] using a secure key in your setup ? Once those two are confirmed for the PPA we can upload for review by the SRU queue. [1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3635 ** Description changed: [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://git.launchpad.net/ubuntu/+source/libpam-mount/plain/debian/patches/0015-Use-crypt_get_type-to-get-type-and-support-CRYPT_LUK.patch [2]: https://sourceforge.net/u/ifranzki/pam-mount/ci/d4434c05e7c0cf05d87089404cfa2deedc60811a/ [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/uvtool/libvirt/images/disco-luks-d1.qcow 200M - $ sudo qemu-img create -f qcow2 /var/lib/uvtool/libvirt/images/disco-luks-d2.qcow 200M - $ virsh edit - # added - <disk type='file' device='disk'> - <driver name='qemu' type='qcow2'/> - <source file='/var/lib/uvtool/libvirt/images/disco-luks-d1.qcow'/> - <target dev='vdc' bus='virtio'/> - </disk> - <disk type='file' device='disk'> - <driver name='qemu' type='qcow2'/> - <source file='/var/lib/uvtool/libvirt/images/disco-luks-d2.qcow'/> - <target dev='vdd' bus='virtio'/> - </disk> + # shut down the guest + # create disks + $ sudo qemu-img create -f qcow2 /var/lib/uvtool/libvirt/images/disco-luks-d1.qcow 200M + $ sudo qemu-img create -f qcow2 /var/lib/uvtool/libvirt/images/disco-luks-d2.qcow 200M + $ virsh edit + # added + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/uvtool/libvirt/images/disco-luks-d1.qcow'/> + <target dev='vdc' bus='virtio'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/uvtool/libvirt/images/disco-luks-d2.qcow'/> + <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 + $ 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 + - 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 + $ 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/lukspassword - $ sudo cryptsetup luksFormat --batch-mode --verbose --force-password --key-file=/home/ubuntu/lukspassword --type luks /dev/vdc1 - $ sudo cryptsetup luksFormat --batch-mode --verbose --force-password --key-file=/home/ubuntu/lukspassword --type luks2 /dev/vdd1 + $ echo -n alice > /home/ubuntu/lukspassword + $ sudo cryptsetup luksFormat --batch-mode --verbose --force-password --key-file=/home/ubuntu/lukspassword --type luks /dev/vdc1 + $ sudo cryptsetup luksFormat --batch-mode --verbose --force-password --key-file=/home/ubuntu/lukspassword --type luks2 /dev/vdd1 - open the devices - $ sudo cryptsetup open --type luks --batch-mode --verbose --key-file=/home/ubuntu/lukspassword /dev/vdc1 enc-luks1 - $ sudo cryptsetup open --type luks2 --batch-mode --verbose --key-file=/home/ubuntu/lukspassword /dev/vdd1 enc-luks2 + $ sudo cryptsetup open --type luks --batch-mode --verbose --key-file=/home/ubuntu/lukspassword /dev/vdc1 enc-luks1 + $ sudo cryptsetup open --type luks2 --batch-mode --verbose --key-file=/home/ubuntu/lukspassword /dev/vdd1 enc-luks2 - format decrypted devices - $ sudo mkfs.ext4 -L ENC-LUKS1 /dev/mapper/enc-luks1 - $ sudo mkfs.ext4 -L ENC-LUKS2 /dev/mapper/enc-luks2 + $ sudo mkfs.ext4 -L ENC-LUKS1 /dev/mapper/enc-luks1 + $ sudo mkfs.ext4 -L ENC-LUKS2 /dev/mapper/enc-luks2 - close devices again - $ sudo cryptsetup close enc-luks1 - $ sudo cryptsetup close enc-luks2 + $ 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 + $ 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/pam_mount.conf.xml - # add there under Volume definitions - <volume user="alice" path="/dev/mapper/enc-luks1" mountpoint="~/luks1" fstype="crypt" /> - <volume user="alice" path="/dev/mapper/enc-luks2" mountpoint="~/luks2" fstype="crypt" /> - - <volume user="alice" path="/dev/vdc1" mountpoint="~/luks1" fstype="crypt" /> - <volume user="alice" path="/dev/vdd1" mountpoint="~/luks2" fstype="crypt" /> - + $ sudo vim /etc/security/pam_mount.conf.xml + # add there under Volume definitions + <volume user="alice" path="/dev/mapper/enc-luks1" mountpoint="~/luks1" fstype="crypt" /> + <volume user="alice" path="/dev/mapper/enc-luks2" mountpoint="~/luks2" fstype="crypt" /> + + <volume user="alice" path="/dev/vdc1" mountpoint="~/luks1" fstype="crypt" /> + <volume user="alice" path="/dev/vdd1" mountpoint="~/luks2" fstype="crypt" /> + - 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 + 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/mapper/_dev_vdc1 on /home/alice/luks1 type ext4 (rw,relatime,helper=crypt) - /dev/mapper/_dev_vdd1 on /home/alice/luks2 type ext4 (rw,relatime,helper=crypt) + /dev/mapper/_dev_vdc1 on /home/alice/luks1 type ext4 (rw,relatime,helper=crypt) + /dev/mapper/_dev_vdd1 on /home/alice/luks2 type ext4 (rw,relatime,helper=crypt) - 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 + 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 + 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] - * n/a + * IMHO this fits under the SRU + (https://wiki.ubuntu.com/StableReleaseUpdates) term "Other safe cases" + -> "For Long Term Support releases we sometimes want to introduce new + features". There is a need for this feature as some abilities of luks + can only be used with LUKS2 (like the secret key bugproxy is mentioning) + and the change should not affect/regress existing non luks2 use cases. ---- 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://sourceforge.net/p/pam-mount/pam-mount/merge-requests/2/ Now upstream available https://sourceforge.net/projects/pam-mount/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1804408 Title: [19.04 FEAT] LUKS2 support for pam_mount To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1804408/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
