Live data from Hacker News

Kata Containers – The speed of containers, the security of VMs

katacontainers.io

61–70 of 76 posts

Re: Kata Containers – The speed of containers, the security of VMs

#61
post #31
post #29

Earlier quoted context omitted.

This is the most blatant and clearly incorrect... FUD?..lie?... I have ever heard to date about jails. Jails are secure. As are SmartOS zones. Whoever you heard that there are “many instances of breaking out of a jail” from is full of sh47. And you would be wise to never listen to them ever again. No really, EVER. And no, breaking the ps4 was not a jail exploit. The attacker already had elevated privileges. So you wo…

Sheesh, no need to get so emotional about it. I said instances of breaking out, not instances of jail exploits. I don't know of any jail-specific exploits. But when we say "elevated privileges" are we talking root inside of a jail? Because if that breaks jails, then a large class of Docker exploits also wouldn't classify as 'exploits' under that criteria. One of the biggest problems with Linux namespaces is the band-…

> Bugs in syscalls in FreeBSD aren't unheard of though, even if less commonly found than Linux.

Dangerous assumption.

More likely, there are fewer people looking for vulnerabilities in BSD than in Linux.

Re: Kata Containers – The speed of containers, the security of VMs

#62
post #50

Earlier quoted context omitted.

yeah there are probably not many 'jail' exploits specifically targeted for getting out of jail/exploiting jail primitives. but people just use normal kernel exploits to get out of jail/zones. i would say jails/zones are about as secure as linux containers. ie: about as secure as the linux kernel is.

And you would be wrong.

The person you are replying to has discovered multiple exploitable bugs in Illumos via DTrace from inside zones:

Here are the first two that pop up if you google his name. http://www.zerodayinitiative.com/advisories/ZDI-16-168/ http://www.zerodayinitiative.com/advisories/ZDI-16-274/

He gave a talk at DTrace conf 2016 about all the security vulnerabilities he personally found in DTrace in SmartOS. Here are the slides: http://slides.com/benmurphy/deck

Re: Kata Containers – The speed of containers, the security of VMs

#63
post #44

Earlier quoted context omitted.

Zones have the same problem that linux containers have which is a massive attack surface in the form of a kernel. And if you think zones are secure: Which OS do you think had more kernel exploits that could be used to escape container/zone in the last 2 years? I think the answer is much closer than you might think.

I am not tracking closely to be honest since I have not being working with Illumos based distros for 5 years +/- when we were using omniOS I do not remember things being too bad. Not sure what % of vuln. are Oracle Solaris specific given that majority of orig. SUN eng. left long time ago Illumos might be in much better shape vs Solaris.

http://www.zerodayinitiative.com/advisories/ZDI-16-168/

http://www.zerodayinitiative.com/advisories/ZDI-16-274/

These were both in Illumos found by the person you are replying to.

Re: Kata Containers – The speed of containers, the security of VMs

#64
post #42

How is this better than using rkt with an lkvm stage1[1], which also uses the work done by the Clear Containers team? It looks like Kata packages QEMU as well, which seems a bit overkill. [1] https://coreos.com/rkt/docs/latest/running-kvm-stage1.html

> a bit overkill

They also said the same about Xen, that a special purpose microkernel was a better choice than Linux as a hypervisor...

Re: Kata Containers – The speed of containers, the security of VMs

#65
post #31

Earlier quoted context omitted.

Sheesh, no need to get so emotional about it. I said instances of breaking out, not instances of jail exploits. I don't know of any jail-specific exploits. But when we say "elevated privileges" are we talking root inside of a jail? Because if that breaks jails, then a large class of Docker exploits also wouldn't classify as 'exploits' under that criteria. One of the biggest problems with Linux namespaces is the band-…

> Bugs in syscalls in FreeBSD aren't unheard of though, even if less commonly found than Linux. Dangerous assumption. More likely, there are fewer people looking for vulnerabilities in BSD than in Linux.

Well, I did say

>less commonly found

rather than less common. Impossible to know with 100% certainty what's literally less common.

If I had to guess, I'd guess FreeBSD had less bugs in general, just because the surface is generally smaller, and the system is more homogeneous.

Re: Kata Containers – The speed of containers, the security of VMs

#66
post #47

