Bug 221278 - selinux errors with nVidia video driver
selinux errors with nVidia video driver
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-03 10:09 EST by Need Real Name
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-22 10:14:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2007-01-03 10:09:27 EST
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)
Comment 1 Daniel Walsh 2007-01-03 16:28:10 EST
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.
Comment 2 Axel Thimm 2007-01-03 21:47:47 EST
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!
Comment 3 Daniel Walsh 2007-01-08 15:41:34 EST
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
Comment 4 Axel Thimm 2007-01-08 16:51:39 EST
> 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!
Comment 5 Need Real Name 2007-01-08 17:10:03 EST
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...
Comment 6 Need Real Name 2007-01-14 12:32:51 EST
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
Comment 7 Daniel Walsh 2007-01-15 10:06:35 EST
The specificatons have been fixed in the base policy.  nvidia should fix their
libraries.  Axel should not need to change anything.
Comment 8 Need Real Name 2007-03-27 20:27:26 EDT
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
Comment 9 Daniel Walsh 2007-03-28 08:44:40 EDT
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.


Comment 10 Ulrich Drepper 2007-03-29 12:29:36 EDT
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
Comment 11 Daniel Walsh 2007-08-22 10:14:01 EDT
Fixed in current release

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