10 ms·

Don't expose the docker socket, even to a container

133 points by lvh 11y ago

deleted 11y ago
[deleted]
alpb 11y ago
dockerd -- nope. It's `docker -d`
- nailer 11y ago
  'daemonisedthingd' is standard UNIX terminology.
benwilber0 11y ago
Docker is not a sandbox and was never intended to be. A comprehensive SELinux profile for untrusted Docker containers could be developed, but I've yet to see one. If you want to run untrusted Docker containers, then this is what you want.
0x400614 11y ago
I don't understand the point of Docker. It seems like a great product. For any serious production grade containerization , I'd use a real virtualization solution like KVM, or VMWare.
- geofft 11y ago
  It's containerization between trustworthy apps; it's not security containerization. What it gets you is, if you have one application that's designed to run well on RHEL 5 with /usr/bin/python pointing to Python 2.4, and another one that's designed to run well on Debian testing with a manual /usr/bin/python symlink to Python 3, you can give both of them what they want. This has nothing to do with security. If you want Docker + security isolation, I'm intrigued by Clear Containers, which is a lightweight KVM-based virtualization thing: https://lists.clearlinux.org/pipermail/dev/2015-September/000049.html https://lists.clearlinux.org/pipermail/dev/2015-September/00... https://lwn.net/Articles/644675/ https://lwn.net/Articles/644675/
  - takeda 11y ago
    > It's containerization between trustworthy apps; it's not security containerization. Isn't that what a process is? The containers in Linux are based on Jails from FreeBSD and zones from Solaris. They are absolutely there for security. Regarding the remaining part of your post, I understand what you are trying to show but python is a really bad example. You absolutely can have python 2 and 3 side by side, or even different minor versions. And with virtualenv or pyvenv (that came with 3.4) you can even have multiple installation of the sane version. If you add setuptools to your application you can easily generate single file package (I personally like wheel) the deployment is as simple as writing pip install myawesomeapp-1.0.py2.py3.whl it downloads all dependencies. There is not much that Docker would help, it only makes things more complex.
    - rdtsc 11y ago
      Pretty much. It is marketing multiple exiting open source Linux technologies (overlay file systems, namespacing for processes, network sockets, chroots) under a set of tools and bam! -- hundreds of millions of dollars in valuation.
      - superuser2 11y ago
        Well, more than that, it's packaging them into user-friendly tools and promoting the shit out of it. Still Docker the company's core value proposition is a hosted registry, something many savvy corporations will never go for. Docker the product could probably do just fine if the company were to fold.
        LoSboccacc 11y ago
        but the hosted registry is what your average distribution already provide under the form of packages. and with everything moving to services, I see the utility of actually using components diminishing fast (well except for those providing those services) but for everyone else, docker solves no actual problem that can't already be solved now.
- stephengillie 11y ago
  Any virtualization solution is going to require you manage an operating system. One of the goals of contanerization is for developers to only work with the application.
  - voltagex_ 11y ago
    Unfortunately most docker containers seem to bring along 200+mb of operating system with them.
    - stephengillie 11y ago
      The binaries have to run somewhere. Container evangelists love to espouse the purity of running any container on any dock OS, and this is as true as being able to migrate VMs between any host - it still comes down to what the application/VM needs from the underlying OS/hardware.
      - vidarh 11y ago
        Mostly it comes down to lack of experience with containers so far, and lack of tools. Most apps need very little from the underlying OS if you actually take the time to e.g. set up a toolchain with a build container that you then move the build artefacts out of to install into the final container. Instead you see a lot of containers that in effect include all the build dependencies and a nearly full OS pulled in by that. It is improving, though slowly.
    - xorcist 11y ago
      This. Only 2G, not 200M. I try to get people to package application plus dependencies yet this is what they do every time. Every single time. Plus they always base it on images from the Internet, so bascially we trust some stranger with root privileges to all our data. Not always on the same image of course.
    - davexunit 11y ago
      Yes, this is a fundamental issue with Docker and other container systems that work with raw disk images as their basic unit of information. I have implemented a container system for the GNU Guix package manager that doesn't have this image bloat problem because it doesn't use opaque disk images. We store packages in a content-addressable storage system, which allows us to know the precise dependency graph for any piece of software in the system. Since we know the full set of software needed for any container, we are able to share the same binaries amongst all containers on a single host via a bind mount.