They don't seem to have written any code yet. [1] So what we have at this point is a marketing website about their ambition and goals? [1] https://github.com/kata-containers/runtimes

There does seem to be a fair bit left to write (or clean up and open source from Hyper.sh and Intel) e.g. the entire testing repo is empty I would suggest we are looking at a conference driven development release

I am a product manager for Intel's Clear Containers and am also working in this community with Kata. We are still under development and merging Intel Clear Containers (CC) and Hyper.sh runV. Our 1.0 release is scheduled for March timeframe, at which point we plan to have a migration path for customers using runv or CC. We launched this week so that we can build our community and continue to merge the code in the open!

Re: Kata Containers – The speed of containers, the security of VMs

#67
post #25

Earlier quoted context omitted.

I'm sure there's more, but the most obvious is that they share one running kernel. So, one kernel exploit in one container means you now have all the running containers.

So containers are as vulnerable as the operating system? It seems like if your kernel has been pwned you’re already SOL? Or couldn’t someone in that position just as easily pwn a VM, or run the same exploit on multiple vms? I’m not sure if I’m missing something

Assuming the attacker already knew the IP of every VM, and they were all running the same kernel with the same exploit, and they were all exposed to the internet, it would be similar...although you would have to repeat the steps 'N' times. Or, assuming you could somehow escalate your VM kernel exploit to a higher level hypervisor exploit and get to the top.

That's not usually the case, though.

With containers, you get the kernel exploit, and you're in, for the most part.

Re: Kata Containers – The speed of containers, the security of VMs

#68
post #59

Earlier quoted context omitted.

But, AFAIK, LXD and RKt are similar to Docker as a container runtime though. They all share the host kernel, and if one container is hosed/tainted, your host kernel becomes the attack vector. If I read correctly, hypercontainer/kata containers lets you bring your own kernel for your containers and isolates it from the host using intel hardware features(same ones that KVM leverages). That's where it gets interesting t…

Kata Containers uses KVM; QEMU, which is the userspace KVM client, is configured so that it looks like you are running on a container. However, what you get is indeed a virtual machine. It is simply impossible for "real" containers to provide the same isolation as virtual machine, simply because the attack surface is that of the shared kernel; a hypervisor presents a much more constrained interface to a VM than the f…

Silly question: if the KVM is using para-virtualized drivers and there is a vulnerability in same, then the host kernel would still be vulnerable?

Re: Kata Containers – The speed of containers, the security of VMs

#69
post #68
post #59

Earlier quoted context omitted.

Kata Containers uses KVM; QEMU, which is the userspace KVM client, is configured so that it looks like you are running on a container. However, what you get is indeed a virtual machine. It is simply impossible for "real" containers to provide the same isolation as virtual machine, simply because the attack surface is that of the shared kernel; a hypervisor presents a much more constrained interface to a VM than the f…

Silly question: if the KVM is using para-virtualized drivers and there is a vulnerability in same, then the host kernel would still be vulnerable?

Many of KVM's paravirtualized drivers run in QEMU, and in turn that is usually running heavily confined, for example using SELinux.

So it's true that, as in the famous Theo de Raadt rant, virtualization overall adds to the attack surface compared to containers. But it would also be stupid to ignore that it also introduces very important bottlenecks: to get to the hypervisor, you have to break KVM which is only ~60000 lines of code; getting remote code execution in QEMU might be easier, but then you also have to break the host kernel from a process that has access to almost nothing on the system.

There is also vhost, which is implementing PV drivers in the host kernel. This however is also a small amount of code, and it is generally used only for networking and AF_VSOCK sockets.

Re: Kata Containers – The speed of containers, the security of VMs

#70
post #63
post #44

Earlier quoted context omitted.

I am not tracking closely to be honest since I have not being working with Illumos based distros for 5 years +/- when we were using omniOS I do not remember things being too bad. Not sure what % of vuln. are Oracle Solaris specific given that majority of orig. SUN eng. left long time ago Illumos might be in much better shape vs Solaris.

http://www.zerodayinitiative.com/advisories/ZDI-16-168/ http://www.zerodayinitiative.com/advisories/ZDI-16-274/ These were both in Illumos found by the person you are replying to.

Good point does not look too horrible as far as track record though :) less than number of docker vuln. and about the same as vmware which is an actual vm
Post reply on HN