Xserver security

[Lekensteyn]

Bumblebee is currently not suited for multi-user systems. The X server can be accessed by all users.

Test case:

• Run optirun bash as an user which is allowed to start the X server
  • In the newly bash shell started by optirun, use DISPLAY=:0 xinput list and DISPLAY=:8 xinput list to verify that you're allowed to access the X server
  • Exit from that shell
• Run DISPLAY=:0 xinput list and DISPLAY=:8 xinput list again, it'll succeed which is OK
• Now change to another user (using su - user) and run DISPLAY=:0 xinput list and DISPLAY=:8 xinput list again. The first command fails which is fine, but the latter can still be run which is obviously not OK.

Options passed to X in /etc/init.d/bumblebee (man Xserver and Xorg --help):

-ac disables host-based access control mechanisms. Enables access by any host, and permits any host to modify the access control list. Use with extreme caution. This option exists primarily for running test suites remotely.
-sharevts share VTs with another X server (do not remove, it'll take over the current vty, the only way to correct this is to login remotely, e.g. SSH)
-noreset don't reset after last client exists

I haven't found a way yet to improve this. Perhaps we should just trust other users on the system. That's fine on a machine with no exposed services but problematic otherwise. Remember that all users on a machine can access the Bumblebee X server. This possibly allows for keyloggers by other unprivileged users on the system.

xauth looks interesting (check the manual page), but at that point I stopped searching.

[Samsagax]

I think we can manage this with the authority feature of X. Allowing only members of group 'bumblebee' on 'localhost' to access it. It should not be difficult and we won't have to use any {su,sudo,gksu} or anything to run bumblebee applications.

I know there is a 'policykit' thing (sort-off) to give some security to X servers. Maybe we can follow that.

[ArchangeGabriel]

Answer is in VirtualGL doc : there is actually no way to secure that.

VirtualGL requires access to the application server’s 3D graphics card so that it can create off-screen pixel buffers (Pbuffers) and redirect the 3D rendering from applications into these Pbuffers. Unfortunately, accessing a 3D graphics card on Linux and Solaris/x86 systems requires going through an X server. On such systems, the only way to share the application server’s 3D graphics card among multiple users is to grant those users access to the 3D X server (the X server attached to the application server’s 3D graphics card. Refer to the figures in Chapter 2.)

It is important to understand the security risks associated with this. Once a user has access to the 3D X server, there is nothing that would prevent the user from logging keystrokes or reading back images from that X server. Using xauth, one can obtain “untrusted” X authentication keys which prevent such exploits, but unfortunately, those untrusted keys also disallow access to the 3D hardware. Thus, it is necessary to grant full trusted access to the 3D X server for any>users that will need to run VirtualGL. Unless you fully trust the users to whom you are granting this access, then you should avoid logging in locally to the 3D X server (particularly as root) unless absolutely necessary.

[Samsagax]

Maybe you should look at this section of the User's Guide:

http://www.virtualgl.org/vgldoc/2_2_1/#hd005