Is it possible to have the same degree of security with a container as is provided by a virtual machine?
http://wiki.smartos.org/display/DOC/Tuning+the+IO+Throttle
http://dtrace.org/blogs/brendan/2012/12/19/the-use-method-sm...
In a VM, you don't share a kernel with other users, so the local root exploit doesn't buy you anything.
I prefer containers and think VMs are a huge hack for most problems. But as it stands now, the number of local root exploits vs say remote exploits on Linux is probably greater by a factor of 100 or so, so you're taking much more risk.
Security is one of the problems with Linux containers that still needs to be resolved. (see http://mattoncloud.org/2012/07/16/are-lxc-containers-enough/, Google "lxc security")
Isolation strategies involving syscall filtering and mandatory access control (MAC) tools like selinux dramatically reduce the attack surface. For example, I know several recent root exploits were not possible to run on Fedora with selinux enabled.
People also discover hypervisor exploits at a reliable clip, too. Virtualization isn't a panacea of security isolation.
AFAIK you have to add SELinux yourself, and all the PaaS providers are probably doing something custom (or not). The newer thing seems to be seccomp filters (http://lwn.net/Articles/494252/), which are motivated by ChromeOS. I would like to see a comparison; from what I can tell seccomp is a lot simpler conceptually, although there are fewer user space tools for it.
The article didn't actually say "LXC" but it seems to be what most PaaS providers are using. When I tried LXC, while lighter than VMs, it also seemed too heavy, because you end up with 5 or 6 processes (starting with an "init") for every process you want to run. Using just raw namespaces and cgroups seems to be feasible although again there are few tools to do that. Apparently systemd has support, although I don't use any distros with it.
Docker is also a new thing, but I think it is just on top of LXC, so it is only as secure as your distro's LXC is.
From what I understand is that ZFS was so slowly ported to Linux due to the license problems. But why were Zones not quickly adapted?
Basically I think it is a consequence of containers/sandboxing being a very "commercial" technology, even though they are open source. The main users are hosting providers, and there's a significant amount of money in that business.
In the 90's there was a hosting "land rush" with all of these companies like 1and1 and dreamhost selling shared hosting on Linux. They were the ones that developed Linux VServer and OpenVZ apparently, and I think the pace was too great to get it into the mainline. Interested in any first-hand knowledge people have.
And in the 2010's there is a PaaS "land rush", with all of these companies building on AWS and other IaaS, while needing containerization like LXC. The OP's article is calling for increased support in distros -- I think the same lack of time for cooperation is happening. Heroku, Cloud Foundry, dot Cloud, ActiveState, etc. are all using the same thing essentially, but there's a big land grab, so they are all maintaining proprietary and complex user space configuration.
The kernel features like the various namespaces are just about finished trickling in I think; that doesn't mean they're secure though.
Yeah, but if you can run services in containers that don't need root access, you know have to exploit the services, find a privilege escalation exploit, and then run your local root exploit. If you don't give out root access in your containers, you can get the advantages of containers while minimizing the downsides.