Bug 1966158
| Summary: | podman --privileged no longer able to access /dev/dma_heap | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Florian Bezdeka <florian> |
| Component: | selinux-policy | Assignee: | Zdenek Pytela <zpytela> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 34 | CC: | dwalsh, florian, grepl.miroslav, ifont, ishukla, lvrabec, mmalik, omosnace, rmeggins, socketpair, sonik.bhoom, vmojzis, zpytela |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-06-01 15:29:05 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. |
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;