As a summer project, I'm looking to prevent any piece of proprietary software like many games I run from have access to my personal files. After looking a lot at sandboxing, I've decided that anything like chroot is far too complicated for me to use, as simplicity=security. I've created a user all these applications will be run as, and ensured only members of my personal account's group, which this user isn't in, can access my documents. Things seem at a surface level like they're working (especially after I added it to the video group), but I thought it prudent to ask what security issues still exist.

  • Can an application steal control of Control-Alt-Fn[1-12]?
    • Can an application read what's happening on another x server run by the other user?
  • Does it matter if my account for proprietary software has a weak password?
  • Since my /home/$USER folder itself gives no permissions to anyone not in my group or me, it doesn't matter what permissions the files in there have, does it? The file names inside can't be read, can they?
  • Wine doesn't do any funky system-level things that would be a vulnerability, does it?
  • Are there any vulnerabilities through the /tmp directory?
  • Are there any other vulnerabilities, that any application running in that account could use to get access to my documents?
  • What are the good practices for this sort of thing?

I'm running debian testing. Any advice would be appreciated.

  • 3
    If you want to be completely secure: don't run the program! Alternately, things like VMs (see Qubes-OS) are the best available.
    – Ali Lown
    Aug 12, 2011 at 21:37

2 Answers 2


Chroot wouldn't give you any security anyway, it's only designed for very specific use cases. See Debian unstable chroot security issues and chroot "jail" - what is it and how do I use it?.

Any application that has access to the X server can do a lot of things. It can snoop on other applications that display windows on the same server. It can log key presses. It can rebind keys. It can inject key presses into other applications. It has access to the clipboard. If you run the untrusted applications on an X server where you never run any application that runs as your ordinary user, this is not a concern, except that the application can remove your ability to switch to another console.

Wine itself doesn't run with elevated privileges. The X server does (it runs as root), so if there's a vulnerability in it, you've lost. There's an effort going on to avoid running the X server as root, but that involves moving parts of the code into the kernel driver which runs with the utmost privilege level. You always need to trust your kernel.

Any application can access files in /tmp and /var/tmp. If this is a concern, don't use these directories for your own files. It's very easy to set up per-user temporary directories: install the libpam-tmpdir package. Applications can also access other data that you may consider sensitive, such as the list of users on your system, the list of programs you have installed, etc. Data underneath a directory that's not readable (more precisely, has no execute permission) by the application cannot be accessed by the application.

If the applications are not too demanding (in particular not too graphics-intensive), run them in a dedicated OS installation in a virtual machine. This is the most isolation you can get short of dedicated hardware. Deny that virtual machine network access, and don't put any sensitive data in it — this gives you double protection against privacy violations.


The most secure approach is to run the proprietary software in a virtual machine (VM). This is pretty simple to set up, and you can find free VMs (e.g., VirtualBox). However, since you mention games, this may not work for games (it may produce unacceptable performance degradation in some graphics-intensive games).

Another possibility is to install a second copy of the OS on a separate partition on the hard-drive, and then reboot into your "for-fun" OS when you want to run the proprietary applications. However, this is probably too much of a pain to use in practice.

A third possibility, if you can install the software from a user (non-root) account, is to create a new user account for your proprietary software, install the software as that account, and run it from that account. You might not even need to log out and log back in, if you use sudo or 'ssh -X' (although this could cause some loss of security because of fundamental vulnerabilities in the X protocol).

A fourth possibility, if you are running on a Linux distribution that supports SELinux, is to use SELinux's sandbox program. See, e.g., this Linux Foundation article, or Dan Walsh's blog post, Dan Walsh's slides on it. However, I'll warn you this might be a bit more fiddly to use.

If you want to get fancy, sandboxing.org, lists a number of other sandboxing technologies. For your purposes, Plash (see also the Plash wiki) is probably the most sophisticated and mature sandbox, so you could try Plash as well if you wanted.

Unfortunately, none of this is super-easy. I wish OS's made this a lot easier, but at present, I'm afraid it's a bit of a pain.

  • Some links doesn't work anymore: the Plash link and that one to the user report. Perhaps you could fix them or and include some information into your answer... would be great!
    – student
    Apr 24, 2014 at 19:48
  • @student, thanks for letting me know! I've updated my answer accordingly. Appreciate it.
    – D.W.
    Apr 24, 2014 at 20:23

You must log in to answer this question.