- AgentME 11y ago
  Think of it like a tool for packaging and deploying applications with everything they need. Its purpose is closer to package managers than being a secure sandbox for running untrusted users' VMs.
  - vezzy-fnord 11y ago
    Funny, an article got posted here just an hour ago advocating against treating Docker like a package manager: http://vilkeliskis.com/blog/2015/09/23/docker_is_not_a_package_management_tool.html http://vilkeliskis.com/blog/2015/09/23/docker_is_not_a_packa... I'd be inclined to agree. The reductionist sum of mechanisms that make a Linux container have always been about detaching, multiplexing and partitioning kernel resource subsystems. Docker was the first program that really hyped it into the idea of being about application deployment, but I fear this gives people wrong impressions and makes the mistake of treating an emergent property as if it were a fundamental.
    - KirinDave 11y ago
      The first part of your post made sense. I have no idea what point you're trying to convey with the second part. That applications are not business logic over kernel resources is a curious argument to make.
  - doug1001 11y ago
    that was my initial impression i got from reading some posts on the Docker Site, and perhaps there is no consistent definition of "package manager"--to me though, the most difficult tasks a p/m must do are: reproducible builds, dependency management, conflict resolution among transitive dependencies, and the like. But Docker does none of these things as i understand it.
- jkyle 11y ago
  KVM & VMWare are not containerization, they're full virtualization. There are a lot of benefits to containers and they don't have to be insecure. More efficient resource utilization and orders of magnitude faster allocation and launching to name two. Google runs a significant portion of its internal operations in a container infrastructure and has for quite a while.[1] They're perfectly capable of deployment into production environments. I won't comment on docker as I haven't spent the time to fully grok all its warts. 1. http://research.google.com/pubs/pub43438.html http://research.google.com/pubs/pub43438.html
  - _yy 11y ago
    > Google runs a significant portion of its internal operations in a container infrastructure and has for quite a while.[1] They use containers inside virtual machines. Virtualization for security, containers for deployment.
    - jkyle 11y ago
      I know from Joe Beda's talk [1] they run vm's inside containers for scenarios where they need a managed os. And that those containers run on bare metal. But I can't speak to the reverse not being an employee or authority on Google's internals. 1. https://speakerdeck.com/jbeda/containers-at-scale https://speakerdeck.com/jbeda/containers-at-scale
- Pyxl101 11y ago
  Containerization and virtualization serve different purposes. VMs run actual operating systems within them. A single operating system runs many different containers, that each act something like processes running on that same OS, in a way where they're highly sandboxed and segmented from each other. If your goal is strong isolation, then VMs are definitely better today. The purpose of Docker and similar container technologies is not that kind of isolation. It's to package up and distribute applications in a way that's more decoupled than simply installing them all on the same system.
  - takeda 11y ago
    I'm not hiding that after I learned about Docker I became skeptic. It seems like yet another thing that people observed what Google was doing, and then implementing it wrong. Google is using containers instead of VMs. This still provides security isolation and allows them to use resources more efficiently (VM has overhead where you need a whole OS for every instance). This approach does not make much sense in public cloud, where you already run inside of VM and the overhead is really for Amazon not you. So I see Docker is now pivoting to be a package manager, but there are already tools that do that. You can argue that Docker is simpler but so was rpm when it started. As Docker will grow it will become more complex in order to support all functionality package format already provides. There might be an argument that you can run multiple Docker containers on a single host, but that's what processes are for. There is change happening, and looks like cloud companies want to create "cloud os", I guess Docker is step toward that direction, but at current state in don't see it offering anything valuable to the organization that uses it.
    - monkey26 11y ago
      Docker as a package manager somewhat matches my use, and I think it does its job well. As the packager, I can just create one "package" that any Linux distribution running Docker can install, instead of creating packages for multiple versions of many different distributions.
      - takeda 11y ago
