Hacker News Reader

Comment by bjt | Hacker News Reader

From http://www.ubuntu.com/cloud/tools/lxd:

> And it’s going to be a real hypervisor? > Yes. We’re working with silicon companies to ensure hardware-assisted security and isolation for these containers, just like virtual machines today. We’re working to ensure that the kernel security cross-section for individual containers can be tightened up for each specific workload. We’ll make sure you can live-migrate these containers from machine to machine. And we’re adding the ability to bind storage and network interfaces to the containers, just like virtual machines.

Maybe that's not the specific meaning that you had in mind, but they're definitely going beyond a plain old LXC container.

View on HN

"Working with silicon companies to ensure hardware-assisted security" doesn't mean that much though. A MMU is already hardware-assisted security.

https://linuxcontainers.org/lxd/introduction/ says "unprivileged containers" as the leading security feature.

Googling for that, there's more info at https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-con...

What do you possibly gain by introducing VT-* features into your container product?

I would imagine you would get better security and performance isolation

At the cost of whatever bugs/vulnerabilities exist in the VT-* implementation on the silicon

At the moment, the container host exposes any kernel vulnerability to the container guests; that's a large enough attack surface that the advice I've most frequently come across is "Run your customer's containers in a VM so they can't attack your host". That's obviously less than ideal, so if VT-* can add a layer of isolation such that I don't need a VM layer in the infrastructure, it's worth it.

So you're not longer sharing a kernel with the host?

The VM doesn't share a kernel with the host, no. Without knowing exactly what virtualisation knobs Canonical are planning on adding here, it's difficult to say how much isolation is on the table.

Isolation. uid 0 is treated specially, and root breakouts inside containers (especially containers which aren't constrained by the audit subsystem in some way, like grsec or selinux or apparmor) or kernel exploits can bust your whole system open, among other security risks with containers.

hypervisor breakouts exist, but they're much rarer.

Reply on news.ycombinator.com