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@xxxxxxxxxxxxxxxx :: lmorgul on irc.freenode.net
"The only thing necessary for the triumph of evil is for good men
to do nothing." (Edmond Burke)
