Bug 1949948 - SELinux is preventing gdb from 'read' accesses on the file /var/cache/fwupd/metainfo.xmlb.
Summary: SELinux is preventing gdb from 'read' accesses on the file /var/cache/fwupd/m...
Keywords:
Status: CLOSED DUPLICATE of bug 1896648
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 34
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:2b6922f10a6774eccf5b7cf3345...
: 1950706 2024596 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-04-15 13:13 UTC by CharlieI
Modified: 2021-12-09 15:29 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2021-12-09 15:29:11 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
System journal output showing fwupd crash (16.05 KB, text/plain)
2021-04-23 10:56 UTC, Alex Finkel
no flags Details

Description CharlieI 2021-04-15 13:13:15 UTC
Description of problem:
Occurred at boot, updated yesterday pm .
SELinux is preventing gdb from 'read' accesses on the file /var/cache/fwupd/metainfo.xmlb.

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

If you believe that gdb should be allowed read access on the metainfo.xmlb file 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 'gdb' --raw | audit2allow -M my-gdb
# semodule -X 300 -i my-gdb.pp

Additional Information:
Source Context                system_u:system_r:abrt_t:s0-s0:c0.c1023
Target Context                system_u:object_r:fwupd_cache_t:s0
Target Objects                /var/cache/fwupd/metainfo.xmlb [ file ]
Source                        gdb
Source Path                   gdb
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-34.3-1.fc34.noarch
Local Policy RPM              selinux-policy-targeted-34.3-1.fc34.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 5.11.13-300.fc34.x86_64 #1 SMP Sun
                              Apr 11 15:07:42 UTC 2021 x86_64 x86_64
Alert Count                   3
First Seen                    2021-04-15 14:10:03 BST
Last Seen                     2021-04-15 14:10:03 BST
Local ID                      6dbb5d64-5018-41e0-974c-20068f50a068

Raw Audit Messages
type=AVC msg=audit(1618492203.742:917): avc:  denied  { read } for  pid=2716 comm="gdb" name="metainfo.xmlb" dev="sda2" ino=2030433 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fwupd_cache_t:s0 tclass=file permissive=0


Hash: gdb,abrt_t,fwupd_cache_t,file,read

Version-Release number of selected component:
selinux-policy-targeted-34.3-1.fc34.noarch

Additional info:
component:      selinux-policy
reporter:       libreport-2.14.0
hashmarkername: setroubleshoot
kernel:         5.11.13-300.fc34.x86_64
type:           libreport

Comment 1 CharlieI 2021-04-16 07:45:43 UTC
Similar problem has been detected:

Happened at boot.

hashmarkername: setroubleshoot
kernel:         5.11.13-300.fc34.x86_64
package:        selinux-policy-targeted-34.3-1.fc34.noarch
reason:         SELinux is preventing gdb from 'read' accesses on the file /var/cache/fwupd/metainfo.xmlb.
type:           libreport

Comment 2 Ian Laurie 2021-04-18 02:48:58 UTC
Similar problem has been detected:

Boot Fedora 34 WS and log in.

hashmarkername: setroubleshoot
kernel:         5.11.14-300.fc34.x86_64
package:        selinux-policy-targeted-34.3-1.fc34.noarch
reason:         SELinux is preventing gdb from 'read' accesses on the file /var/cache/fwupd/quirks.xmlb.
type:           libreport

Comment 3 Zdenek Pytela 2021-04-19 17:16:35 UTC
*** Bug 1950706 has been marked as a duplicate of this bug. ***

Comment 4 Colin Barker 2021-04-22 23:44:08 UTC
looking at journalctl --boot=-0 
the gdb errors seem to be related to firmware update daemon 1.5.9-1.fc33 crash in g_propogate_error () in fu_bluez_backend_connect_cb (fwupd + 0x3bd64) just prior:

is a separate bug report for fwupd required?


