6 ms·

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 e

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

jessfraz 12y ago
lol Alex I didn't give people commands to remove their root filesystem ;) also thanks for the overlayfs patch its amazing
- alexlarsson 12y ago
  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.
  - jessfraz 12y ago
    yes but you are kinda ruining the point, this is a fun hack with Docker, take it or leave it, that's all.
    - eropple 12y ago
      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.
      - walterbell 12y ago
        Yes, see Qubes to understand the level of effort required for robust isolation between desktop AppVMs.
        eropple 12y ago
        Totally. It's not a simple task, and what this post describes creates a threat model that I would generously term "dire."
    - geofft 12y ago
      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.)
      - jessfraz 12y ago
        The commands I give are fine. 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.
        eropple 12y 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.
        geofft 12y ago
        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.
    - rdtsc 12y ago
      "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.
teraflop 12y ago
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.
- geofft 12y ago
  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.
- zobzu 12y ago
  If you break the app you have +- the same access.. see if you break irssi you're not root either. 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.
Iv 12y ago
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.
jdub 12y ago
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. :-) http://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxed-linux-desktop-app/ http://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxe... http://www.youtube.com/watch?v=t-2a_XYJPEY http://www.youtube.com/watch?v=t-2a_XYJPEY Like Ron Burgundy, he's... "kind of a big deal". (Suffer the compliments, Alex.)

jessfraz 12y ago

lol Alex I didn't give people commands to remove their root filesystem ;) also thanks for the overlayfs patch its amazing

alexlarsson 12y ago
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.
- jessfraz 12y ago
  yes but you are kinda ruining the point, this is a fun hack with Docker, take it or leave it, that's all.
  - eropple 12y ago
    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.
    - walterbell 12y ago
      Yes, see Qubes to understand the level of effort required for robust isolation between desktop AppVMs.
      - eropple 12y ago
        Totally. It's not a simple task, and what this post describes creates a threat model that I would generously term "dire."
  - geofft 12y ago
    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.)
    - jessfraz 12y ago
      The commands I give are fine. 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.
      - eropple 12y 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.
        geofft 12y ago
        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.
  - rdtsc 12y ago
    "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.

teraflop 12y ago

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.

geofft 12y ago
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.
zobzu 12y ago
If you break the app you have +- the same access.. see if you break irssi you're not root either. 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.

Iv 12y ago

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.

jdub 12y ago

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. :-) http://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxed-linux-desktop-app/ http://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxe... http://www.youtube.com/watch?v=t-2a_XYJPEY http://www.youtube.com/watch?v=t-2a_XYJPEY Like Ron Burgundy, he's... "kind of a big deal". (Suffer the compliments, Alex.)