[pkg-cryptsetup-devel] Bug#758788: Bug#758788: cryptsetup: Passphrase caching broken in decrypt_keyctl

Fri Oct 10 08:29:33 UTC 2014

Hi Jonas,

Le 09/10/2014 10:39, Jonas Meurer a écrit :
> Hey Luc,
> 
> Am 09.10.2014 um 09:54 schrieb luc:
>>> Am 03.10.2014 um 21:55 schrieb Jonas Meurer:
>>> Did you find time to do the additional testing/debugging yet? I'd like
>>> to fix this bug in time for Debian Jessie, provided that it's really a
>>> bug in the package and not an issue on your side ;)
>>
>> Not yet, but I intend to do so.
>> The problem occurs on a computer with some critical information on it,
>> and the partitions already use the full disk space. This implies I have
>> to do
>> some careful work of shrinking filesystems, logical volumes and so on
>> before I can
>> set up a test partition aside.
> 
> I see. But you don't need to resize your filesystems or go through
> similar hassle. Simply use file containers for testing. The following
> commands should setup a testing environment (use carefully, even though
> I tested them):
> 
> # dd if=/dev/urandom of=/cont1 bs=1M count=3
> # dd if=/dev/urandom of=/cont2 bs=1M count=3
> # echo "testpw" | cryptsetup luksFormat /cont1
> # echo "testpw" | cryptsetup luksFormat /cont2
> # echo "cont1_crypt /cont1 pw1 luks,keyscript=decrypt_keyctl" \
> 	>> /etc/crypttab
> # echo "cont2_crypt /cont1 pw1 luks,keyscript=decrypt_keyctl" \
> 	>> /etc/crypttab
> # cryptdisks_start cont1_crypt
> # cryptdisks_start cont2_crypt

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:

root at marislae:~# cryptdisks_start cont1_crypt
[....] Starting crypto disk...[info] cont1_crypt (starting)...
Caching passphrase for /cont1:  ******
[ ok _crypt (started)...done.
root at marislae:~# cryptdisks_start cont2_crypt
[....] Starting crypto disk...[info] cont2_crypt (starting)...
Using cached passphrase for /cont2.
[ ok _crypt (started)...done.
root at marislae:~#

The /dev/mapper/cont1_crypt and /dev/mapper/cont2_crypt did appear
correctly.

Is there a way I could check the keyring just after boot, before it is
cleared? I could probably set an independent init script to run after
disks are mounted to dump the list of the keys in the keyring to some
file in /tmp so I can retrieve them once the system is up and debug. I
thing I could do this using some keyctl command, but don't know which
one to use for a given entry in /etc/crypttab. Should it be simply
"keyctl list pw1" in the case of your example or something else? I saw
in the decrypt_keyctl script some cryptkey-$1 identifier (probably used
with an _ appended). How could I use this?

best regards

Luc

> 
>>> As already mentioned - up to now I'm unable to reproduce the bug. For
>>> me, decrypt_keyctl works in all tested setups. The provided passphrase
>>> is stored in kernel keyring with first invokation and used for all the
>>> following device unlockings that have the same keyscript/keyname
>>> configured.
>>
>> I understand your point. It is difficult to debug here (as mentioned
>> earlier putting
>> some echo commands completely trashed the boot sequence). I'll do my best.
> 
> I'm sorry that I brought you in troubles here. The echo command was
> untested and I at least should have written that. It was meant for
> debugging purposes only but it completely broke the keyscript. I'll try
> to not make such premature requests again :-/
> 
> Cheers,
>  jonas
> 
>>>> I test the decrypt_keyctl script with the following setup, and it works
>>>> as expected. Maybe you could try a similar setup:
>>>>
>>>> - create two small lvm logical volumes (5MB are more than enough)
>>>> - luksformat both logical volumes
>>>> - add them to your crypttab:
>>>>
>>>> clv1_crypt /dev/<VG>/<LV1> testkey1 luks,keyscript=decrypt_keyctl
>>>> clv2_crypt /dev/<VG>/<LV2> testkey1 luks,keyscript=decrypt_keyctl
>>>>
>>>> - try unlocking them via cryptdisks_start:
>>>>
>>>> # cryptdisks_start clv1_crypt
>>>> # cryptdisks_start clv2_crypt
>>>>
>>>> The second unlocking should use the key cached during first unlocking.
>>>>
>>>> It would be awesome if you could test this. I as well tested this setup
>>>> during boot process, and it works as expected as well. Also tested with
>>>> UUID instead of source device path in crypttab, same result.
>>>>
>>>> I've no glue what's different on your setups, and any help with
>>>> debugging would be highly appreciated.
>>>>
>>>>>> In case that you still encounter the bug, please paste your full
>>>>>> /etc/fstab and /etc/crypttab again.
>>>>>
>>>>> /etc/crypttab:
>>>>>
>>>>> sdb1_crypt UUID=9aa983b5-0224-406b-a177-7481162c6172
>>>>> sda5_sdb1_common_key luks,keyscript=decrypt_keyctl
>>>>> sda5_crypt UUID=3764df68-de26-4a24-a7dc-1498cb6b20ab
>>>>> sda5_sdb1_common_key luks,keyscript=decrypt_keyctl
>>>>
>>>> Nothing suspicious here, looks ok to me.
>>>>
>>>>> Note that the two partitions contain physical volumes for LVM, as shown
>>>>> here:
>>>>
>>>> Actually the content of your encrypted devices should not matter at all.
>>>>
>>>> Kind regards,
>>>>  jonas
>>>>
>>>> _______________________________________________
>>>> pkg-cryptsetup-devel mailing list
>>>> pkg-cryptsetup-devel at lists.alioth.debian.org
>>>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cryptsetup-devel
>>>>
>>>>
>>
>> _______________________________________________
>> pkg-cryptsetup-devel mailing list
>> pkg-cryptsetup-devel at lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cryptsetup-devel
> 