4 ms·

Impressive. Is there consensus on security bad/best practices when it comes to VMs and containers? I mean if even established VMs/Hypervisors can't save you, w

Impressive. Is there consensus on security bad/best practices when it comes to VMs and containers? I mean if even established VMs/Hypervisors can't save you, what prospect is there of containers to actually contain anything? Maybe POSIX chroot jails aren't that bad after all? Because, like, they're the simplest thing that can possibly work, and don't come with the complexity of VMs and Linux containers/namespaces; and if they turn out to be vulnerable you'd be able to switch to another kernel (BSDs)?

temac 10y ago
You have bugs in every (mainstream) kernels. With them, you can elevate your privileges to kernel level, and once you've done that it's game over. There is no reason to believe an additional layer (a VM) will always protect you (at least given how they are also written in unsafe languages for now). However there is no reason to believe it will in average makes things worse, and every reasons to believe it will in average increase your security.
staticassertion 10y ago
Basically the VM is sandwiched between the host and parent OS. With a full VM you have a separate kernel. With containers, like Docker, you share a kernel. The VM is then considered more secure because it adds that extra layer between them... but is it? It's just more code - more code, more problems. The more effective solution is to simply harden the kernel of the host system, and then use a lighter solution like docker. Grsecurity + Docker seems like a solid fit to me, and you can mash another layer like Apparmor on top. It is very rare that I see a kernel vulnerability that would not be entirely mitigated by Grsecurity, or otherwise made far more costly. The point is to stop adding layers on top and instead to focus on security that lower, trusted base.
rsync 10y ago
"Is there consensus on security bad/best practices when it comes to VMs and containers?" Yes - it's called simplicity. Fewest moving parts possible. Limit attack surface to the smallest amount possible. You can pursue this at every layer of the stack and at every layer of abstraction - it should be a primary design philosophy that informs every system you build.
daxelrod 10y ago
Please read this article[1] about how exactly chroot jails function as a security measure. If you have a process that's already not running as root, all a chroot jail does is decrease the attack surface a bit by giving that process a more limited view of the filesystem. As soon as you run something as root, or give that chroot process access to a vulnerable setuid-root binary, it can escape. An exploit anywhere in the kernel (not just in the implementation of chroot), could lead to the system being taken over. Chroot jails are easy to reason about, but they don't really help you if you're, say, studying malware. [1]: https://access.redhat.com/blogs/766093/posts/1975883 https://access.redhat.com/blogs/766093/posts/1975883

temac 10y ago

You have bugs in every (mainstream) kernels. With them, you can elevate your privileges to kernel level, and once you've done that it's game over. There is no reason to believe an additional layer (a VM) will always protect you (at least given how they are also written in unsafe languages for now). However there is no reason to believe it will in average makes things worse, and every reasons to believe it will in average increase your security.

staticassertion 10y ago

Basically the VM is sandwiched between the host and parent OS. With a full VM you have a separate kernel. With containers, like Docker, you share a kernel. The VM is then considered more secure because it adds that extra layer between them... but is it? It's just more code - more code, more problems. The more effective solution is to simply harden the kernel of the host system, and then use a lighter solution like docker. Grsecurity + Docker seems like a solid fit to me, and you can mash another layer like Apparmor on top. It is very rare that I see a kernel vulnerability that would not be entirely mitigated by Grsecurity, or otherwise made far more costly. The point is to stop adding layers on top and instead to focus on security that lower, trusted base.

rsync 10y ago

"Is there consensus on security bad/best practices when it comes to VMs and containers?" Yes - it's called simplicity. Fewest moving parts possible. Limit attack surface to the smallest amount possible. You can pursue this at every layer of the stack and at every layer of abstraction - it should be a primary design philosophy that informs every system you build.

daxelrod 10y ago

Please read this article[1] about how exactly chroot jails function as a security measure. If you have a process that's already not running as root, all a chroot jail does is decrease the attack surface a bit by giving that process a more limited view of the filesystem. As soon as you run something as root, or give that chroot process access to a vulnerable setuid-root binary, it can escape. An exploit anywhere in the kernel (not just in the implementation of chroot), could lead to the system being taken over. Chroot jails are easy to reason about, but they don't really help you if you're, say, studying malware. [1]: https://access.redhat.com/blogs/766093/posts/1975883 https://access.redhat.com/blogs/766093/posts/1975883