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 1966158 - podman --privileged no longer able to access /dev/dma_heap
Summary: podman --privileged no longer able to access /dev/dma_heap
Keywords:
Status: CLOSED DUPLICATE of bug 1965743
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 34
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-31 14:50 UTC by Florian Bezdeka
Modified: 2021-07-16 19:46 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-06-01 15:29:05 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Florian Bezdeka 2021-05-31 14:50:07 UTC
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;

Comment 1 Daniel Walsh 2021-06-01 14:56:00 UTC
Are you running with the unconfined_domain disabled?

Comment 2 Daniel Walsh 2021-06-01 14:59:56 UTC
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.

Comment 3 Florian Bezdeka 2021-06-01 15:12:33 UTC
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.

Comment 4 Daniel Walsh 2021-06-01 15:18:33 UTC
Sure, the label is just incorrect it should be specific to char (and block devices?) not directories

Comment 5 Zdenek Pytela 2021-06-01 15:29:05 UTC
Right, it will be fixed with the next build.

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

Comment 6 Коренберг Марк 2021-06-16 12:43:39 UTC
Triggered in Fedora 33 with updates.

Comment 7 sonik 2021-07-01 01:51:46 UTC
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

Comment 8 indra 2021-07-01 17:37:45 UTC
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

Comment 9 sonik 2021-07-01 17:52:05 UTC
(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.

Comment 10 Ivan Font 2021-07-02 00:33:51 UTC
(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

Comment 11 sonik 2021-07-02 02:03:36 UTC
(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.


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