Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoiding indirect GLX for sandboxed Wine app #3144

Closed
haarp opened this issue Jan 14, 2020 · 13 comments
Closed

Avoiding indirect GLX for sandboxed Wine app #3144

haarp opened this issue Jan 14, 2020 · 13 comments
Labels
information_old (Deprecated; use "doc-todo" or "needinfo" instead) Information was/is required

Comments

@haarp
Copy link
Contributor

haarp commented Jan 14, 2020

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
Copy link

totaam commented Jan 14, 2020

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
Copy link
Contributor Author

haarp commented Jan 15, 2020

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
Copy link
Collaborator

Is there a way to selectively keep groups?

@haarp You can try the allusers option.

@haarp
Copy link
Contributor Author

haarp commented Jan 16, 2020

@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
Copy link
Collaborator

@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
Copy link
Collaborator

Vincent43 commented Jan 16, 2020

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
Copy link
Contributor Author

haarp commented Jan 16, 2020

@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
Copy link
Collaborator

@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
Copy link
Collaborator

Suggestion:

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

@haarp
Copy link
Contributor Author

haarp commented Jan 16, 2020

@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
Copy link
Collaborator

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

@haarp
Copy link
Contributor Author

haarp commented Jan 17, 2020

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 rusty-snake added the information_old (Deprecated; use "doc-todo" or "needinfo" instead) Information was/is required label Feb 10, 2020
@rusty-snake
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
information_old (Deprecated; use "doc-todo" or "needinfo" instead) Information was/is required
Projects
None yet
Development

No branches or pull requests

5 participants