Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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


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).


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.


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.


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).


Can't you take advantage of a kernel vulnerability on any reduced environment, regardless of LXC?


Not in certain container types such as a full VM.


Not wrong at all. He asked about LXC. Privilege restrictions are not part of LXC.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: