Avoiding indirect GLX for sandboxed Wine app

[haarp]

Greetings,

I have an untrusted Windows app running under Wine in need of 3D acceleration. When I remove its ability to use the net with --network=none, I'm getting

X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  154 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)

After some googling, it appears that starting X with the +iglx parameter (indirect GLX) seems to solve the problem. And indeed, it does! However, indirect GLX usually appears to be necessary to run 3D application over the network (which I'm not doing), and it is a possible security vulnerability.

I suspect that indirect GLX is needed because I disabled network access for my app. So I tried the alternative mentioned in the firejail manpage, which is --protocol=unix. This however makes the app not start at all.

I would like to avoid needing indirect GLX, but without giving the untrusted app network access. What are my options?

Thanks a lot!

[totaam]

Try https://virtualgl.org/
All it needs is a socket connection to the real X11 server with GPU access.
This socket will only be used for opengl commands so it is pretty narrow and safe.

[haarp]

Thanks for your suggestion, totaam.

I've since found out that net=none was not responsible for my program failing with X errors. It was nogroups in Wine's profile, probably because it removed the video group. Is there a way to selectively keep groups?

[glitsj16]

Is there a way to selectively keep groups?

@haarp You can try the allusers option.

[haarp]

@glitsj16

You can try the allusers option.

Yes, I've read that in the manpage. But adding allusers does not seem to make a difference, nor does it or nogroups have any options. The manpage is not clear how exactly allusers modifies behavior.

[glitsj16]

@haarp I guess your only alternative for now is to use a wine.local with ignore nogroups or to use --ignore=nogroups in the command that starts this application. I have zero experience with wine. Cannot really judge whether or not this constitutes a bug in the profile. Do you see this behaviour in other wine applications that need 3D accel?

[Vincent43]

Generally on modern systemd based distro, static resource access control by groups (like video, audio, etc.) isn't used anymore so I think ignore nogroups is acceptable workaround for corner cases.

[haarp]

@glitsj16 This problem appears in any Wine app using 3D acceleration. At least on Nvidia hardware, Intel hardware does not appear to be affected. I would say this is a bug in the Wine profile, yes.

[Vincent43]

@haarp the problem is this can be fixed only by removing nogroups from wine profile which will reduce security for everyone regardless if they need it or not.

[rusty-snake]

Suggestion:

# Cause issues with 3D acceleration with nVidia,
# comment or put 'ignore nogroups' in your wine.local.
nogroups

[haarp]

@Vincent43 I'm aware if that. I'm not sure how to solve this properly myself. But please bear in mind that a modern distro does not imply systemd.

Further research revealed that for Nvidia GLX to work, the user needs access to /dev/nvidia0 and /dev/nvidiactl (possibly /dev/nvidia-modeset too, for apps that change the resolution?) which is usually handled by giving the video group rw rights to it, and adding users in need of 3D acceleration to this group.

This actually concerns any application wishing to do 3D acceleration on an Nvidia card (with the propietary drivers), it is not limited to Wine! Easily tested with firejail --nogroups glxgears.

So while @rusty-snake 's suggestion is a start (even if not very discoverable), it needs to be applied to all apps that might do 3D acceleration, and which currently have nogroups set.

[Vincent43]

For nvidia even systemd may not help although I'm not sure. Perhaps you should add ignore nogroups to globals.local

[haarp]

For nvidia even systemd may not help although I'm not sure. Perhaps you should add ignore nogroups to globals.local

Yes, that's a good workaround for now. But I'm wondering how to properly fix this in the future, for everybody. Possibly by providing finer-grained control over user groups? 3D acceleration isn't the only use case where a group might be necessary for a certain task, while all other groups can be removed.

[rusty-snake]

• more gradual control over supplementary groups #2042
• https://github.com/netblue30/firejail/wiki/Frequently-Asked-Questions#3d-acceleration-with-nvidia-hardware

I'm closing here because the original question in answered.