Docker containers on the desktop

What did Alex say that hinges on you consciously mounting root into a container? Either you've given the unprivileged host user access to the Docker socket (implicitly giving permission to run any container, which enables a hostile to mount root inside a container) or you're running as the host's root user. This is, by my lights, an anti-sandbox--there's separation of file system (though not really any security not offered by the file system) at the cost of major privilege escalation and the kind of false empowerment that leads people to do dumb, risky things. And it really bears very little resemblance to the Apple sandboxing system to which you are attempting to equate it.

(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.

I spent a few years working on general-purpose security sandboxing for Linux desktop apps (as a master's thesis), and gave up. The problem is that there are a bunch of common-sense things like not giving access to the root filesystem, and a million less common-sense things that also give you the ability to escape the sandbox. It really sucks.

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.

Right, but the fact that such large ecosystems have originated out of these high-level abstractions (on top of Docker you have all the container clustering and orchestration platforms, homegrown PaaS and whatnot) shows that there is indeed something lacking.

What the OP probably meant is that none of these solutions are actually a seamless part of the workflow when using the OS.

It's impossible to secure direct, unfiltered access to the X11 protocol: the protocol, by its nature, involves no access controls on who owns what widgets, who gets to inject events, and so forth.

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.