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.
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
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = lxcbr0
lxc.network.hwaddr = 00:16:3e:77:88:99
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
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
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
for f in /dev/input/*; do
if [ ! -c "$f" ]; then
elif udevadm info --query=property --name="$f" | grep --quiet $joyprop; then
# Use the first arg as a separator to join the remaining args
# Use an environment variable to help Steam's old SDL version find gamepads
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/^.*\///')
if [ "$STARTED" = "true" ]; then
lxc-stop -n $CONTAINER -t 10
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/