Docker containers on the desktop
blog.jessfraz.com
blog.jessfraz.com
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: https://github.com/magcius/keylog
Secondly, if you have docker access you have root access. You can easily run something like:
docker run -v /:/tmp ubuntu rm -rf /tmp/*
Which will remove all the files on your system.
Once you have the images running the code in them could easily break out of the container via X11, and do things like sniff all keyboard events and inject events into any app.
Of course, the apps you put in the images probably are not doing that. But people need to be aware that this is not a sandbox they can run untrusted code in.
This sort of thing is irresponsible without the proper explanation of the dangers involved.
It's a fun hack, and I think if you said it was a fun hack instead of a security measure you'd have gotten a different reaction. (I agree it's a fun hack! It's just not a security measure.)
The one Alex gives in his comment mounts root into a container, something I am not saying at all or even close doing at all. No one should ever mount root in a container, its common sense.
(EDIT: And the Dockerfiles are running the applications inside as root. As mentioned elsewhere, Docker doesn't currently use user namespaces, so an RCE in Google Chrome has just been upgraded to a root RCE because of this. Feeling safe?)
I generally don't subscribe to a particularly absolutist view of the world, but this is a real bad thing and I pretty strongly feel that somebody who works on Docker not explaining the ramifications of this misuse of the technology is pretty irresponsible.
That ensures that any container-to-outside-user exploit can also turn into a container-to-root exploit.
If you have an X11 socket, then you can inject keystrokes to launch a new docker process that runs `rm -rf /`.
If you have write access to ~/.gnupg, as in the Mutt example, then you can edit ~/.gnupg/gpg.conf to set `exec-path ~/.gnupg/pwned`, so that keyserver helpers are looked up in that path, and then create an executable in that directory that runs docker to run `rm -rf /`. So the next time someone runs `gpg --search-keys` on the host....
Sandboxing applications is hard. There's a reason the only good UNIX sandboxes in general use are on iOS and Android, because they had no backwards-compatibility constraints, and even those sandboxes aren't perfect.
There's X11, as Alex mentioned. If you grant permissions to an app to use the X11 socket, it has the ability to inject keystrokes to any other application in the same X session. If you have a terminal open where you run "sudo", then the app can gain root.
Your gparted example gives the app access to the root partition. This allows it the ability to modify anything on the drive without going through the filesystem's security layer. It can go change root's password, modify setuid binaries, etc. It can then flush the disk cache by reading a lot of something else, ensuring that the next time the kernel wants to check root's password, it won't be cached.
Also, the state of the Linux kernel is such that if an app is running as UID 0 (even within a container), it probably has the ability to exploit some subtlety in the kernel interface to gain root. This is much reduced if you're using user namespaces (which, AIUI, Docker is not yet using), but it's still a risk. It's a huge risk without user namespaces.
If you trust the app, then you don't need an app (security) sandbox, which I think is what Alex is saying: "This is not sandboxing." If you don't trust the app, then Docker will not effectively restrict what the app can do to your system.
But now. He mentioned a valid security issue and instead of being glad and acknoweledging it you are dismissing it. With security issues that is not cool.
It doesn't help probably that you put "Docker" or "microservices" in the headline it would get upvoted to the top.
Of course, there have been other vulnerabilities in the past allowing containers to get root. And the X11 weakness alone is enough to not treat this as a security layer.
It's kind of like the general distaste for setuid binaries. If you have a correctly-written setuid binary, then you can use it to sandbox a process by, say, running it in a chroot. But if it's not correctly written, you have problems on your hands that far outweigh the problem you were originally trying to solve. So a random desktop app that ships with a setuid helper binary is going to be seen with suspicion. (Chrome is the only one I can think of that ships one, but they probably employ the people most qualified to write a bug-free setuid app, and they're getting rid of it in favor of user namespaces anyway.)
Of course, for the average developer desktop, processes probably have fifteen ways to gain passwordless root anyway. I certainly set sudo to nopasswd for convenience. :) So on a developer desktop, it's a nifty hack, although it doesn't gain you security against a malicious app/exploit. But as a general-purpose sandboxing approach, it's a bad tradeoff to make.
This stuff is only sort-of reliable when-containers-dont-have-root-bug-today if you run that as a separate user than yourself in a different X server
So basically not cool.
The way GNOME is doing ACTUAL sandboxing is much neater. Turns out it doesn't use Docker also. Go figure /sarcasm.
So your "when-containers-dont-have-root-bug-today" applies to Gnome too...
Also: there is no such thing as 'actual' sandboxing. There are many forms of sandboxing, containers (not docker-exclusive, as Gnome is using it exactly the same way) is one form, but we also know Virtual Machines, the Java VM, Javascript in a browser, ... the list goes on - all meaning the same thing: shield an application from everything else on the computer and try to prevent it from breaking out.
It does try to keep containers separated but it does not enforce thatthrough a particularly strong mechanism.
http://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxe...
http://www.youtube.com/watch?v=t-2a_XYJPEY
Like Ron Burgundy, he's... "kind of a big deal".
(Suffer the compliments, Alex.)
But.
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.
Given an unfriendly app, Docker is no different from running the unfriendly app directly.
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.
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 security sandbox.
I understand the risk of a kernel zero-day. But for Desktop apps, when used in conjunction with SELinux, can't Docker be considered to provide a level of sandboxing? In fact, I have not heard of any container breakouts. AFAIK, the only incidence that came close (but only worked on unpatched Docker) was https://news.ycombinator.com/item?id=7909622 and this was before their 1.0 release.
I'd like to hear your thoughts since a project I'm working on assumes that in a year's time containers will provide a Sandboxing alternative for server-side use. I can see some companies doing this already.
EDIT: X11 issues aside, as mentioned above by alexlarsson
Apart from things that you've explicitly given it access to (like device nodes), the risk of zero-days is higher because these sorts of things aren't quite zero-days: it's not fundamentally a violation of the kernel's security model for uid 0 to be able to do root-y things. You might want it to be unable to, and you might mostly succeed by not exposing certain device nodes, using a process namespace (CLONE_NEWPID) so it can't attach itself as a debugger to other things on the system, etc. etc. But there's no intent in the kernel to make this safe. It's mostly an emergent feature of other things, and emergent features make bad security features.
What you can do is run as not root, which still makes you the same as some other UID on the system, but guarantees that you're not risking increasing privileges. User namespaces give you a few additional features here: first, even the process of entering a chroot / container doesn't require root or a setuid binary, which is neat. Second, even if you're root inside the container, you're not root on the host system in the same sense, and it's just kernel code that's checking for uid == 0 (which should almost all be gone, since they changed the uid_t type in userns-enabled kernels) that thinks you're root.
SELinux might be able to help you here, and I'm not really familiar with what the standard recommendations for SELinux and Docker are. I'd basically consider applying it as if the container didn't exist: if you're comfortable with something running as root with SELinux confinement, then it's definitely fine to run as root inside Docker with SELinux confinement. If not, I wouldn't risk it.
For server containment, you should take a look at https://sandstorm.io/ , which uses user namespaces and runs apps as uid 1000 inside the namespace. This means that it's running with no more privilege than the host user in the worst case.
Note that local privilege escalation exploits in Linux are found regularly, like on a monthly basis, and every one is likely a Docker breakout.
geofft mentioned Sandstorm -- my project -- which actually does claim to be a sandbox, and isn't affected by most of these kernel exploits. Here's a blog post discussing the differences:
https://blog.sandstorm.io/news/2014-08-13-sandbox-security.h...
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.
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.
I'd say evil, people don't automate stupid.
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).
Unless i am badly off the mark, ld will use soname to tell lib v1.0 from v1.1 or v5.97. But the problem is with package manager flatly refusing to have anything to do with installing multiple lib versions side by side.
That is, if they have the same package name. End result is that one distro use glib3.xyz to designate glib 3.x, while another use glib-3.xyz Yet another use glib.3.xyz.
They all hold the same files, but for the package managers they are different packages. And will resolve dependencies based on that.
Applying containers and/or sandboxes to this is a Will E. Coyote solution...
So they "avoid" it by insisting on using a specific version for the duration of the distro version.
What the OP probably meant is that none of these solutions are actually a seamless part of the workflow when using the OS.
http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and...
One thing, though: Docker itself presents a privilege hole that can't be easily plugged, too. That's a large part of why I've expressed alarm upthread.
Could someone more knowledgeable comment?
[1]: http://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxe...
I'm not an unprivileged user on any machine I operate in any practical sense, nor are most Linux desktop users, so to me that point is largely moot. That is, even if I'm technically not root most of the time, if I run a malicious app it can relatively easily set up plenty of traps in my home directory to get me to run whatever code it want with elevated privileges sooner or later anyway. So from the outside, having the ability to run Docker does not expose me much more - get my user account, and chances are you get root if you're not completely inept.
That doesn't mean it wouldn't be good to get a better/more fine grained privilege model for Docker for other use cases.
Inside Docker containers, nothing stops us from having everything run as a regular user, though admittedly many Docker containers errs and runs everything as root often for no good reason (especially given that Docker's port forwarding/mapping means a lot of daemons that otherwise at least wants to start as root - even if it could be avoided - have even less reason to be started as root)
But even running as root, assuming an app that isn't malicious, barring me stupidly mounting "/" to a volume in the container, it won't e.g. do things like accidentally deleting [major system directory] (as some app did a while back), even if the app in the container is running as root (which is largely unnecessary, though admittedly done too often, in Docker containers).
It also won't barf files all over my filesystem for no good reason. And I won't accidentally expose ports I don't want to expose. Amongst many other things
I don't know how to say this in a way that isn't snarky, but: be better about your operational security, then. I run all of my Unix machines with the exception of the Mac I don't care about with a user not in /etc/sudoers. That you're tripping yourself up is your own fault.
That doesn't excuse this sort of recklessness being advocated by a Docker employee.
People have tried to make it more secure in various ways (trusted X, selinux X), but it is impossible because so much of the way X does things like DnD, cut-and-paste, window managers, etc that its just not possible to separate clients from each other without the entire thing breaking.
There is a "SECURITY" extension to X11, which is what's (often) used when you run ssh -X instead of ssh -Y. It doesn't quite support everything; I fairly often saw things like emacs crash when run with ssh -X. Furthermore, it provides only a single isolation boundary. Every app running with the security extension has access to each other. So, for this sort of use case, the best you could have is that all your Dockerized apps can mess with each other, but not with processes on the host, which isn't quite what you'd hope.
There's "security-enhanced X", but basically imagine SELinux applied to each widget on your screen (which is what it is). If you think making SELinux usable and secure is hard, you won't look forward to this.
I sketched a design a while ago for doing protocol-level filtering of X where each app effectively lived in its own namespace. Widgets, resources, etc. created by one app are inaccessible to another, because they're not nameable. A middle layer translates each name into a name in a common global namespace, so the X server is unmodified. I think this is doable but a lot of work, especially given how many extensions are in the X protocol. It also doesn't really help you if, say, your OpenGL stack isn't good at isolating one app from another.
I think the other promising approach is to use a remote-desktop like solution (like Xpra, or x11vnc, or something) which spawns a separate X11 server, and screen-scrapes it and passes it to the host. You lose a few things like OpenGL, and the overhead might get prohibitive if you run one X server per app, but the isolation is pretty solid.
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).
Denial of Service attacks are probably more straightforward than in a virtualized environment; I'm sure you could find a way to starve the kernel for something.
That said, there's currently no trivial "now I'm root on the host box" option or anything.
Please stop repeating this. Docker is not a security tool, apparently by their own decision. It hurts people to have that be part of the common knowledge.
For me it's about creating a setup that is far more easy to reproduce in the face of e.g. system upgrades, setting up a new machine, as well as protection against stupid mistakes, and about containing state.
And as another commenter pointed out, you can't give a user permission to actually start a docker container without also giving them root access to the host.
[1] https://docs.docker.com/articles/security/ [2] http://lwn.net/Articles/626665/
Abstract
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 spent an entire day getting opencv with Python bindings installed on my Mac and I'm dreading deploying it anywhere else.
So most of the question is whether you're happy with this as a distribution mechanism. The best you'll be able to do is something like VMware's Unity mode, which isn't bad, but isn't good either. Alternatively, you could run an X11 server on Windows (via Cygwin) and OS X (Xdarwin), but that's also going to look very non-native.
If you're not, then there's an open technical problem of how to make it look reasonable. I'd consider whether browser-based desktop apps are an option: you can require a recent Chrome or Firefox, come up with three common launchers for each platform (think PhoneGap), and then run the Linux backend inside a VM on Windows and OS X. But that seriously restricts the set of apps that are in scope, and at that point, you might also try just building a cross-platform backend (using Go, maybe?).