5 ms·

I think it should be pretty obvious why people put things into containers :-) Few main points though, which pushed me making this Docker container: 1. I want

• Gonzih 10y ago
  So you don't trust application code, but you trust image makers code?.
  • ihsw 10y ago
    I think the parent author meant they trust the explicit and narrow boundaries the application code is permitted to run in.
  • coldtea 10y ago
    He can always check the image specification, no?
  • swsieber 10y ago
    Yes? (Not the OP) The image build instructions are pretty easy to audit. And I trust docker (to an extent). So in my mind it's safer, but not absolutely safe. I just view it as another layer of security :)
  • arno1 10y ago
    This thread is not about to what extent I trust things. But security-wise, running it in a container is better, than running it without isolation. IMHO. And of course, no one asks getting this image built by the 3rd party, since the Dockerfile is open, just build it yourself ;-)
    • kordless 10y ago
      There is very little reason to believe that escalated privileges are not possible within a given virtualized environment, at least with current technologies. Containers are great for development and production on your own infrastructure, or shared infrastructure like GCE or AWS. Security can be had from doing inspected builds, self signing, etc. For consumers, however, it's a completely different ballgame.
      • MichaelBurge 10y ago
        All those Docker commands usually run as root or something equivalent to root. So a container breakout could lead to root on the host system. I think kordless is claiming that using Docker here could increase the severity of an attack; otherwise it doesn't seem like putting up another barrier could hurt security, even if it is later broken.
        • arno1 10y ago
          I would say, using a Docker would move the vector of attack to a Docker engine and a Linux kernel implementation of cgroups, naming spaces. But it would still help in preventing such bugs as https://github.com/valvesoftware/steam-for-linux/issues/3671 https://github.com/valvesoftware/steam-for-linux/issues/3671 HN discussion: https://news.ycombinator.com/item?id=8896186 https://news.ycombinator.com/item?id=8896186
        • kordless 10y ago
          My claim would be applied to all virtualized environments, including containers and VMs - not just Docker. Microkernels have a decent shot at keeping the security issue at bay, but even then it can't keep them out forever. Everything falls to hacking eventually. That's the nature of it, at least till now. I would note that Docker is primarily a tool for developers and operations folk who are also the author of the software being run. Docker itself is not the risk here, but using it for some use cases may very well be.
      • jerf 10y ago
        I'd be more worried about the game doing something accidentally bad to my system than deliberate hacking: https://github.com/valvesoftware/steam-for-linux/issues/3671 https://github.com/valvesoftware/steam-for-linux/issues/3671 By the time serious hacking is an issue through Steam, I'd expect containers will be that much better anyhow. For all they can be criticized, and regardless of whether you think some other approach would have been better, they're getting the "trial by fire" treatment. By hook or by crook, in another year or two I expect they'll be as secure as you could ask for.
  • 010a 10y ago
    Fundamentally, it is fewer things that I _have_ to trust. The shim which defines an image should be much easier to grok than the entire application.
• djsumdog 10y ago
  There's a Steam overlay in Gentoo, and it mostly works, but lately I've had a lot of issues with ATI's open source drivers and Steam, to the point where I just setup a windows machine for games. This looks really promising though, and shows a practical use case for docker.