On 8/17/11 12:24 PM, Yushu Yao wrote: > I'm trying to deploy VirtualGL to a production machine (which uses LDAP > authentication and has GPFS mounts). I do not want to restrict access to > the vglusers group. Just wondering what are the security risks I should > consider? > > I don't know much about how X server/VGL works, so any suggestion is > greatly appreciated. > > Also in the VGL manual the following statement kind of worries me: > > "Disabling XTEST will not prevent a user from logging keystrokes or > reading images from the 3D X server, but if a user has access to the 3D > X server, disabling XTEST will prevent them from inserting keystrokes or > mouse events and thus hijacking local X sessions on that X server. " > > Does this mean that any user using VGL will be able to log keystrokes of > other users? Any link to detailed docs will be very helpful too.
No, what it means is that anyone who has access to display :0 will theoretically be able to log any keystrokes sent to that display only. There are 2 basic security issues to bear in mind with VGL: (1) If a user is logged in remotely and is using VirtualGL, that means they have access to display :0. Thus, they can theoretically snoop the keystrokes or view the desktop of someone who is logged in locally to the machine. Solution? Don't log in locally using the X server, unless you are sure no one is on the machine. The only one who should ever need to log in locally is the SysAdmin, and they can administer the machine using VNC or SSH or remote X or the local text console. In fact, switching to the local text console will disable anyone's ability to use display :0 with VirtualGL, so this effectively turns off VirtualGL use temporarily. (2) A VirtualGL user can theoretically snoop the 3D rendering commands and rendered 3D images being transferred between other users' applications and display :0. In the past, some ultra-paranoid users, such as application service providers that had multiple companies sharing the same machine, saw this as a problem, but those problems are largely solved through virtualization these days. If all of the VirtualGL users work for the same organization and there are thus no IP concerns regarding the rendered 3D images, then this is a non-issue. It is the case that any user who has access to any X server can log events being sent to that X server or view the output of the X server. That's simply the way X11 works. It has nothing to do with VirtualGL specifically, except that we are having to go through the X server to get access to the 3D hardware. Sun did some work regarding direct 3D hardware access on SPARC, using an API called GLP, and we tried to get vendors interested in using the EGL API (http://www.khronos.org/registry/egl/) for doing the same thing on x86 platforms, but unfortunately, no one seems to be interested in this. Thus, we have to jump through some hoops to access the root X server in as secure a manner as possible. Restricting access to vglusers is mainly useful if you are in a less controlled IT environment, in which many users will be logging into the machine but not all will be using VirtualGL. It just gives you a way of knowing who has access to your root X server. However, if most users in your organization will be using VirtualGL, there is no benefit to using the vglusers restriction. ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