- vacri 11y ago
  If your VMs are single-purpose, you don't necessarily need VMs. Containers are single-process things - they're not running syslog or cron or any of that overhead, for example. Docker is also big on ensuring you are using the literal same artifact in dev as on prod (assuming you change your team's workflow, of course). Which is the right thing to use is entirely dependent on your use case.
  - insaneirish 11y ago
    > Containers are single-process things - they're not running syslog or cron or any of that overhead, for example. You're either being entirely too prescriptive or interchanging containers and Docker freely when they are not equivalent, though one is a particular implementation of the other. People have been running containers that emulate a full system for quite a while (see FreeBSD jails, illumos/Solaris zones, Linux OpenVZ, LXC, etc.).
- tbronchain 11y ago
  We[1] believe that the point of Docker is to provide "application packages" (called containers), which is a big step ahead to deliver applications (using their words: build, ship, run). However, we also do believe the isolation containers provide isn't sufficient for multi-tenant usages. This is the main motivation behind Hyper, which run groups of container images (Pods) as Virtual Machines. [1] https://hyper.sh https://hyper.sh
hosay123 11y ago
I don't really get this, the implication is the container becomes more secure without access to the socket, yet it has access to the hundreds of local kernel APIs with which on the average month it can easily gain higher privileges than root, especially on contemporary machines where half the admins around these days don't even know what a security update looks like
- KirinDave 11y ago
  Why knowingly give a trivial breakout vector to code you don't trust?
notjack 11y ago
This assumes that Docker containers are being used like VMs. They're not designed to allow running isolated arbitrary code in some sort of multi-tenancy setup, they're designed to isolate dependencies and configuration between your own deployed services. This is a "security vulnerability" in the same way that putting up a white picket fence around a jail is - a gross mis-application of a tool built for a completely different purpose.
- insaneirish 11y ago
  > They're not designed to allow running isolated arbitrary code in some sort of multi-tenancy setup You mean Linux containers are not designed for this, nor are they designed to be secure. What a sad design failure. Some [1] container technology was developed with security as a first principle. [1]: http://us-east.manta.joyent.com/jmc/public/opensolaris/ARChive/PSARC/2002/174/zones-design.spec.opensolaris.pdf http://us-east.manta.joyent.com/jmc/public/opensolaris/ARChi...
  - notjack 11y ago
    I should clarify I mean Docker containers specifically, good point.
  - geofft 11y ago
    And you can run Docker containers on SmartOS, using "LX-branded zones", which do Linux syscall emulation: https://www.joyent.com/blog/triton-docker-and-the-best-of-all-worlds https://www.joyent.com/blog/triton-docker-and-the-best-of-al... I'd be curious if the Joyent folks believe Triton to have the security properties that everyone seems to want out of Docker. It doesn't involve the standard Docker daemon, so it might.
    - lloydde 11y ago
      @geofft that is a great link, our CTO Bryan Cantrill continued to beat the drum at the Docker SF meetup in May 6, 2015. Video and transcript at https://www.joyent.com/developers/videos/bryan-cantrill-virtualizing-the-docker-remote-api-with-triton https://www.joyent.com/developers/videos/bryan-cantrill-virt... . My favorite line is, "And, so in terms of the security of containers, from our perspective they have to be secure because if you're able to break out of a container into the global zone of SmartOS, you could delete the company." Yesterday at http://containersummit.io/ http://containersummit.io/, Bryan's talk "Going Container Native" (video coming soon) was in the same vein, SmartOS (illumos) directly benefits from its Solaris lineage -- Solaris Zones were engineered for security. We, Joyent, absolutely do believe Triton has the security properties that everyone seems to want out of Docker, because Joyent has been running OS containers in multi-tenant production since ~2006. Open source SmartDataCenter [1], rebranded Triton, is the exact same code that is run in Joyent's Public Cloud. This truth in code, product and service contributed to me leaving an OpenStack company to join Joyent two years ago. 1. https://github.com/joyent/sdc https://github.com/joyent/sdc
codemac 11y ago
Docker is a rootkit over HTTP.
- voltagex_ 11y ago
  >A rootkit is a collection of computer software, typically malicious, designed to enable access to a computer or areas of its software that would not otherwise be allowed (for example, to an unauthorized user) while at the same time masking its existence or the existence of other software. Doesn't really describe Docker, does it?
  - codemac 11y ago
    It does if you're talking about `docker -d` and --privileged.
    - KirinDave 11y ago
      Rootkits hide themselves. Docker makes no effort to do so. I know you're trying to make joke, but it's not funny.
      - codemac 11y ago
        That's the joke, literally. This is a blog post about how docker is insecure when you can get root perms over a socket the docker daemon exports when you explicitly map it back into a docker container... as if it's unexpected when it's explicitly docker's design and the command line you provided. Oh well, I did think it was funny.
      - totony 11y ago
        it hides in plain sight
jayfk 11y ago
In other news, mounting / gives you access to the root filesystem.
KirinDave 11y ago
Do... people really offer docker sockets to running containers without thoroughly vetting them first? Are people really that good at avoiding the warnings? I mean, I know it's popular to pass the socket in for automatically re-configuring proxies... but I haven't seen any serious use outside of that.
paulmd 11y ago
I will never expose the Wu-Tang Socket.
raspasov 11y ago
Can someone describe a real-attack scenario, using Docker's default settings as of the latest version? I see a lot of people claiming that it's insecure but no concrete examples of exploits. I am not saying that it's as secure as VMs, or that it's inherently secure - I am genuinely* interested and really do care about this. *We're in a limited beta of cloudmonkey.io, and we want to run unrelated/untrusted containers side by side securely.
- brianshaler 11y ago
  I assumed that's what the video in the article was about [0], but I haven't watched it to be sure. Is there anything in particular that isn't clear from the article? Or are you asking about docker security concerns beyond what this article is about? It seems the main point is if there is any way to exploit code running within a container that has unfettered root access to the host system via the docker socket, an attacker would then have complete control over the host system. Exploitation is often mitigated in layers, where if Service A is exploited, an attacker can only rwx what and where Service A has been granted priveleges to rwx. That should be as little as possible, the bare minimum access that service needs to operate. There's no reason your web server or database should be able to install new programs, create users, etc. If Service B is running in a container and is given access to write to the docker socket, suddenly any exploitation of that service opens a door to immediately have full and unfettered root access to the host system. > [0] FTA "... ended up making a screencast to unambiguously demonstrate the flaw in their setup..."
skarap 11y ago
To be honest, exposing host's /var/run/libvirtd.sock to a guest VM will have exactly the same consistencies.
tobbyb 11y ago
A container is just running a process or chroot in its own namespace. If you run it as it is you have a single process container like Docker uses, if you run an init in the namespaced process you have LXC or OS containers that can support multiple processes like a lightweight VM. [1] With LXC containers you start them as root and there is no lingering background LXC process running. Docker also starts containers as root but also has dockerd hanging around presumably so non root users can interface with it. But the container process is still running as root so dockerd seems a bit redundant and unnecesary. This is because untill recently you couldn't run chroot as non root users and needed to run containers as root. But 'user namespaces' (> kernel 3.8) changes this and allows users to run processes in namespaces as a non root user. LXC has supported unprivileged containers for some time now [2] so you can run LXC containers as non root users, as in the entire container process is unprivileged. Docker and Rkt are working on this but its not simple to implement for container managers as non privileged users cannot access networking and mounts. But when it does presumably dockerd can run as an unprivileged process. But Linux kernel namespaces have not been designed for multi-tenancy for instance cgroups are not namespace aware, and untill this changes in the kernel, containers will not provide the level of isolation or security required for multi-tenant workloads. And containers managers like LXC or Docker that take these capabilities and merge them with networking and layered filesystems like aufs or overlayfs cannot work around this. Parallels OVZ is designed for multi tenancy but the kernel patch it appears is too large and invasive and doesn't look it will be merged. So user namespaces is one level of security and isolation, you can also use seccomp, app armour, selinux or even grsec. But you have to find the middle ground between security and usability and given the relative confusion about containers, namespaces, and container managers it will take time to mature. [1] https://www.flockport.com/how-linux-containers-work/ https://www.flockport.com/how-linux-containers-work/ [2] https://www.flockport.com/lxc-using-unprivileged-containers/ https://www.flockport.com/lxc-using-unprivileged-containers/

133 points by lvh 11y ago

deleted 11y ago

[deleted]

alpb 11y ago

dockerd -- nope. It's `docker -d`

nailer 11y ago
'daemonisedthingd' is standard UNIX terminology.

benwilber0 11y ago

Docker is not a sandbox and was never intended to be. A comprehensive SELinux profile for untrusted Docker containers could be developed, but I've yet to see one. If you want to run untrusted Docker containers, then this is what you want.

0x400614 11y ago

I don't understand the point of Docker. It seems like a great product. For any serious production grade containerization , I'd use a real virtualization solution like KVM, or VMWare.

geofft 11y ago
It's containerization between trustworthy apps; it's not security containerization. What it gets you is, if you have one application that's designed to run well on RHEL 5 with /usr/bin/python pointing to Python 2.4, and another one that's designed to run well on Debian testing with a manual /usr/bin/python symlink to Python 3, you can give both of them what they want. This has nothing to do with security. If you want Docker + security isolation, I'm intrigued by Clear Containers, which is a lightweight KVM-based virtualization thing: https://lists.clearlinux.org/pipermail/dev/2015-September/000049.html https://lists.clearlinux.org/pipermail/dev/2015-September/00... https://lwn.net/Articles/644675/ https://lwn.net/Articles/644675/
- takeda 11y ago
  > It's containerization between trustworthy apps; it's not security containerization. Isn't that what a process is? The containers in Linux are based on Jails from FreeBSD and zones from Solaris. They are absolutely there for security. Regarding the remaining part of your post, I understand what you are trying to show but python is a really bad example. You absolutely can have python 2 and 3 side by side, or even different minor versions. And with virtualenv or pyvenv (that came with 3.4) you can even have multiple installation of the sane version. If you add setuptools to your application you can easily generate single file package (I personally like wheel) the deployment is as simple as writing pip install myawesomeapp-1.0.py2.py3.whl it downloads all dependencies. There is not much that Docker would help, it only makes things more complex.
  - rdtsc 11y ago
    Pretty much. It is marketing multiple exiting open source Linux technologies (overlay file systems, namespacing for processes, network sockets, chroots) under a set of tools and bam! -- hundreds of millions of dollars in valuation.
    - superuser2 11y ago
      Well, more than that, it's packaging them into user-friendly tools and promoting the shit out of it. Still Docker the company's core value proposition is a hosted registry, something many savvy corporations will never go for. Docker the product could probably do just fine if the company were to fold.
      - LoSboccacc 11y ago
        but the hosted registry is what your average distribution already provide under the form of packages. and with everything moving to services, I see the utility of actually using components diminishing fast (well except for those providing those services) but for everyone else, docker solves no actual problem that can't already be solved now.
stephengillie 11y ago
Any virtualization solution is going to require you manage an operating system. One of the goals of contanerization is for developers to only work with the application.
- voltagex_ 11y ago
  Unfortunately most docker containers seem to bring along 200+mb of operating system with them.
  - stephengillie 11y ago
    The binaries have to run somewhere. Container evangelists love to espouse the purity of running any container on any dock OS, and this is as true as being able to migrate VMs between any host - it still comes down to what the application/VM needs from the underlying OS/hardware.
    - vidarh 11y ago
      Mostly it comes down to lack of experience with containers so far, and lack of tools. Most apps need very little from the underlying OS if you actually take the time to e.g. set up a toolchain with a build container that you then move the build artefacts out of to install into the final container. Instead you see a lot of containers that in effect include all the build dependencies and a nearly full OS pulled in by that. It is improving, though slowly.
  - xorcist 11y ago
    This. Only 2G, not 200M. I try to get people to package application plus dependencies yet this is what they do every time. Every single time. Plus they always base it on images from the Internet, so bascially we trust some stranger with root privileges to all our data. Not always on the same image of course.
  - davexunit 11y ago
    Yes, this is a fundamental issue with Docker and other container systems that work with raw disk images as their basic unit of information. I have implemented a container system for the GNU Guix package manager that doesn't have this image bloat problem because it doesn't use opaque disk images. We store packages in a content-addressable storage system, which allows us to know the precise dependency graph for any piece of software in the system. Since we know the full set of software needed for any container, we are able to share the same binaries amongst all containers on a single host via a bind mount.
AgentME 11y ago
Think of it like a tool for packaging and deploying applications with everything they need. Its purpose is closer to package managers than being a secure sandbox for running untrusted users' VMs.
- vezzy-fnord 11y ago
  Funny, an article got posted here just an hour ago advocating against treating Docker like a package manager: http://vilkeliskis.com/blog/2015/09/23/docker_is_not_a_package_management_tool.html http://vilkeliskis.com/blog/2015/09/23/docker_is_not_a_packa... I'd be inclined to agree. The reductionist sum of mechanisms that make a Linux container have always been about detaching, multiplexing and partitioning kernel resource subsystems. Docker was the first program that really hyped it into the idea of being about application deployment, but I fear this gives people wrong impressions and makes the mistake of treating an emergent property as if it were a fundamental.
  - KirinDave 11y ago
    The first part of your post made sense. I have no idea what point you're trying to convey with the second part. That applications are not business logic over kernel resources is a curious argument to make.
- doug1001 11y ago
  that was my initial impression i got from reading some posts on the Docker Site, and perhaps there is no consistent definition of "package manager"--to me though, the most difficult tasks a p/m must do are: reproducible builds, dependency management, conflict resolution among transitive dependencies, and the like. But Docker does none of these things as i understand it.
jkyle 11y ago
KVM & VMWare are not containerization, they're full virtualization. There are a lot of benefits to containers and they don't have to be insecure. More efficient resource utilization and orders of magnitude faster allocation and launching to name two. Google runs a significant portion of its internal operations in a container infrastructure and has for quite a while.[1] They're perfectly capable of deployment into production environments. I won't comment on docker as I haven't spent the time to fully grok all its warts. 1. http://research.google.com/pubs/pub43438.html http://research.google.com/pubs/pub43438.html
- _yy 11y ago
  > Google runs a significant portion of its internal operations in a container infrastructure and has for quite a while.[1] They use containers inside virtual machines. Virtualization for security, containers for deployment.
  - jkyle 11y ago
    I know from Joe Beda's talk [1] they run vm's inside containers for scenarios where they need a managed os. And that those containers run on bare metal. But I can't speak to the reverse not being an employee or authority on Google's internals. 1. https://speakerdeck.com/jbeda/containers-at-scale https://speakerdeck.com/jbeda/containers-at-scale
Pyxl101 11y ago
Containerization and virtualization serve different purposes. VMs run actual operating systems within them. A single operating system runs many different containers, that each act something like processes running on that same OS, in a way where they're highly sandboxed and segmented from each other. If your goal is strong isolation, then VMs are definitely better today. The purpose of Docker and similar container technologies is not that kind of isolation. It's to package up and distribute applications in a way that's more decoupled than simply installing them all on the same system.
- takeda 11y ago
  I'm not hiding that after I learned about Docker I became skeptic. It seems like yet another thing that people observed what Google was doing, and then implementing it wrong. Google is using containers instead of VMs. This still provides security isolation and allows them to use resources more efficiently (VM has overhead where you need a whole OS for every instance). This approach does not make much sense in public cloud, where you already run inside of VM and the overhead is really for Amazon not you. So I see Docker is now pivoting to be a package manager, but there are already tools that do that. You can argue that Docker is simpler but so was rpm when it started. As Docker will grow it will become more complex in order to support all functionality package format already provides. There might be an argument that you can run multiple Docker containers on a single host, but that's what processes are for. There is change happening, and looks like cloud companies want to create "cloud os", I guess Docker is step toward that direction, but at current state in don't see it offering anything valuable to the organization that uses it.
  - monkey26 11y ago
    Docker as a package manager somewhat matches my use, and I think it does its job well. As the packager, I can just create one "package" that any Linux distribution running Docker can install, instead of creating packages for multiple versions of many different distributions.
    - takeda 11y ago
vacri 11y ago
If your VMs are single-purpose, you don't necessarily need VMs. Containers are single-process things - they're not running syslog or cron or any of that overhead, for example. Docker is also big on ensuring you are using the literal same artifact in dev as on prod (assuming you change your team's workflow, of course). Which is the right thing to use is entirely dependent on your use case.
- insaneirish 11y ago
  > Containers are single-process things - they're not running syslog or cron or any of that overhead, for example. You're either being entirely too prescriptive or interchanging containers and Docker freely when they are not equivalent, though one is a particular implementation of the other. People have been running containers that emulate a full system for quite a while (see FreeBSD jails, illumos/Solaris zones, Linux OpenVZ, LXC, etc.).
tbronchain 11y ago
We[1] believe that the point of Docker is to provide "application packages" (called containers), which is a big step ahead to deliver applications (using their words: build, ship, run). However, we also do believe the isolation containers provide isn't sufficient for multi-tenant usages. This is the main motivation behind Hyper, which run groups of container images (Pods) as Virtual Machines. [1] https://hyper.sh https://hyper.sh

hosay123 11y ago

I don't really get this, the implication is the container becomes more secure without access to the socket, yet it has access to the hundreds of local kernel APIs with which on the average month it can easily gain higher privileges than root, especially on contemporary machines where half the admins around these days don't even know what a security update looks like

KirinDave 11y ago
Why knowingly give a trivial breakout vector to code you don't trust?

notjack 11y ago

This assumes that Docker containers are being used like VMs. They're not designed to allow running isolated arbitrary code in some sort of multi-tenancy setup, they're designed to isolate dependencies and configuration between your own deployed services. This is a "security vulnerability" in the same way that putting up a white picket fence around a jail is - a gross mis-application of a tool built for a completely different purpose.

insaneirish 11y ago
> They're not designed to allow running isolated arbitrary code in some sort of multi-tenancy setup You mean Linux containers are not designed for this, nor are they designed to be secure. What a sad design failure. Some [1] container technology was developed with security as a first principle. [1]: http://us-east.manta.joyent.com/jmc/public/opensolaris/ARChive/PSARC/2002/174/zones-design.spec.opensolaris.pdf http://us-east.manta.joyent.com/jmc/public/opensolaris/ARChi...
- notjack 11y ago
  I should clarify I mean Docker containers specifically, good point.
- geofft 11y ago
  And you can run Docker containers on SmartOS, using "LX-branded zones", which do Linux syscall emulation: https://www.joyent.com/blog/triton-docker-and-the-best-of-all-worlds https://www.joyent.com/blog/triton-docker-and-the-best-of-al... I'd be curious if the Joyent folks believe Triton to have the security properties that everyone seems to want out of Docker. It doesn't involve the standard Docker daemon, so it might.
  - lloydde 11y ago
    @geofft that is a great link, our CTO Bryan Cantrill continued to beat the drum at the Docker SF meetup in May 6, 2015. Video and transcript at https://www.joyent.com/developers/videos/bryan-cantrill-virtualizing-the-docker-remote-api-with-triton https://www.joyent.com/developers/videos/bryan-cantrill-virt... . My favorite line is, "And, so in terms of the security of containers, from our perspective they have to be secure because if you're able to break out of a container into the global zone of SmartOS, you could delete the company." Yesterday at http://containersummit.io/ http://containersummit.io/, Bryan's talk "Going Container Native" (video coming soon) was in the same vein, SmartOS (illumos) directly benefits from its Solaris lineage -- Solaris Zones were engineered for security. We, Joyent, absolutely do believe Triton has the security properties that everyone seems to want out of Docker, because Joyent has been running OS containers in multi-tenant production since ~2006. Open source SmartDataCenter [1], rebranded Triton, is the exact same code that is run in Joyent's Public Cloud. This truth in code, product and service contributed to me leaving an OpenStack company to join Joyent two years ago. 1. https://github.com/joyent/sdc https://github.com/joyent/sdc

codemac 11y ago

Docker is a rootkit over HTTP.

voltagex_ 11y ago
>A rootkit is a collection of computer software, typically malicious, designed to enable access to a computer or areas of its software that would not otherwise be allowed (for example, to an unauthorized user) while at the same time masking its existence or the existence of other software. Doesn't really describe Docker, does it?
- codemac 11y ago
  It does if you're talking about `docker -d` and --privileged.
  - KirinDave 11y ago
    Rootkits hide themselves. Docker makes no effort to do so. I know you're trying to make joke, but it's not funny.
    - codemac 11y ago
      That's the joke, literally. This is a blog post about how docker is insecure when you can get root perms over a socket the docker daemon exports when you explicitly map it back into a docker container... as if it's unexpected when it's explicitly docker's design and the command line you provided. Oh well, I did think it was funny.
    - totony 11y ago
      it hides in plain sight

jayfk 11y ago

In other news, mounting / gives you access to the root filesystem.

KirinDave 11y ago

Do... people really offer docker sockets to running containers without thoroughly vetting them first? Are people really that good at avoiding the warnings? I mean, I know it's popular to pass the socket in for automatically re-configuring proxies... but I haven't seen any serious use outside of that.

paulmd 11y ago

I will never expose the Wu-Tang Socket.

raspasov 11y ago

Can someone describe a real-attack scenario, using Docker's default settings as of the latest version? I see a lot of people claiming that it's insecure but no concrete examples of exploits. I am not saying that it's as secure as VMs, or that it's inherently secure - I am genuinely* interested and really do care about this. *We're in a limited beta of cloudmonkey.io, and we want to run unrelated/untrusted containers side by side securely.

brianshaler 11y ago
I assumed that's what the video in the article was about [0], but I haven't watched it to be sure. Is there anything in particular that isn't clear from the article? Or are you asking about docker security concerns beyond what this article is about? It seems the main point is if there is any way to exploit code running within a container that has unfettered root access to the host system via the docker socket, an attacker would then have complete control over the host system. Exploitation is often mitigated in layers, where if Service A is exploited, an attacker can only rwx what and where Service A has been granted priveleges to rwx. That should be as little as possible, the bare minimum access that service needs to operate. There's no reason your web server or database should be able to install new programs, create users, etc. If Service B is running in a container and is given access to write to the docker socket, suddenly any exploitation of that service opens a door to immediately have full and unfettered root access to the host system. > [0] FTA "... ended up making a screencast to unambiguously demonstrate the flaw in their setup..."

skarap 11y ago

To be honest, exposing host's /var/run/libvirtd.sock to a guest VM will have exactly the same consistencies.

tobbyb 11y ago

A container is just running a process or chroot in its own namespace. If you run it as it is you have a single process container like Docker uses, if you run an init in the namespaced process you have LXC or OS containers that can support multiple processes like a lightweight VM. [1] With LXC containers you start them as root and there is no lingering background LXC process running. Docker also starts containers as root but also has dockerd hanging around presumably so non root users can interface with it. But the container process is still running as root so dockerd seems a bit redundant and unnecesary. This is because untill recently you couldn't run chroot as non root users and needed to run containers as root. But 'user namespaces' (> kernel 3.8) changes this and allows users to run processes in namespaces as a non root user. LXC has supported unprivileged containers for some time now [2] so you can run LXC containers as non root users, as in the entire container process is unprivileged. Docker and Rkt are working on this but its not simple to implement for container managers as non privileged users cannot access networking and mounts. But when it does presumably dockerd can run as an unprivileged process. But Linux kernel namespaces have not been designed for multi-tenancy for instance cgroups are not namespace aware, and untill this changes in the kernel, containers will not provide the level of isolation or security required for multi-tenant workloads. And containers managers like LXC or Docker that take these capabilities and merge them with networking and layered filesystems like aufs or overlayfs cannot work around this. Parallels OVZ is designed for multi tenancy but the kernel patch it appears is too large and invasive and doesn't look it will be merged. So user namespaces is one level of security and isolation, you can also use seccomp, app armour, selinux or even grsec. But you have to find the middle ground between security and usability and given the relative confusion about containers, namespaces, and container managers it will take time to mature. [1] https://www.flockport.com/how-linux-containers-work/ https://www.flockport.com/how-linux-containers-work/ [2] https://www.flockport.com/lxc-using-unprivileged-containers/ https://www.flockport.com/lxc-using-unprivileged-containers/