EGL backend security

[Takanori Nakane]

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

[DRC]

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.

[Takanori Nakane]

Hi,

Thank you very much for clarification.

This is very instructive in setting up our HPC cluster.

Best regards,

Takanori Nakane