5 ms·

I looked at it several times but never really got it. Can I use Docker to isolate different servers (think http, xmpp, another http on another port) on a server

by Sprint 13y ago

I looked at it several times but never really got it. Can I use Docker to isolate different servers (think http, xmpp, another http on another port) on a server so that if one of them was exploited, the attacker would be constrained to inside the container? Or is it "just" of a convenient way to put applications into self-contained packages?

zrail 13y ago
> Can I use Docker to isolate different servers That's the idea. Docker is based on LXC which provides configurable isolation between process groups. So, you could run your http in one container, your database in another, and your application server in a 3rd and have reasonable confidence that they can only talk to each other the way you want them to.
shykes 13y ago
It's both. Everyone using docker benefits from the "software distribution" feature. Some people using docker also benefit from the security and isolation features - it depends on your needs and the security profile of your application. Because the underlying namespacing features of the kernel are still young, it's recommended to avoid running untrusted code as root inside a container on a shared machine. If you drop privileges inside the container, use an additional layer of security like SELinux, grsec, apparmor etc. then it is absolutely possible and viable in production. It's only a matter of time before linux namespaces get more scrutiny and people grow more comfortable with them as a first-class security mechanism. It took a while for OpenVZ to get there, but not there are hosting providers using it for VPS offerings. On top of namespacing, docker manages other aspects of the isolation including firewalling between containers and the outside world (currently optional but soon to be mandatory), whitelisting of traffic between certain containers, etc.
- pradn 13y ago
  Which namespacing features are still young? Is it still possible to evade LXC as described in this post? http://blog.bofh.it/debian/id_413 http://blog.bofh.it/debian/id_413
  - shykes 13y ago
    To my knowledge there are currently no known exploits. It's more a matter of risk management: newer codebases are less secure because we had less time to find bugs and spread best practices. That problem is amplified for larger codebases (but diminished by a more active developer community).
  - throwaway092834 13y ago
    Yes, it is trivial for a root user in an LXC container to break out. One can load a kernel module from within a container, for example. LXC containers do not provide security partitioning at all.
    - shykes 13y ago
      This is just totally wrong. Any decent container configuration (including the default docker configuration) will agressively drop capabilities, preventing you from doing this, and any other script-kiddie attack. See my other comment in this thread for a more accurate answer.
      - throwaway092834 13y ago
        Not wrong at all. He asked about LXC. Privilege restrictions are not part of LXC.
      - justincormack 13y ago
        Yes, you probably need a proper kernel vulnerability, which you can exploit in a reduced environment. Not trivial, but not impossible, scanning this years CVEs some would probably be sufficient (eg ones that only nees socket access).
        riquito 13y ago
        Can't you take advantage of a kernel vulnerability on any reduced environment, regardless of LXC?
yebyen 13y ago
I have heard two opinions. One of them is paranoid: "if you give up root on the container you give up root on the host system." I am not sure I believe this, I can't show you how to do the compromise and escalation, but I know there is a -privileged mode you can use on your containers in which Root user can do things like create device nodes, reset the system clock, and presumably other things you should not allow if you are concerned about this kind of attack. The other opinion (given that you don't enable -privileged mode) is that lxc namespaces _do_ protect your host and other containers from being exploited due to compromise of a contained process, and cgroups _do_ protect your precious i/o and cpu cycles from being fully consumed and deadlocking your whole system when a rogue container decides to start infinite looping. The competent answer of course is "try it", you should know that there are ways your processes can be compromised, and you should check if the exploits you know about result in the same or different privilege escalations when you apply them to a service hosted within a docker instance. That being said, you can't really prove a negative...
- julien421 13y ago
  This is maybe part of the answer on the security point http://blog.docker.io/2013/08/containers-docker-how-secure-are-they/#more-697 http://blog.docker.io/2013/08/containers-docker-how-secure-a...
