|
|
|
|
|
|
by eropple
4133 days ago
|
|
|
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. |
|
|
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.