7 ms·

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.

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.