Bug 1862173

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Reopening since we are looking to address this issue

Hi Ondrej,
The CLI format we're expecting is something along the lines of:

cryptsetup luksOpen --key-desc=[KEY_DESC_TO_UNLOCK] [DEVICE] [NAME]
cryptsetup luksAddKey --key-desc=[KEY_DESC_TO_UNLOCK] [DEVICE]

Hi Lukas,
The justification for this change is that we are currently required to copy the passphrase from the kernel keyring into a temporary file. This temporary file is held only in memory and is locked to ensure it will never be written to swap space. The file is kept in a mount namespace to prevent regular users from being able to see it. The file permissions also prevent anyone but root from accessing. However, we would be able to remove all of this code from Stratis if we were able to provide a key description instead and have Clevis read the passphrase directly from the kernel keyring instead of requiring a keyfile. This would significantly reduce risk of leaking secrets by consolidating them to the kernel keyring and never requiring them to be stored outside of it.

Do either of you have any additional questions about what we need or why we need it?

(In reply to John Baublitz from comment #10)
> Hi Ondrej,
> The CLI format we're expecting is something along the lines of:
> 
> cryptsetup luksOpen --key-desc=[KEY_DESC_TO_UNLOCK] [DEVICE] [NAME]

This should work out-of-the box since cryptsetup 2.0 with luks2-keyring token/plugin. Could you provide me with
"cryptsetup luksDump --debug-json [DEVICE]"?

(I guess you're not using luks2-keyring token/plugin I suppose, but I should be able to add this functionality for device activation anyway)

We actually are using the luks2-keyring token so does this mean that this is only work that Clevis needs to do?

Ok, thanks for confirmation.

Just, FYI this is how the luks2-keyring activation should work:

1) cryptsetup token add --key-description my_key [DEVICE]
2) upload valid passphrase in key described 'my_key' (user type, user keyring)
3) cryptsetup open [DEVICE] [NAME]

Step 3) activates device without prompt for passphrase input.

Not sure about clevis and what would be needed on their side or what is eventually missing.

cryptsetup-2.4.3-4.el9.x86_64
5.14.0-85.el9.x86_64
#echo -n AxKfOehjcn | keyctl padd user mykey @u
# echo redhat redhat | cryptsetup  -q --type 'luks2'  luksFormat /dev/sdc
# cryptsetup  token add --key-description mykey    /dev/sdc
# cryptsetup open /dev/sdc pQWY
Enter passphrase for /dev/sdc:

HI,

Please check the #18 test steps if coverd the bug?

The basic idea is that unlocking a cryptsetup volume does indeed work using tokens specifying a key description. This causes the device to unlock without prompting the user for a passphrase when invoking cryptsetup luksOpen. The problem here is that cryptsetup luksAddKey does not have this same functionality. cryptsetup luksAddKey requires an existing passphrase to modify the key slots and a new passphrase to add to an open key slot. Our long term goal is to add this feature so that Clevis can invoke cryptsetup luksAddKey and use a key description to fetch the existing password for modification access from the kernel keyring. Currently, cryptsetup luksAddKey only supports a keyfile and stdin for password input as far as I can tell. Adding a key description option for password input would provide us with the ability to remove a rather lengthy workaround to expose passphrases from the kernel keyring securely as a file so that cryptsetup can consume them. Ondrej, I have no strong preference for whether you'd like to take advantage of tokens to accomplish this or whether you'd rather provide a command line parameter to specify the key description. I think we can make either work.

Ondrej and Sergio, we had already discussed this over email, but I just want to make sure that the bugzilla has the appropriate information because my original request was a little too vague for those following along.

Thanks!

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Hi,

cryptsetup-2.4.3-5.el9.x86_64

[root@hp-dl380g10-06 ~]# cryptsetup  token add --key-description mykey    /dev/loop0
[root@hp-dl380g10-06 ~]#  cryptsetup open /dev/loop0 pQWY
[root@hp-dl380g10-06 ~]# lsblk
NAME                           MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
loop0                            7:0    0   100M  0 loop  
└─pQWY                         253:3    0    84M  0 crypt 
sda                              8:0    0 558.9G  0 disk  
├─sda1                           8:1    0     1G  0 part  /boot
└─sda2                           8:2    0 557.9G  0 part  
  ├─rhel_hp--dl380g10--06-root 253:0    0    70G  0 lvm   /
  ├─rhel_hp--dl380g10--06-swap 253:1    0  31.3G  0 lvm   [SWAP]
  └─rhel_hp--dl380g10--06-home 253:2    0 456.5G  0 lvm   /home
sdb                              8:16   1     0B  0 disk  
[root@hp-dl380g10-06 ~]# cryptsetup luksAddKey /dev/loop0 --token-only txt   <<< still need input exist password 
Enter any existing passphrase: 


cryptsetup-2.6.0-1.el9.x86_64

[root@intel-chiefriver-02 home]# cryptsetup luksAddKey /dev/loop0 --token-only  << no need exist password, 
Enter new passphrase for key slot: 
Verify passphrase: 
[root@intel-chiefriver-02 home]# 
[root@intel-chiefriver-02 home]# cryptsetup luksAddKey /dev/loop0 --token-only   txt
[root@intel-chiefriver-02 home]# 


Is it expected for the bug ?

This command cwith ryptsetup-2.6.0-1.el9

> cryptsetup luksAddKey /dev/loop0 --token-only   txt

will unlock existing keyslot by any token eligible and add a new keyslot protected by passphrase in 'txt' file. It seems to be working as expected.

> cryptsetup luksAddKey /dev/loop0 --token-only

This also unlocks existing keyslot by any token eligible but it will ask for passphrase in interactive prompt. If you want to add a new keyslot protected by a token, you have to specify the token with specific token id (--token-id parameter).

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (cryptsetup bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2534