[pkg-cryptsetup-devel] Bug#939357: cryptsetup-run: invoking "sudo cryptdisks_start" with "decrypt_keyctl" in crypttab fails
Sebastian Mohr
sebi at debian.sebi.name
Tue Sep 3 23:18:57 BST 2019
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
More information about the pkg-cryptsetup-devel
mailing list