mclarke 13y ago
I wrote up some thoughts yesterday on Docker's value as a tool in continuous integration testing which might find interesting: http://mike-clarke.com/2013/11/applied-docker-continuous-integration/ http://mike-clarke.com/2013/11/applied-docker-continuous-int...

by Sprint 13y ago

zrail 13y ago

> Can I use Docker to isolate different servers That's the idea. Docker is based on LXC which provides configurable isolation between process groups. So, you could run your http in one container, your database in another, and your application server in a 3rd and have reasonable confidence that they can only talk to each other the way you want them to.

shykes 13y ago

It's both. Everyone using docker benefits from the "software distribution" feature. Some people using docker also benefit from the security and isolation features - it depends on your needs and the security profile of your application. Because the underlying namespacing features of the kernel are still young, it's recommended to avoid running untrusted code as root inside a container on a shared machine. If you drop privileges inside the container, use an additional layer of security like SELinux, grsec, apparmor etc. then it is absolutely possible and viable in production. It's only a matter of time before linux namespaces get more scrutiny and people grow more comfortable with them as a first-class security mechanism. It took a while for OpenVZ to get there, but not there are hosting providers using it for VPS offerings. On top of namespacing, docker manages other aspects of the isolation including firewalling between containers and the outside world (currently optional but soon to be mandatory), whitelisting of traffic between certain containers, etc.

pradn 13y ago
Which namespacing features are still young? Is it still possible to evade LXC as described in this post? http://blog.bofh.it/debian/id_413 http://blog.bofh.it/debian/id_413
- shykes 13y ago
  To my knowledge there are currently no known exploits. It's more a matter of risk management: newer codebases are less secure because we had less time to find bugs and spread best practices. That problem is amplified for larger codebases (but diminished by a more active developer community).
- throwaway092834 13y ago
  Yes, it is trivial for a root user in an LXC container to break out. One can load a kernel module from within a container, for example. LXC containers do not provide security partitioning at all.
  - shykes 13y ago
    This is just totally wrong. Any decent container configuration (including the default docker configuration) will agressively drop capabilities, preventing you from doing this, and any other script-kiddie attack. See my other comment in this thread for a more accurate answer.
    - throwaway092834 13y ago
      Not wrong at all. He asked about LXC. Privilege restrictions are not part of LXC.
    - justincormack 13y ago
      Yes, you probably need a proper kernel vulnerability, which you can exploit in a reduced environment. Not trivial, but not impossible, scanning this years CVEs some would probably be sufficient (eg ones that only nees socket access).
      - riquito 13y ago
        Can't you take advantage of a kernel vulnerability on any reduced environment, regardless of LXC?

yebyen 13y ago

I have heard two opinions. One of them is paranoid: "if you give up root on the container you give up root on the host system." I am not sure I believe this, I can't show you how to do the compromise and escalation, but I know there is a -privileged mode you can use on your containers in which Root user can do things like create device nodes, reset the system clock, and presumably other things you should not allow if you are concerned about this kind of attack. The other opinion (given that you don't enable -privileged mode) is that lxc namespaces _do_ protect your host and other containers from being exploited due to compromise of a contained process, and cgroups _do_ protect your precious i/o and cpu cycles from being fully consumed and deadlocking your whole system when a rogue container decides to start infinite looping. The competent answer of course is "try it", you should know that there are ways your processes can be compromised, and you should check if the exploits you know about result in the same or different privilege escalations when you apply them to a service hosted within a docker instance. That being said, you can't really prove a negative...

julien421 13y ago
This is maybe part of the answer on the security point http://blog.docker.io/2013/08/containers-docker-how-secure-are-they/#more-697 http://blog.docker.io/2013/08/containers-docker-how-secure-a...

mclarke 13y ago

I wrote up some thoughts yesterday on Docker's value as a tool in continuous integration testing which might find interesting: http://mike-clarke.com/2013/11/applied-docker-continuous-integration/ http://mike-clarke.com/2013/11/applied-docker-continuous-int...