This is not sandboxing. Quite the opposite, this gives the apps root access:<p>First of all, X11 is completely unsecure, the "sandboxed" app has full access to every other X11 client. Thus, its very easy to write a simple X app that looks for say a terminal window and injects key events (say using Xtest extension) in it to type whatever it wants. Here is another example that sniffs the key events, including when you unlock the lock screen: <a href="https://github.com/magcius/keylog" rel="nofollow">https://github.com/magcius/keylog</a><p>Secondly, if you have docker access you have root access. You can easily run something like:<p>docker run -v /:/tmp ubuntu rm -rf /tmp/*<p>Which will remove all the files on your system.
This is neat.<p>But.<p>Docker isn't sandboxing in a security sense. It's sandboxing in a deployment sense: given a friendly app and a friendly host, the app can get an environment it wants without bothering the host to adapt too much. Given two friendly apps and a friendly host, the two apps can see different environments.<p>Given an unfriendly app, Docker is no different from running the unfriendly app directly.<p>I think the really cool thing about this is that, given how straightforward these examples look, you can use this as a deployment platform: go use whatever weird Linux distro you want, and still be able to run software that's only supported on an Ubuntu LTS.<p>But I think the comparison to Apple's sandbox is misleading, and also vaguely unfair to the good work that Apple has done in building a <i>security</i> sandbox.
I hate that the isolation of containers gets oversold as a security feature because there is real value in what you might call "configuration isolation".<p>Often, I am reluctant to run something not because of a trust issue but a complexity issue. I run a heavily customized environment. I will often be burned by an application---for example---creating a symlink that under "normal" circumstances is perfectly copacetic but all but destroys some carefully crafted aspect of my environment. Similarly, isolation that is not up to the task of stopping evil is often more than adequate for stopping stupid (e.g., the recent "Steam deletes your home directory" issue). How often have you updated your system only to have one or two apps misbehave? With what jessfraz presents here, yum and apt become tools you can apply selectively. There are real non-security benefits to be had.<p>I realize that part of the oversell is the nature of hype but I can't help but feel that a---perhaps---equal part is that talking about these kinds of benefits is a more subtle and nuanced conversation.
Ignoring X11 security, I have also used this technique successfully in certain situations. See: <a href="https://github.com/samtstern/android-vagrant" rel="nofollow">https://github.com/samtstern/android-vagrant</a><p>That allows anyone on Linux to download, install, and run Android Studio with a single 'docker run ...' command, and for Mac/Windows users to do the same within a VM using just 'vagrant up'. It's not something I'd use to run Android Studio myself, but it's great to get someone quickly up and running without messing with all of the environment headaches (Android SDK location, Java version, etc).
In a recent article on sandboxing in linux [1] it was mentioned that "X11 is impossible to secure". I'm not sure how deep that goes, or whether it's relevant to what's been done here.<p>Could someone more knowledgeable comment?<p>[1]: <a href="http://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxed-linux-desktop-app/" rel="nofollow">http://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxe...</a>
Aside from the security issues with X11 I've never had a good experience from a usability perspective with X11 on OS X. Basic actions like resizing windows need to offer a native-quality experience before mass adoption can happen. Disclaimer: I'm not sure if this was a limitation of the apps or of X11
This reminds me of the subuser project (<a href="http://subuser.org/" rel="nofollow">http://subuser.org/</a>) which is basically about using Docker to achieve sandboxing - the project is effectively aiming to build a linux package manager out of Docker.<p>Several commenters have pointed out the very real security issues with opening the X11 port. This is true, but you could use ssh forwarding or VNC (at a considerable performance penalty). I believe the other security issues (mainly related to PID 0 and which user processes are run at) will be solved shortly. Running applications in Docker is never going to be as secure as running an app in a full VM, but it can definitely be better than trusting random code on the internet (the recent Steam client issue springs to mind).
You can also use just LXC to do the same: <a href="https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/" rel="nofollow">https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-container...</a>
Are Docker containers actually sensibly secure as sandboxes? I thought there were still some gaps that needed to be closed in the underlying tech for it to be as safe as virtualization?
These are great - I'm already using docker containers for nearly everything I do for development, and now I'm inspired to continue the trend into all the other applications on my system. They're more portable (I keep my zsh aliases in github) and it'll keep my Arch/i3 install cleaner too. Thanks for the tips. I think my next step will be to start assigning the apps to their own workspaces in i3. Great post.
<a href="https://www.usenix.org/legacy/events/atc10/tech/full_papers/Potter.pdf" rel="nofollow">https://www.usenix.org/legacy/events/atc10/tech/full_papers/...</a><p>Abstract<p>Desktop computers are often compromised by the interaction of untrusted data and buggy software. To address this problem, we present Apiary, a system that transparently contains application faults while retaining the usage metaphors of a traditional desktop environment. Apiary accomplishes this with three key mechanisms. It isolates applications in containers that integrate in a controlled manner at the display and file system. It introduces ephemeral containers that are quickly instantiated for single application execution, to prevent any exploit that occurs from persisting and to protect user privacy. It introduces the Virtual Layered File System to make instantiating containers fast and space efficient, and to make managing many containers no more complex than a single traditional desktop. We have implemented Apiary on Linux without any application or operating system kernel changes. Our results with real applications, known exploits, and a 24-person user study show that Apiary has modest performance overhead, is effective in limiting the damage from real vulnerabilities, and is as easy for users to use as a traditional desktop.
I was missing a docker container that hosts the Xserver and produces the X socket for the other GUI containers. This would be great for non-gui docker management platforms such as CoreOS.
Would this be a good way to deploy an opencv based solution?<p>I spent an entire day getting opencv with Python bindings installed on my Mac and I'm dreading deploying it anywhere else.