Comment by sarnowski | Hacker News Reader

Comment by sarnowski | Hacker News Reader

Parent Full thread

Containers are just advanced chroots. They do the same with the network interface, process list and your local user list as chroot is doing with your filesystem. In addition, containers often throttle resource consumption of CPU, memory, block I/O and network I/O of the running application to have some QoS for other colocated applications in the same machine.

It is the spot between chroot and VM. Looks like a VM from the inside, provides some degree of resource usage QoS and does not require you to run a full operating system like a VM.

Another concept that is now also often automatically connected to containers is the distribution mechanism that Docker brought. While provisioning is an orthogonal topic to runtime, it is nice that these two operational topics are solved at the same time in a convinient way.

rkt did some nice work to allow you to choose the runtime isolation level while sticking to the same provisioning mechanism:

https://coreos.com/rkt/docs/latest/devel/architecture.html#s...

Unfortunately containers provide about the same security as chroots too. Nothing even close to a true virtual machine with not much lower cost.

Seccomp, apparmor, and namespacing (especially user!) do add a lot more security than plain old chroots, but still not at the level of a VM.

But couldn't containers have been designed that way? One thing I have in mind is one of windows 10 recent features, which consist in running certain applications using the same hardware level memory protection mechanism than VMs, so that the application is safe from the OS/Kernel, and the OS/Kernel is safe from the application (can't find the exact name for this new feature unfortunately).

Containers can't be designed that way as long as the primitives to build them that way (which are mostly part of the Linux kernel) are missing. That's a core part of the article. Containers aren't an entity by themselves, they're a clever and useful combination of an existing set of capabilities.

You can design all you like, but implementation takes work.

Seccomp only landed for Docker in about 1.12

It is like that... but in Zones or Jails, not in Linux "container toolkit"

No, the Windows 10 feature he's talking about uses Hyper-V internally. It's called, unsurprisingly, Hyper-V containers: https://docs.microsoft.com/en-us/virtualization/windowsconta...

Actually I found it. It's called Windows 10 Virtual Secure mode

https://channel9.msdn.com/Blogs/Seth-Juarez/Windows-10-Virtu...

(or Windows 10 isolated user mode, which seems kind of similar)

https://channel9.msdn.com/Blogs/Seth-Juarez/Mitigating-Crede...

Oh yeah that's another use of Hyper-V, somewhat similar to ARM TrustZone. It's used to implement "Credential Guard".

Chroot does not provide security, just a restricted view on the file system. Container can provide pretty ok security, but fail with Kernel Exploits. VMs provide better security, but also fail with VM exploits (which there are quite regularly some).

Actually many of the VM exploits are related to qemu device emulation or paravirtualization drivers, which are closed by the use of Xen stubdom. Only very few were privilege escalation via another vector, both in kvm and in Xen. I have no idea about other hypervisors.

And in turn most QEMU vulnerabilities are closed by SELinux of your distribution enables it. Libvirt (and thus the virt-manager GUI) automatically confine each QEMU process so that it can only access the resources for that particular VM.

in Linux...

as the article shows, this is not the point for Zones and Jails.

Is there any fundamental difference between containers and shared-kernel virtualization (OpenVZ) that I am missing?

OpenVZ was an early container implementation that required patches to the Linux kernel that never made it into mainline. Parallels acquired the company behind OpenVZ, Virtuozzo, and then worked to mainline much of the functionality into what are now Linux namespaces.

Oh really? I didn't know that namespaces is linux are the openvz changes. Thought they were a completely new implementation mostly driven by Google?

They aren't, but share some similarities. OpenVZ can be considered an inspiration for LXC. (Which was mostly implemented by RedHat and not Google.)

Correction. The LXC project was mainly Daniel Lezcano and Serge Hallyn from IBM. Then some cgroup support from Google. And then Canonical hired Serge Hallyn and Stephane Graber to continue work on LXC around 2009 where they have continued to develop it till today. Docker based off LXC in 2013.

Very helpful. Thanks.

Reply on news.ycombinator.com