Sandboxing games

Huitsi

Not to be confused with sandbox games.

(tl;dr: Games would benefit from sandboxing simply due to amount of different games there are. However, sandboxing a game is non-trivial for a player, so we as developers should think of ways to make our games easy to run sandboxed.)

Sandboxing (isolating from parts of the system in hopes of security benefits) games is something I've thought a lot about lately and I'd be curious to know if anyone else has any thoughts on this. I've added some of mine below.

Why should games be sandboxed?

The main thing that makes me want to sandbox games specifically is the amount of different games I run, many of which aren't available in distro repos (which is also not a guarantee on non-maliciousness, much less non-vulnerability). And while sandboxing can't make running them perfectly safe, it would be nice to at least require malicious actors to put in more effort.

Apart from straight up malicious games, games can also have vulnerabilities (see here for example), which a sandbox could help mitigate. And of course, some games have a system of loading third party mods which the original dev hasn't audited.

Another thing about games is that they typically should only need to access a small part of the filesystem – their own config and savegames plus some read-only access to some libraries etc. Restricting them to that just seems prudent.

How to sandbox games as a player?

Sandboxing is part of the core packaging model of both Flatpak and Snap, so software installed through them may be effectively sadboxed out of the box. I say "may" however, since you can't trust them blindly. For example, Flatpak will happily give an installed package whatever extra access rights it requests. Snap sandoxing uses AppArmor becoming ineffective if that isn't available.

Websites are sandboxed by browsers as a matter of course, so web games are also automatically sandboxed. Pesonally, browser sandboxes are among the ones I find the easiest to trust as they are protecting countless people against loads of untrusted code every day. Using them, of course, requires there to be a web port of the game that then has to suffer the limitations of the platform.

There are also some standalone sandboxing programs, Firejail being the perhaps best-known example. Pre-made profiles exist for some programs, but in practice you'll end up writing your own, and my experience with that hasn't been great. To get the best possible sandbox, you'll want to start by forbidding as much as possible, which unfortunately does not tend to be the default state. And only after getting that sorted do you get to start the painstaking process of figuring out what rights the sandboxed program actually needs.

The biggest hammer in the sandboxing toolbox are virtual machines. VMs certainly provide the most isolation while still running on the same machine. This comes at the cost of performance, especially for graphics and thus games. Native contexts might however improve the situation.

How to sandbox games as a developer?

So, sandboxing as the end user is a pain. Could we as developers provide an easy way to sandbox our games? I could see providing the extra security and being easier to trust being worth the effort.

Providing Flatpak and/or Snap packages and/or web ports is the only standardised way I know of providing your software pre-sandboxed in a way verifiable at a glance (assuming you trust the sandbox of course). I have considered proving Firejail or or AppArmor profiles, but that would require extra action on the user side, meaning the effort would only end up benefiting a minority of users. I also fear such profiles would end up being too complex to check easily, reducing the trust benefit.

Certainly any game processing untrusted input, especially code-executing mods, should consider sandboxing itself somehow. I'll mention Landlock, which is a new(-ish) way for a Linux process to restrict itself, but other methods exist as well.

Again, I'd be curious to know if anyone else has any thoughts on this and what they might be.

ffaf

No thoughts, just to let you know your column was interesting and made me think.

As a developer I feel a bit overwhelmed to be honest, as in I have never seen something developed using the language I use (Haskell) using flatpak.

I guess if you write for a widely emulated machine, you don't need sandboxing :P

Huitsi

ffaf No thoughts, just to let you know your column was interesting and made me think.

Thanks!

As a developer I feel a bit overwhelmed to be honest, as in I have never seen something developed using the language I use (Haskell) using flatpak.

Yeah, if the tools you need to build aren't included in the SDKs, building Flatpaks gets complicated. Basically you'll need to build the build tools too, or include some pre-built binaries in the "source".

I guess if you write for a widely emulated machine, you don't need sandboxing :P

I honestly completely forgot about emulators. You are right, targeting an emulated system means the emulator is the sandbox, so nothing further is required of you. This is essentially the same situation as with targeting the web. Emulators themselves are still prime candidates for (self-)sandboxing, however.

In other news, I did end up making an AppArmor profile for my simple C/SDL2/GLES2 game. It wasn't too bad once I worked around a bug in the tooling. The profile ended up looking like this. It might look simple, but there is a LOT of stuff in the abstractions, and I know that at least X and dbus (not sure how the "strict" part affects it) are potential avenues for sandbox escape.

