Slashdot Mirror
Containers or Virtual Machines: Which is More Secure? (zdnet.com)
Are virtual machines (VM) more secure than containers? You may think you know the answer, but IBM Research has found containers can be as secure, or more secure, than VMs. From a report: James Bottomley, an IBM Research Distinguished Engineer and top Linux kernel developer, writes: "One of the biggest problems with the current debate about Container vs Hypervisor security is that no-one has actually developed a way of measuring security, so the debate is all in qualitative terms (hypervisors 'feel' more secure than containers because of the interface breadth) but no-one actually has done a quantitative comparison." To meet this need, Bottomley created Horizontal Attack Profile (HAP), designed to describe system security in a way that it can be objectively measured. Bottomley has discovered that "a Docker container with a well crafted seccomp profile (which blocks unexpected system calls) provides roughly equivalent security to a hypervisor."
No jails?
should we be surprised?
Btw almost no one maintains good seccomp profiles, it is too cumbersome.
VMs give you better out of the box security than out of the box containers, and he probably knows it.
"a Docker container with a well crafted seccomp profile (which blocks unexpected system calls) provides roughly equivalent security to a hypervisor."
Hypervisor it is, then!
Seriously - if your security depends on something being "well crafted", you might as well have no security - because eventually, it won't be "well crafted" - somebody will screw it up.
Answer: Neither. Intels CPU bugs have made it possible to break both.
Because this article is talking about things people use
than virtual machines. Why is this even a question?
Because most people dumped Solaris more than a decade ago?
Exactly. An ideal container, perfectly configured and perfectly implemented, with a more-secure but less- convenient settings, would be -
Well it would be non-existent, because shit ain't perfect. If things in the real world were perfect, security wouldn't be much of an issue.
I'll have hard data in real-world containers and VMs next month. My company (Alert Logic) just released a suite of security services for containers so we will be able to tell exactly how often, and in which ways, our customers actual containers are breached, and what vulnerabilities they actually have. I can cross-reference that data with VMs in my database.
Based on decades of experience, I expect the data will show that VMs are more secure. I also expect the data will show that what you put IN the container or VM is far more important than whether you put it in a VM or container. Stupid in a VM is stupid, stupid in a container is stupid. Containers can use less RAM, though.
Someone mentioned chroot, which is the basic system call behind containers. Chroot is not a security tool. Chroot was not designed for security. Chroot does not provide security of any kind. Leaving chroot is as simple as chrooting again:
mkdir foo; chroot foo; cd ..
Chroot is useful for cross-compiling and certain other tasks related to developing software. It was created for the purpose of compiling and testing BSD4.2 before it was ready for release. Bill's machine ran 4.1, he could switch to 4.2 versions of the files by running chroot. (And could go back to the 4.1 system by simply running chroot again)
Systems such as containers, pledge, seccomp, jails, systrace variants, chroot etc. are all about restricting what otherwise would have been a process's ambient authority by plugging holes here and there until you can't find any more holes to plug. The problem is the holes that you don't find.
Another approach is to do the opposite: start with the process having no authority and give it only explicit access to the specific interfaces of the specific objects it needs to do its job --- and nothing more.
That is called Capability-based security and is IMHO the only fail-safe way to sandbox processes.
Some of Unix's predecessors had capabilities, some even with special CPU support so that it did not hav emore overhead than shifting pointers, but it was one of those many things that were not included when the original Unix was written to work on off-the-shelf hardware.
In recent years, a capabilities model has been added to BSDs and Linux in the form of the Capsicum project.
The other day, I stumbled over the CloudABI system, which is a runtime environment that uses Capsicum for applications on cloud servers.
With CloudABI your applications would be sandboxed just as safely as if they ran on virtual machines but without the overhead.
The big drawback is that programs need to be rewritten for it. The idea is though that when rewriting a program for CloudABI you should mostly just have to change things to make it compile and run. This would entail quite a bit of gruntwork but it should be pretty much straightforward and therefore less error-prone than to tweak security policies for something like seccomp or SELinux.
And BTW, chroot was never intended to be used for sandboxing.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
You're worried that hackers can get to one VM, but it's important that the other VM is super-secure, yet you don't run them on different hardware? Pretty odd.
Socialism: a lie told by totalitarians and believed by fools.
Try it. Copy and paste the commands. If you look, especially at old systems, you'll notice the code for chroot looks an awful lot like the code for cd. There's a reason for that.
Cd changes which directory the "." alias points to, chroot changes which directory the "/" points to. Just as you can cd to change ".", then cd again to change it again, chroot works the same way. It's just about as "secure" as cd, because it's almost the same code.