Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1965743

Summary: systemd was denied reading and searching /dev/dma_heap while booting with selinux-policy-34.9-1.fc34
Product: [Fedora] Fedora Reporter: Matt Fagnani <matt.fagnani>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 34CC: alex.go4more, amessina, andrew.kavalov, bgoncalv, brady.garland, canyon, chrisa, dwalsh, florian, gchalupa, grepl.miroslav, ifont, jlebon, jsd, j.stippa, jwadodson, kayajooks, kwiesmul, lam, louis.delos, lvrabec, mattison.computer, michael.scheiffler, mikes, mikhail.v.gavrilov, mmalik, mnk, noobusinghacks, ochal, omajid, omosnace, sergei.litvinenko, sonik.bhoom, tgpanaitescu, valsu, vkadlcik, vmojzis, voj-tech, zpytela
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: selinux-policy-34.10-1.fc34 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1969323 (view as bug list) Environment:
Last Closed: 2021-06-10 01:13:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1969323    

Description Matt Fagnani 2021-05-29 04:46:09 UTC
Description of problem:

I updated a F34 KDE Plasma installation with sudo dnf upgrade --refresh with updates-testing enabled. The update included selinux-policy-34.9-1.fc34. I'm using the targeted policy in enforcing mode. I rebooted. systemd was denied reading /dev/dma_heap at around the time that systemd-journal started during the next 2 boots.

audit[1]: AVC avc:  denied  { read } for  pid=1 comm="systemd" path="/dev/dma_heap" dev="devtmpfs" ino=137 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:dma_device_t:s0 tclass=dir permissive=0

systemd-udevd was denied searching /dev/dma_heap shortly after that when various devices were started. systemd-udevd had the error "system: Failed to process device, ignoring: Permission denied"

May 29 00:10:56 audit[644]: AVC avc:  denied  { search } for  pid=644 comm="systemd-udevd" name="dma_heap" dev="devtmpfs" ino=137 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dma_device_t:s0 tclass=dir permissive=0
May 29 00:10:56 audit[644]: SYSCALL arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=556d525243c0 a2=2a0000 a3=0 items=0 ppid=618 pid=644 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="systemd-udevd" exe="/usr/bin/udevadm" subj=system_u:system_r:udev_t:s0-s0:c0.c1023 key=(null)
May 29 00:10:56 audit: PROCTITLE proctitle="/usr/lib/systemd/systemd-udevd"
May 29 00:10:56 systemd-udevd[644]: system: Failed to process device, ignoring: Permission denied

The SELinux troubleshooter GUI didn't show the denials above. 

I ran ls -lZ /dev/dma_heap
ls: cannot open directory '/dev/dma_heap': Permission denied

The SELinux troubleshooter GUI showed ls was denied reading dma_heap when I ran that.

type=AVC msg=audit(1622261698.973:652): avc:  denied  { read } for  pid=3118 comm="ls" name="dma_heap" dev="devtmpfs" ino=137 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dma_device_t:s0 tclass=dir permissive=0

Version-Release number of selected component (if applicable):
selinux-policy-34.9-1.fc34.noarch

How reproducible:
The denials happened on 2/2 boots with selinux-policy-34.9-1.fc34.

Steps to Reproduce:
1. Boot a Fedora 34 KDE Plasma installation updated to 2021-5-28
2. Log in to Plasma on Wayland
3. start konsole
4. sudo dnf upgrade --refresh (with updates-testing enabled) The update must include selinux-policy-34.9-1.fc34.
5. Reboot
6. Log in to Plasma on Wayland
7. start konsole 
8. ls -lZ /dev/dma_heap

Actual results:
systemd was denied reading and searching /dev/dma_heap while booting with selinux-policy-34.9-1.fc34. ls was denied reading /dev/dma_heap.

Expected results:
No denials would happen.

Additional info:

