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

There are still a few gotchas on the low level stuff, especially networking, but also other areas that involve kernel drivers more directly.

The security around the containers still isn't as good as a hardware VM, but I think hardware segregation is on the road map.

It's ideal for running container inside VMs, though, and offers nice management segregation on those larger VMs.



Can you name some of these networking gotchas you mentioned? And elaborate on the security remark?


The major security issue is that containers share the same kernel as the host, with the whole kernel syscall interface as attack vector. VMs run separate kernels that only interface with the host via the hypervisor.


Well, there's also the issue that "Linux containers" are not a kernel primitive. So there's plenty of syscalls that aren't even namespaced (the keyring ones come to mind). Docker handles this by having a default seccomp profile that disables a bunch of syscalls that aren't namespaced.

However, the development of Zones and Jails (on SunOS/Solaris/illumos and FreeBSD) was much more security focused, with the default being "that's not allowed in a (Jail|Zone) until we can make sure it's safe". I really wish Linux had just ported Jails or inspired their security model on them.

I do a lot of work with the internals of Docker and runC at SUSE. Trust me, it's not pretty how you have to set up "Linux containers" and there's 1001 gotchas.


And we haven't seen many hypervisor security holes in the past... :) Especially with Xen.




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

Search: