Now that Steam is officially available on Linux, I am very interested in it!

However, I wonder what is the security system in Steam?

When I download a game through Steam, will the game run as native application that has complete access to user data or in a sandboxed environment with declared permissions (similar to Android)?

  • 1
    I find it highly unlikely that it would be sandboxed, but I suppose it's possible. Feb 16, 2013 at 18:45
  • @SevenSidedDie Since it is a cross-platform system, the games are probably running in a virtualised enviroment, in which case it is easy to sandbox it.
    – HRJ
    Feb 17, 2013 at 5:53
  • 7
    The games are ported, not run in a virtualised environment. There is no emulation or compatibility layers in the Steam for Linux design. (That's why there is a limited selection available right now, rather than the whole library.) Given that, the only sandboxing that makes sense is if Steam launched each game in a chroot jail, and I'd be surprised if doing that even occurred to the Valve devs. Feb 17, 2013 at 6:37
  • @SevenSidedDie Thanks for confirming it is not virtualised. So Steam is just a store + perhaps some networking API? Steam downloads about 175MB of stuff upon first installation; I wonder what exactly it provides.
    – HRJ
    Feb 17, 2013 at 10:00
  • 1
    Most of this stuff is graphical assets for the skin and Big Picture Mode which is a lot of eye candy. The client itself and the necessary binaries are rather small.
    – user28015
    Sep 26, 2014 at 2:53

4 Answers 4


Steam doesn't use sandboxes. For example, in Windows, Steam games usually save their data in My Documents, Appdata, their own installation folder or Steam's Steam Cloud folder (which syncs back to the online storage service for your saves, configurations and other user data). Some even install other programs, like a multiplayer component's library (e.g.: Games for Windows - LIVE).

Valve, however, put some restrictions in place to prevent unwanted behaviour, like a game installing a publisher's games marketplace without asking. The only thing closest to doing that is Ubisoft's uPlay, which Ubisoft wanted to use for updating their games, so instead of shipping the full client each game comes with a mini version that lacks the marketplace and can only be started when you start its associated game.

Games on Steam are mostly the same as their retail counterparts, only slightly modified to use Steam's authentication DRM and made downloadable through Steam's servers.

Steam offers additional services in return, like automatic updates, cloud synchronisation of game user data, achievements, leaderboards and other personalised data (look at a user's Team Fortress 2 stats for an example) and more.

  • Would you do a DLL dependency check via ldd, if you have installed Steam under Linux? It would be highly interesting to see whether they modified the game binaries to require Steam to run, and, if so, how.
    – DrFish
    Feb 20, 2013 at 9:09
  • ``` ldd which steam not a dynamic executable ```
    – HRJ
    Feb 20, 2013 at 13:28

Steam doesn't protect your system from untrusted games, or from itself.

You might be interested in Stéphane Graber's article on using LXC to do this, and the steam-lxc project he created for that purpose.

September 2014 Update:

I finally got around to setting this up myself. The links above are a little out of date, but Stéphane posted a more recent set of articles on LXC 1.0 that were very helpful. Between those and a bit of experimenting, I got Steam working in an unprivileged container, and it works pretty well.

Warning: Even if you run Steam (and its games) in a container, it will normally still be able to access your screen, mouse, and keyboard via the X protocol. Some X extensions exist for mitigating this problem, but I have not yet tried running Steam as an untrusted X client. One simple way to limit this exposure is to create a separate linux user account for your Steam container, use your desktop environment's "switch user" feature to log in as that user for playing games, and switch between that desktop session and your normal desktop session as needed. Since this approach uses a separate X server session for Steam, X protocol sniffing shouldn't be possible, though the GPU and its drivers might still be exploitable across X servers.

My command line for creating the container:

lxc-create -n steambox -t download -- -d ubuntu -r trusty -a amd64

I edited my container config file to look something like this:

# Distribution configuration
lxc.include = /usr/share/lxc/config/ubuntu.common.conf
lxc.include = /usr/share/lxc/config/ubuntu.userns.conf
lxc.arch = x86_64

# Container specific configuration
lxc.id_map = u 0 100000 1000
lxc.id_map = g 0 100000 1000
lxc.id_map = u 1000 1000 1
lxc.id_map = g 1000 1000 1
lxc.id_map = u 1001 101001 64535
lxc.id_map = g 1001 101001 64535
lxc.rootfs = /home/myusername/.local/share/lxc/steambox/rootfs
lxc.utsname = steambox

# Network
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = lxcbr0
lxc.network.hwaddr = 00:16:3e:77:88:99

# Video
lxc.mount.entry = /tmp/.X11-unix tmp/.X11-unix none bind,optional,create=dir
lxc.mount.entry = /dev/dri dev/dri none bind,optional,create=dir
lxc.mount.entry = /dev/nvidia0 dev/nvidia0 none bind,optional,create=file
lxc.mount.entry = /dev/nvidiactl dev/nvidiactl none bind,optional,create=file
#lxc.cgroup.devices.allow = c 195:* rwm
# video0 doesn't exist on my system.
#lxc.mount.entry = /dev/video0 dev/video0 none bind,optional,create=file

# Sound
lxc.mount.entry = /dev/snd dev/snd none bind,optional,create=dir

# Game Controllers
# Steam uses SDL for controller support; SDL uses udev and /dev/input/*
lxc.mount.entry = /dev/input dev/input none bind,optional,create=dir
#lxc.cgroup.devices.allow = c 13:* r
# uinput might be needed for gamepad support with streaming
#lxc.mount.entry = /dev/uinput dev/uinput none bind,optional,create=file
#lxc.cgroup.devices.allow = c 10:223 rwm

# for debugging
#lxc.aa_profile = unconfined


This is only meant to get you started. You'll still have to set up your host system as described in the articles, and probably reboot it, before it will work. Please don't ask me to troubleshoot your system.

I'm running Ubuntu with an nVidia card. Different distributions and video cards will probably require a few different paths, device file names, and device numbers.

Note that I haven't set lxc.cgroup.devices.deny = a yet, so the container isn't quite as locked down as it could be. (I'll change that once I finish experimenting.)

I had to install the same nVidia driver package in the container that I have on the host. (Even a minor version number mismatch caused errors when Steam tried to use the driver.)

I deliberately used the amd64 architecture and the Ubuntu Trusty release for my container, despite the fact that Valve supports only i386 and Precise. I did this because I want Valve's spyware to count me among those using a modern OS, in hopes that they'll start supporting it sooner.

Once I had steam working in the container, I set up a launcher script on my host system. It's named steam and lives in my PATH, so steam command lines work pretty much just like they would if Steam was installed normally. Here's the script:



# Execute a command in the container, with X display support
run_in_container() {
  lxc-attach --clear-env -n $CONTAINER -- sudo -u $RUNASUSER -i \
    env DISPLAY="$DISPLAY" "$@"

# Find joystick devices so we can tell Steam's old SDL library to use them
# https://github.com/ValveSoftware/steam-for-linux/issues/1894#issuecomment-25295972
enum_joysticks() {
  local joyprop=ID_INPUT_JOYSTICK=1
  for f in /dev/input/*; do
    if [ ! -c "$f" ]; then
    elif udevadm info --query=property --name="$f" | grep --quiet $joyprop; then
      echo "$f"

# Use the first arg as a separator to join the remaining args
join() {
  local IFS="$1"
  echo "$*"

# Use an environment variable to help Steam's old SDL version find gamepads
run_steam_with_joysticks() {
  run_in_container SDL_JOYSTICK_DEVICE="$(join : $(enum_joysticks))" \

if ! lxc-wait -n $CONTAINER -s RUNNING -t 0; then
    lxc-start -n $CONTAINER -d
    lxc-wait -n $CONTAINER -s RUNNING

run_in_container xauth add $(xauth list | sed 's/^.*\///')
run_steam_with_joysticks "$@"

if [ "$STARTED" = "true" ]; then
    lxc-stop -n $CONTAINER -t 10

The enum_joysticks, join, and SDL_JOYSTICK_DEVICE= parts are only there to work around a Steam bug that prevents Big Picture Mode from detecting game controllers on an Ubuntu Trusty system. You could probably remove those parts from the script if your container is running Ubuntu Precise or you don't use Big Picture Mode.

With that script installed in my PATH, I can copy the each game's .desktop file from my container to my host system to make the game appear in my applications menu. (I usually copy the icon as well, or edit the .desktop file to name an icon that's installed on my host.)

cp /home/myusername/.local/share/lxc/steambox/rootfs/home/ubuntu/.local/share/applications/thegame.dekstop /home/myusername/.local/share/applications/

Good luck!

  • Indeed, I had started looking at lxc too, for this and other such uses. The links you posted are a great head start.
    – HRJ
    Oct 20, 2013 at 4:56
  • September update: thanks for the original and the recipe for unprivileged containers. I have been using LXCs quite a bit and I suspect this thread started my first foray into using them!
    – HRJ
    Sep 26, 2014 at 6:40

Flatpak can be used to run Linux applications in a container. Flathub, which hosts and distributes containerized apps for flatpak, has the Steam app. Once you've installed the flatpak Steam app you can then run it via flatpak run -v com.valvesoftware.Steam/x86_64/stable

  • Heh; nice to see a reply after 7 years. As of today, I am indeed using flatpak to run Steam! Though, can you confirm whether the games themselves run inside the flatpak sandbox, or is it only the launcher that does?
    – HRJ
    Feb 5, 2021 at 17:57
  • @HRJ Any child/descendant processes of a containerized process are also inside the container, otherwise it would be trivially easy escape the sandbox. In Feb 5, 2021 at 22:43
  • true but then there are many combinations of permissions possible, and some combination might allow an escape. A completely hypothetical example: the dbus permission might allow an application to be launched via the dbus protocol, and flatpak allows dbus permission to be granted to apps. So, some level of scrutiny is still required.
    – HRJ
    Feb 7, 2021 at 6:09

You can use a partition with Steam Os to run all Steam games in a safe place separated from your files. All the files the games will access are those within the partition, and the worst virus could do is to wipe or alter user files in that sandbox.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .