Hi, Thank you very much for clarification. This is very instructive in setting up our HPC cluster.
Best regards, Takanori Nakane On Sunday, July 7, 2024 at 12:38:20 AM UTC+9 DRC wrote: > Technically speaking, the GLX spec requires that GLX drawables be > accessible from other processes, so when using a conformant GLX > implementation with VirtualGL's GLX back end, it is absolutely possible > to snoop other users' Pbuffers. I am attaching example code that > demonstrates how to do that if you know the Pbuffer ID. > > In practice, this works with nVidia's drivers, because those drivers use > DRI2 (which allocates GPU buffers through the X server.) It doesn't > work with Mesa-based drivers, because those drivers use DRI3 (which > allocates GPU buffers in the X client.) DRI3-based drivers aren't > technically conformant with the GLX spec, because they disallow sharing > GLX drawables across process boundaries. However, that was always a > really esoteric and unreliably supported use case, and no modern OpenGL > applications of which I'm aware try to do that. Thus, DRI3-based > drivers gain a bit of security at the expense of sacrificing conformance > with a GLX feature that few applications ever used. > > Pbuffer snooping can be thwarted either by denying the snooper access to > the 3D X server or denying the snooper access to the /dev/nvidia* > devices, which is why vglserver_config allows both to be configured > separately. (NOTE: If you restrict framebuffer device access to the > vglusers group, then the account under which the display manager runs-- > gdm, for instance-- has to be in that group.) > > Now as to the EGL back end, it uses renderbuffer objects to emulate GLX > Pbuffers, and to the best of my understanding, RBOs cannot be shared > among multiple processes. In fact, because RBOs are confined to a > specific OpenGL context, it took some effort to implement the EGL back > end in such a way that the RBOs could be shared among multiple contexts > in the same process (a critical feature of GLX Pbuffers.) Thus, > securing the framebuffer devices is probably a belt-and-suspenders > measure if you are only using the EGL back end. > > There is a bit of history behind that as well. Back in the dawn of time > (the early 2000s) before EGL existed, Sun Microsystems had an API called > GLP that was specific to their framebuffers. GLP allowed you to create > Pbuffer contexts using a framebuffer device rather than a 3D X server, > and it was possible to snoop other users' Pbuffers through the GLP > device. Thus, it was necessary to provide sysadmins with the ability to > secure the GLP devices. When I implemented the EGL back end, I wanted to > give sysadmins the same ability with EGL devices. The truth is that I > haven't dug into the issue enough to know whether a snooping exploit is > possible with the EGL back end. It probably isn't, but I wanted to > allow for the possibility that it is. > > I will look into clarifying the documentation. > > > On 7/5/24 9:50 PM, Takanori Nakane wrote: > > Dear VirtualGL community, > > > > I would like to know security implications of the EGL backend. > > The > > document > https://rawcdn.githack.com/VirtualGL/virtualgl/3.1.1/doc/index.html#hd006003 > > says: > > > > > When using the EGL back end, the only way to share the application > > server’s GPU(s) among multiple users is to grant those users access to > > the device(s) associated with the GPU(s). > > > ... > > > Yes > > Only users in the vglusers group can run OpenGL applications on the > > VirtualGL server (the configuration script will create the vglusers > > group if it doesn’t already exist.) This limits the possibility that > > an unauthorized user could snoop the 3D framebuffer device(s) and thus > > see (or alter) the output of a 3D application that is being used with > > VirtualGL. > > > No > > Any authenticated user can run OpenGL applications on the VirtualGL > > server. If it is necessary for users outside of the vglusers group to > > log in locally to this server and run OpenGL applications, then this > > option must be selected. > > > > My confusion here is whether a user can snoop and interfere with other > > users' 3D applications. My intuition is no, because processes are > > isolated by kernel (just as one user cannot touch another user's CUDA > > application). But then, what is the point of limiting GPU access to > > the vglusers group? Is the restriction an *additional* layer of > > caution just in case there is a security flaw in the GPU driver or > kernel? > > > > For the GLX background, this old > > thread > https://virtualgl-users.narkive.com/KHab71sF/security-issues-for-virtualgl > > clarifies the situation. > > When sharing an X server (:0), > > 1. A *remote* user can snoop *local* X user's keystrokes but not other > > *remote* user's. > > 2. A *remote* user can snoop other users' (local or remote) 3D rendering. > > (I think it might be useful if this is clarified in the documentation) > > > > Best regards, > > > > Takanori Nakane -- You received this message because you are subscribed to the Google Groups "VirtualGL User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/80b5ede7-f203-43a3-92b0-c734784ea58bn%40googlegroups.com.
