5 ms·

Is Docker a good way to bring more security on a server with a few different websites? Separating the sites from each other and run nginx as a proxy in front of

by stesch 13y ago

Is Docker a good way to bring more security on a server with a few different websites? Separating the sites from each other and run nginx as a proxy in front of them? What's the overhead?

zobzu 13y ago
its not as good as using separate vms, but has arguably lower overhead also, its not really docker doing that, its LXC. Docker is an API around it.
- nickstinemates 13y ago
  Docker is not an API around LXC. Any more than any application using a framework is a wrapper around said framework. However, the analogy I just made is only at a point in time. LXC is not the only Linux provider to manage cgroups/namespaces, it was just the most convenient at the time for the target audience. That is a fleeting position soon remedied. If you'd like to know more, I'd encourage you to get involved with Docker development.
  - zobzu 13y ago
    yeah, docket is an api around namespaces.. and thus lxc, right now. thanks for nothing really.
FireBeyond 13y ago
Yes, it is. It’s atop LXC (Linux Containers), which - oversimplified - is process namespacing, jails, etc. There’s near zero overhead, because there’s no virtualization.
midas007 13y ago
It depends. If the goal is to consolidate several boxes to a single VM, it does this. Be sure host-based (on the linux box) firewall rules are set and documented. If possible, set network-based firewall rules also (AWS security groups).
_wmd 13y ago
Unfortunately Docker prevents hosting environments from employing some of the most potent security mitigations added to Linux recently. You cannot treat a docker container like a virtual machine – code running in the container has almost unfettered access to the parent kernel, and the millions of lines of often-buggy C that involves. For example with the right kernel configuration, this approach leaves the parent machine vulnerable to the recent x86_32 vulnerability (http://seclists.org/oss-sec/2014/q1/187 http://seclists.org/oss-sec/2014/q1/187) and many similar bugs in its class. The algorithms in the running kernel are far more exposed too - instead of managing a single process+virtual network+memory area, all the child's resources are represented concretely in the host kernel, including its filesystem. For example, this vastly increases the likelihood that a child could trigger an unpatched DoS in the host, e.g. the directory hashing attacks that have effected nearly every filesystem implementation at some point (including btrfs as recently as 2012). The containers code in Linux is also so new that trivial security bugs are being found in it all the time – particularly in sysfs and procfs. I don't have a link right now, though LWN wrote about one a few weeks back. While virtual machines are no security panacea, they diverge in what classes of bugs they can be affected by. Recent Qemu/libvirt supports running under seccomp.. ensuring even if the VM emulator is compromised, the host kernel's exposure remains drastically limited. Unlike qemu, you simply can't apply seccomp to a container without massively reducing its usefulness, or using a seccomp policy so liberal that it becomes impotent. You could use seccomp with Docker by nesting it within a VM, but at that point Docker loses most of its value (and could be trivially replaced by a shell script with a cute UI). Finally when a bug is discovered and needs to be patched, or a machine needs to be taken out of service, there is presently no easy way to live-migrate a container to another machine. The most recent attempt (out of I think 3 or 4 now) to add this ability to Linux appears to have stalled completely. As a neat system for managing dev environments locally, it sounds great. As a boundary between mutually untrusted pieces of code, there are far better solutions, especially when the material difference in approaches amounts to a few seconds of your life at best, and somewhere south of 100mb in RAM.
- nl 13y ago
  This is all true. If a web application has a vulnerability that allows arbitrary code execution then Docker is only a mild help. BUT, it can help migrate a certain set of security problems. It is a very simple way to provide pretty good protection against file-traversal type vulnerabilities, even when combined with privilege escalation. People shouldn't view Docker as a security "silver bullet". But at the same time it does provide an additional layer of security, and that layer can be useful. The Docker people have a good post[1] about the Docker security model, and they list two future improvements they see as important: "map the root user of a container to a non-root user of the Docker host, to mitigate the effects of a container-to-host privilege escalation;" and "allow the Docker daemon to run without root privileges, and delegate operations requiring those privileges to well-audited sub-processes, each with its own (very limited) scope: virtual network setup, filesystem management, etc." I think most people would agree these are important goal. [1] http://blog.docker.io/2013/08/containers-docker-how-secure-are-they/ http://blog.docker.io/2013/08/containers-docker-how-secure-a...

by stesch 13y ago

Is Docker a good way to bring more security on a server with a few different websites? Separating the sites from each other and run nginx as a proxy in front of them? What's the overhead?

zobzu 13y ago

its not as good as using separate vms, but has arguably lower overhead also, its not really docker doing that, its LXC. Docker is an API around it.

nickstinemates 13y ago
Docker is not an API around LXC. Any more than any application using a framework is a wrapper around said framework. However, the analogy I just made is only at a point in time. LXC is not the only Linux provider to manage cgroups/namespaces, it was just the most convenient at the time for the target audience. That is a fleeting position soon remedied. If you'd like to know more, I'd encourage you to get involved with Docker development.
- zobzu 13y ago
  yeah, docket is an api around namespaces.. and thus lxc, right now. thanks for nothing really.

FireBeyond 13y ago

Yes, it is. It’s atop LXC (Linux Containers), which - oversimplified - is process namespacing, jails, etc. There’s near zero overhead, because there’s no virtualization.

midas007 13y ago

It depends. If the goal is to consolidate several boxes to a single VM, it does this. Be sure host-based (on the linux box) firewall rules are set and documented. If possible, set network-based firewall rules also (AWS security groups).

_wmd 13y ago

Unfortunately Docker prevents hosting environments from employing some of the most potent security mitigations added to Linux recently. You cannot treat a docker container like a virtual machine – code running in the container has almost unfettered access to the parent kernel, and the millions of lines of often-buggy C that involves. For example with the right kernel configuration, this approach leaves the parent machine vulnerable to the recent x86_32 vulnerability (http://seclists.org/oss-sec/2014/q1/187 http://seclists.org/oss-sec/2014/q1/187) and many similar bugs in its class. The algorithms in the running kernel are far more exposed too - instead of managing a single process+virtual network+memory area, all the child's resources are represented concretely in the host kernel, including its filesystem. For example, this vastly increases the likelihood that a child could trigger an unpatched DoS in the host, e.g. the directory hashing attacks that have effected nearly every filesystem implementation at some point (including btrfs as recently as 2012). The containers code in Linux is also so new that trivial security bugs are being found in it all the time – particularly in sysfs and procfs. I don't have a link right now, though LWN wrote about one a few weeks back. While virtual machines are no security panacea, they diverge in what classes of bugs they can be affected by. Recent Qemu/libvirt supports running under seccomp.. ensuring even if the VM emulator is compromised, the host kernel's exposure remains drastically limited. Unlike qemu, you simply can't apply seccomp to a container without massively reducing its usefulness, or using a seccomp policy so liberal that it becomes impotent. You could use seccomp with Docker by nesting it within a VM, but at that point Docker loses most of its value (and could be trivially replaced by a shell script with a cute UI). Finally when a bug is discovered and needs to be patched, or a machine needs to be taken out of service, there is presently no easy way to live-migrate a container to another machine. The most recent attempt (out of I think 3 or 4 now) to add this ability to Linux appears to have stalled completely. As a neat system for managing dev environments locally, it sounds great. As a boundary between mutually untrusted pieces of code, there are far better solutions, especially when the material difference in approaches amounts to a few seconds of your life at best, and somewhere south of 100mb in RAM.

nl 13y ago
This is all true. If a web application has a vulnerability that allows arbitrary code execution then Docker is only a mild help. BUT, it can help migrate a certain set of security problems. It is a very simple way to provide pretty good protection against file-traversal type vulnerabilities, even when combined with privilege escalation. People shouldn't view Docker as a security "silver bullet". But at the same time it does provide an additional layer of security, and that layer can be useful. The Docker people have a good post[1] about the Docker security model, and they list two future improvements they see as important: "map the root user of a container to a non-root user of the Docker host, to mitigate the effects of a container-to-host privilege escalation;" and "allow the Docker daemon to run without root privileges, and delegate operations requiring those privileges to well-audited sub-processes, each with its own (very limited) scope: virtual network setup, filesystem management, etc." I think most people would agree these are important goal. [1] http://blog.docker.io/2013/08/containers-docker-how-secure-are-they/ http://blog.docker.io/2013/08/containers-docker-how-secure-a...