The changelog for selinux-policy-34.9-1.fc34 at https://koji.fedoraproject.org/koji/buildinfo?buildID=1756366 included the change
- Label /dev/dma_heap/* char devices with dma_device_t

The denial audit messages showed that /dev/dma_heap was labelled dma_device_t.

Comment 1 Zdenek Pytela 2021-05-31 14:44:37 UTC
I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/763

Comment 2 Zdenek Pytela 2021-06-01 15:29:01 UTC
*** Bug 1966158 has been marked as a duplicate of this bug. ***

Comment 3 Joerg Stippa 2021-06-02 04:41:34 UTC
The same holds for the "updatedb" command:
# ausearch -c 'updatedb' --raw
type=AVC msg=audit(1622608033.147:1006): avc:  denied  { search } for  pid=10344 comm="updatedb" name="dma_heap" dev="devtmpfs" ino=137 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dma_device_t:s0 tclass=dir permissive=0

... and I guess many more, which try to travel beyond this directory.
# echo /dev/dma_heap/*
Finally, "setroubleshootd" itself has an issue. Complete log messages caused by dma_heap:
# ausearch -f dma_heap --raw
type=AVC msg=audit(1622608033.147:1006): avc:  denied  { search } for  pid=10344 comm="updatedb" name="dma_heap" dev="devtmpfs" ino=137 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dma_device_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1622608106.822:1010): avc:  denied  { read } for  pid=10421 comm="ls" name="dma_heap" dev="devtmpfs" ino=137 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dma_device_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1622608110.014:1011): avc:  denied  { getattr } for  pid=10346 comm="setroubleshootd" path="/dev/dma_heap" dev="devtmpfs" ino=137 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:object_r:dma_device_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1622608475.388:1015): avc:  denied  { read } for  pid=3823 comm="bash" name="dma_heap" dev="devtmpfs" ino=137 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dma_device_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1622608479.087:1017): avc:  denied  { getattr } for  pid=10498 comm="setroubleshootd" path="/dev/dma_heap" dev="devtmpfs" ino=137 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:object_r:dma_device_t:s0 tclass=dir permissive=0

Comment 4 Zdenek Pytela 2021-06-04 19:51:39 UTC
*** Bug 1967590 has been marked as a duplicate of this bug. ***

Comment 5 Zdenek Pytela 2021-06-04 19:52:33 UTC
*** Bug 1967624 has been marked as a duplicate of this bug. ***

Comment 6 Zdenek Pytela 2021-06-04 19:58:44 UTC
*** Bug 1968052 has been marked as a duplicate of this bug. ***

Comment 7 Zdenek Pytela 2021-06-04 19:58:58 UTC
*** Bug 1968053 has been marked as a duplicate of this bug. ***

Comment 8 Zdenek Pytela 2021-06-04 19:59:02 UTC
*** Bug 1968054 has been marked as a duplicate of this bug. ***

Comment 9 louis.delos 2021-06-04 21:00:07 UTC
Is there a work around for this other then disabling SELinux right now? 

All attemps to relabel this file get perm issues even as root.

Comment 10 Daniel Walsh 2021-06-06 13:20:23 UTC
Put the machine in permissive mode and attempt to relabel it, then put it back into enforcing.

Comment 11 NM 2021-06-07 14:40:15 UTC
sudo fixfiles -B onboot

relabeling at boot did not help me.

Comment 12 Fedora Update System 2021-06-07 15:44:29 UTC
FEDORA-2021-f014ca8326 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-f014ca8326

Comment 13 Zdenek Pytela 2021-06-07 15:48:10 UTC
To have /dev/dma_heap working, you unfortunately need the new selinux-policy-34.10-1.fc34 build.

Comment 14 Zdenek Pytela 2021-06-07 16:02:56 UTC
*** Bug 1968126 has been marked as a duplicate of this bug. ***

Comment 15 Zdenek Pytela 2021-06-07 16:28:22 UTC
*** Bug 1968571 has been marked as a duplicate of this bug. ***

Comment 16 Zdenek Pytela 2021-06-08 21:50:29 UTC
*** Bug 1969658 has been marked as a duplicate of this bug. ***

Comment 17 Fedora Update System 2021-06-09 01:16:39 UTC
FEDORA-2021-f014ca8326 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-f014ca8326`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-f014ca8326

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 18 jan p. springer 2021-06-09 14:51:03 UTC
FEDORA-2021-f014ca8326 works for me.

Comment 19 Zdenek Pytela 2021-06-09 21:25:11 UTC
*** Bug 1968192 has been marked as a duplicate of this bug. ***

Comment 20 Zdenek Pytela 2021-06-09 21:25:16 UTC
*** Bug 1968193 has been marked as a duplicate of this bug. ***

Comment 21 Fedora Update System 2021-06-10 01:13:30 UTC
FEDORA-2021-f014ca8326 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 22 Michael 2021-06-10 11:40:34 UTC
Similar problem has been detected:

Ran updatedb

hashmarkername: setroubleshoot
kernel:         5.12.9-300.fc34.x86_64
package:        selinux-policy-targeted-34.10-1.fc34.noarch
reason:         SELinux is preventing updatedb from 'search' accesses on the directory dma_heap.
type:           libreport

Comment 23 Zdenek Pytela 2021-06-11 14:56:34 UTC
*** Bug 1970556 has been marked as a duplicate of this bug. ***

Comment 24 robert fairbrother 2021-06-14 00:25:10 UTC
Similar problem has been detected:

I was performing updates in the tty shell and playing hbr radio on rhythmbox, BOINC-client was running 

hashmarkername: setroubleshoot
kernel:         5.13.0-0.rc4.20210603git324c92e5e0ee.35.fc35.x86_64
package:        selinux-policy-targeted-34.9-1.fc35.noarch
reason:         SELinux is preventing restorecon from 'search' accesses on the directory dma_heap.
type:           libreport

Comment 25 robert fairbrother 2021-06-15 02:26:04 UTC
Similar problem has been detected:

playing a radio station in rhythmbox and running mc with sudo on gnome-terminal 

hashmarkername: setroubleshoot
kernel:         5.13.0-0.rc5.20210611git929d931f2b40.42.fc35.x86_64
package:        selinux-policy-targeted-34.9-1.fc35.noarch
reason:         SELinux is preventing find from 'read' accesses on the directory dma_heap.
type:           libreport

Comment 26 Kevin Wiesmueller 2021-06-15 17:58:30 UTC
Can this also receive a backport to Fedora 33? I started seeing this issue this week as it prevents me from running privileged docker containers.

kernel: 5.12.10-200.fc33.x86_64
package: selinux-policy-targeted 5.12.10-200.fc33.x86_64

Comment 27 Zdenek Pytela 2021-06-15 20:54:43 UTC
*** Bug 1971197 has been marked as a duplicate of this bug. ***

Comment 28 Zdenek Pytela 2021-06-15 20:54:51 UTC
*** Bug 1971214 has been marked as a duplicate of this bug. ***

Comment 29 Zdenek Pytela 2021-06-15 20:54:57 UTC
*** Bug 1971316 has been marked as a duplicate of this bug. ***

Comment 30 Zdenek Pytela 2021-06-18 19:08:50 UTC
*** Bug 1972971 has been marked as a duplicate of this bug. ***

Comment 31 Zdenek Pytela 2021-06-18 19:08:52 UTC
*** Bug 1972972 has been marked as a duplicate of this bug. ***

Comment 32 Zdenek Pytela 2021-06-18 19:09:12 UTC
*** Bug 1973324 has been marked as a duplicate of this bug. ***

Comment 33 Zdenek Pytela 2021-06-18 19:10:00 UTC
*** Bug 1973480 has been marked as a duplicate of this bug. ***

Comment 34 Zdenek Pytela 2021-06-18 19:10:13 UTC
*** Bug 1973412 has been marked as a duplicate of this bug. ***

Comment 35 Zdenek Pytela 2021-06-18 19:10:22 UTC
*** Bug 1973759 has been marked as a duplicate of this bug. ***

Comment 36 Alex. H. F. 2021-06-19 10:57:01 UTC
Similar problem has been detected:

At each system startup??

hashmarkername: setroubleshoot
kernel:         5.12.9-200.fc33.x86_64
package:        selinux-policy-targeted-3.14.6-38.fc33.noarch
reason:         SELinux is preventing find from 'read' accesses on the Verzeichnis dma_heap.
type:           libreport

Comment 37 Michael Setzer II 2021-06-19 19:10:39 UTC
Similar problem has been detected:

Believe that rkhunter is accessing the /dev directory and causing the issue.
See a similar issue if I go to directory and do an ls??

hashmarkername: setroubleshoot
kernel:         5.12.11-200.fc33.x86_64
package:        selinux-policy-targeted-3.14.6-38.fc33.noarch
reason:         SELinux is preventing /usr/bin/find from 'read' accesses on the directory dma_heap.
type:           libreport

Comment 38 Sergei LITVINENKO 2021-06-20 13:24:38 UTC
Similar problem has been detected:

The error occurs for no apparent reason after rebooting.

hashmarkername: setroubleshoot
kernel:         5.12.10-200.fc33.x86_64
package:        selinux-policy-targeted-3.14.6-38.fc33.noarch
reason:         SELinux is preventing find from 'read' accesses on the каталог dma_heap.
type:           libreport

Comment 39 Michael Setzer II 2021-06-21 12:38:06 UTC
Similar problem has been detected:

Shows up in SELinux Troubleshooter.
Believe rkhunter is scanning /dev directory that causes it.

hashmarkername: setroubleshoot
kernel:         5.12.11-200.fc33.x86_64
package:        selinux-policy-targeted-3.14.6-38.fc33.noarch
reason:         SELinux is preventing find from 'open' accesses on the directory /dev/dma_heap.
type:           libreport

Comment 40 Michael Setzer II 2021-06-22 00:55:32 UTC
Similar problem has been detected:

Shows up in SELinux Troubleshooter.
Believe it happens with rkhunter running and accessing the /dev directory.

hashmarkername: setroubleshoot
kernel:         5.12.11-200.fc33.x86_64
package:        selinux-policy-targeted-3.14.6-38.fc33.noarch
reason:         SELinux is preventing find from 'open' accesses on the directory /dev/dma_heap.
type:           libreport

Comment 41 Florian Bezdeka 2021-06-28 15:01:13 UTC
At least the part mentioned in bug 1966158 affects Fedora 33 as well (unable to run privileged podman containers). Can we expect something like a backport? Kevin already asked for it, but no response so far.

Comment 42 sonik 2021-06-29 17:57:51 UTC
Fedora 33 - Not able to run PlexMS with privileged podman. Also affects docker-ce

to work around:
 
$ sudo selinuxenabled 0
$ sudo chcon system_u:object_r:device_t:s0 /dev/dma_heap/
$ sudo selinuxenabled 1

Should we expect a back-port to Fedora33?

Comment 43 Zdenek Pytela 2021-06-29 18:30:23 UTC
(In reply to Florian Bezdeka from comment #41)
> At least the part mentioned in bug 1966158 affects Fedora 33 as well (unable
> to run privileged podman containers). Can we expect something like a
> backport? Kevin already asked for it, but no response so far.

There is a F33 bz clone linked to this one, will be a part of the next build.

Comment 44 Michael Setzer II 2021-06-30 00:20:20 UTC
Similar problem has been detected:

Shows in SELinux Troubleshooter
Think linked to rkhunter scan

hashmarkername: setroubleshoot
kernel:         5.12.12-200.fc33.x86_64
package:        selinux-policy-targeted-3.14.6-38.fc33.noarch
reason:         SELinux is preventing /usr/bin/find from 'read' accesses on the directory dma_heap.
type:           libreport

Comment 45 Ivan Font 2021-07-02 00:34:13 UTC
(In reply to sonik from comment #42)
> Fedora 33 - Not able to run PlexMS with privileged podman. Also affects
> docker-ce
> 
> to work around:
>  
> $ sudo selinuxenabled 0
> $ sudo chcon system_u:object_r:device_t:s0 /dev/dma_heap/
> $ sudo selinuxenabled 1
> 
> Should we expect a back-port to Fedora33?

I think setenforce was intended. This worked for me:

$ sudo setenforce 0
$ sudo chcon system_u:object_r:device_t:s0 /dev/dma_heap/
$ sudo setenforce 1

Comment 46 sonik 2021-07-02 02:02:37 UTC
(In reply to Ivan Font from comment #45)
> (In reply to sonik from comment #42)
> > Fedora 33 - Not able to run PlexMS with privileged podman. Also affects
> > docker-ce
> > 
> > to work around:
> >  
> > $ sudo setenforce 0
> > $ sudo chcon system_u:object_r:device_t:s0 /dev/dma_heap/
> > $ sudo setenforce 1
> > 
> > Should we expect a back-port to Fedora33?
> 
> I think setenforce was intended. This worked for me:
> 
> $ sudo setenforce 0
> $ sudo chcon system_u:object_r:device_t:s0 /dev/dma_heap/
> $ sudo setenforce 1

Sorry. I made a typo in haste.

Comment 47 Mathias Nicolajsen Kjærgaard 2021-07-07 06:42:59 UTC
(In reply to Zdenek Pytela from comment #43)
> (In reply to Florian Bezdeka from comment #41)
> > At least the part mentioned in bug 1966158 affects Fedora 33 as well (unable
> > to run privileged podman containers). Can we expect something like a
> > backport? Kevin already asked for it, but no response so far.
> 
> There is a F33 bz clone linked to this one, will be a part of the next build.

What F33 bz are you referring to? I only see a clone for EL 9, and F33 seems to still be affected by this bug - even with selinux-policy from updates-testing.
I really hope this fix gets backported, since it is bug that was introduced by applying normal updates to a working system.

Comment 48 Zdenek Pytela 2021-07-07 13:40:51 UTC
(In reply to Mathias Nicolajsen Kjærgaard from comment #47)
> > There is a F33 bz clone linked to this one, will be a part of the next build.
> 
> What F33 bz are you referring to? I only see a clone for EL 9, and F33 seems
> to still be affected by this bug - even with selinux-policy from
> updates-testing.
> I really hope this fix gets backported, since it is bug that was introduced
> by applying normal updates to a working system.

bz#1967536

Comment 49 Michael Setzer II 2021-07-15 18:59:38 UTC
Similar problem has been detected:

Believe it happens with rkhunter access 

hashmarkername: setroubleshoot
kernel:         5.12.15-200.fc33.x86_64
package:        selinux-policy-targeted-3.14.6-38.fc33.noarch
reason:         SELinux is preventing /usr/bin/find from 'read' accesses on the directory dma_heap.
type:           libreport

Comment 50 Michael Setzer II 2021-07-19 21:00:53 UTC
Similar problem has been detected:

believe happens with rkhunter scan of directory

hashmarkername: setroubleshoot
kernel:         5.12.15-200.fc33.x86_64
package:        selinux-policy-targeted-3.14.6-39.fc33.noarch
reason:         SELinux is preventing file from 'search' accesses on the directory dma_heap.
type:           libreport

Comment 51 Michael Setzer II 2021-07-19 21:02:20 UTC
Similar problem has been detected:

believe happens with rkhunter scan of /dev directory

hashmarkername: setroubleshoot
kernel:         5.12.15-200.fc33.x86_64
package:        selinux-policy-targeted-3.14.6-39.fc33.noarch
reason:         SELinux is preventing /usr/bin/find from 'read' accesses on the directory dma_heap.
type:           libreport

Comment 52 Bill 2021-07-21 19:20:26 UTC
Similar problem has been detected:

I've so far observed this problem in all three of these situations:
- running "chkrootkit" from the command line;
- running "rkhunter --check" from the command line; and
- during the daily rkhunter run (a cron job).

This has been happening for weeks, though I do "dnf upgrade" every week.

Running, as root, the commands suggested by the selinux alert:
ausearch -c 'find' --raw | audit2allow -M my-find
semodule -X 300 -i my-find.pp
did not help.  I tried at least twice.

hashmarkername: setroubleshoot
kernel:         5.12.15-200.fc33.x86_64
package:        selinux-policy-targeted-3.14.6-38.fc33.noarch
reason:         SELinux is preventing find from 'open' accesses on the directory /dev/dma_heap.
type:           libreport

Comment 53 sonik 2021-07-21 19:47:20 UTC
(In reply to Bill from comment #52)
> Similar problem has been detected:
> 
> I've so far observed this problem in all three of these situations:
> - running "chkrootkit" from the command line;
> - running "rkhunter --check" from the command line; and
> - during the daily rkhunter run (a cron job).
> 
> This has been happening for weeks, though I do "dnf upgrade" every week.
> 
> Running, as root, the commands suggested by the selinux alert:
> ausearch -c 'find' --raw | audit2allow -M my-find
> semodule -X 300 -i my-find.pp
> did not help.  I tried at least twice.
> 
> hashmarkername: setroubleshoot
> kernel:         5.12.15-200.fc33.x86_64
> package:        selinux-policy-targeted-3.14.6-38.fc33.noarch
> reason:         SELinux is preventing find from 'open' accesses on the
> directory /dev/dma_heap.
> type:           libreport

Run this: 
$ sudo setenforce 0
$ sudo chcon system_u:object_r:device_t:s0 /dev/dma_heap/
$ sudo setenforce 1

OR

Run this: 
$ sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-f014ca8326 # FC34
$ sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-3b341e9e71 # FC33

Comment 54 sonik 2021-07-21 19:50:18 UTC
(In reply to sonik from comment #53)
> (In reply to Bill from comment #52)
> > Similar problem has been detected:
> > 
> > I've so far observed this problem in all three of these situations:
> > - running "chkrootkit" from the command line;
> > - running "rkhunter --check" from the command line; and
> > - during the daily rkhunter run (a cron job).
> > 
> > This has been happening for weeks, though I do "dnf upgrade" every week.
> > 
> > Running, as root, the commands suggested by the selinux alert:
> > ausearch -c 'find' --raw | audit2allow -M my-find
> > semodule -X 300 -i my-find.pp
> > did not help.  I tried at least twice.
> > 
> > hashmarkername: setroubleshoot
> > kernel:         5.12.15-200.fc33.x86_64
> > package:        selinux-policy-targeted-3.14.6-38.fc33.noarch
> > reason:         SELinux is preventing find from 'open' accesses on the
> > directory /dev/dma_heap.
> > type:           libreport
> 
> Run this: 
> $ sudo setenforce 0
> $ sudo chcon system_u:object_r:device_t:s0 /dev/dma_heap/
> $ sudo setenforce 1
> 
> OR
> 
> Run this: 
> $ sudo dnf upgrade --enablerepo=updates-testing
> --advisory=FEDORA-2021-f014ca8326 # FC34
> $ sudo dnf upgrade --enablerepo=updates-testing
> --advisory=FEDORA-2021-3b341e9e71 # FC33

well according to https://bugzilla.redhat.com/show_bug.cgi?id=1967536 the fix has been push to stable FC33.  You should just need to update.

Comment 55 Bill 2021-07-23 19:12:05 UTC
(responding to both comment #53 and comment #54, both by "sonik")

My weekly "dnf upgrade" was done yesterday (Thursday, July 22).  There have been a few runs of rkhunter and chkrootkit since then.  I've seen no selinux alerts since the "dnf upgrade".  I did check the SELinux Alert Browser.  The most recent alert was before the "dnf upgrade".  Since sonik's comment #54 advice worked, his comment #53 advice was not tried.

Problem solved.
Thank-you sonik.