Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionBruno Goncalves
2021-06-08 08:22:46 UTC
+++ This bug was initially created as a clone of Bug #1965743 +++
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.
--- Additional comment from Zdenek Pytela on 2021-05-31 16:44:37 CEST ---
I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/763
--- Additional comment from Zdenek Pytela on 2021-06-01 17:29:01 CEST ---
--- Additional comment from Joerg Stippa on 2021-06-02 06:41:34 CEST ---
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
--- Additional comment from Zdenek Pytela on 2021-06-04 21:51:39 CEST ---
--- Additional comment from Zdenek Pytela on 2021-06-04 21:52:33 CEST ---
--- Additional comment from Zdenek Pytela on 2021-06-04 21:58:44 CEST ---
--- Additional comment from Zdenek Pytela on 2021-06-04 21:58:58 CEST ---
--- Additional comment from Zdenek Pytela on 2021-06-04 21:59:02 CEST ---
--- Additional comment from on 2021-06-04 23:00:07 CEST ---
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.
--- Additional comment from Daniel Walsh on 2021-06-06 15:20:23 CEST ---
Put the machine in permissive mode and attempt to relabel it, then put it back into enforcing.
--- Additional comment from NM on 2021-06-07 16:40:15 CEST ---
sudo fixfiles -B onboot
relabeling at boot did not help me.
--- Additional comment from Fedora Update System on 2021-06-07 17:44:29 CEST ---
FEDORA-2021-f014ca8326 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-f014ca8326
--- Additional comment from Zdenek Pytela on 2021-06-07 17:48:10 CEST ---
To have /dev/dma_heap working, you unfortunately need the new selinux-policy-34.10-1.fc34 build.
--- Additional comment from Zdenek Pytela on 2021-06-07 18:02:56 CEST ---
--- Additional comment from Zdenek Pytela on 2021-06-07 18:28:22 CEST ---