extracts follow:
systemd-coredump[162711]: Process 162493 (fwupd) of user 0 dumped core
...
<stack trace snipped>
...
systemd[1]: systemd-coredump: Succeeded.
audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@2-162710-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=fwupd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
systemd[1]: fwupd.service: Main process exited, code=dumped, status=11/SEGV
systemd[1]: fwupd.service: Failed with result 'core-dump'
...
abrt-dump-journal-oops[1015]: abrt-dump-journal-oops: Found oopses: 1
abrt-dump-journal-oops[1015]: abrt-dump-journal-oops: Creating problem directories
audit[162742]: AVC avc:  denied  { read } for  pid=162742 comm="gdb" name="quirks.xmlb" dev="dm-3" ino=1086 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fwupd_cache_t:s0 tclass=file permissive=0
audit[162742]: AVC avc:  denied  { read } for  pid=162742 comm="gdb" name="metadata.xmlb" dev="dm-3" ino=889 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fwupd_cache_t:s0 tclass=file permissive=0
audit[162742]: AVC avc:  denied  { read } for  pid=162742 comm="gdb" name="metainfo.xmlb" dev="dm-3" ino=3215 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fwupd_cache_t:s0 tclass=file permissive=0
abrt-dump-journal-oops[1015]: Reported 1 kernel oopses to Abrt
abrt-server[162721]: Deleting problem directory ccpp-2021-04-22-17:04:55.508470-162493 (dup of ccpp-2021-04-22-12:23:03.508550-155041)
abrt-notification[162771]: Process 155041 (fwupd) crashed in g_propagate_error()
abrt-server[162750]: Can't find a meaningful backtrace for hashing in '.'
abrt-server[162750]: Preserving oops '.' because DropNotReportableOopses is 'no'
abrt-notification[162789]: System encountered a non-fatal error in ??()
...
systemd[1]: Started dbus-:1.12-org.fedoraproject.Setroubleshootd.
audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.12-org.fedoraproject.Setroubleshootd@10 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
...
audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-localed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
...
setroubleshoot[162793]: AnalyzeThread.run(): Cancel pending alarm
setroubleshoot[162793]: failed to retrieve rpm info for /var/cache/fwupd/quirks.xmlb
systemd[1]: Started dbus-:1.12-org.fedoraproject.SetroubleshootPrivileged.
audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.12-org.fedoraproject.SetroubleshootPrivileged@1 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
setroubleshoot[162793]: SELinux is preventing gdb from read access on the file /var/cache/fwupd/quirks.xmlb. For complete SELinux messages run: sealert -l 2c1bcca8-fe7b-4dd4-9324-6569fecb0916
setroubleshoot[162793]: SELinux is preventing gdb from read access on the file /var/cache/fwupd/quirks.xmlb.
                                                    
                                                    *****  Plugin catchall (100. confidence) suggests   **************************
                                                    
                                                    If you believe that gdb should be allowed read access on the quirks.xmlb file 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 'gdb' --raw | audit2allow -M my-gdb
                                                    # semodule -X 300 -i my-gdb.pp
                                                    
