Description of problem: Podman with --priveleged fails to run, access to /dev/dma_heap denied. Version-Release number of selected component (if applicable): selinux-policy-34.9-1.fc34.noarch How reproducible: Steps to Reproduce: 1. sudo podman run --rm -t -i --privileged debian:buster Actual results: Error: open /dev/dma_heap: permission denied Expected results: Shell inside the container Additional info: Audit-Log: type=AVC msg=audit(1622466934.596:1200): avc: denied { read } for pid=12878 comm="podman" name="dma_heap" dev="devtmpfs" ino=167 scontext=unconfined_u:system_r:container_runtime_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dma_device_t:s0 tclass=dir permissive=0 type=AVC msg=audit(1622471339.520:1340): avc: denied { open } for pid=15903 comm="podman" path="/dev/dma_heap" dev="devtmpfs" ino=167 scontext=unconfined_u:system_r:container_runtime_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dma_device_t:s0 tclass=dir permissive=0 type=AVC msg=audit(1622471404.466:1364): avc: denied { search } for pid=16288 comm="podman" name="dma_heap" dev="devtmpfs" ino=167 scontext=unconfined_u:system_r:container_runtime_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dma_device_t:s0 tclass=dir permissive=0 The following TE fixes the problem: module fix-podman 1.0; require { type container_runtime_t; type dma_device_t; class dir { open read search }; } #============= container_runtime_t ============== #!!!! This avc is allowed in the current policy allow container_runtime_t dma_device_t:dir { open read }; allow container_runtime_t dma_device_t:dir search;
Are you running with the unconfined_domain disabled?
Never mind, the issue here is that the /dev/dma_heap directory is mislabeled in selinux policy as a dma_device_t rather then device_t. Directory should not have a device type on them.
The changelog of selinux-policy-34.9-1.fc34.noarch: * Do Mai 27 00:00:00 2021 Zdenek Pytela <zpytela> - 34.9-1 [snip] - Label /dev/zram[0-9]+ block device files with fixed_disk_device_t - Label /dev/udmabuf character device with dma_device_t - Label /dev/dma_heap/* char devices with dma_device_t - Label /dev/acpi_thermal_rel char device with acpi_device_t The change to dma_device_t seems to be a conscious change.
Sure, the label is just incorrect it should be specific to char (and block devices?) not directories
Right, it will be fixed with the next build. *** This bug has been marked as a duplicate of bug 1965743 ***
Triggered in Fedora 33 with updates.
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
Yeah same for me it triggered in Fedora 33 with the update not able to get the work around bash-5.0$ sudo chcon system_u:object_r:device_t:s0 /dev/dma_heap/ chcon: failed to change context of '/dev/dma_heap/' to ‘system_u:object_r:device_t:s0’: Permission denied
(In reply to indra from comment #8) > Yeah same for me it triggered in Fedora 33 with the update > > not able to get the work around > > bash-5.0$ sudo chcon system_u:object_r:device_t:s0 /dev/dma_heap/ > chcon: failed to change context of '/dev/dma_heap/' to > ‘system_u:object_r:device_t:s0’: Permission denied You must disable selinux to gain access to /dev/dma_heap then re-enable it once you have corrected the selinux context.
(In reply to sonik from comment #7) > 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 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 #10) > (In reply to sonik from comment #7) > > 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 > > 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 my haste.