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.
I've submitted a Fedora PR to address the issue: https://github.com/fedora-selinux/selinux-policy/pull/763
*** Bug 1966158 has been marked as a duplicate of this bug. ***
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
*** Bug 1967590 has been marked as a duplicate of this bug. ***
*** Bug 1967624 has been marked as a duplicate of this bug. ***
*** Bug 1968052 has been marked as a duplicate of this bug. ***
*** Bug 1968053 has been marked as a duplicate of this bug. ***
*** Bug 1968054 has been marked as a duplicate of this bug. ***
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.
Put the machine in permissive mode and attempt to relabel it, then put it back into enforcing.
sudo fixfiles -B onboot relabeling at boot did not help me.
FEDORA-2021-f014ca8326 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-f014ca8326
To have /dev/dma_heap working, you unfortunately need the new selinux-policy-34.10-1.fc34 build.
*** Bug 1968126 has been marked as a duplicate of this bug. ***
*** Bug 1968571 has been marked as a duplicate of this bug. ***
*** Bug 1969658 has been marked as a duplicate of this bug. ***
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.
FEDORA-2021-f014ca8326 works for me.
*** Bug 1968192 has been marked as a duplicate of this bug. ***
*** Bug 1968193 has been marked as a duplicate of this bug. ***
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.
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
*** Bug 1970556 has been marked as a duplicate of this bug. ***
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
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
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
*** Bug 1971197 has been marked as a duplicate of this bug. ***
*** Bug 1971214 has been marked as a duplicate of this bug. ***
*** Bug 1971316 has been marked as a duplicate of this bug. ***
*** Bug 1972971 has been marked as a duplicate of this bug. ***
*** Bug 1972972 has been marked as a duplicate of this bug. ***
*** Bug 1973324 has been marked as a duplicate of this bug. ***
*** Bug 1973480 has been marked as a duplicate of this bug. ***
*** Bug 1973412 has been marked as a duplicate of this bug. ***
*** Bug 1973759 has been marked as a duplicate of this bug. ***
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
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
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
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
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
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.
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?
(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.
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
(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
(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.
(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.
(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
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
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
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
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
(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
(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.
(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.