[pkg-cryptsetup-devel] Bug#939357: cryptsetup-run: invoking "sudo cryptdisks_start" with "decrypt_keyctl" in crypttab fails

[Sebastian Mohr]

Package: cryptsetup-run
Version: 2:2.1.0-5
Severity: normal
File: /lib/cryptsetup/scripts/decrypt_keyctl

Dear Maintainer,

when configuring this encrypted machine running debian stable with keyscript
"decryt_keyctl", the invocation of "cryptdisks_start data{0,1}_crypt" when
logged in via ssh as normal user and "sudo -i" to root fails with the message:

| [....] Starting crypto disk...data0_crypt (starting)...Caching passphrase for data0_crypt:  *********************
| keyctl_set_timeout: Permission denied
| Error setting timeout on key (824927206), removing
| Nothing to read on input.
| Caching passphrase for data0_crypt:

After some searching, I found a link to bug #758788, especially message #45 and #50 [1], which
described seemingly the same bug:

| > On the first invocation (for cont1_crypt), I got this dialog:
| >
| > root at marislae:~# cryptdisks_start cont1_crypt
| > [[....] Starting crypto disk...[info] cont1_crypt (starting)...
| > Caching passphrase for /cont1:  ******
| > keyctl_set_timeout: Permission denied
| > Error setting timeout on key (2524288), removing
| > Caching passphrase for /cont1:  ******
| > keyctl_set_timeout: Permission denied
| > Error setting timeout on key (612589418), removing
| >
| > [Here I pressed <ctrl-C> to stop the attempts]
| >
| > Caching passphrase  for /cont1:  Erreur de lecture de la phrase secrète.
| >
| >
| > I was running the commands from root. I initially logged in to the
| > computer from SSH to a regular user, than did "sudo -i" to get root
| > access if this matters. As I suspected this may be a problem, I allowed
| > root direct SSH access and tried again, login directly to root account,
| > this time it worked:
|
| Interesting, never saw these kind of problems before. I'm testing on a
| Laptop with Ubuntu 14.04 installed and use 'sudo -i' a lot. Indeed I
| used it for testing the commands above as well. For me it worked. But
| let's keep that aside. It's another issue and out of scope for this
| bugreport ;)

But I haven't found another link to that aspect of that bug; the mentioned
bug was closed without looking at that facette further.

Another link I stumbled upon was one of Matthew Gerret describing a workaround
with the kernel keyring and sudo [2].

I adapted a copy of decrypt_keyctl to his suggestions and afterwards I could
decrypt the multiple cryptdisks. Here is the patch:

--- 8< --- 8< --- 8< ---

--- decrypt_keyctl      2019-06-10 14:51:15.000000000 +0200
+++ decrypt_keyctl_debug        2019-09-03 23:33:51.311240116 +0200
@@ -43,8 +43,13 @@
          keyctl unlink "$KID_" @u
          KID_=""
      fi
-    KID_="$(printf "%s" "$KEY_" | keyctl padd user "$ID_" @u)"
+    KID_="$(printf "%s" "$KEY_" | keyctl padd user "$ID_" @s)"
      [ -n "$KID_" ] || die "Error adding passphrase to kernel keyring"
+    if ! ( keyctl setperm "$KID_" 0x3f3f0000 && keyctl link "$KID_" @u && keyctl unlink "$KID_" @s ); then
+        keyctl unlink "$KID_" @u
+        keyctl unlink "$KID_" @s
+        die "Error transferring permissions on key ($KID_), removing"
+    fi
      if ! keyctl timeout "$KID_" "$TIMEOUT_"; then
          keyctl unlink "$KID_" @u
          die "Error setting timeout on key ($KID_), removing"

--- 8< --- 8< --- 8< ---

I don't know whether there are further security implications or something like that,
nor did I do extensive testing. The error handling was also added in a quick way
without testing it further (I also don't know how to provoke that error). I just
wanted to let you know that and how I fixed a problem not only I had.


Regards

Sebastian

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758788#50
[2]: https://mjg59.dreamwidth.org/37333.html