tech-101-linux-games-and-solitary-confinement.md 4.1 KB

Title: Tech 101: Linux, games and solitary confinement Date: 2018-09-22 Modified: 2018-09-22 Category: Blog Slug: tech-101-linux-games-and-solitary-confinement Tags: tech-101, howto, games, security Summary: How to use Firejail to stop proprietary games learning, or sharing, things they shouldn't

[Something about coauthoring and notes about who's saying what]

"You can say it's a compiler problem, or a tool problem, but actually, it's my problem, because I have to fix it."

  • Yossi Kreinin (or at least, paraphrased from him)

Games are fun - or at least they should be. Many people play them, myself included, and as with many other things, a computer can be of great help. Even though I love traditional games, computer-based gaming has an appeal that they cannot match due to the (frankly amazing) processing power a computer can bring to the problem of keeping you entertained. However, unfortunately, very few games are open-source, and this is a fact that is very unlikely to change in the near (or distant) future. This is unfortunate, but there's not much we can do it about it.

That being said, however, we want to make sure that we don't [more justification here]

[structure of what we plan to do]

[mention multiplayer games are out of scope]

[mention Wine is out of scope because lol]

The problem

Before we can start solving any sort of security issue, it's important to understand precisely what we're trying to protect from. This is known as a threat model, and without one of these, any attempts at security are bound to be mediocre at best, and useless at worst. In the context of proprietary games, your primary issue is information. More exactly, it's important that any game whose codebase you cannot study:

  • Has no ability to learn of anything it shouldn't (such as your SSH keys, for instance); and
  • Even if it does learn something it shouldn't, has no ability to send this information anywhere.

Thus, what we really want to do is confine: essentially, the game should run in a place where any information not essential to it functioning simply doesn't exist (or can't be accessed, same thing), and we should give it no ability to break out of this environment either by itself (by gaining capabilities it shouldn't have) or indirectly (by sending something out).

[maybe more?]

The solution

So now that we know what we need to protect ourselves from, it's time to consider how we can go about doing that. Given what we want, there is a tool that seems suited to the task: Firejail. While it's certainly capable of significantly more than what we need, its main advantages are:

  • Configurability using text files
  • Integration of many different features needed to do our job
  • Availability (basically any decent distro packages Firejail)

[more content goes here]

An example

Let's consider a good example: Darkest Dungeon, from GOG. Let's go through the process of setting up a suitably sandboxed HOME, as well as a custom Firejail profile for it. Firstly, we need to create a directory for all our games to live in, with a sub-directory for those from GOG:

::sh
[koz@Sebastian ~]$ mkdir -p ~/games/gog

We can run the installer to put Darkest Dungeon in that folder; for the rest of this example, we'll assume we can find the 'starter script' at ~/games/gog/darkest-dungeon/start.sh. Let's also keep our game profiles in there too:

::sh
[koz@Sebastian ~]$ mkdir -p ~/games/profiles

Next, we can copy the default Firejail profile (under an appropriately-modified name) to that directory:

::sh
[koz@Sebastian ~]$ cp /etc/firejail/default.profile
~/games/profiles/darkest-dungeon.profile

[describe how we edit things to make it do what we want and why]

Conclusion

Obviously, this approach is not a panacea: it's quite possible that we have to adjust some of these in order to make certain games work. However, it does provide a very good starting point for securing other proprietary games. [something in closing]