Bug 2149260 - SELinux is preventing gst-plugin-scan from 'getattr' accesses on the chr_file /dev/nvidia-uvm-tools.
Summary: SELinux is preventing gst-plugin-scan from 'getattr' accesses on the chr_file...
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 37
Hardware: x86_64
OS: Unspecified
low
unspecified
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:81edea52a66a15cb46c9769fec2...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-11-29 11:15 UTC by Brian J. Murrell
Modified: 2023-03-02 19:38 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2023-03-02 19:38:04 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Brian J. Murrell 2022-11-29 11:15:17 UTC
Description of problem:
Not sure why this happened.
SELinux is preventing gst-plugin-scan from 'getattr' accesses on the chr_file /dev/nvidia-uvm-tools.

*****  Plugin restorecon (90.5 confidence) suggests   ************************

If you want to fix the label. 
/dev/nvidia-uvm-tools default label should be xserver_misc_device_t.
Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly.
Do
# /sbin/restorecon -v /dev/nvidia-uvm-tools

*****  Plugin device (9.50 confidence) suggests   ****************************

If you want to allow gst-plugin-scan to have getattr access on the nvidia-uvm-tools chr_file
Then you need to change the label on /dev/nvidia-uvm-tools to a type of a similar device.
Do
# semanage fcontext -a -t SIMILAR_TYPE '/dev/nvidia-uvm-tools'
# restorecon -v '/dev/nvidia-uvm-tools'

*****  Plugin catchall (1.40 confidence) suggests   **************************

If you believe that gst-plugin-scan should be allowed getattr access on the nvidia-uvm-tools 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 'gst-plugin-scan' --raw | audit2allow -M my-gstpluginscan
# semodule -X 300 -i my-gstpluginscan.pp

Additional Information:
Source Context                system_u:system_r:xdm_t:s0-s0:c0.c1023
Target Context                system_u:object_r:device_t:s0
Target Objects                /dev/nvidia-uvm-tools [ chr_file ]
Source                        gst-plugin-scan
Source Path                   gst-plugin-scan
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-37.14-1.fc37.noarch
Local Policy RPM              selinux-policy-targeted-37.14-1.fc37.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 6.0.9-300.fc37.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Wed Nov 16 17:36:22 UTC 2022
                              x86_64 x86_64
Alert Count                   1
First Seen                    2022-11-26 17:01:28 EST
Last Seen                     2022-11-26 17:01:28 EST
Local ID                      af6584d4-8331-4584-b58f-b8499aefc083

Raw Audit Messages
type=AVC msg=audit(1669500088.181:362): avc:  denied  { getattr } for  pid=2941 comm="gst-plugin-scan" path="/dev/nvidia-uvm-tools" dev="devtmpfs" ino=1457 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=0


Hash: gst-plugin-scan,xdm_t,device_t,chr_file,getattr

Version-Release number of selected component:
selinux-policy-targeted-37.14-1.fc37.noarch

Additional info:
component:      selinux-policy
reporter:       libreport-2.17.4
hashmarkername: setroubleshoot
kernel:         6.0.9-300.fc37.x86_64
type:           libreport

Comment 1 Brian J. Murrell 2022-11-29 11:15:51 UTC
# /sbin/restorecon -nv /dev/nvidia-uvm-tools
/sbin/restorecon: lstat(/dev/nvidia-uvm-tools) failed: No such file or directory

So the file doesn't even exist (any more).

Comment 2 Zdenek Pytela 2022-11-29 12:58:51 UTC
Brian,

Do you have an nvidia provided kernel module? I am afraid in that case you need to check with them for further steps.

Problem is that we have a default label in the policy (see also the setroubleshoot report):

# matchpathcon /dev/nvidia-uvm-tools
/dev/nvidia-uvm-tools   system_u:object_r:xserver_misc_device_t:s0

but the driver needs to handle it on its own or with udev help, but I don't even know if the label is correct or there should be assigned a different one.

Comment 3 Brian J. Murrell 2022-11-29 14:54:32 UTC
$ lsmod | grep nvidia
nvidia_drm             73728  3
nvidia_modeset       1187840  4 nvidia_drm
nvidia_uvm           2859008  0
nvidia              55250944  392 nvidia_uvm,nvidia_modeset
i2c_nvidia_gpu         16384  0

I guess we can close this then.

I really ought to figure out how to use the Intel GPU in this laptop instead.

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation CometLake-H GT2 [UHD Graphics] (rev 05)
01:00.0 VGA compatible controller: NVIDIA Corporation TU106GLM [Quadro RTX 3000 Mobile / Max-Q] (rev a1)

Comment 4 Zdenek Pytela 2023-03-02 19:38:04 UTC
I am afraid this issue needs to be resolved with the driver vendor.


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