[19.04 FEAT] LUKS2 support for pam_mount

[bugproxy]

[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>
- 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.

[Other Info]

 * 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/

[bugproxy (bugproxy)]

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

[Dimitri John Ledkov (xnox)]

Hi, in disco-proposed there is already support for LUKS2 via the following patch

https://git.launchpad.net/ubuntu/+source/libpam-mount/plain/debian/patches/0015-Use-crypt_get_type-to-get-type-and-support-CRYPT_LUK.patch

it implements LUKS2 support slightly differently to the patch that was submitted upstream, but either should provide equivalent functionality.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2018-11-22 02:50 EDT-------
Yes that patch should have the same effect.

The only thing that comes to my mind is if it is intended that other types, such as PLAIN, LOOPAES, VERITY, TRCRYPT or INTEGRITY would also be accepted?

crypt_get_type() returns whatever type the volume uses, and is not limited to just LUKS (1+2). So if the volume would use for example LOOPAES, then it would try to perform the crypt_load() with type LOOPAES. This might work, but some types might require additional parms specified with crypt_load(), so I doubt that this will work for other types than LUKS.
Also crypt_format() certainly requires additional parms for non-LUKS volumes.

By using type CRYPT_LUKS instead of CRYPT_LUKS1 (like my patch does), you limit it to just LUKS (1 or 2), but reject any other types.

Not sure which approach is better.....

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2018-11-26 03:00 EDT-------
I checked the libcryptsetup code further:

crypt_init() just initializes the context, and sets the type inside the context to NULL.
A subsequent crypt_get_type() will therefore return NULL in any case.
The type field of the context is only set during crypt_load() or during crypt_format(). Thus it does not make much sense to call crypt_get_type() before crypt_load() or crypt_format().

So your patch is essentially the same as mine. Both pass NULL to crypt_load() as type, resulting in LUKS 1 or 2. Yours is just somewhat more obfuscating? :-)

[Dimitri John Ledkov (xnox)]

It's not even my patch =) just something that was done by maintainers in Debian =)))) so obfuscating++

[Dimitri John Ledkov (xnox)]

libpam-mount 2.16-9ubuntu1 is now in disco (release).

[Christian Ehrhardt  (paelzer)]

Hi Ingo,
we are sorting out the needs for an SRU of this - until I have discussed with the Team (all others still asleep :-) ) I wanted to ask if you had a test setup for LUKS1/LUKS2 available that you used to write your patch. If so we could reuse that for the verifications of PPAs and the final SRU.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2019-02-05 03:43 EDT-------
We have documented the use of pam_mount with LUKS(2) and secure keys and the PAES cipher in the manual "Pervasive Encryption for Data Volumes" in chapter 5, section "Opening and mounting an encrypted volume at user login":
https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.lxdc/lxdc_unlock_partition_userlogin.html
You can certainly also use the procedure described there with clear key LUKS (1 and 2), you just need to adapt the commands accordingly for clear key usage.

[Christian Ehrhardt  (paelzer)]

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

[Christian Ehrhardt  (paelzer)]

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

[Christian Ehrhardt  (paelzer)]

Waiting for tests by jfh and ifranzki - setting incomplete until I get those confirmed.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2019-02-06 06:56 EDT-------
Looks good !

I installed the PPA (2.16-5ubuntu0.1) on Ubuntu 18.10 and configured pam_mount for user 'user' with a LUKS2 encrypted disk using secure keys:

/etc/security/pam_mount.conf.xml:

<volume user="user" path="/dev/dasdd3" mountpoint="~"
fstype="crypt" fskeycipher="none"
fskeypath="/etc/luks_keys/user-disk.key" />

When I logon the user, it unlocks and mounts the LUKS2 volume successfully:

user@s8360029:~$ df | grep user
/dev/mapper/_dev_dasdd3 7029456 31668 6621000 1% /home/user

[Christian Ehrhardt  (paelzer)]

Thanks ifranzki,
I also added automated tests to the packages on the SRU as well as in Debian [1].

Test results look good atm and will give the whole thing some more confidence:
Cosmic with fix: http://paste.ubuntu.com/p/nfwBTqBdP9/
Cosmic without: http://paste.ubuntu.com/p/2rzYZJ3RYJ/
Bionic with fix: http://paste.ubuntu.com/p/WwFDY99dNh/

All we need now is a review on the MPs to check for oversights or silly mistakes - that should happen today and then I can upload to the SRU queue.

[1]: https://salsa.debian.org/debian/libpam-mount/merge_requests/1

[Christian Ehrhardt  (paelzer)]