TPW

Hmmh. While I honor the fundamental idea to improve user security, I see some structural problems.

When the developer offers a security mechanism, the user still have to trust the developer. All of these mechanisms are potentially unsafe (note that this is not a purely academical issues: 1 2. Technical inapt users can not check if the security mechanism offered to them is relatively secure, or just a diversion, while apt users can - especially when it comes to FLOSS games - already take measures. So, in the end, it always comes back to "checking yourself" or "trust the developer".

And while one could say that - even if it only helps a bit - there is nothing lost by doing it, there is no way of sandboxing a game without loosing resources the one way or the other. This goes not only for the hardware resources of the player, but also for the developers time. I already struggle to find enough time (and energy) to code - pre-packing and supporting additional security measures with only relative use would further reduce this.

Maybe a possible alternative to such a technical solution would be a web-of-trust-attempt? Known, trustworthy FLOSS-game devs do a quick check of a new releases source code, and if there ain't anything fishy, the md5-sum and version number could be released on a whitelist. Would still require the players to do some thinking before executing something (but then again: You can't really help against this!). The drawback is that this would take again time, and you'd need to find people willing to do this - again for a rather questionable benefit.

Personally, I'm rather inexorable when it comes to running indie games (including, but not limited to FLOSS) on my system. In most cases, I'm nearly the only one who plays them anyway - so I assume that people who try to spread malicious code are likely to search for more effective vectors.

Huitsi

TPW Hmmh. While I honor the fundamental idea to improve user security, I see some structural problems.

Thanks for your thoughts!

When the developer offers a security mechanism, the user still have to trust the developer. All of these mechanisms are potentially unsafe (note that this is not a purely academical issues: 1 2. Technical inapt users can not check if the security mechanism offered to them is relatively secure, or just a diversion, while apt users can - especially when it comes to FLOSS games - already take measures. So, in the end, it always comes back to "checking yourself" or "trust the developer".

Checking that a well-known sandbox is in effect should be considerably easier than properly checking anything but the smallest programs. The effort still varies from "just running it in a browser/emulator" to "checking the AppArmor/Firejail/etc. profile". Even the latter is easier than actually going through and understanding the entire source code.

After that, of course, you still have to trust the sandbox. Vulnerabilities will always be a concern, but finding and abusing one raises the cost of an attack significantly. As for link 1, I know Flatpak suffers from the mentality of being a distribution method first, and sandbox second. After five years since the last one, the Flatkill site could use another update though. Link 2, on the other hand, just makes the case for (self-)sandboxing emulators.

And while one could say that - even if it only helps a bit - there is nothing lost by doing it, there is no way of sandboxing a game without loosing resources the one way or the other. This goes not only for the hardware resources of the player, but also for the developers time. I already struggle to find enough time (and energy) to code - pre-packing and supporting additional security measures with only relative use would further reduce this.

Yes, there are absolutely costs to sandboxing. I'd still argue it can be worthwhile. In particular, a lot of the sandboxing methods are a part of widely used distribution channels, meaning that

the performance/hardware costs are already accepted by a lot of people, and
targeting them can potentially mean reaching new audiences.

Maybe a possible alternative to such a technical solution would be a web-of-trust-attempt? Known, trustworthy FLOSS-game devs do a quick check of a new releases source code, and if there ain't anything fishy, the md5-sum and version number could be released on a whitelist. Would still require the players to do some thinking before executing something (but then again: You can't really help against this!). The drawback is that this would take again time, and you'd need to find people willing to do this - again for a rather questionable benefit.

I'm afraid I don't think this it at all feasible. Problems include:

finding trustworthy people willing to do this,
the sheer volume of (even FLOSS) games,
a proper, competent review is a huge amount of effort,
and also, MD5 has been considered insecure for over a decade :P.

Personally, I'm rather inexorable when it comes to running indie games (including, but not limited to FLOSS) on my system. In most cases, I'm nearly the only one who plays them anyway - so I assume that people who try to spread malicious code are likely to search for more effective vectors.

I only got paranoid about this relatively recently myself. You're absolutely right that FLOSS games are not the most attractive vector for anyone looking to hit a lot of high-value targets. I'd still feel a lot better if abusing that vector wasn't so easy.