PPA with the builds is available at [1]. Test steps added to the SRU template and tested against: - disco ok - cosmic fail - bionic fail - cosmic + ppa ok - bionic + ppa ok
[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3635 ** Changed in: libpam-mount (Ubuntu Cosmic) Status: New => In Progress ** Changed in: libpam-mount (Ubuntu Bionic) Status: New => In Progress ** 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. + * 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. + 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). + 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. + * 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] - * TBD derived from - https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.lxdc/lxdc_unlock_partition_userlogin.html + * 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> + - 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/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 + - format decrypted devices + $ 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 + - 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/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 + - 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) + - 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. + * 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 + * n/a ---- - 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/ ** Tags added: server-next -- 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
