Security Implication of getting key / passphrase for LUKS in plaintext as root user

[Markus-]

Before digging deeper in Tang / Clevis I played around and started to think about the following.

If I use plain LUKS without Tang / Clevis I have my key / passphrase bound to a slot and I am not able to get it out in plaintext. The root-User can use cryptsetup to get the master-key of an open Container and put a new key / passphrase onto it (cryptsetup luksAddKey /dev/vdb1 --master-key-file <(dmsetup table --showkey /dev/mapper/luks-ec013cf7-ad72-4dcf-8a1e-0548016a3e2c | awk '{print$5}' | xxd -r -p)) - based on: https://access.redhat.com/solutions/1543373

If I use Tang / Clevis the user can get access to the keys / passphrases issued by clevis-luks-bind in plaintext by using luksmeta load -d <DEVICE> -s <SLOT> > JWE clevis decrypt < JWE

I now this is "works as designed" but I try to understand the risk analysis behind this.

Between the two described usecases there are some differences - the result can be the same - a known key to the container which can be used to get access without being in the network.

Regards Markus

[mtottenh]

If I use Tang / Clevis the user can get access to the keys / passphrases issued by clevis-luks-bind in plaintext by using luksmeta load -d -s > JWE

I'm pretty sure this would require root access anyway (loading luksmeta slots requires opening the underlying device directly which should be restricted to root). So I don't think there is any change in the threat model.