Description of problem: It can be reproduced by running a simple container in a rootless podman context. ``` podman run -it --rm hello-world podman run -it --rm --network=pasta hello-world `` Using slirp4netns or no network prevents this bug. ``` podman run -it --rm --network=slirp4netns hello-world podman run -it --rm --network=none hello-world `` SELinux is preventing /usr/bin/pasta from read, write access on the chr_file /dev/udmabuf. ***** Plugin leaks (86.2 confidence) suggests ***************************** If you want to ignore pasta trying to read write access the udmabuf chr_file, because you believe it should not need this access. Then you should report this as a bug. You can generate a local policy module to dontaudit this access. Do # ausearch -x /usr/bin/pasta --raw | audit2allow -D -M my-pasta # semodule -X 300 -i my-pasta.pp ***** Plugin catchall (14.7 confidence) suggests ************************** If you believe that pasta should be allowed read write access on the udmabuf chr_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'pasta' --raw | audit2allow -M my-pasta # semodule -X 300 -i my-pasta.pp Additional Information: Source Context unconfined_u:unconfined_r:pasta_t:s0-s0:c0.c1023 Target Context system_u:object_r:dma_device_t:s0 Target Objects /dev/udmabuf [ chr_file ] Source pasta Source Path /usr/bin/pasta Port <Unknown> Host (removed) Source RPM Packages passt-0^20250611.g0293c6f-1.fc42.x86_64 Target RPM Packages SELinux Policy RPM selinux-policy-targeted-41.43-1.fc42.noarch Local Policy RPM Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 6.14.11-300.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Jun 10 16:24:16 UTC 2025 x86_64 Alert Count 4 First Seen 2025-06-22 08:48:35 -03 Last Seen 2025-06-22 09:00:16 -03 Local ID fc69ce1e-57d5-48bc-93d5-b040b69e0b36 Raw Audit Messages type=AVC msg=audit(1750593616.482:1895): avc: denied { read write } for pid=32233 comm="pasta" path="/dev/udmabuf" dev="devtmpfs" ino=155 scontext=unconfined_u:unconfined_r:pasta_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dma_device_t:s0 tclass=chr_file permissive=0 type=SYSCALL msg=audit(1750593616.482:1895): arch=x86_64 syscall=execve success=yes exit=0 a0=c000493770 a1=c00062e000 a2=c00049aa08 a3=0 items=0 ppid=32219 pid=32233 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts2 ses=3 comm=pasta exe=/usr/bin/pasta subj=unconfined_u:unconfined_r:pasta_t:s0-s0:c0.c1023 key=(null) Hash: pasta,pasta_t,dma_device_t,chr_file,read,write Version-Release number of selected component: selinux-policy-targeted-41.43-1.fc42.noarch Additional info: reporter: libreport-2.17.15 reason: SELinux is preventing /usr/bin/pasta from read, write access on the chr_file /dev/udmabuf. package: selinux-policy-targeted-41.43-1.fc42.noarch component: selinux-policy hashmarkername: setroubleshoot type: libreport kernel: 6.14.11-300.fc42.x86_64 component: selinux-policy
Created attachment 2094657 [details] File: description
Created attachment 2094658 [details] File: os_info
(In reply to Agustín P from comment #0) > Target Context system_u:object_r:dma_device_t:s0 > Target Objects /dev/udmabuf [ chr_file ] On my desktop (Fedora 42 Workstation on bare metal), `/dev/udmabuf` is unlabelled (and running `sudo restorecon -vF /dev/udmabuf` doesn't change that); on my server (Fedora 42 IoT on KVM), `/dev/udmabuf` is labelled as `system_u:object_r:dma_device_t:s0` (just like yours). > ``` > podman run -it --rm hello-world > podman run -it --rm --network=pasta hello-world > ``` I get no SELinux denials when running those commands on either of my systems, even after running `sudo semodule --disable_dontaudit --build`. And `container_runtime_t` (the label that pasta used to run under) doesn't appear to be allowed to write to `dma_device_t` either, so I'm not really sure why this problem only showed up now. I'm not familiar with `/dev/udmabuf`, but a web search suggests that it's useful for hardware acceleration, so I wonder if this issue might be hardware-dependent? What network card/driver are you using? Does the problem go away if you disable (network) hardware offloading? Also, bug 2338718, bug 2300176, and bug 2223727 address similar SELinux denials, but those all seem to be GPU-related, not network-related.
(In reply to Max Chernoff from comment #3) > (In reply to Agustín P from comment #0) > > Target Context system_u:object_r:dma_device_t:s0 > > Target Objects /dev/udmabuf [ chr_file ] > > On my desktop (Fedora 42 Workstation on bare metal), `/dev/udmabuf` is > unlabelled (and running `sudo restorecon -vF /dev/udmabuf` doesn't change > that); on my server (Fedora 42 IoT on KVM), `/dev/udmabuf` is labelled as > `system_u:object_r:dma_device_t:s0` (just like yours). I apologize for the delay in replying, I've been a bit busy these days. I performed the tests on a HyperV VM (Fedora 42 KDE), while on my desktop (also Fedora 42 KDE) there are no SELinux related issues. In both cases (HyperV and my desktop) the context is the same. ``` ls -lZ /dev/udmabuf crw-rw---- 1 root kvm ? 10, 125 Jun 25 23:16 /dev/udmabuf stat /dev/udmabuf File: /dev/udmabuf Size: 0 Blocks: 0 IO Block: 4096 character special file Device: 0,6 Inode: 137 Links: 1 Device type: 10,125 Access: (0660/crw-rw----) Uid: ( 0/ root) Gid: ( 36/ kvm) Context: system_u:object_r:dma_device_t:s0 Access: 2025-06-25 23:16:33.736090487 -0300 Modify: 2025-06-25 23:16:33.736090487 -0300 Change: 2025-06-25 23:16:37.042504298 -0300 Birth: 2025-06-25 23:16:13.989999997 -0300 ``` I'm not an expert regarding SELinux, so I'm sorry if anything I say is wrong. > > ``` > > podman run -it --rm hello-world > > podman run -it --rm --network=pasta hello-world > > ``` > > I get no SELinux denials when running those commands on either of my > systems, even after running `sudo semodule --disable_dontaudit --build`. And > `container_runtime_t` (the label that pasta used to run under) doesn't > appear to be allowed to write to `dma_device_t` either, so I'm not really > sure why this problem only showed up now. > > I'm not familiar with `/dev/udmabuf`, but a web search suggests that it's > useful for hardware acceleration, so I wonder if this issue might be > hardware-dependent? What network card/driver are you using? Does the problem > go away if you disable (network) hardware offloading? > > Also, bug 2338718, bug 2300176, and bug 2223727 address similar SELinux > denials, but those all seem to be GPU-related, not network-related. Leaving aside my desktop (on which I performed the same tests and failed to reproduce the problem), below is the information requested regarding the VM: ``` ethtool -i eth0 driver: hv_netvsc version: 6.15.3-200.fc42.x86_64 firmware-version: N/A expansion-rom-version: bus-info: 2a7d5cbb-7582-4aa0-b6e8-b438c75 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: yes supports-priv-flags: no ``` Disabling network hardware offloading does not help: ``` sudo ethtool -k eth0 | grep ': on' rx-vlan-offload: on [fixed] tx-vlan-offload: on [fixed] receive-hashing: on highdma: on [fixed] ``` A relevant fact is that in one of my last tests I used XRDP to use the HyperV's "Enhanced Session Mode" and I could not reproduce the problem. In addition, I cannot replicate bug 2374198 either on my desktop or in Enhanced Session Mode/XRDP. Perhaps this problem is related to HyperV/hv_netvsc?
(In reply to Agustín P from comment #4) > I performed the tests on a HyperV VM (Fedora 42 KDE), while on my desktop > (also Fedora 42 KDE) there are no SELinux related issues. That's definitely an interesting detail. > [...] > > Perhaps this problem is related to HyperV/hv_netvsc? Looking at the issue with nft(1), I would tend to say yes. I start wondering what operation is done on /dev/udmabuf. Can it be that for whatever reason it's passed as standard stream (input, output or error) for pasta(1)? Does the same SELinux warning appear if you run, say, 'pasta --help >/dev/null'?
(In reply to Stefano Brivio from comment #5) > Looking at the issue with nft(1), I would tend to say yes. I start wondering > what operation is done on /dev/udmabuf. Can it be that for whatever reason > it's passed as standard stream (input, output or error) for pasta(1)? Does > the same SELinux warning appear if you run, say, 'pasta --help >/dev/null'? That's an interesting test I didn't think of. Thanks! You are right, the issue occurs even if you only use `pasta`. ``` pasta pasta --help pasta --help > /dev/null ``` I'm not sure the role of `/dev/udmabuf` with pasta, but I didn't find anything interesting with `strace`.
Some additional info that may be useful: ``` type=AVC msg=audit(1751396127.419:331): avc: denied { read write } for pid=4035 comm="passwd" path="/dev/udmabuf" dev="devtmpfs" ino=155 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dma_device_t:s0 tclass=chr_file permissive=0 ``` At this point it is quite clear that this problem is not related to pasta(1). I still can't reproduce the issues (pasta(1), nft(8), passwd(1)) in HyperV with XRDP/"Enhanced Session Mode". Also it's quite interesting that I cannot reproduce this at all using TTY, so I'm really not sure where the cause of the issue is. ``` lsmod | awk 'NR==1 || /hv/ || /hyper/' Module Size Used by hv_netvsc 135168 0 hv_utils 57344 2 hv_balloon 49152 0 hv_storvsc 32768 3 scsi_transport_fc 131072 1 hv_storvsc hyperv_drm 28672 1 hid_hyperv 16384 0 hyperv_keyboard 12288 0 hv_sock 24576 0 vsock 69632 5 hv_sock hv_vmbus 196608 8 hv_balloon,hv_utils,hv_netvsc,hid_hyperv,hv_storvsc,hyperv_keyboard,hyperv_drm,hv_sock ``` Maybe it is related to `hyperv_drm`?