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 - systemd was denied reading and searching /dev/dma_heap while booting with selinux-policy-34.9-1.fc34
Summary: systemd was denied reading and searching /dev/dma_heap while booting with sel...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 34
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1966158 1967590 1967624 1968052 1968053 1968054 1968126 1968192 1968193 1968571 1969658 1971197 1971316 1972971 1972972 1973324 1973412 1973480 1973759 (view as bug list)
Depends On:
Blocks: 1969323
TreeView+ depends on / blocked
 
Reported: 2021-05-29 04:46 UTC by Matt Fagnani
Modified: 2021-07-12 22:53 UTC (History)
37 users (show)

Fixed In Version: selinux-policy-34.10-1.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1969323 (view as bug list)
Environment:
Last Closed: 2021-06-10 01:13:30 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

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
Note You need to log in before you can comment on or make changes to this bug.