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
Where exactly does it say, "or more secure" Mr. Editor?
Not knocking article itself arguing the potential gains in container security possibly on-par with virtualization, but the extra crap step of modern Slashdot editors.
than virtual machines. Why is this even a question?
Because most people dumped Solaris more than a decade ago?
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.
More to the point, a container running on a VM is quite obviously less secure than directly running on the VM. If you're running on someone else's hardware (cloud etc), then your choices are VM or container-in-a-VM, so that's pretty obvious. If you're running on your own hardware, then it's a pretty odd security concern to be very worried about either breach.
Socialism: a lie told by totalitarians and believed by fools.
Yeah, what does IBM know about VMs? They've only had VM products for about 50 years.
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
is that they are HUGE, ..! A big maintenance effort, more lingering bugs, bigger attach surface, plenty of possibilities to hide nasty things. Containers are a much smaller thing to take a look in and review, keep updated etc.
Or how about a virtual machine hypervisor running within a Solaris zone? Because this is what SmartOS does for its hypervisor.
The notion of self-secure system stinks of utopia. First of all, security of complex system is not a static state it's a dynamic state of an eternal sword and shield fight
I do not believe in karma. "Funny"=-6. Do good and forbid evil. Yours, Oft-Offtopic Flamebaiting Troll.
The approach described is pure theory, with bold assumptions such as uniform bug density. I am not sure the model can predict anything, and I am not even sure it fits existing experimental data.
It is almost as useless as dark matter in cosmological models.
Surprised nobody has made this point yet.
A VM can be set to run as a part of a VLAN, giving you a little extra bit of security.
Not entirely. I still run across the odd solaris 7/8/9 system from time to time. I still run one myself. You don't fuck with what isn't broken; there hasn't been a need to replace it, although it has been discussed. (maybe should based entirely on the power bill)
(I have several systems standing by for testing and troubleshooting whatever might come across my desk. But they aren't actually on.)
but still, are lacking in the security department.
VMs in theory should be more secure, but in practice, Hypervisors are such huge behemoths that there are always security holes in the hypervisor.
In reality, discussing the relative security between containers and VMs is like discussing how many angels can dance in the head of a pin, a futile excersice.
the relative security will ebb and flow, some times in favour of VMs, sometimes in favour of Containers.
But in the end, it will not matter, as we all will end up running our containers inside VMs, sacrificing some of the performance gains of containers for the HUUUGE sysadmin advantages of VMs.
*** Suerte a todos y Feliz dia!
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.
Not entirely.
Not entirely what? Re-read my post. I didn't say everyone dumped Solaris, but Solaris was relegated to niche status by most people long ago. There's a good reason Sun made OpenSolaris 13 years ago and it wasn't because they had tons of paying customers.
"Not entirely" as in [in my experience] many former solaris shops still have bits of solaris remaining. It wasn't "dumped", but incrementally replaced over the years. (solaris 10 was the real kick-in-the-ass to start moving... SMF, the systemD of the Solaris world.)
OpenSolaris was as much a marketing ploy as it was a means to remain relevant -- "Open Source" being the trendy new buzz word / business model. You could already get solaris for free -- for "non-commercial" use. (surprisingly, even under the infinite greed of Oracle, solaris is still available for free.) Sun was the only source for sparc hardware to run the OS, so they already had your money. (solaris/x86 never had much of a software market)
(Sure, anyone running x86 hardware is far better off moving to linux or even windows. The few solaris/x86 installs I knew were moved to linux and windows.)
Containers and VMs are not really security tech. Nobody in their right mind would call using a dedicated machine a "security technology", VMs and Containers are not either. They serve to partition a machine and, to a limited degree, they can achieve that. But as soon as somebody breaks into a container or a VM, they can usually do what they want anyways, just the same as with a dedicated system: Send spam, hack other machines using the identity of the container of VM, steal local data, etc.
What both containers and VMs give you is _less_ security compared to a dedicated machine, since in addition to all the normal security problems, you also get possible attacks on the isolation layer and on other containers or VMs running on the same hardware. That means overall, you are _less_ secure.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Also, unless there are bugs in the software using the hardware, which there is
"First they came for the slanderers and i said nothing."
I will argue that in this case, there is a simple answer: both are insecure.
"First they came for the slanderers and i said nothing."
Security, at least when done above amateur-level, is not black and white.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.