On Thu, 2004-04-29 at 09:20 -0400, Daniel J Walsh wrote:
Andrew Farris wrote:
>On Wed, 2004-04-28 at 11:40 -0400, Daniel J Walsh wrote:
>>Andrew Farris wrote:
>>>I am working toward getting Enforcing mode to work with
the nvidia
>>>binary drivers, and having some difficulties. I see that there is some
>>>policy with this intention , but it is not quite adequate yet, as below.
>>>Some hints how to proceed, or solutions to this would be appreciated.
>>>Running enforcing with /dev/nvidia* labeled as xserver_misc_device_t:
>>>
>>>Apr 26 17:13:59 CirithUngol kernel: audit(1083024839.937:0): avc:
>>>denied { read write } for pid=15200 exe=/usr/X11R6/bin/glxinfo
>>>name=nvidiactl dev=hdb8 ino=65738 scontext=LordMorgul:user_r:user_t
>>>tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file
>>>
>>>Apr 26 17:14:04 CirithUngol kernel: audit(1083024844.641:0): avc:
>>>denied { read write } for pid=15209 exe=/usr/X11R6/bin/glxgears
>>>name=nvidiactl dev=hdb8 ino=65738 scontext=LordMorgul:user_r:user_t
>>>tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file
<snipped>
>Sorry about the extra size email, it is confusing. Yes, running
with
>the /dev/nvidia* devices labeled as xserver_misc_device_t will allow the
>X server to run and login.. etc. However it does NOT allow glxinfo or
>glxgears to run (they complain about access permissions
>to /dev/nvidiactl). I need policy that will allow user programs access
>{ read write } to /dev/nvidiactl before any OpenGL apps will run with
>these drivers (the same issue happens for Quake3, AAOps.. not just these
>GL test tools).
>
Not sure of the security ramifications, but does adding the following
fix your problem? This might
need to be a tunable.
diff -u base_user_macros.te~ base_user_macros.te
--- base_user_macros.te~ 2004-04-29 09:18:03.882721648 -0400
+++ base_user_macros.te 2004-04-29 09:18:58.802372592 -0400
@@ -250,6 +250,9 @@
')dnl end ifdef xdm.te
+# Access the special XServer devices.
+allow $1_t xserver_misc_device_t:chr_file rw_file_perms;
+
# Access the sound device.
allow $1_t sound_device_t:chr_file { getattr read write ioctl };
Yes, this does fix the problem, although in my case this last change
only really needed to apply to /dev/nvidiactl, and not the whole set
of /dev/nvidia* device nodes. If it is worth the bloat, another type
could be used for the single node.
For a desktop or workstation system, which should be the ONLY systems
running these closed source drivers, the security issues are probably
minimal -- Although the system could be brought down by these drivers,
having no source to the encrypted driver would probably make it
difficult to exploit. Is this a minor issue?
It would be very nice if this were tunable, so that the policy would
enable the device type, label the devices, and allow this access. A
similar problem may exist for the ATI closed source drivers as well.
What I have done (including your latest) is summarized below:
1) create type xserver_misc_device_t in types/devices.te
2) add entry to label the devices in file_contexts/program/xserver.fc
3) uncomment access to the devices in macros/program/xserver_macros.te
4) add above patch to base_user_macros.te to allow user access
If anyone is following along and would like to check if this works for
their setup as well, the patch below can be applied with:
cd /etc/security/selinux/src/policy
patch -p1 < /path/to/saved/diff-file
patch to test this first workaround available at:
http://webpages.charter.net/cirithungol/fedora/policy-nvidia-dev.patch
--
Andrew Farris, CPE senior (California Polytechnic State University, SLO)
fedora(a)andrewfarris.com :: lmorgul on
irc.freenode.net
"The only thing necessary for the triumph of evil is for good men
to do nothing." (Edmond Burke)