Bug 1810836 - clevis-udisks2 not working: The /dev/tpmrm0 device must be readable and writable!
Summary: clevis-udisks2 not working: The /dev/tpmrm0 device must be readable and writa...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: clevis
Version: 31
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Sergio Correia
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-03-06 01:12 UTC by nicolasoliver03
Modified: 2020-09-25 16:40 UTC (History)
5 users (show)

Fixed In Version: clevis-14-1.fc32
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-07 17:13:52 UTC
Type: Bug


Attachments (Terms of Use)

Description nicolasoliver03 2020-03-06 01:12:30 UTC
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@1000.service/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@1000.service/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@1000.service/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@1000.service/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)

Comment 1 nicolasoliver03 2020-03-06 01:20:07 UTC
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

Comment 2 nicolasoliver03 2020-03-06 21:39:14 UTC
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 :)

Comment 3 Sergio Correia 2020-03-06 23:20:39 UTC
> Workaround: changing the permissions in the resource manager makes it work:
> 

[snip]

What are the permissions of /usr/libexec/clevis-luks-udisks2?

Comment 4 nicolasoliver03 2020-03-07 01:03:01 UTC
[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

Comment 5 Sergio Correia 2020-03-09 13:35:30 UTC
(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.

Comment 6 nicolasoliver03 2020-03-09 16:48:30 UTC
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?

Comment 7 Javier Martinez Canillas 2020-03-10 17:30:08 UTC
(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...

Comment 8 Sergio Correia 2020-03-10 17:36:25 UTC
(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

Comment 9 Sergio Correia 2020-03-10 22:19:19 UTC
(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.

Comment 10 nicolasoliver03 2020-03-11 15:42:03 UTC
[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? :)

Comment 11 nicolasoliver03 2020-03-11 15:43:47 UTC
[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? :)

Comment 12 Sergio Correia 2020-03-11 18:11:49 UTC
(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.

Comment 13 Sergio Correia 2020-06-22 04:46:03 UTC
PR: https://github.com/latchset/clevis/pull/208

Comment 14 Fedora Update System 2020-08-31 12:39:54 UTC
FEDORA-2020-b35219394f has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-b35219394f

Comment 15 Fedora Update System 2020-08-31 13:18:38 UTC
FEDORA-2020-d42f4e90f9 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-d42f4e90f9

Comment 16 Fedora Update System 2020-08-31 15:55:55 UTC
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.

Comment 17 Fedora Update System 2020-08-31 18:58:07 UTC
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.

Comment 18 Fedora Update System 2020-09-07 17:13:52 UTC
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.

Comment 19 Fedora Update System 2020-09-25 16:40:19 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.