setroubleshoot[162793]: AnalyzeThread.run(): Set alarm timeout to 10
setroubleshoot[162793]: AnalyzeThread.run(): Cancel pending alarm
sealertauto.desktop[162340]: /usr/bin/seapplet:46: DeprecationWarning: Gtk.StatusIcon.new_from_file is deprecated
sealertauto.desktop[162340]:   self.status_icon = Gtk.StatusIcon.new_from_file(
seapplet[162340]: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
sealertauto.desktop[162340]: /usr/bin/seapplet:50: DeprecationWarning: Gtk.StatusIcon.set_visible is deprecated
sealertauto.desktop[162340]:   self.status_icon.set_visible(True)
setroubleshoot[162793]: failed to retrieve rpm info for /var/cache/fwupd/metadata.xmlb
setroubleshoot[162793]: SELinux is preventing gdb from read access on the file /var/cache/fwupd/metadata.xmlb. For complete SELinux messages run: sealert -l 2c1bcca8-fe7b-4dd4-9324-6569fecb0916
setroubleshoot[162793]: SELinux is preventing gdb from read access on the file /var/cache/fwupd/metadata.xmlb.
                                                    
                                                    *****  Plugin catchall (100. confidence) suggests   **************************
                                                    
                                                    If you believe that gdb should be allowed read access on the metadata.xmlb file 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 'gdb' --raw | audit2allow -M my-gdb
                                                    # semodule -X 300 -i my-gdb.pp
                                                    
setroubleshoot[162793]: AnalyzeThread.run(): Set alarm timeout to 10
setroubleshoot[162793]: AnalyzeThread.run(): Cancel pending alarm
setroubleshoot[162793]: failed to retrieve rpm info for /var/cache/fwupd/metainfo.xmlb
setroubleshoot[162793]: SELinux is preventing gdb from read access on the file /var/cache/fwupd/metainfo.xmlb. For complete SELinux messages run: sealert -l 2c1bcca8-fe7b-4dd4-9324-6569fecb0916
setroubleshoot[162793]: SELinux is preventing gdb from read access on the file /var/cache/fwupd/metainfo.xmlb.
                                                    
                                                    *****  Plugin catchall (100. confidence) suggests   **************************
                                                    
                                                    If you believe that gdb should be allowed read access on the metainfo.xmlb file 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 'gdb' --raw | audit2allow -M my-gdb
                                                    # semodule -X 300 -i my-gdb.pp
                                                    
setroubleshoot[162793]: AnalyzeThread.run(): Set alarm timeout to 10
systemd[1]: dbus-:1.12-org.fedoraproject.SetroubleshootPrivileged: Main process exited, code=killed, status=14/ALRM
audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.12-org.fedoraproject.SetroubleshootPrivileged@1 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
systemd[1]: dbus-:1.12-org.fedoraproject.SetroubleshootPrivileged: Failed with result 'signal'.
systemd[1]: dbus-:1.12-org.fedoraproject.SetroubleshootPrivileged: Consumed 4.885s CPU time.
systemd[1]: dbus-:1.12-org.fedoraproject.Setroubleshootd: Main process exited, code=killed, status=14/ALRM
audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.12-org.fedoraproject.Setroubleshootd@10 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
systemd[1]: dbus-:1.12-org.fedoraproject.Setroubleshootd: Failed with result 'signal'.
systemd[1]: dbus-:1.12-org.fedoraproject.Setroubleshootd: Consumed 3.451s CPU time.

Comment 5 Colin Barker 2021-04-23 07:38:10 UTC
suggest this is related to bug 1949491 - [abrt] fwupd: g_propagate_error(): fwupd killed by SIGSEGV
https://bugzilla.redhat.com/show_bug.cgi?id=1949491

Comment 6 Alex Finkel 2021-04-23 10:56:13 UTC
Created attachment 1774760 [details]
System journal output showing fwupd crash

Output extracted from the output of 'journalctl -S today' starting where fwupd gets a general protection fault, including stack trace data and ending with the setroubleshooter which is triggered by gdb.

ABRT says the backtrace does not contain enough meaningful function frames to be reported.

Kernel - 5.11.15-200.fc33.x86_64
fwupd-1.5.9-1.fc33.x86_64
selinux-policy-3.14.6-36.fc33.noarch
selinux-policy-targeted-3.14.6-36.fc33.noarch

Comment 7 Jan Vlug 2021-04-24 12:08:00 UTC
Potential duplicate of: bug 1896648

Comment 8 Alex Finkel 2021-04-26 10:51:04 UTC
Recent update of fwupd to fwupd-1.5.9-2.fc33 may have resolved this.

fwupd did not crash after update and reboot, therefore no gdb and no related AVC denials.

Comment 9 Thomas Crawford 2021-10-08 04:50:34 UTC
Similar problem has been detected:

I am having to drop back and use kernel 5.13.16-200.fc34.x86_64 although kernel 5.14.9 is installed.  The 5.14.9 kenel hangs my computer (reported)

hashmarkername: setroubleshoot
kernel:         5.13.16-200.fc34.x86_64
package:        selinux-policy-targeted-34.21-1.fc34.noarch
reason:         SELinux is preventing gdb from 'open' accesses on the file /var/cache/fwupd/metainfo.xmlb.
type:           libreport

Comment 10 Steve Kirk 2021-11-18 12:24:12 UTC
*** Bug 2024596 has been marked as a duplicate of this bug. ***

Comment 11 Zdenek Pytela 2021-12-09 15:29:11 UTC

*** This bug has been marked as a duplicate of bug 1896648 ***


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