Description of problem: Axel Thimm (from atrpms) suggested that I pass this one on to you to see if it is appropriate to solve at the general selinux policy level... Here is the buzilla entry that I originally entered on the atrpms bugzilla system. ------------------------------------------------- The nvidia driver module has an selinux conflict when run under the (default) 'targeted' selinux policy. Specifically, I get the following "avc: denied" errors: avc: denied { execmod } comm=Xorg name=nvidia-1.0-9631_drv.o scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lib_t:s0 tclass=file avc: denied { execmod } comm=Xorg name=nvidia-1.0-9631_drv.o scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file audit2allow gives the following suggested additions to the policy: require { class file execmod; type init_t; type lib_t; type xdm_t; role system_r; }; allow init_t lib_t:file execmod; allow xdm_t lib_t:file execmod; ---------------------------------------------------------------------------- Please let me know what you think is the most practical way to correct this. (i.e., even if technically this is an nvidia company problem but if they are unlikely to correct this, then I would prefer an alternative practical solution such as either fixing the selinux policy or making suggestions for how to fix the rpm compiled by Axel)
chcon -t textrel_shlib_t nvidia-1.0-9631_drv.o Also please update to the latest policy. Also if you install setroubleshoot, it will help you diagnose selinux-errors.
If I were to update the rpm to include this, how would I express this in the specfile? For rpm to record the context it would have to be part of %install or an attribute to the %files section. Since %install runs as a non-root user, can this user use chcon w/o limitations (under %{buildroot})? Thanks!
The best idea is to tell me what the path is and to get it into the base policy. you could use semanage and restorecon semanage fcontext -a -t textrel_shlib_t PATH restorecon PATH
> The best idea is to tell me what the path is and to get it into the base > policy. OK, the modules and libs are located under /usr/lib/xorg/modules/drivers/nvidia-graphics-1.0-9746/nvidia_drv.so /usr/lib/xorg/modules/extensions/nvidia-graphics-1.0-9746/libglx.so.1.0.9746 /usr/lib/xorg/modules/nvidia-graphics-1.0-9746/libnvidia-wfb.so.1.0.9746 /usr/lib/nvidia-graphics-1.0-9746/libGL.so.1.0.9746 /usr/lib/nvidia-graphics-1.0-9746/libGLcore.so.1.0.9746 /usr/lib/nvidia-graphics-1.0-9746/libXvMCNVIDIA.so.1.0.9746 /usr/lib/nvidia-graphics-1.0-9746/libnvidia-cfg.so.1.0.9746 /usr/lib/nvidia-graphics-1.0-9746/libnvidia-tls.so.1.0.9746 /usr/lib/nvidia-graphics-1.0-9746/tls/libnvidia-tls.so.1.0.9746 with symlinks to higher folders w/o the nvidia-graphics-[^/]* part, e.g. /usr/lib(64)?/xorg/modules/drivers/(nvidia-graphics-[^/]*/)?nvidia_drv\.so /usr/lib(64)?/xorg/modules/extensions/(nvidia-graphics-[^/]*/)?libglx\.so\.[^/]* /usr/lib(64)?/xorg/modules/(nvidia-graphics-[^/]*/)?libnvidia-wfb\.so\.[^/]* /usr/lib(64)?/(nvidia-graphics-[^/]*/)?libGL\.so\.[^/]* /usr/lib(64)?/(nvidia-graphics-[^/]*/)?libGLcore\.so\.[^/]* /usr/lib(64)?/(nvidia-graphics-[^/]*/)?libXvMCNVIDIA\.so\.[^/]* /usr/lib(64)?/(nvidia-graphics-[^/]*/)?libnvidia-cfg\.so\.[^/]* /usr/lib(64)?/(nvidia-graphics-[^/]*/)?libnvidia-tls\.so\.[^/]* /usr/lib(64)?/(nvidia-graphics-[^/]*/)?tls/libnvidia-tls\.so\.[^/]* The above covers both conventional nvidia installs, too. But I don't really know which libs need special selinux treatment. For example libnvidia-wfb is a very fresh part of the driver only used with nv80 hardware, so s/o with such a hardware would have to report on selinux issues I guess, or not? Thanks!
Of course, to perhaps state the obvious, "9746" is the current version number. There are other legacy versions still out there and new one no doubt on the way...
Has this been fixed yet? I am still a little unsure whether this is to be fixed (by you :) in the base policy or by Axel in his rpm spec file. Thanks
The specificatons have been fixed in the base policy. nvidia should fix their libraries. Axel should not need to change anything.
It seems that this is still not fixed. What exactly does nvidia need to change or if they are unresponsive is there anything Axel could possibly do (if he is willing) to fix this? If you tell me exactly what needs to be done by nvidia, I would be happy to file a bug report on their forum
The best source of information on this topic is at http://people.redhat.com/~drepper/selinux-mem.html I have added Uli to the CC list to see if he has any other comments.
It's not possible to exactly tell NVidia what is needed since we don't have access to the sources. Given their goal of speed I assume they have hand-written asm code which is not PIC safe. Or C/C++ code could miss the -fpic/-fPIC option since they think it eats up too much performance. http://people.redhat.com/drepper/textrelocs.html
Fixed in current release