Uploaded to the SRU queue

[Frank Heimes (fheimes)]

I did one more successful test on bionic and LUKS2.
Thanks for the other tests and results results.
I just change the status now to In Progress...

[Brian Murray (brian-murray)]

Hello bugproxy, or anyone else affected,

Accepted libpam-mount into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libpam-mount/2.16-5ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Christian Ehrhardt  (paelzer)]

FYI - before you go testing this - the builders currently have some issues.
So while the source is in -proposed the package isn't fully built yet.
Be sure when testing to actually have the new code in place.

TL;DR - probably better wait one day to start testing

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2019-02-14 02:55 EDT-------
I already did test this as a PPA (2.16-5ubuntu0.1) on Ubuntu 18.10, see a few comments above. Do you want me to test it again?

[Christian Ehrhardt  (paelzer)]

Hi ifranzki, the test you did was the sanity check on my PPA before bringing it to the eyes of the SRU Team. The one that was called for in comment #16 is now "the real thing" available in cosmic-proposed and binaries that would be released.
They are >=99,9% identical, but to be sure a test against <release>-proposed is needed to complete SRUs.
Yet atm due to the builders, give it some time to actually build please.

[Christian Ehrhardt  (paelzer)]

Before the update afte rlogin as described in the test steps:

$ ssh alice@localhost
# mount | grep luks
/dev/mapper/_dev_vdc1 on /home/alice/luks1 type ext4 (rw,relatime,helper=crypt)
<no luks2>

Upgrading from proposed
ubuntu@cosmic-luks:~$ sudo apt install libpam-mount
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  cifs-utils davfs2 sshfs hxtools
The following packages will be upgraded:
  libpam-mount
1 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.
Need to get 81.8 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://ports.ubuntu.com/ubuntu-ports cosmic-proposed/main s390x libpam-mount s390x 2.16-5ubuntu0.1 [81.8 kB]
Fetched 81.8 kB in 0s (319 kB/s)
(Reading database ... 71606 files and directories currently installed.)
Preparing to unpack .../libpam-mount_2.16-5ubuntu0.1_s390x.deb ...
Unpacking libpam-mount (2.16-5ubuntu0.1) over (2.16-5) ...
Processing triggers for libc-bin (2.28-0ubuntu1) ...
Processing triggers for man-db (2.8.4-2) ...
Setting up libpam-mount (2.16-5ubuntu0.1) ...
Processing triggers for libc-bin (2.28-0ubuntu1) ...

$ ssh alice@localhost
$ mount | grep luks
/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)

Working as intended, setting verified

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2019-02-14 10:50 EDT-------
I have upgraded from proposed and retested with a LUKS2 volume using secure keys. I can confirm that it still works as intended.

[Łukasz Zemczak (sil2100)]

The verification of the Stable Release Update for libpam-mount has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libpam-mount - 2.16-5ubuntu0.1

---------------
libpam-mount (2.16-5ubuntu0.1) cosmic; urgency=medium

  * d/p/0015-Use-crypt_get_type-to-get-type-and-support-CRYPT_LUK.patch:
    allow more than just LUKS1 by detecting the type (LP: #1804408)
  * d/tests/control, d/tests/local-luks: add autopkgtest for luks1/luks2
    automount on user login. (LP: #1679327)

 -- Christian Ehrhardt <email address hidden> Wed, 06 Feb 2019 09:56:49 +0100

[Łukasz Zemczak (sil2100)]

Hello bugproxy, or anyone else affected,

Accepted libpam-mount into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libpam-mount/2.16-3ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Christian Ehrhardt  (paelzer)]

Test executed fine on the SRU from proposed:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/libp/libpam-mount/20190225_143346_e53d2@/log.gz

The same for all architectures.
And since the test also covers LUKS1 and LUKS2 login mounts we already have this verified to work :-)

[Launchpad Janitor (janitor)]

This bug was fixed in the package libpam-mount - 2.16-3ubuntu0.1

---------------
libpam-mount (2.16-3ubuntu0.1) bionic; urgency=medium

  * d/p/0015-Use-crypt_get_type-to-get-type-and-support-CRYPT_LUK.patch:
    allow more than just LUKS1 by detecting the type (LP: #1804408)
  * d/tests/control, d/tests/local-luks: add autopkgtest for luks1/luks2
    automount on user login. (LP: #1679327)

 -- Christian Ehrhardt <email address hidden> Wed, 06 Feb 2019 10:02:48 +0100

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2019-03-05 02:34 EDT-------
IBM bugzilla status-> closed, Fix Released with Bionic,Cosmic and Disco