This is not sandboxing. Quite the opposite, this gives the apps root access:
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:
Just so everyone knows, this is Alex "I have a weird interest in application bundling systems" Larsson, who is doing some badass bleeding edge work on full on sandboxed desktop applications on Linux. :-)
Yes, I think that it is important to make this point around as docker gains popularity: security is not part of their original design. The problem they apparently wanted to solve initially is the ability for a linux binary to run, whatever its dependencies are, on any system.
It does try to keep containers separated but it does not enforce thatthrough a particularly strong mechanism.
AFAIK, breaking out of a Docker container isn't as trivial as the first part of your comment suggests. In particular, a Docker container can't run other Docker commands unless you grant it access with something like "docker run -v /var/run/docker.sock:/var/run/docker.sock".
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.
I'm not entirely sure what Alex meant there, but I think his comment there was that the only way to be able to make use of this (at least until user namespace support lands in Docker) is for the user to have effective root on the system. So even if the sandboxing works, it's being done at a cost of requiring that, outside the sandbox, the users have an easy and passwordless way to gain root. This not only gives apps way more power than they had in the event of a sandbox escape mechanism (like the X11 socket), it also gives every unsandboxed app on the system way more power.
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.
Its super easy to get out of this container. Just connect to the x socket, then look for a terminal window, the start injecting keyboard input into it.
Gnome sandboxing uses exactly the same technologies behind the scenes as Docker uses: cgroups, namespaces, ... They add the additional requirement that they need Wayland to circumvent the security issues that X11 presents them. Other than that, you could do it just the same way.
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.
Not sure what you mean, any user with access to docker can run processes as root, with any part of the host system mounted into the container. Now, that access was not added by you, but its required to be able to run your images.
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.
You wrote, "I know that the rest of my system is completely unaffected from anything the app does." This is unfortunately not true.
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.
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.
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.
Yeah, that's also an interesting point: in order to use Docker, the host user must have (effective) root capabilities on the host.
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.
What is he ruining by pointing out security vulnerabilities in this "fun hack"? (Something you're claiming in that blog post is beneficial, so I'm not exactly buying your retroactive characterization here.)
This sort of thing is irresponsible without the proper explanation of the dangers involved.
"Take it or leave it" is cool if it is a game or "I like the font to be blue" or "you are using Haskell, why don't you use Javascript instead". They should totally leave it and move on.
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.
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.