Are Steam games sandboxed?

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.

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

# EOF

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:

#!/bin/sh

CONTAINER=steambox
RUNASUSER=ubuntu
STEAMCOMMAND=/usr/games/steam

# 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
      continue
    elif udevadm info --query=property --name="$f" | grep --quiet $joyprop; then
      echo "$f"
    fi
  done
}

# Use the first arg as a separator to join the remaining args
join() {
  local IFS="$1"
  shift
  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))" \
    $STEAMCOMMAND "$@"
}

STARTED=false
if ! lxc-wait -n $CONTAINER -s RUNNING -t 0; then
    lxc-start -n $CONTAINER -d
    lxc-wait -n $CONTAINER -s RUNNING
    STARTED=true
fi

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

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

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!