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.
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.
Bug 1969323 - 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 DUPLICATE of bug 1967818
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: selinux-policy
Version: 9.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: beta
: 9.0 Beta
Assignee: Zdenek Pytela
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On: 1965743
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-06-08 08:22 UTC by Bruno Goncalves
Modified: 2021-10-21 16:30 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of: 1965743
Environment:
Last Closed: 2021-06-21 12:22:33 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Bruno 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 ---

Comment 11 Zdenek Pytela 2021-06-21 12:22:33 UTC
Not exactly the same issue as bz#1967818, but will be resolved with the update there.

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


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