Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: clevis-udisks2 is not working. A log is present in the journal with the message "The /dev/tpmrm0 device must be readable and writable!" The password prompt appears instead of automatic unlock. Unlocking with clevis luks unlock works fine Version-Release number of selected component (if applicable): Fedora 31 (Workstation Edition) [intel@fedora-workstation-1 ~]$ rpm -qa clevis* clevis-luks-12-1.fc31.x86_64 clevis-udisks2-12-1.fc31.x86_64 clevis-12-1.fc31.x86_64 How reproducible: Having clevis-udisks2 Connect an encrypted flash drive with a clevis token to an usb port. Steps to Reproduce: 1. install clevis-udisks2 2. connect encrypted flash drive to usb port Actual results: Password prompt Expected results: Unlocked device automatically Additional info: [root@fedora-workstation-1 intel]# cryptsetup luksDump /dev/sdb1 LUKS header information Version: 2 Epoch: 5 Metadata area: 16384 [bytes] Keyslots area: 16744448 [bytes] UUID: 4a342074-e31b-4efc-b1e2-faa8ed9b5a73 Label: (no label) Subsystem: (no subsystem) Flags: (no flags) Data segments: 0: crypt offset: 16777216 [bytes] length: (whole device) cipher: aes-xts-plain64 sector: 512 [bytes] Keyslots: 0: luks2 Key: 512 bits Priority: normal Cipher: aes-xts-plain64 Cipher key: 512 bits PBKDF: argon2i Time cost: 7 Memory: 1048576 Threads: 4 Salt: 8f cb 6c 34 ac b6 ef 66 7c 6d 8b c4 da 48 45 69 f0 5c b3 41 2c 53 27 1e 83 57 b1 e0 23 6d a3 2f AF stripes: 4000 AF hash: sha256 Area offset:32768 [bytes] Area length:258048 [bytes] Digest ID: 0 1: luks2 Key: 512 bits Priority: normal Cipher: aes-xts-plain64 Cipher key: 512 bits PBKDF: argon2i Time cost: 7 Memory: 1048576 Threads: 4 Salt: c6 f7 32 81 fd 2a c6 8b d4 e0 24 e0 e1 c9 54 c9 fe 46 fd a4 95 38 f9 9e 75 77 59 be 1c 33 3b 8e AF stripes: 4000 AF hash: sha256 Area offset:290816 [bytes] Area length:258048 [bytes] Digest ID: 0 Tokens: 0: clevis Keyslot: 1 Digests: 0: pbkdf2 Hash: sha256 Iterations: 124356 Salt: d0 f2 78 1f c8 a4 bf bd 0d 92 72 60 e9 2c 27 bd 31 c5 a9 a2 85 b1 dc 16 d2 9d 77 99 b9 fb 79 2c Digest: b0 85 9c 3e a4 9a c6 f7 f8 37 90 21 d8 fe 9f 2a f0 e3 b4 17 7f 1d d9 a8 ff a1 0d 7a d2 fd 14 09 [root@fedora-workstation-1 intel]# journalctl --file /var/log/journal/e99f8bac4a96422ea7f66e72a738ed33/user-1000.journal | grep clevis Mar 04 10:31:32 fedora-workstation-1 systemd[1702]: Failed to attach 2092 to compat systemd cgroup /user.slice/user-1000.slice/user/gnome-launched-clevis-luks-udisks2.desktop-2092.scope: Permission denied Mar 04 10:32:22 fedora-workstation-1 clevis-luks-udisks2.desktop[2092]: /dev/sda1 TOKN 0 clevis Mar 04 10:32:22 fedora-workstation-1 clevis-luks-udisks2.desktop[2092]: /dev/sda1 META Success Mar 04 10:32:22 fedora-workstation-1 clevis-luks-udisks2.desktop[2092]: The /dev/tpmrm0 device must be readable and writable! Mar 04 10:32:22 fedora-workstation-1 clevis-luks-udisks2.desktop[2092]: /dev/sda1 RCVR Success (0) Mar 05 06:12:35 fedora-workstation-1 systemd[1702]: gnome-launched-clevis-luks-udisks2.desktop-2092.scope: Failed to kill control group /user.slice/user-1000.slice/user/gnome-launched-clevis-luks-udisks2.desktop-2092.scope, ignoring: Operation not permitted Mar 05 06:12:35 fedora-workstation-1 systemd[1702]: gnome-launched-clevis-luks-udisks2.desktop-2092.scope: Killing process 2092 (clevis-luks-udi) with signal SIGKILL. Mar 05 06:12:35 fedora-workstation-1 systemd[1702]: gnome-launched-clevis-luks-udisks2.desktop-2092.scope: Failed to kill control group /user.slice/user-1000.slice/user/gnome-launched-clevis-luks-udisks2.desktop-2092.scope, ignoring: Operation not permitted Mar 05 06:12:35 fedora-workstation-1 systemd[1702]: gnome-launched-clevis-luks-udisks2.desktop-2092.scope: Succeeded. Mar 05 12:54:19 fedora-workstation-1 systemd[17071]: Failed to attach 17527 to compat systemd cgroup /user.slice/user-1000.slice/user/gnome-launched-clevis-luks-udisks2.desktop-17527.scope: Permission denied Mar 05 16:50:27 fedora-workstation-1 clevis-luks-udisks2.desktop[17527]: /dev/sda1 TOKN 0 clevis Mar 05 16:50:27 fedora-workstation-1 clevis-luks-udisks2.desktop[17527]: /dev/sda1 META Success Mar 05 16:50:27 fedora-workstation-1 clevis-luks-udisks2.desktop[17527]: The /dev/tpmrm0 device must be readable and writable! Mar 05 16:50:27 fedora-workstation-1 clevis-luks-udisks2.desktop[17527]: /dev/sda1 RCVR Success (0)
The /dev/tpmrm0 has the default permission. Example for both Fedora Workstation 31 and IoT 31 below: [root@fedora-workstation-1 intel]# ls -la /dev/tpmrm0 crw-rw----. 1 tss tss 253, 65536 Mar 5 06:13 /dev/tpmrm0 [root@fedora-workstation-1 intel]# ls -la /dev/tpmrm0 crw-rw----. 1 tss tss 253, 65536 Mar 5 06:13 /dev/tpmrm0
Workaround: changing the permissions in the resource manager makes it work: [root@fedora-workstation-1 lvm-encryption]# chmod o+rw /dev/tpmrm0 [root@fedora-workstation-1 lvm-encryption]# ls -la /dev/tpmrm0 crw-rw-rw-. 1 tss tss 253, 65536 Mar 6 06:50 /dev/tpmrm0 [root@fedora-workstation-1 lvm-encryption]# journalctl --file /var/log/journal/e99f8bac4a96422ea7f66e72a738ed33/system.journal | grep clevis Mar 06 13:31:19 fedora-workstation-1 clevis-luks-udisks2.desktop[2981]: /dev/sda TOKN 0 clevis Mar 06 13:31:19 fedora-workstation-1 clevis-luks-udisks2.desktop[2981]: /dev/sda META Success Mar 06 13:31:19 fedora-workstation-1 clevis-luks-udisks2.desktop[2981]: /dev/sda RCVR Success (53) But I think those permissions changes are not good for the security point of view :)
> Workaround: changing the permissions in the resource manager makes it work: > [snip] What are the permissions of /usr/libexec/clevis-luks-udisks2?
[intel@fedora-workstation-1 ~]$ ls -la /usr/libexec/clevis-luks-udisks2 -rwsr-xr-x. 1 root root 28664 Jan 20 04:42 /usr/libexec/clevis-luks-udisks2
(In reply to nicolasoliver03 from comment #4) > [intel@fedora-workstation-1 ~]$ ls -la /usr/libexec/clevis-luks-udisks2 > -rwsr-xr-x. 1 root root 28664 Jan 20 04:42 /usr/libexec/clevis-luks-udisks2 I guess it works fine with tang, since it does not require any extra permissions? The issue here is that "clevis decrypt" will run with user/group clevis, and hence it will be unable to use /dev/tpmrm0, which is required when using the tpm2 pin.
Did not test with TANG. Added clevis to tss group: [intel@fedora-workstation-1 ~]$ sudo usermod -a -G tss clevis [intel@fedora-workstation-1 ~]$ groups clevis clevis : clevis tss Still get the same "The /dev/tpmrm0 device must be readable and writable!" issue, and password prompt is not dismissed. Could this be the same problem impacting in https://bugzilla.redhat.com/show_bug.cgi?id=1810332?
(In reply to Sergio Correia from comment #5) > (In reply to nicolasoliver03 from comment #4) > > [intel@fedora-workstation-1 ~]$ ls -la /usr/libexec/clevis-luks-udisks2 > > -rwsr-xr-x. 1 root root 28664 Jan 20 04:42 /usr/libexec/clevis-luks-udisks2 > > I guess it works fine with tang, since it does not require any extra > permissions? > > The issue here is that "clevis decrypt" will run with user/group clevis, and > hence it will be unable to use /dev/tpmrm0, which is required when using the > tpm2 pin. But that's not the case, since the /usr/libexec/clevis-luks-udisks2 binary has the SETUID bit set. So it should be executed as root and be able to read the TPM device...
(In reply to Javier Martinez Canillas from comment #7) > (In reply to Sergio Correia from comment #5) > > (In reply to nicolasoliver03 from comment #4) > > > [intel@fedora-workstation-1 ~]$ ls -la /usr/libexec/clevis-luks-udisks2 > > > -rwsr-xr-x. 1 root root 28664 Jan 20 04:42 /usr/libexec/clevis-luks-udisks2 > > > > I guess it works fine with tang, since it does not require any extra > > permissions? > > > > The issue here is that "clevis decrypt" will run with user/group clevis, and > > hence it will be unable to use /dev/tpmrm0, which is required when using the > > tpm2 pin. > > But that's not the case, since the /usr/libexec/clevis-luks-udisks2 binary > has the SETUID bit set. So it should be executed as root and be able to read > the TPM device... Yeah, but at some point we fork+exec to run clevis decrypt, and before that, we change the user and group: https://github.com/latchset/clevis/blob/master/src/luks/udisks2/clevis-luks-udisks2.c#L481
(In reply to nicolasoliver03 from comment #6) > Did not test with TANG. > > Added clevis to tss group: > > [intel@fedora-workstation-1 ~]$ sudo usermod -a -G tss clevis > [intel@fedora-workstation-1 ~]$ groups clevis > clevis : clevis tss > > Still get the same "The /dev/tpmrm0 device must be readable and writable!" > issue, and password prompt is not dismissed. While we set the uid and gid for the clevis user and group, it seems the process trying to use the tpm does not have the groups properly set, which causes this issue. Could you please try this scratch build and see if it helps? https://koji.fedoraproject.org/koji/taskinfo?taskID=42388116 > Could this be the same problem impacting in > https://bugzilla.redhat.com/show_bug.cgi?id=1810332? No, that's a different issue.
[intel@fedora-workstation-1 clevis-scratch]$ sudo bash install.sh Last metadata expiration check: 1:39:21 ago on Wed 11 Mar 2020 06:49:41 AM PDT. Dependencies resolved. ====================================================================================================================================================== Package Architecture Version Repository Size ====================================================================================================================================================== Upgrading: clevis x86_64 12-1.fc31.scorreia.bz1810836 @commandline 54 k clevis-luks x86_64 12-1.fc31.scorreia.bz1810836 @commandline 18 k clevis-udisks2 x86_64 12-1.fc31.scorreia.bz1810836 @commandline 19 k Transaction Summary ====================================================================================================================================================== Upgrade 3 Packages Total size: 91 k Is this ok [y/N]: y Downloading Packages: Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Running scriptlet: clevis-12-1.fc31.scorreia.bz1810836.x86_64 1/6 Upgrading : clevis-12-1.fc31.scorreia.bz1810836.x86_64 1/6 Upgrading : clevis-luks-12-1.fc31.scorreia.bz1810836.x86_64 2/6 Upgrading : clevis-udisks2-12-1.fc31.scorreia.bz1810836.x86_64 3/6 Cleanup : clevis-udisks2-12-1.fc31.x86_64 4/6 Cleanup : clevis-luks-12-1.fc31.x86_64 5/6 Cleanup : clevis-12-1.fc31.x86_64 6/6 Running scriptlet: clevis-12-1.fc31.x86_64 6/6 Verifying : clevis-12-1.fc31.scorreia.bz1810836.x86_64 1/6 Verifying : clevis-12-1.fc31.x86_64 2/6 Verifying : clevis-luks-12-1.fc31.scorreia.bz1810836.x86_64 3/6 Verifying : clevis-luks-12-1.fc31.x86_64 4/6 Verifying : clevis-udisks2-12-1.fc31.scorreia.bz1810836.x86_64 5/6 Verifying : clevis-udisks2-12-1.fc31.x86_64 6/6 Upgraded: clevis-12-1.fc31.scorreia.bz1810836.x86_64 clevis-luks-12-1.fc31.scorreia.bz1810836.x86_64 clevis-udisks2-12-1.fc31.scorreia.bz1810836.x86_64 Complete! It works now! Password prompt appears and get dismissed, then I get another prompt for authorization to create the mapper (only once, get the auth cached after that apparently). Which was the fix? :)
(In reply to nicolasoliver03 from comment #11) [snip] > > It works now! Password prompt appears and get dismissed, then I get another > prompt for authorization to create the mapper (only once, get the auth > cached after that apparently). Thanks for testing. I will keep investigating this one. I will be testing older releases to check their behavior regarding this authorization prompt. > > Which was the fix? :) Besides adding the user clevis to the tss group, I added a call to initgroups() before changing the uid/gid of the process doing the key recovery, so it has the groups mapped correctly.
PR: https://github.com/latchset/clevis/pull/208
FEDORA-2020-b35219394f has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-b35219394f
FEDORA-2020-d42f4e90f9 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-d42f4e90f9
FEDORA-2020-d42f4e90f9 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-d42f4e90f9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d42f4e90f9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-b35219394f has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-b35219394f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-b35219394f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-d42f4e90f9 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-b35219394f has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.