Remix.run Logo
galad87 2 hours ago

Games are an almost perfect type of software to be run in a sandbox. The question is, why aren't they already run in a sandbox?

ux266478 an hour ago | parent | next [-]

SteamOS leverages namespaces via pressure-vessel already. The problem exists exclusively on Windows. Paravirtualized drivers introduce API incompatibility issues and decades of cumulative engine infrastructure made for Windows using the Win32 API means nobody wants to swap over to using UWP and thus AppContainers are a non-starter (and that's without getting to sacrificing Wine/Proton compatibility).

The native isolation mechanisms like silos are things that require wrangling by professional sysadmins, I didn't even know they existed until I started writing this post. The real question to be asking is why is sandboxing so bad on Windows? Despite some searching, I still have no conclusive answer as to how to go about filesystem isolation in Win32-space, or if it's even possible.

malkia an hour ago | parent [-]

Sandboxing is quite easy (user-wise), once you install the sandbox system. By default it allows only a single sandbox, and with small `.wsb` file you can drive what's visible from the host, whether the GPU should be active, etc. - https://learn.microsoft.com/en-us/windows/security/applicati...

It's great for testing, and Sandbox is just the tip of the iceberg of what Windows Containers support

- e.g. maybe someone can come up with "launcher" that goes through it (somehow).

Aerroon an hour ago | parent | prev | next [-]

They are? Games need pretty much all the performance they can possibly get. Can you sandbox them without having a performance impact?

Consider that people pay a $300 premium to get ~10% better performance (buying an RTX 5080 instead of a 5070 Ti).

Personally I know that sometimes closing the web browser in the background makes my game run better - that web browser doesn't even interact with the game! Would a sandbox have a smaller impact?

blueg3 38 minutes ago | parent | next [-]

It certainly could.

Buying a better GPU improves your graphics performance and that's basically unrelated to the area where a sandbox impacts performance.

Killing your web browser is probably just lowering memory pressure?

Sandboxes add overhead to syscalls. It's kind of similar to running under Wine, which also adds significant syscalls overhead. Wine also has a much more impactful DirectX translation layer, so your sandbox performance would be probably be much better than the Wine performance.

devmor 28 minutes ago | parent [-]

> your sandbox performance would be probably be much better than the Wine performance.

That’s hard to believe, given that many games run better under WINE than native Windows.

chainingsolid 26 minutes ago | parent | prev [-]

Most of the sandboxing you need for a game is less full sandbox and more a whitelist on file access and local network communication.

pjc50 an hour ago | parent | prev | next [-]

PC games tend to be the reverse: they demand control over the machine, in order to try to detect or prevent being run alongside various forms of cheating software.

They also need low-latency access to the GPU, which I suspect is a fertile vector for privilege escape exploits.

blueg3 an hour ago | parent [-]

Only a relatively small (but popular) subset of games use anticheat. Most games -- including the one in this article -- could theoretically run in a sandbox.

1bpp 2 hours ago | parent | prev | next [-]

Every Xbox game runs in a HyperV container, maybe it's not a crazy idea for PC

wao0uuno 2 hours ago | parent | prev | next [-]

Running games on Linux via Proton provides some isolation. It’s not technically a proper sandbox though.

parasense an hour ago | parent | next [-]

Proton is just emulation, and it will happily expose the underlying host system to the running game software. In particular the filesystem and some peripheral devices. However, Valve is moving towards sandboxing in Steam. You can already run the whole thing with a flatpak sandbox, and valve themselves are using ostree. With srvio is possible to run the whole thing in a throwaway windows vm while the graphics card is passed through

sophrosyne42 an hour ago | parent [-]

This is why it was foolish to give a new name to it. It was originally called Wine Is Not an Emulator.

zufallsheld 28 minutes ago | parent [-]

It's not a new name. Proton is Valve's fork of wine. They also contribute patches to wine.

unethical_ban 6 minutes ago | parent [-]

I think their point is proton is not an emulator.

q3k an hour ago | parent | prev | next [-]

You can just use Linux syscalls from an .exe executed by Wine. There is no sandboxing.

https://gist.github.com/q3k/e5952111283ea59ee78a7699919a055b

SuperNinKenDo 2 hours ago | parent | prev [-]

Anything that wants to traverse your filesystem could do so trivially from a wineprefix, but stuff like sniffing your browser extensions might be harder depending on the technique.

allthetime 41 minutes ago | parent | prev | next [-]

They often are on macOS now. https://developer.apple.com/documentation/security/accessing...

blitzar an hour ago | parent | prev | next [-]

Is this not just an artifact of windows not sandboxing anything meaningfully and that itself is an artifact of punch cards?

sph an hour ago | parent | prev | next [-]

I run Proton in Steam flatpak, as well as itch.io from flatpak. That is reasonable enough isolation for my use case.

nubinetwork an hour ago | parent | prev | next [-]

Some anti piracy is already a sandbox.

SuperNinKenDo 2 hours ago | parent | prev | next [-]

I've formally studied gamedev, but haven't done anything in over a decade, but even before you get to the thorny issue of anti-cheat sustems, games rely on running at a(n often very) low level and doing unconventional things. I imagine they're one of the hardest things there are to sandbox without causing massive levels of breakage. But someone more knowledgeable about either side of the equation (sandboxing and/or game development) might be able to shed more light.

wotsdat an hour ago | parent | prev [-]

[dead]