How do you troubleshoot bwrap/wine sandboxes for Windows games?
I use Wine to play Windows games. As is well known:
- Wine is not a sandbox
- Windows games are proprietary blobs and can contain malware
- Windows malware can potentially harm Linux through Wine
I don't want malware having free reign on my Linux machine so I sandbox it with bwrap. For the less-informed, bwrap is the low-level tool used for flatpak, which is used by Wine Bottles, a popular Wine tool. In practice I see that attempting to set up sandboxes with Flatpak or Bottles (what it calls "dedicated sandbox") results in very similar behavior to the CLI command bwrap wine foo.exe.
I noticed that as I try to restrict a game with bwrap, there are often files that it requires access to, and fails without. For example, many games need access to /sys/devices/system/cpu and /dev/nvidia0 (not surprising). The problem is to find all such possible path when the game is failing.
As a general approach I can always:
- Confirm the game runs with all paths permitted
- Confirm the game fails with only some paths permitted
- Keep adding a few paths from 1 to 2 until it works
This sort of works, but of course it's not very practical. Is there some direct way to see what files the game is trying to access inside the bwrap wine, and failing?
1 answer
I've done this exact thing with these same tools, as recently as this morning.
I use strace to measure file access sometimes; trouble is, a lot of programs/libraries will attempt to look for a lot of files that don't need to exist, so combing through the strace logs can be a long slog too. In theory, I could have written a script that would correlate those logs with paths that actually exist in my host filesystem. In practice, generally I do the same 1-2-3 dance you describe and only supplement that with strace when I'm stumped.
0 comment threads
0 comment threads