Bug 2271330 - SELinux is preventing usbguard-daemon from 'read' accesses on the directory userdb.
Summary: SELinux is preventing usbguard-daemon from 'read' accesses on the directory u...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: usbguard
Version: 40
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Attila Lakatos
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:22d2b2b715a6668a6a70da439c6...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-03-24 21:52 UTC by Dominik 'Rathann' Mierzejewski
Modified: 2024-07-18 04:16 UTC (History)
6 users (show)

Fixed In Version: usbguard-1.1.3-1.fc41 usbguard-1.1.3-1.fc40
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-07-18 04:16:41 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
File: os_info (756 bytes, text/plain)
2024-03-24 21:52 UTC, Dominik 'Rathann' Mierzejewski
no flags Details
File: description (1.96 KB, text/plain)
2024-03-24 21:52 UTC, Dominik 'Rathann' Mierzejewski
no flags Details

Description Dominik 'Rathann' Mierzejewski 2024-03-24 21:52:48 UTC
Description of problem:
SELinux is preventing usbguard-daemon from 'read' accesses on the directory userdb.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that usbguard-daemon should be allowed read access on the userdb directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'usbguard-daemon' --raw | audit2allow -M my-usbguarddaemon
# semodule -X 300 -i my-usbguarddaemon.pp

Additional Information:
Source Context                system_u:system_r:usbguard_t:s0
Target Context                system_u:object_r:systemd_userdbd_runtime_t:s0
Target Objects                userdb [ dir ]
Source                        usbguard-daemon
Source Path                   usbguard-daemon
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-40.13-1.fc40.noarch
Local Policy RPM              usbguard-selinux-1.1.2-2.fc40.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 6.8.0-0.rc6.49.fc40.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Mon Feb 26 18:38:52 UTC 2024
                              x86_64
Alert Count                   6
First Seen                    2024-03-13 18:29:36 CET
Last Seen                     2024-03-13 18:29:46 CET
Local ID                      f0d1c6a0-5476-4dc2-8e6a-79f90802ee29

Raw Audit Messages
type=AVC msg=audit(1710350986.845:426): avc:  denied  { read } for  pid=1238 comm="usbguard-daemon" name="userdb" dev="tmpfs" ino=47 scontext=system_u:system_r:usbguard_t:s0 tcontext=system_u:object_r:systemd_userdbd_runtime_t:s0 tclass=dir permissive=0


Hash: usbguard-daemon,usbguard_t,systemd_userdbd_runtime_t,dir,read

Version-Release number of selected component:
selinux-policy-targeted-40.13-1.fc40.noarch

Additional info:
reporter:       libreport-2.17.15
reason:         SELinux is preventing usbguard-daemon from 'read' accesses on the directory userdb.
package:        selinux-policy-targeted-40.13-1.fc40.noarch
kernel:         6.8.1-300.fc40.x86_64
hashmarkername: setroubleshoot
component:      usbguard
type:           libreport
component:      usbguard

Comment 1 Dominik 'Rathann' Mierzejewski 2024-03-24 21:52:50 UTC
Created attachment 2023435 [details]
File: os_info

Comment 2 Dominik 'Rathann' Mierzejewski 2024-03-24 21:52:52 UTC
Created attachment 2023436 [details]
File: description

Comment 3 Christian Stadelmann 2024-04-12 13:48:57 UTC
Same here. This happens in a GNOME desktop with usbguard-notifier and usbguard daemon running. I did not interact with USBGuard in any way, i.e., the issue happened at login.

Comment 4 Fedora Update System 2024-06-10 08:38:20 UTC
FEDORA-2024-eef6346806 (usbguard-1.1.3-1.fc41) has been submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-eef6346806

Comment 5 Fedora Update System 2024-06-10 13:50:23 UTC
FEDORA-2024-eef6346806 (usbguard-1.1.3-1.fc41) has been pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 6 Dennis Schridde 2024-06-18 08:29:11 UTC
On boot I regularly get the message that usbguard was denied access to "userdb". This often (always? sometimes?) appears when a device of mine is rejected (cf. https://github.com/USBGuard/usbguard/issues/623#issue-2285029167 for details on that problem).


reason:         SELinux is preventing usbguard-daemon from 'read' accesses on the directory userdb.
package:        selinux-policy-targeted-40.22-1.fc40.noarch
hashmarkername: setroubleshoot
type:           libreport
kernel:         6.9.4-200.fc40.x86_64
comment:        On boot I regularly get the message that usbguard was denied access to "userdb". This often (always? sometimes?) appears when a device of mine is rejected (cf. https://github.com/USBGuard/usbguard/issues/623#issue-2285029167 for details on that problem).

Comment 7 Dennis Schridde 2024-06-18 08:35:55 UTC
(In reply to Dennis Schridde from comment #6)
> reason:         SELinux is preventing usbguard-daemon from 'read' accesses
> on the directory userdb.
> package:        selinux-policy-targeted-40.22-1.fc40.noarch
> hashmarkername: setroubleshoot
> type:           libreport
> kernel:         6.9.4-200.fc40.x86_64
> comment:        On boot I regularly get the message that usbguard was denied
> access to "userdb". This often (always? sometimes?) appears when a device of
> mine is rejected (cf.
> https://github.com/USBGuard/usbguard/issues/623#issue-2285029167 for details
> on that problem).

❯ dnf info usbguard
Last metadata expiration check: 0:00:31 ago on Di 18 Jun 2024 10:34:33 CEST.
Installed Packages
Name         : usbguard
Version      : 1.1.2
Release      : 2.fc40
Architecture : x86_64
Size         : 1.3 M
Source       : usbguard-1.1.2-2.fc40.src.rpm
Repository   : @System
From repo    : fedora
Summary      : A tool for implementing USB device usage policy
URL          : https://usbguard.github.io/
License      : GPL-2.0-or-later
Description  : The USBGuard software framework helps to protect your computer against rogue USB
             : devices by implementing basic whitelisting/blacklisting capabilities based on
             : USB device attributes.

Comment 8 Dominik 'Rathann' Mierzejewski 2024-07-08 10:58:54 UTC
Connected the machine to a USB hub with keyboard, mouse and webcam hooked up.


reason:         SELinux is preventing usbguard-daemon from 'read' accesses on the directory userdb.
package:        selinux-policy-targeted-40.23-1.fc40.noarch
kernel:         6.9.7-200.fc40.x86_64
hashmarkername: setroubleshoot
comment:        Connected the machine to a USB hub with keyboard, mouse and webcam hooked up.
type:           libreport

Comment 9 Dominik 'Rathann' Mierzejewski 2024-07-08 11:05:40 UTC
This is not fixed in F40, please back port to F40.

Comment 10 Fedora Update System 2024-07-12 06:06:50 UTC
FEDORA-2024-e939d3474b (usbguard-1.1.3-1.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-e939d3474b

Comment 11 Attila Lakatos 2024-07-12 06:08:01 UTC
Yeah the rebase was planned for rawhide and it was not backported to f40. I backported the appropriate patches. thanks.

Comment 12 Dominik 'Rathann' Mierzejewski 2024-07-16 10:20:32 UTC
(In reply to Attila Lakatos from comment #11)
> Yeah the rebase was planned for rawhide and it was not backported to f40. I
> backported the appropriate patches. thanks.

Excellent, thank you!

Comment 13 Fedora Update System 2024-07-18 04:16:41 UTC
FEDORA-2024-e939d3474b (usbguard-1.1.3-1.fc40) has been pushed to the Fedora 40 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.