mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #3144] Avoiding indirect GLX for sandboxed Wine app #1975
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#1975
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @haarp on GitHub (Jan 14, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3144
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
After some googling, it appears that starting X with the
+iglxparameter (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 commented on GitHub (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 commented on GitHub (Jan 15, 2020):
Thanks for your suggestion, totaam.
I've since found out that
net=nonewas not responsible for my program failing with X errors. It wasnogroupsin Wine's profile, probably because it removed thevideogroup. Is there a way to selectively keep groups?@ghost commented on GitHub (Jan 16, 2020):
@haarp You can try the
allusersoption.@haarp commented on GitHub (Jan 16, 2020):
@glitsj16
Yes, I've read that in the manpage. But adding
allusersdoes not seem to make a difference, nor does it ornogroupshave any options. The manpage is not clear how exactly allusers modifies behavior.@ghost commented on GitHub (Jan 16, 2020):
@haarp I guess your only alternative for now is to use a wine.local with
ignore nogroupsor to use--ignore=nogroupsin 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 commented on GitHub (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 thinkignore nogroupsis acceptable workaround for corner cases.@haarp commented on GitHub (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 commented on GitHub (Jan 16, 2020):
@haarp the problem is this can be fixed only by removing
nogroupsfrom wine profile which will reduce security for everyone regardless if they need it or not.@rusty-snake commented on GitHub (Jan 16, 2020):
Suggestion:
@haarp commented on GitHub (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/nvidia0and/dev/nvidiactl(possibly/dev/nvidia-modesettoo, for apps that change the resolution?) which is usually handled by giving thevideogroup 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
nogroupsset.@Vincent43 commented on GitHub (Jan 17, 2020):
For nvidia even systemd may not help although I'm not sure. Perhaps you should add
ignore nogroupstoglobals.local@haarp commented on GitHub (Jan 17, 2020):
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 commented on GitHub (Feb 10, 2020):
I'm closing here because the original question in answered.